# Robot Safety Scanners: Design Assumptions and Verification Evidence - Canonical: https://pearlgateway.net/docs/robot-safety-scanners-design-assumptions-and-verification-evidence/ - Updated: 2026-09-11T00:59:00+00:00 A robot safety scanner is often treated as a digital switch: a component that is either in a safe state or not. In practice, it is a continuous measurement system operating under a set of physical and environmental assumptions that can change without visible warning. When an autonomous mobile robot (AMR) stops unexpectedly in an empty aisle, or when a test target at the edge of a protective field does not produce the expected trip, the cause is usually not a failed component but a violated assumption. This article explains those design assumptions, describes the evidence that should be collected during field verification, and separates meaningful test results from misleading ones. It is written for warehouse operators, maintenance engineers, and controls teams that need to diagnose scanner behaviour without relying on vendor folklore. Site procedures, lockout requirements, OEM documentation, and competent engineering judgment always take priority over the generic guidance presented here. ## The Role of the Safety Scanner in an AMR Fleet The safety scanner is one input to a larger safety-relevant control chain. On a typical AMR, the scanner monitors a two-dimensional plane around the robot, distinguishes between protective and warning field zones, and communicates status to a safety controller or safety-rated relay. That controller ultimately commands motor power, braking, and sometimes steering. The scanner is not the safety function by itself; it is the sensing element in a system that also includes cabling, connectors, controller logic, contactors, brake actuators, and the mechanical ability of the robot to stop within an acceptable distance. Because the scanner is mounted on a moving vehicle, its verification differs from that of a stationary machine guard. The vehicle moves across changing floor surfaces, passes through doorways with changing light, carries different payloads, and suffers mechanical wear in its suspension and wheels. The scanner’s protective field is defined relative to the robot’s frame, but the world around the robot is not static. Fleet traffic, staging of pallets, shrink wrap hanging from loads, and reflective floor markings all enter and leave the field as the robot travels. Verification evidence therefore has to include both the scanner’s internal state and the external conditions at the time of testing. Another important interaction is with the robot’s navigation and localization systems. The navigation lidar and the safety scanner are often confused with each other during troubleshooting. Navigation lidar is not safety-rated and may continue to map reflections from glass or shiny surfaces, while the safety scanner reacts to the same surface differently because of its own evaluation criteria. A technician who treats the two as interchangeable will collect misleading evidence. The verification process should explicitly identify which sensor is reporting the event and which field zone was triggered. ## Design Assumptions Embedded in Scanner Placement Every safety scanner installation is engineered around a small set of assumptions. They are rarely written on the robot itself, but their violation explains most field problems. **Assumption: the floor is the reference plane.** The protective field is configured as a polygon at a specific height above the mounting surface. That configuration assumes a flat, consistent floor plane. In a real warehouse, floors have epoxy patches, expansion joints, dock leveller transitions, and gradual slopes that change the effective height and angle of the field. A robot that drives over a 10 millimetre bump can tilt the scanner by a fraction of a degree, which is enough to shift the field boundary by several centimetres at the far edge. Verification evidence must therefore include a record of floor condition along the test path, not just a statement that the robot sat on a level workshop floor. **Assumption: target reflectivity lies within a defined range.** The scanner determines distance from the time or phase of a reflected laser pulse. To do this reliably, it assumes that surfaces inside the field reflect enough light to be detected but not so much that they appear closer than they are. Dark shrink wrap, black rubber curtains, and matte painted steel can absorb sufficient light that the scanner simply sees no object. Highly reflective surfaces such as polished concrete, wet floors, pallet strapping, or retroreflective tape can produce false echoes or apparent field intrusions. The scanner is designed to tolerate some variation, but not unlimited variation. Test evidence based on a piece of cardboard from the receiving bay does not represent the reflectivity range of the actual environment. **Assumption: response time plus stopping distance stays inside the protective field.** The scanner has a rated response time from the moment an object enters the field to the moment the safety output changes state. The robot control system then has a finite time to remove motive power and apply brakes. The combination of these delays, multiplied by current travel speed, must be shorter than the distance from the field boundary to the robot’s physical body. This assumption depends on wheel traction, brake wear, payload mass, and battery voltage. A verification test that only confirms the scanner trips is incomplete; the evidence must also confirm that the complete robot stops before contact with the test target. **Assumption: mounting geometry remains stable.** The scanner mounting bracket, its fasteners, and the robot chassis are assumed to be rigid. A minor collision with a rack or a repeated vibration from bad floor joints can bend a bracket by a few degrees without leaving an obvious mark. This changes the elevation angle of the scan plane. The scanner may still produce a clean output, but the protective field may be pointing too high to detect a person lying on the floor or too low to detect objects protruding from a pallet. Verification should periodically include measurement of the scanner’s mounting height and tilt against the robot’s documented baseline. ## What the Scanner Actually Measures vs. What We Infer A scanner emits laser pulses at discrete angular steps and measures the distance to the first surface that returns enough signal. Internally, the device maintains a set of distance readings for each angle. Software then classifies those readings as inside or outside the configured zones, applies filtering and hysteresis, and decides whether the output should be in the run state or the stop state. The inferential leap happens when a technician interprets a trip as “the scanner saw a person.” More accurately, the scanner saw a surface with sufficient reflectivity at a distance within the zone. The surface could be a person, but it could also be a plastic curtain moving in air conditioning draft, a pallet strap hanging below its load, a reflection from a glossy floor, or the laser bouncing off a nearby robot. Conversely, a person wearing matte dark clothing could be invisible to the scanner until their body moves close enough that the angle of incidence changes and more light returns. Verification evidence should therefore focus on the scanner’s raw behaviour, not on the narrative we attribute to it. Useful questions include: Which angular sector produced the trip? Was the distance reading stable or flickering? Did the scanner report reduced measurement quality before the trip? Many modern scanners can output diagnostic counters for invalid measurements, contamination level, and reflectivity. When those values are available through the robot’s diagnostic interface, they should be recorded during every verification run. A scanner with a dirty window, for example, might produce progressively more invalid readings before finally tripping on a completely empty aisle. ## Symptoms That Point to Scanner Verification Problems The following symptoms are commonly misattributed to software bugs or intermittent hardware faults. In most cases, they are verification problems created by the difference between design assumptions and site conditions. - Intermittent stops in an aisle that appears completely empty at the time of the event. - Stops that occur at consistent map positions, even when those positions look harmless. - Trips that happen only in the morning or afternoon, suggesting that sunlight through a dock door is entering the field. - Failures to trip during acceptance testing using a moving test target, especially at the far edge of the protective field. - A gradual increase in stopping distance despite no change to the robot’s speed settings. - Trips that occur only when the robot is moving in one direction along a corridor, not the reverse direction. - Test passes on a clean workshop floor but unexplained trips on the actual warehouse floor. The table below maps these symptoms to likely design assumption violations and the evidence that should be captured during diagnosis. It is intended as a decision aid, not as a substitute for an approved verification procedure. Symptom | Design Assumption at Risk | First Evidence to Capture | Escalate If Intermittent stops in an empty aisle | Reference plane or scanning window cleanliness | Event log timestamps correlated with robot position; floor profile measurement; scanner contamination counter | Trips persist after cleaning and with no measurable floor deviation Test target does not cause a trip | Target reflectivity assumption | Retest with a target matching the manufacturer’s documented test target characteristics; record distance and angle | Failure occurs even with a compliant target at the protective field boundary Trips only near bright doorways | Environmental lighting and reflective surfaces | Record time of day, weather, door position, and any bright surfaces inside the field | No lighting condition consistently reproduces the trip Stopping distance is too long at working speed | Response ## Related Pearl Gateway Guides - [Piece-Picking Robots: Commissioning and Acceptance Checklist](/docs/piece-picking-robots-commissioning-and-acceptance-checklist/) - [Mobile Robot Charging Stations: Commissioning and Acceptance Checklist](/docs/mobile-robot-charging-stations-commissioning-and-acceptance-checklist/) - [Fleet Traffic Management: Commissioning and Acceptance Checklist](/docs/fleet-traffic-management-commissioning-and-acceptance-checklist/) ## Site-Specific Review Worksheet This educational worksheet supports a structured review of robot safety scanners: design assumptions and verification evidence. Begin by identifying the equipment boundary, control ownership, operating modes, material characteristics, upstream dependencies and downstream consequences. Record what the system is expected to do, what was actually observed and which evidence is time-aligned. Avoid changing several variables at once, because simultaneous changes make cause and effect difficult to establish. ### Evidence to collect - Operating mode, active mission or route, and the exact sequence state. - Alarm history, device state changes and controller timestamps. - Physical observations such as alignment, contamination, wear, obstruction and load condition. - Recent maintenance, software changes, parameter changes and recurring work orders. - Upstream and downstream readiness, including blocked, starved and unavailable conditions. ### Decision boundaries Use approved site procedures and competent engineering judgment before intervention. General information in the Robotics, AMRs & Automated Handling library cannot determine whether a specific machine is safe to enter, restart or modify. Preserve original settings, document authorized adjustments and establish a rollback point before controlled testing. When evidence conflicts, stop and resolve the timestamp, naming or measurement discrepancy before drawing a conclusion. ### Closeout record A useful closeout record states the symptom, confirmed cause, evidence, corrective action, validation method, residual risk and follow-up owner. It should also identify whether the event exposed a design weakness, maintenance gap, training issue, spare-parts issue or monitoring blind spot. This turns a single recovery into reusable reliability knowledge without treating one observation as universal. ## Evidence Matrix for Operational Review Evidence group \| Questions to answer \| Why it matters Sequence state \| What mode, step, mission and interlock state were active? \| Separates a physical problem from an expected control hold. Material condition \| Were load dimensions, orientation, stability and spacing within the intended envelope? \| Explains faults that appear random when only controller data is reviewed. Device evidence \| Which inputs changed, in what order, and against which timestamp? \| Supports repeatable diagnosis instead of component substitution by guesswork. Change history \| What maintenance, configuration, software or process change preceded the symptom? \| Helps define a useful comparison window and rollback boundary. For robot safety scanners: design assumptions and verification evidence, the matrix should be completed with evidence from the same event window. Mixing observations from unrelated shifts can create a convincing but false causal story. If timestamps are inconsistent, establish which controller, server or operator record is authoritative before comparing event order. Trend evidence is more useful when the measurement definition remains stable. Record units, sampling interval, filtering, equipment mode and product family. A rising fault count may reflect increased throughput rather than deteriorating equipment, while a stable count can hide deterioration if production volume has fallen. ## Implementation and Governance Questions Before changing a maintenance task, control parameter or operating method related to robot safety scanners: design assumptions and verification evidence, define ownership and approval boundaries. Identify who can authorize the change, who validates it, how the previous state will be restored and which operating conditions must be represented during the test. - Is the observed condition repeatable, and has the equipment boundary been stated clearly? - Are mechanical, electrical, controls, software and process explanations being considered independently? - Does the proposed action alter a safety function, protected access rule, alarm priority or recovery sequence? - Can the result be measured with an agreed baseline rather than operator impression alone? - Will the change remain valid across product sizes, routes, modes, shifts and degraded conditions? - Is there a documented rollback point and a named owner for follow-up observation? Temporary workarounds should be visible in shift handover and maintenance records. An undocumented workaround can become the new normal and obscure the original defect. Closeout should distinguish containment, corrective action and systemic prevention so later teams do not assume that a restarted system has been permanently repaired. This governance context is especially important in robotics, amrs & automated handling, where local changes can affect upstream release logic, downstream capacity, inventory state or recovery behavior outside the immediate machine boundary.