Safety-Rated Sensing vs Navigation Perception in AMRs An Evidence Audit

Executive verdict: An AMR that can see, classify, map, and avoid an object is not automatically performing a safety function. A perception capability becomes creditable risk reduction only when the hazardous event, required response, sensing boundary, control path, integrity target, failure behavior, operating limits, and validation evidence are all defined as one traceable claim. This distinction is the line between useful autonomy and defensible functional safety.

That line is becoming harder to see. Modern mobile robots may use the same laser scanner for protective-field monitoring and localization, combine several cameras and LiDARs in a common perception computer, or advertise artificial intelligence that recognizes people, forklifts, pallets, and floor debris. These capabilities can improve availability and reduce nuisance stops. Yet a high-performing perception stack may remain outside the safety-related control system, while a comparatively simple protective device may be the only channel credited with initiating a protective stop.

This article is a claim audit, not another sensor comparison. The existing guides to mobile robot sensor selection, safety laser scanner selection, and dynamic obstacle avoidance explain what sensors do and how navigation reacts. Here, the question is narrower and more demanding: which part of that capability may be cited in a risk assessment, and what evidence must survive an engineering review?

The Claim Under Audit: “Our AMR Sees People”

“The robot sees people” sounds precise, but it is not a safety requirement. It does not identify which people-related hazardous event is controlled, the smallest or least detectable body feature, the approach direction, the robot mode, the load configuration, the environmental conditions, the maximum detection latency, the required safe state, or the probability that a dangerous failure will remain undetected. It also says nothing about what happens after detection. A bounding box on a video stream is not a stop command, and a stop command is not proof that the loaded vehicle stops before contact.

Buyers searching for AMR safety-rated sensors should therefore resist making “safety-rated” a property of a shopping list. The useful unit of analysis is the safety function. A function might be written as: when a person-sized test object enters the active protective field during automatic travel, the safety-related control system shall initiate the defined stop response and prevent hazardous motion before the separation distance is consumed, under the stated speed, direction, payload, floor, environmental, and fault conditions. That statement can be decomposed, tested, and traced. “The AMR has two LiDARs” cannot.

Three questions expose an unsupported claim

1. What risk-reduction function is claimed? Name the hazard, exposed person or asset, operating mode, triggering condition, commanded response, safe state, and required integrity. If those items are missing, the team is discussing a feature rather than a safety requirement.
2. Which exact signal path performs it? Trace the path from emitted energy or captured image through detection, evaluation, communication, safety logic, field selection, motion control, brake or torque removal, and fault response. Mark every non-safety component and every shared dependency.
3. What evidence supports every boundary? Device declarations, architecture calculations, software lifecycle records, configuration checksums, response-time measurements, environmental tests, stopping trials, fault-injection results, and site acceptance records must match the installed baseline—not a generic product family.

A claim that cannot answer all three questions may still describe a commercially valuable capability. It simply should not be credited as personnel risk reduction until the missing boundaries and evidence are supplied.

The Evidence Boundary Map

Comparison searches such as safety LiDAR vs navigation LiDAR often imply that wavelength, scan rate, range, or point density decides the issue. Those specifications matter to detection performance, but the decisive difference is the evaluated function and its evidence envelope. “LiDAR” describes a measurement technology. It does not, by itself, describe a safety architecture.

The term AMR navigation perception belongs primarily to the first column’s productivity claims: localization, mapping, free-space estimation, object recognition, trajectory prediction, and route planning. These functions can prevent many encounters and make motion smoother. Their contribution should be documented, but accident avoidance in normal operation is not the same claim as reliable risk reduction in the presence of faults.

One Physical Scanner Can Feed Two Evidence Worlds

The cleanest demonstration of the boundary is a safety laser scanner that has both safety outputs and raw distance-data interfaces. A manufacturer may allow its range data to be consumed by a navigation computer for localization or SLAM while its evaluated protective-field function sends safety outputs to a safety controller. Physically, both streams originate in one enclosure. Logically and evidentially, they can be different products.

Pilz, for example, documents PSENscan distance data for localization and navigation through open interfaces, while also describing the scanner, safe controller, encoder evaluation, and dynamic protected-field switching as a safety solution. IEC 61496-1 makes the boundary unusually explicit: the standard addresses electro-sensitive protective equipment used to protect people and does not address functions unrelated to personnel protection, including use of sensing-unit data for navigation. The important lesson is not about one brand. It is that certification of a defined protective function does not automatically certify every data output, API, ROS node, map, or algorithm fed by the same optics.

