AMR (Autonomous Mobile Robot)
System
Topic overview
Quick facts
AMR safety combines two traditions that historically evolved separately. From machinery safety it inherits safety-rated functions: protective fields on certified scanners that trigger protective stops, safely-limited speed, emergency stop, and stability requirements, engineered to ISO 13849 performance levels.
From autonomy it inherits the SOTIF-style problem: navigation and perception software decides where the robot goes, and that software can behave hazardously without any component fault, in situations the developers did not anticipate.
R15.08 (for industrial mobile robots) and (for driverless industrial trucks) both reflect this hybrid, specifying required safety functions while leaving the perception-dependence problem to careful system design.
A central design pattern is the separation of the safety-rated layer from the autonomy layer: certified scanners and a safety controller guarantee that whatever the navigation stack does, the platform stops before contact, with protective field sets switched as a function of safety-rated speed.
The harder cases are where that pattern breaks down: detecting obstacles the scanner plane misses (overhangs, forks at height, objects on the floor below the plane), operating with loads that change stopping distance and stability, and interactions like docking where fields must be muted.
Fleet operation adds a system level: traffic management, intersection rules, interaction with manual forklifts and pedestrians, and facility-specific conditions (ramps, dock edges, floor quality) mean the safe deployment is a property of robot plus facility plus operations, not of the robot alone.
This is why R15.08 style thinking pushes significant responsibility onto the integrator and end user, and why the facility commissioning assessment matters as much as the product certificate.
The case for AMR
AMR vendors live or die on deployment velocity, and safety architecture decides it: a clean safety-rated layer with defensible PL claims makes each customer's risk assessment fast, while a design that leans on the navigation stack for safety forces every deployment into bespoke argumentation.
Incidents with pedestrians or manual vehicles in a customer facility are existential for a young vendor, and the legal exposure is shared with the integrator and end user, which is exactly why sophisticated customers audit vendor safety files before fleet purchases.
Getting the standards story right (R15.08, , and the facility-side obligations) is thus a sales asset, not overhead.
AMR in practice
AMR deployment assurance path
The vendor performs a product-level risk assessment covering the robot's hazards across its intended facility types, implements the required safety functions (protective fields with speed-dependent switching, limited speed, e-stop, stability measures) with ISO 13849 PL calculations, and validates stopping distances against the field geometry at worst-case load and speed.
Deployment then adds a site-specific risk assessment by the integrator or end user: mapping facility hazards (blind corners, ramps, dock edges, pedestrian routes), configuring fields and speed zones, and validating in situ. Perception and navigation limitations are analyzed SOTIF-style: what the sensors cannot see, and what keeps those cases safe.
Auditors and customer safety teams look for the field-set calculation evidence, the muting and docking logic rationale, the load and floor condition assumptions, and a clear delineation of vendor versus integrator versus end-user responsibilities.
Where teams get AMR wrong
Standards related to AMR
ANSI/A3 R15.08 sets the requirements that AMR work has to satisfy: safety requirements for autonomous mobile robots (amrs) and mobile manipulators in industrial environments.
Assessors evaluate AMR against ISO 3691-4, safety requirements for driverless industrial trucks and automated guided vehicles.
AMR operating zone types (ISO 3691-4)
| Zone | Meaning | Requirement |
|---|---|---|
| Operating zone | Normal shared operation | Full personnel detection active |
| Restricted zone | Limited/no pedestrian access | Reduced detection permitted with controls |
| Confined zone | Physically excluded personnel | Detection may be muted |
| Hazard zone | Local hazards (docks, chargers) | Zone-specific measures |
AMR by industry
In robotics & automation, AMR comes up in nearly every certification conversation: industrial robots, cobots, amrs, and automated warehousing systems.
Autonomous Systems programs lean on AMR because the sector covers autonomous mobile equipment, off-highway autonomy, and driverless platforms.
Ask our team about AMR
Ben TwomblyFounder & CEOLeads CSA's functional-safety, certification, and engineering programs for safety-critical products and organizations. His assessor-side background informs practical programs that connect standards, engineering work, and credible evidence.
Tom CyrPrincipal Safety Engineer, IFSPSupports industrial and rail functional-safety programs with safety analysis, requirements, lifecycle planning, and certification-readiness guidance.AMR: related terms
How each connects to AMR:
SOTIF is the natural next concept after AMR; assessors expect teams to connect the two.
Programs that deal with AMR almost always involve Safety Function in the same phase.
Like AMR, ATO is a system you will meet early in a safety program.
Collaborative Robot is a system of the same kind; teams comparing the two usually need both.
Understanding AMR is easier with Functional Safety as context, and vice versa.
Teams working on AMR typically encounter Performance Level in the same program.