Functional Safety for Autonomous Mobile Robots: The Complete Guide

Autonomous mobile robots operate in spaces shared with people, move without continuous human supervision, and make real-time decisions based on sensor data. Each of these characteristics creates functional safety requirements that don’t apply to traditional fixed machinery.

The safety challenge for AMRs isn’t just certifying a single system. It’s certifying a system designed to operate in environments it has never been in, encountering people and objects it has never seen, across hundreds or thousands of units running concurrently.

Amazon has operated more than 1 million autonomous robots using the methodology behind ASAP. That scale is proof of what functional safety infrastructure makes possible at the system level.

Standards applicable to AMR functional safety	Scope
IEC 61508	Foundational standard: safety functions of electrical/electronic/programmable systems. Applies to the safety architecture at the system level.
ISO 3691-4	Specific requirements for driverless industrial trucks — AMRs, autonomous forklifts. Covers performance requirements and test methods.
ISO 13849	Safety-related parts of control systems — applies to specific safety functions within the AMR control system.
ISO 12100	Machinery risk assessment methodology — the starting point for hazard analysis.
IEC 62061	SIL-based safety for machinery — an alternative to ISO 13849 for complex safety functions.

Why AMR functional safety is uniquely complex

Most machinery safety certification works with a fixed envelope. The robot is in a defined location. The hazard zone is bounded by physical guards or light curtains. The safety functions are designed around that fixed geometry.

AMRs break every one of those assumptions.

Dynamic operating environments. An AMR navigating a warehouse encounters changing obstacles, varying pedestrian traffic, unexpected objects, and environments that weren’t part of the original hazard analysis. The safety functions have to work correctly across all of these scenarios, including ones that weren’t explicitly anticipated at design time.

Software-intensive safety. AMR navigation, perception, and motion planning are implemented in software. Functional safety of software-intensive systems requires IEC 61508 Part 3 compliance — software safety lifecycle, software architecture, software testing, and software tool qualification. This is a more demanding scope than the hardware-focused requirements most teams are familiar with.

Multiple overlapping standards. ISO 3691-4 is specific to driverless industrial trucks and provides concrete performance requirements (stopping distance, rated speed, obstacle detection). But it references back to IEC 61508 for the safety function integrity requirements. Teams need both.

Fleet-scale deployment. A safety case for one AMR isn’t automatically a safety case for a fleet of 500 AMRs operating in the same facility. Installation-specific hazards (traffic density, shared zones, edge conditions) may require site-specific safety analysis in addition to the product-level certification.

The AMR functional safety lifecycle

Concept phase: hazard analysis and intended use definition

AMR functional safety starts with a thorough intended use definition. More than most system types, AMRs have significant “reasonably foreseeable misuse” scenarios that must be included. Workers who step in front of the robot assuming it will stop. Loads that shift during transit. Communication failures during handoffs.

The HARA for an AMR typically produces a larger hazard list than for fixed machinery because the operating scenarios are more varied. Common hazard categories:

• Collision with persons (pedestrian, worker on foot, person in vulnerable position)
• Collision with infrastructure (racking, walls, other equipment)
• Dropped or shifted payload
• Failure to recognize safe-stop commands
• Software or communication failure leading to unintended motion
• Interaction hazards at load pickup and dropoff stations

Each hazard gets a risk assessment that derives the required Safety Integrity Level or Performance Level for the safety function that will control it.

Architecture: sensor fusion and redundancy

AMR safety architecture for pedestrian detection and collision avoidance typically relies on multiple independent sensing modalities: LiDAR, ultrasonic sensors, cameras, safety laser scanners. The architecture question is how these inputs are combined and validated in the safety function.

IEC 61508 Part 2 requirements for hardware fault tolerance define the minimum number of independent channels required to achieve a given SIL. SIL 2 requires one additional channel beyond what’s needed in the absence of faults (HFT 1). SIL 3 requires two. These requirements drive the sensor redundancy and voting logic architecture.

For AMRs, key architecture decisions include:

• Which sensors are part of the safety-related subsystem vs. the non-safety navigation subsystem
• How sensor fusion is handled (SIL-rated fusion vs. independent safety-rated sensors with separate monitoring)
• How the safety controller is separated from the navigation controller
• What the safe state is for each hazard (stopped, slow speed, redirect) and what triggers each

Verification and validation: the site-specific challenge

ISO 3691-4 provides specific test requirements for AMR performance: stopping distance at rated speed, minimum detection distance, obstacle avoidance performance. These tests are conducted under defined conditions.

But field performance is rarely identical to test conditions. Lighting, floor conditions, traffic density, and obstacle configurations vary. Validation should include testing under representative conditions, including edge cases identified during hazard analysis.

Site-specific installation also requires consideration. When an AMR fleet is deployed in a specific facility, the site layout, traffic management, human work patterns, and interaction zones create additional hazards that may not have been in the original product safety case. A responsible deployment process includes site-specific risk assessment and, where needed, additional safety controls.

Continuous monitoring: the ASAP Operate layer

Functional safety for AMRs doesn’t end at commissioning. Operating conditions change. Fleet performance degrades. Edge cases are encountered that weren’t anticipated during design.

ASAP Operate provides real-time operational telemetry that monitors safety function performance in production. When a parameter drifts from its validated range — stopping distance increasing as a sensor degrades, for example — the system flags it before the safety function fails to meet its integrity requirement. This is the operational layer of the V-Model: continuous monitoring to verify that the safety case remains valid throughout the product’s operational life.

The cost of a safety function degrading silently in a live deployment is significant. The cost of catching it in telemetry before it causes an incident is orders of magnitude lower.

FAQ: Functional Safety for AMRs

What standards apply to AMR functional safety?

AMRs fall under multiple overlapping standards. ISO 3691-4 provides specific performance requirements for driverless industrial trucks. IEC 61508 governs the safety integrity of the electronic and software systems implementing safety functions. ISO 13849 or IEC 62061 may apply to specific control system safety functions. ISO 12100 provides the foundational risk assessment methodology. Most AMR safety programs use all of these in combination.

What is the required SIL level for AMR pedestrian detection?

The required SIL is derived from the hazard analysis, not assigned by default. For an AMR operating in a space with pedestrians at normal walking speeds, the hazard of collision typically results in a SIL 2 or SIL 3 requirement for the detection and stop function, depending on severity assessment and whether additional risk reduction measures are in place. The risk assessment determines the target; the architecture then needs to demonstrate it can be achieved.

How does ISO 3691-4 relate to IEC 61508 for AMRs?

ISO 3691-4 specifies the performance requirements and test methods for driverless industrial trucks. It references IEC 61508 for the safety integrity requirements of the electronic safety systems. In practice, you use ISO 3691-4 to define what the AMR must do and how to test it, and IEC 61508 to define how reliable the safety functions must be. Both are required for a complete safety argument.

What makes AMR functional safety different from fixed robot safety?

Dynamic operating environments, software-intensive safety architectures, and fleet-scale deployment create requirements that don’t exist for fixed machinery. AMRs operate in spaces they haven’t been trained on, encounter people in unpredictable configurations, and run at scale across facilities with site-specific conditions. The safety case needs to address all of these scenarios, including those that weren’t explicitly anticipated at design time.

How does ASAP support AMR functional safety?

ASAP provides pre-configured project templates for AMR applications, covering the common hazard categories, applicable standards, and documentation requirements specific to autonomous mobile robot systems. The platform’s HARA workflow supports the ISO 12100 methodology. Reliability modeling covers both PL calculations (ISO 13849) and SIL calculations (IEC 61508). ASAP Operate provides continuous monitoring of safety function performance in deployed fleets.

---

This post covers general functional safety engineering principles and is for educational purposes only. It is not engineering advice. Consult a qualified functional safety professional and your applicable standards body before making safety-critical design decisions.

---

Amazon used the methodology behind ASAP to manage functional safety for more than 1 million autonomous robots. ASAP includes pre-configured project templates specifically for AMR applications. See the platform.