Label every output by its claim

• Safety output: a defined state or safe communication value generated under the device’s safety manual, connected and configured within the assessed safety function.
• Measurement output: range, remission, image, point-cloud, or object data made available for non-safety processing unless the documentation explicitly places that path within a safety-related scope.
• Diagnostic output: status information used for maintenance or availability. A useful diagnostic message is not automatically a safety signal.
• Configuration channel: the path that changes fields, parameters, firmware, or application sets. Its authorization, versioning, and transfer behavior can affect the safety baseline even when it carries no live detection data.

This is also why “dual use” must never become “shared evidence.” A navigation computer may use raw range data and continue to localize when a noncritical data point is missing. The safety path may instead require a protective stop when its diagnostic threshold is crossed. The two consumers can legitimately apply different filtering, timing, and fault reactions. Combining their test results into one blended reliability claim hides the very distinctions that a safety review needs.

What “Safety-Rated” Changes—and What It Does Not

Teams asking about safety-rated perception for AMRs should treat the phrase as a request for scope, not as a yes-or-no technology label. Safety-related perception is possible, including systems that use multiple sensor technologies, classification, or algorithms. IEC 62998 exists precisely because sensing people can extend beyond traditional electro-sensitive protective equipment. But the burden moves from a familiar certified device boundary toward a larger sensor-system and algorithm boundary. More capability generally creates more assumptions to control, not fewer.

A safety-rated claim must define the object and the context

Detection is not abstract. A claim has to identify the relevant safety-related object characteristics: size, position, reflectivity, clothing or material properties, speed, posture, occlusion, and relationship to the hazard. It must also define surroundings that influence detection: sunlight, artificial lighting, dust, condensation, rain, steam, floor reflectance, mirrors, glass, black surfaces, rack mesh, vibration, electromagnetic disturbance, and contamination. A sensor that performs well on upright pedestrians in a clean laboratory does not thereby cover a crouched technician partly hidden behind a cart in a dusty loading bay.

The function needs an integrity target

The risk assessment determines the required risk reduction and the corresponding target for the safety-related control function. ISO 13849-1 provides a design methodology for safety-related parts of control systems; it does not assign one universal performance level to every mobile-robot function. The target must therefore be justified for the specific hazard and then demonstrated across the relevant architecture. A scanner’s capability is only one input to that demonstration.

The total response chain matters

Detection time is not stopping time. The total chain can include scan acquisition, signal evaluation, communication, safety-controller processing, field-set confirmation, drive response, torque removal or controlled deceleration, brake build-up, mechanical travel, and uncertainty margins. If navigation software requests a gentle slowdown before the protective field is violated, that improves productivity. The safety calculation must still stand when the navigation request arrives late, freezes, or never arrives—unless that software and its entire path are explicitly part of the validated safety function.

Detection Accuracy Is Not Functional-Safety Integrity

A common proposal states that a camera model detects people with 99.7% accuracy and is therefore “safer” than a scanner. That is an invalid comparison until the metrics, populations, failure model, and required function are aligned. Dataset accuracy may average true and false decisions across a selected sample. Safety integrity addresses dangerous failure of a specified function over time and within an architecture, including random hardware failures, systematic faults, diagnostics, independence, and lifecycle controls.

Treat AMR obstacle detection safety as a layered assurance problem:

• Perception quality: precision, recall, localization error, tracking continuity, minimum detectable object, range, occlusion behavior, and confidence calibration.
• Functional behavior: correct response for each object, mode, speed, direction, load, and route condition.
• Fault behavior: response to frozen frames, stale timestamps, corrupted packets, dirty lenses, misalignment, compute overload, memory faults, power interruption, and invalid configuration.
• Safety integrity: whether the complete function meets the required architecture and quantitative or qualitative integrity criteria under its applicable standard.
• Application validation: whether the installed system actually realizes that function before the hazard is reached.

Machine-learning performance introduces additional questions. Was the test set independent of development? Does it represent the current operating domain? How are rare postures, reflective personal protective equipment, mobility aids, partial occlusion, unusual loads, and site lighting represented? What detects an out-of-distribution input? What happens when confidence falls? How are model weights, preprocessing, camera firmware, and training data versioned? Who authorizes a model update, and what revalidation follows?

None of these questions means that AI cannot contribute to a safety-related function. They mean that a leaderboard metric cannot be substituted for safety lifecycle evidence. A non-safety semantic camera can still add major value: it can recognize a forklift earlier, distinguish a pallet from free space, predict pedestrian movement, and help navigation avoid entering a conflict. The correct engineering description is “performance and exposure reduction with a separately validated protective layer,” unless the semantic path itself has been assessed for the claimed safety role.

Five Case Files That Reveal the Boundary

Case 1: A certified scanner supplies SLAM data

The vehicle uses a safety laser scanner’s protected fields to initiate a protective stop. The navigation computer simultaneously consumes raw distance data from that scanner over a standard interface for localization. The device may be suitable for both tasks, but the navigation path does not inherit the protective function’s certification. The audit should record two interfaces, two consumers, two timing assumptions, and two fault responses. If the raw stream freezes while the safety outputs remain healthy, navigation may enter a controlled degraded state. If the protective function reports a fault, the vehicle must follow the validated safe response even if the map remains visually perfect.

Case 2: An AI camera recognizes people beyond the scanner field

The camera can detect a pedestrian earlier than the protective scanner, so the navigation stack slows and replans. This is valuable because it reduces abrupt stops and the chance that the person ever enters the protective field. However, the early response cannot be subtracted from the required protective-field distance unless the camera, inference, timing, communication, control, and failure response form part of the credited safety function. The safe design treats early perception as a productivity layer and ensures that the protective stop remains sufficient at the maximum permitted speed.

Case 3: A 2D plane misses an overhanging load

The safety scanner’s plane detects legs but passes beneath a projecting load or above a low obstacle. A 3D navigation sensor sees the object and normally avoids it. This does not prove that the residual crushing or collision hazard is controlled. The risk assessment must decide whether personnel protection, object protection, load stability, or infrastructure protection requires additional sensing, physical guarding, route restrictions, reduced speed, clearance controls, or a safety-related sensor system with the necessary volumetric coverage. “The 3D camera usually sees it” is an operational observation, not a completed risk-reduction claim.

Case 4: Contamination affects the safety channel

Dust or condensation degrades a scanner window. A separate navigation LiDAR still localizes successfully, so the vehicle appears capable of moving. That is precisely when architecture must overrule appearance. If the safety channel’s diagnostics can no longer guarantee its declared detection capability, continued normal travel cannot be justified merely because another non-safety sensor reports free space. The defined response may be a stop, limited state, manual recovery, or another validated fallback, depending on the design. Maintenance status must not be confused with permission to move.

Case 5: Navigation localization fails while protection remains available

The reverse event is also important. Feature-poor aisles, map mismatch, or wheel slip may cause localization confidence to collapse while the protective fields remain healthy. A robot that no longer knows where it is should not continue its mission merely because it can stop for nearby people. The required behavior could be a controlled stop, limited manual recovery, or a validated relocalization routine. Safety sensing cannot repair mission-state uncertainty, just as navigation perception cannot replace protective integrity. Each channel needs its own degraded-state policy and a documented interaction rule.

Interfaces That Silently Break a Safety Claim

Most unsupported claims do not fail at the sensor brochure; they fail at an interface. A procurement team may correctly specify industrial mobile robot safety sensors and still create an uncreditable function by passing their information through an uncontrolled channel, selecting fields from a nonsafe speed estimate, or connecting a validated stop request to an unverified vehicle response.

Raw data versus safe state information

Point clouds, images, and object lists are rich but require interpretation. Safety outputs are intentionally constrained: field clear or interrupted, device healthy or faulted, valid field selected or not, safe speed condition met or violated. If raw data crosses a standard Ethernet or ROS interface, the safety case must not quietly assume safety communication properties that the interface does not provide. If the project intends to use those data in a safety function, it needs explicit measures for corruption, delay, repetition, loss, masquerade, sequence error, and unauthorized change.

Field selection and speed are coupled

A correctly sized field can become unsafe when the wrong field set is active. The chain therefore includes direction, speed, steering angle, payload geometry, encoder data, selection logic, and confirmation that the selected set corresponds to actual motion. The prior guide to protective-field engineering explains how measured stopping behavior drives field geometry. This audit adds a second condition: the mechanism choosing that geometry must have evidence commensurate with its safety role.

Time synchronization is a hidden dependency

Multi-sensor systems often align frames using timestamps. A camera image, LiDAR scan, encoder value, and pose estimate may describe different moments if clocks drift or queues grow. Navigation quality may decline gradually; a safety decision could become dangerously late. The requirements must define maximum age, maximum skew, buffer behavior, overload response, timeout, and recovery. A healthy network average does not cover a worst-case queue during CPU saturation.

“Stop” has several meanings

A navigation stop request, controlled deceleration, safety stop, emergency stop, safe torque off, brake engagement, and prevention of restart are not interchangeable. Each has different dynamics and intended use. The requirement must state what output is generated, which subsystem executes it, whether steering remains active, how stored energy is managed, and what conditions permit restart. Site tests must measure the resulting motion, not merely observe a bit changing on a diagnostic screen.

Sensor Fusion: Better Perception Does Not Automatically Mean Higher Integrity

Searches for safety laser scanner vs LiDAR invite a one-device answer, but many practical robots use overlapping modalities. Fusion can fill geometric blind spots, reduce nuisance stops, increase localization robustness, and classify complex scenes. The existing guide to mobile robot sensor fusion explains how those performance benefits arise. A safety audit asks a different set of questions.

First, is fusion merely advisory, or is its output credited with allowing hazardous motion? A non-safety camera may ask the robot to slow down earlier while a safety scanner retains final authority to stop. In that architecture, fusion improves availability but is not assigned the protective function’s integrity. If a fused output is used to suppress a stop, shrink a field, classify an object as harmless, or permit motion that would otherwise be inhibited, it has entered the safety argument and needs commensurate evidence.

Second, are the channels actually independent? Two sensors mounted on one bracket may share misalignment. Two algorithms on one computer may share power, clocks, memory, operating system, and overheating. LiDAR and camera can both be obscured by the same contamination. Two cameras trained on the same data can share systematic misclassification. Redundancy is not created by counting devices; it is established by analyzing common-cause and common-mode failures.

Third, what does disagreement mean? Majority voting sounds robust until one sensor is blind to the relevant object and two correlated channels agree incorrectly. A defensible design defines expected agreement, discrepancy thresholds, confidence handling, diagnostic coverage, safe reaction, and recovery. It also validates the combinations of environment and object characteristics that can defeat more than one channel.

The Four-Level Evidence Ladder

A rigorous AMR perception validation program separates four evidence levels. Keeping them distinct prevents a strong laboratory benchmark from being presented as proof of the complete application.

Level 1 evidence is essential, especially for novel perception. It is also the easiest evidence to overstate. A polished demonstration can show hundreds of successful detections while omitting the one scenario that defines the hazard. The audit should build tests from the safety requirement and operating envelope, not from convenient datasets. Worst-case combinations—maximum speed, degraded friction, heaviest approved load, most difficult target, adverse light, partial occlusion, system load, and allowed tolerances—deserve explicit coverage.

Level 3 must connect to the project’s AMR safety requirements specification. Every credited sensing response needs a requirement identifier, owner, version, test method, acceptance criterion, result, deviation status, and link to the installed configuration. Without that chain, evidence becomes a folder rather than an argument.

A Procurement Claim-Audit Worksheet

Procurement language often compresses several technical claims into one attractive phrase. The table below shows how to expand those phrases before a request for quotation, design review, or factory acceptance test.

The phrase AMR sensor safety function should appear in commercial documents as a structured requirement, not as a component feature. Buyers should request a supplier responsibility matrix that identifies who selects the required integrity, who integrates the safe control path, who measures stopping behavior, who validates the current operating environment, and who owns revalidation after change. Ambiguity at contract signature usually reappears as expensive ambiguity at site acceptance.

Lifecycle Drift Can Invalidate a Previously Valid Claim

A safety boundary is a versioned baseline. The installed claim can change when a sensor is moved by a few degrees, a replacement lens has different optical properties, a protective housing is added, firmware changes filtering, a camera model is revised, a new pallet overhangs the chassis, the maximum speed increases, tires wear, floor coating changes, or racks create new occlusions. A map update may be operational for navigation but safety-significant if it alters permitted routes, field switching locations, interaction zones, or speed profiles.

Separate routine maintenance from safety-significant change

Cleaning a window according to an approved procedure may preserve the baseline. Replacing the scanner with a supposedly equivalent model may not. Restoring a validated parameter file can be routine; manually recreating fields from a screenshot is a new configuration. Updating a non-safety object detector may seem unrelated to the protective system, but it can still affect risk if operating procedures, speed optimization, or route access were justified by that detector’s behavior.

ANSI/A3 R15.08-3-2026 is particularly relevant to this operating phase because it addresses users’ continued safe use of industrial mobile robot applications, emphasizing risk assessment, management of change, the current operating environment, and lifecycle responsibility. The lesson for perception is clear: validation is not a launch event. It is a controlled relationship between a configuration and an environment.

Define invalidation triggers before release

• sensor model, firmware, calibration, mount, cover, or field-set change;
• perception model, preprocessing, dataset, threshold, or compute-platform change;
• maximum speed, acceleration, braking parameter, tire, brake, payload, or center-of-gravity change;
• route, aisle width, crossing, workstation, rack, door, lighting, floor, or traffic-rule change;
• new evidence of a missed detection, unexpected stop, field mismatch, latency excursion, contamination, or near miss;
• change in task mode, recovery procedure, manual intervention, maintenance access, or commissioning method.

Each trigger should route to an impact analysis that decides whether documentation review, targeted regression, partial revalidation, or full revalidation is required. The detailed AMR deployment validation process should retain the resulting decision and evidence with the current system baseline.

Standards Map for the 2026 Review Baseline

The following map is a scope guide, not a substitute for purchasing and applying the standards relevant to a jurisdiction and machine. The current published editions and project applicability should be confirmed at the start of every assessment.

• ISO 3691-4:2023: safety requirements and verification for driverless industrial trucks and their systems, explicitly including vehicles commonly called AGVs and AMRs. ISO’s catalog currently also shows a next version under development, so projects should freeze the edition used and monitor revision impact.
• ISO 13849-1:2023: general principles for designing safety-related parts of control systems. It supports design of the complete safety-related control path; it does not assign one universal required performance level to every perception function.
• IEC 61496-1:2020: general requirements and tests for electro-sensitive protective equipment used for personnel protection. Its scope expressly separates protection functions from unrelated use of sensing-unit data for navigation.
• IEC 61496-3:2025: particular requirements for active opto-electronic protective devices responsive to diffuse reflection, the family that includes safety laser scanning applications. Application field dimensions and configuration still depend on the hazard and installation.
• IEC TS 62998-1:2019: safety-related sensors used for protecting people, including detection or classification, with attention to dependable detection and environmental influences.
• IEC TR 62998-2:2020 and IEC TS 62998-3:2023: application and fusion examples plus guidance on sensor technologies, safety-related object properties, interference, algorithms, integration, and validation.
• ANSI/A3 R15.08 series: Part 1 addresses the individual IMR, Part 2 addresses IMR systems and integration, and Part 3—published in 2026—addresses continued safe use by users, risk assessment, the current operating environment, and management of change.

Queries for ISO 3691-4 sensor requirements should therefore not end with a scanner specification. The relevant compliance argument extends across the driverless truck, its control system, guidance means, application, operating environment, and verification. A component can support compliance; it cannot confer application compliance by itself.

The Eight-Gate Release Decision

Before a perception capability is credited in the risk assessment, require a “yes” at every gate. A “no” does not automatically block the robot from deployment; it blocks that capability from being counted as risk reduction until the gap is closed. The application may instead use the capability as a non-safety performance layer behind a separately sufficient safety function.

1. Claim gate: Is the hazardous event, trigger, required response, safe state, mode, and integrity target written and approved?
2. Object gate: Are safety-related object properties, approach paths, occlusions, and environmental influences defined?
3. Boundary gate: Are the exact hardware, software, data, configuration, communication, and motion-response boundaries identified?
4. Integrity gate: Does evidence show that the complete architecture meets the selected safety target, including systematic and common-cause concerns?
5. Timing gate: Is the worst-case sensor-to-stop response measured and included in the validated stopping or separation budget?
6. Fault gate: Do representative dangerous faults, stale data, misconfiguration, contamination, and subsystem disagreement lead to the specified response?
7. Application gate: Has the installed vehicle been tested across routes, modes, payloads, floor states, traffic interactions, and foreseeable interventions?
8. Lifecycle gate: Are owners, inspection intervals, configuration controls, incident review, change triggers, and revalidation decisions operational?

The release record should state one of three outcomes: credited safety function, supported by the full evidence chain; non-safety performance measure, valuable but not used in the risk-reduction calculation; or unsupported claim, which must be removed from specifications and acceptance criteria. This three-way classification prevents teams from treating every useful sensor as either “safe” or “useless.”

Focused FAQ

Can the same LiDAR be used for safety and navigation?

Yes, a device can provide an evaluated protective function and separate measurement data for localization or navigation. The safety evidence applies only to the defined safety function, outputs, configuration, conditions, and integration. Raw data consumed by a navigation computer do not automatically become safety-rated because they originate in the same housing.

Does a safety-certified scanner make the complete AMR safe?

No. The scanner is one element of a larger safety function. Field geometry, mounting, field selection, speed and direction inputs, safety logic, communication, drive response, braking behavior, load, floor, operating modes, and site validation all affect whether the application controls risk.

Can a standard 3D camera be used for obstacle avoidance?

Yes. A non-safety 3D camera can improve detection of overhanging or low objects, support route planning, and reduce unwanted protective stops. Unless its complete signal and control path is validated for a safety role, it should be treated as a performance measure rather than credited personnel protection.

Can AI perception ever be part of a safety function?

Potentially, but the safety case must cover much more than model accuracy. It needs requirements, defined operating domain, dependable detection, fault response, software and data lifecycle controls, integrity evidence, integration, validation, and change management appropriate to the claimed function. A vendor demonstration or aggregate recall figure is insufficient.

Is 99.9% object-detection accuracy equivalent to PL d?

No. Detection accuracy is a dataset performance metric whose meaning depends on labels, class balance, thresholds, and test conditions. A Performance Level applies to a specified safety function and considers architecture, dangerous failure behavior, diagnostics, systematic measures, and other lifecycle evidence. The two numbers are not interchangeable.

If navigation avoids every obstacle in testing, is a protective scanner still needed?

Successful normal-operation testing does not demonstrate behavior under all faults or worst-case conditions. Whether a particular protective technology is needed depends on the risk assessment and applicable requirements, but any credited alternative must provide a complete, validated safety function with adequate integrity—not merely a strong navigation test record.

What is the most important document to request from a sensor supplier?

There is no single sufficient document. Start with the safety manual and exact product/firmware conformity information, then obtain environmental limits, response-time data, diagnostic and interface behavior, mounting and configuration requirements, certificates where applicable, and instructions defining intended and excluded uses. Match every item to the delivered configuration.

What should happen if the navigation sensor works but the safety sensor faults?

The vehicle should follow the predefined and validated response for loss of the safety function, regardless of apparently good navigation data. Depending on the architecture, this may be a protective stop or a tightly controlled validated fallback. Non-safety perception should not silently override a safety fault.

What should happen if safety sensing works but localization fails?

The robot needs a separate degraded-state rule. Protective sensing may reduce collision risk, but it does not prove that the robot knows its location, permitted route, destination, or interaction state. A controlled stop, supervised recovery, or validated relocalization procedure may be required.

When must perception be revalidated?

Revalidation is triggered when a change can affect the approved claim: sensor or mount replacement, firmware or model updates, field changes, speed or load changes, braking changes, new routes, lighting or floor changes, altered traffic, new occlusions, incidents, near misses, or evidence of latency and detection degradation. The impact assessment determines the depth of retesting.

Final Engineering Position

The mature question is not “How many sensors does the AMR have?” It is “Which exact chain prevents which exact hazardous event, within which limits, with what integrity and evidence?” Navigation perception and safety-rated sensing can share hardware, complement each other, and even converge in advanced sensor systems. They must not share claims by implication.

A strong architecture lets perception make the robot anticipatory, fluid, and productive while the safety-related system remains authoritative, bounded, diagnosable, and testable. When advanced perception is itself credited for risk reduction, the evidence boundary expands to include the algorithm, data path, computation, decision logic, operating domain, update process, and failure response. That expansion should be deliberate and visible in the requirements, contract, validation plan, and lifecycle controls.

The practical rule is simple: capability earns operational confidence; a complete traceable safety function earns risk-reduction credit. Keeping those two forms of confidence separate is how integrators avoid inflated claims, purchasers write enforceable acceptance criteria, and operators preserve safe performance after the demonstration team has left the site.

Technical References

• ISO 3691-4:2023 — Driverless industrial trucks and their systems
• ISO 13849-1:2023 — Safety-related parts of control systems
• IEC 61496-1:2020 — General requirements and tests for ESPE
• IEC 61496-3:2025 — Particular requirements for AOPDDR
• IEC TS 62998-1:2019 — Safety-related sensors used for protection of persons
• IEC TR 62998-2:2020 — Application and sensor-fusion examples
• IEC TS 62998-3:2023 — Sensor technologies and algorithms
• ANSI/A3 R15.08 — Parts 1, 2, and 3
• Pilz — Safety scanner protection plus localization and navigation data

#AMRSafetySensors #SafetyRatedSensing #NavigationPerception #SafetyLiDAR #NavigationLiDAR #FunctionalSafety #IndustrialMobileRobots #IEC61496 #ISO36914 #MobileRobotValidation