AMR Safety Requirements Specification From Hazards to Testable Evidence

Conclusion: A deployable AMR safety requirements document must convert identified hazards and operating modes into explicit safety functions, safe states, reset rules, validation methods, and evidence obligations. A list of sensors or standards is not a requirements specification.

Scope: This guide addresses industrial autonomous mobile robots and driverless industrial truck systems used in factories, warehouses, and intralogistics sites. It covers the robot, load, top module, navigation stack, safety-related control, fleet interfaces, workstations, operating zone, people, and lifecycle changes.

Evidence needed: A project should retain a controlled specification, hazard-to-requirement traceability, configuration records, test cases, measured results, deviations, approvals, and revalidation triggers. This article provides an engineering framework, not a project compliance decision.

Why AMR Projects Need Requirements Before They Need More Features

Mobile robot projects often begin with a feature comparison. One supplier offers two safety laser scanners, another offers 3D cameras, and a third promotes artificial-intelligence obstacle recognition. The team compares maximum speed, navigation accuracy, emergency-stop buttons, warning lights, and certificates. Those inputs are useful, but they do not answer the first safety question: what hazardous event must the application prevent or control?

A component cannot be judged in isolation. A scanner may have a safety rating, yet its protective field may not cover the loaded moving envelope. A braking system may stop the robot, yet the measured stop may exceed the space available at a pedestrian crossing. A navigation camera may recognize an obstacle, yet its output may not be part of a safety-related control path. A fleet system may command a stop, yet communication loss may leave the robot operating on stale information. Requirements establish what the complete application must do before the project decides how to implement it.

This is the difference between a product feature list and a mobile robot safety specification. The feature list says what equipment is present. The specification states the required behavior, the conditions in which that behavior is required, the safe state to be achieved, how reset or restart is controlled, and what evidence will demonstrate that the requirement has been met.

The existing guide to AGV and AMR safety standards explains why standards, risk assessment, protective fields, speed control, site validation, and change management belong to one system. This article takes the next engineering step: it shows how to turn that system view into requirements that designers can implement and testers can verify.

Define the System Boundary Before Writing the First Requirement

A safety specification is only meaningful when its boundary is visible. “The AMR shall be safe” is impossible to assess because the term AMR could mean the mobile base, the configured vehicle, a fleet, or the entire application. The system boundary should identify all elements whose behavior can create, prevent, detect, or respond to a hazardous situation.

For an industrial deployment, the boundary normally extends beyond the chassis. It may include the load and load carrier, lift or conveyor module, navigation sensors, safety-related sensors, safety controller, drive and brake functions, map and zone configuration, fleet manager, wireless network, doors, elevators, conveyors, charging stations, workstation handshakes, operator interfaces, floor conditions, traffic rules, and maintenance procedures. If a function depends on an external device, the interface and failure response belong in the specification.

The baseline should also identify versions. A named robot model is not enough. Record the safety-controller firmware, navigation software, fleet software, map revision, scanner configuration, braking configuration, top-module design, approved load cases, battery type, wheel or tire state assumptions, and site layout revision. The same physical robot can have a different risk profile after a map update, payload change, speed increase, or sensor replacement.

Responsibility must be mapped to the same boundary. The manufacturer controls the product design and declared operating limits. The integrator controls the application configuration and interfaces. The site owner controls the operating environment, workforce rules, maintenance, and later changes. A qualified safety professional may evaluate risks and validation evidence, but that review does not remove the responsibilities of the organizations that design, integrate, and operate the system.

Build the Specification from Tasks and Operating Modes

Hazards change when the robot changes mode. A protective measure that is adequate during automatic travel may not address manual recovery, maintenance, or rescue. For that reason, an industrial mobile robot risk assessment should be task-based and mode-aware rather than limited to a generic list of hazards.

Start by listing what people and machines actually do. Examples include loading a pallet, confirming a pickup, crossing a route, clearing a blocked station, cleaning a scanner window, recovering a robot after localization loss, manually steering a disabled unit, replacing a battery, entering a maintenance area, and restarting after an emergency stop. Then identify the operating modes active during each task.

Automatic operation

Automatic operation includes travel, turning, queuing, docking, load transfer, charging, and task execution. Requirements should define authorized speed and load states, protective behavior, route and zone restrictions, expected responses to people or obstacles, and the conditions that cause a controlled stop, protective stop, or other safe response.

Manual, setup, and teaching modes

Manual control changes who commands motion and how close a person may be to the equipment. The specification should identify who is authorized, how the mode is selected, whether speed or motion is limited, how unintended remote commands are prevented, and what happens when the mode selector or enabling device is released.

Maintenance, rescue, and recovery

Maintenance may expose parts, bypass normal traffic rules, or require access near stored energy. Rescue may be needed when a robot stops in an aisle with a load. Recovery may follow localization loss, a protective stop, a communication fault, or an emergency stop. Each state needs explicit isolation, access, confirmation, and restart requirements. “The operator resets the robot” is not enough.

Startup, shutdown, and degraded operation

Requirements should address power restoration, map loading, sensor readiness, brake checks, safety-controller status, time synchronization, network availability, and the validation of current configuration. Degraded operation should not be an undefined fallback. It should be a named state with allowed functions, prohibited functions, speed or route limits, annunciation, escalation rules, and exit conditions.

Use a Hazard-to-Evidence Chain

A mature AMR safety function specification preserves a visible chain from the original hazard to the final validation record. A useful sequence is:

Task and mode - hazardous event - exposed person or asset - risk evaluation - risk-reduction measure - safety function - technical requirement - implementation evidence - validation test - acceptance result.

Consider a pedestrian crossing an AMR route. The hazardous event is not simply “pedestrian detected.” The project must describe the task, robot direction, load, speed, visibility, crossing geometry, foreseeable behavior, and possible contact or trapping scenario. Risk reduction may begin with route separation or crossing design. Safety-related sensing and stopping may then address residual risk. The resulting requirement must state what initiates the response, which motion is controlled, which safe state is required, and how the response is tested under defined conditions.

This chain also prevents a common error: treating dynamic obstacle avoidance as if it automatically provides a safety function. Path planning can improve traffic behavior and reduce unnecessary blockage, but an avoidance algorithm should not be credited with risk reduction unless the complete function, architecture, integrity, diagnostics, limits, and validation support that claim.

Apply risk reduction in layers

The specification should not jump immediately to a sensor. First consider whether the hazardous interaction can be removed or reduced through route design, physical separation, load-interface design, restricted access, workstation layout, or reduced energy. Then define safeguarding and safety-related control functions. Finally, define information, training, inspection, and administrative controls for residual risk. The exact combination depends on the application and applicable requirements.

ISO 12100 provides a general methodology for machinery risk assessment and risk reduction across the lifecycle. ISO 3691-4 addresses safety requirements and verification for driverless industrial trucks and their systems, including vehicles described as automated guided vehicles and autonomous mobile robots within its scope. Neither source turns a generic blog checklist into project approval. The team must establish applicability, market requirements, and project-specific risk reduction with competent personnel.

Write Requirements That Can Fail a Test

A requirement is useful only when two competent reviewers can reach the same conclusion about whether it has been met. Vague words such as safe, quickly, reliably, adequate, intelligent, and user-friendly may express intent, but they do not define acceptance.

A testable requirement normally identifies:

• the function or system that has responsibility;
• the operating mode and configuration in which the requirement applies;
• the initiating event, condition, or detected fault;
• the required response and safe state;
• the response-time, stopping-envelope, position, or state boundary where relevant;
• the allowed reset, restart, override, and authorization behavior;
• the diagnostics, status, alarm, and logging obligations;
• the verification or validation method;
• the acceptance criterion and required evidence;
• the source, owner, revision, and change trigger.

A weak statement says, “The AMR shall stop safely when an obstacle is detected.” It does not define the obstacle, detection region, robot state, load, speed, direction, stopping boundary, control path, restart behavior, or evidence.

A stronger pattern says, “When the safety-related detection function is active in automatic travel and its protective field is infringed, the configured robot shall command the defined safe motion state through the approved safety-related control path; the robot and approved load shall remain within the validated stopping envelope for the recorded speed, floor, slope, tire, brake, and payload configuration. Restart shall require the specified field-clear and reset conditions. Compliance shall be demonstrated by the linked test cases and retained measurement records.”

The stronger version still needs project values. It deliberately does not invent them. The stopping envelope, total response, test repetitions, uncertainty, and acceptance criteria must come from the actual system design, applicable standards, manufacturer instructions, and measured project evidence.

A Practical AMR Safety Requirements Specification Structure

The following structure is an original project template, not a reproduction of a paid standard. It can be adapted into an SRS database, controlled document, or requirements-management system.

Document control and intended use

Record document owner, reviewers, approval status, target market, applicable site, intended use, foreseeable misuse considered, excluded applications, and the standards or regulations reviewed. Include a version-history table that explains why each revision was made.

System and configuration baseline

Identify robot models, top modules, approved loads, safety devices, safety controller, drive and brake configuration, navigation stack, fleet software, map, wireless interfaces, external equipment, site revision, and environmental limits. Requirements should reference configuration identifiers rather than informal descriptions.

Operating modes, tasks, and role permissions

Define automatic travel, docking, charging, loading, manual control, maintenance, rescue, startup, shutdown, fault, and degraded states. State which roles may select each mode, command motion, reset a protective response, change safety parameters, or approve a return to service.

Hazards and risk-reduction decisions

Link each significant hazardous situation to the affected tasks, exposed persons, risk evaluation, selected risk-reduction measures, and residual-risk communication. Do not hide unresolved assumptions in meeting notes. Record them as controlled actions or open requirements.

Safety function requirements

Give every safety function a unique identifier. Define initiation, response, safe state, applicable modes, performance or integrity basis, fault reaction, reset, restart, diagnostics, interfaces, validation method, and evidence. Where a required performance level or other integrity target is used, document how it was determined; do not copy a value from another application.

Performance and navigation constraints

Keep performance requirements visible but distinguish them from safety functions. Examples include localization availability, docking repeatability, route completion, map recovery, traffic capacity, and communication latency. If a performance failure can contribute to a hazardous situation, define the monitored condition and the safety-related response separately.

Verification, validation, and lifecycle controls

Link requirements to design reviews, analysis, inspection, component evidence, factory tests, site tests, fault injection, training, maintenance, periodic proof or function checks, and revalidation. Define what happens when a test fails and who can approve a deviation.

Use a Requirements Table, Not Scattered Prose

This table creates AMR safety requirements traceability. A reviewer can move from a hazard to a requirement, from the requirement to a design element, from the design element to a test, and from the test to a signed result. When a map, load, scanner, brake, or software version changes, the same links identify what must be reviewed again.

Separate Navigation Performance from Safety Functions

Navigation and safety interact, but they are not interchangeable. A navigation function estimates position, plans a route, follows a path, avoids congestion, or recovers from a blocked aisle. A safety function reduces risk by achieving or maintaining a defined safe state with the required integrity. The SRS should state which is which.

The site guide to mobile robot sensor selection can support the performance discussion. The article on safety laser scanner protective fields provides deeper context for field design. Neither page should be used as evidence that a specific project function has achieved a required integrity level. Project evidence must identify the exact component, architecture, configuration, conditions, and validation result.

Specify Faults, Degraded States, and Recovery Before They Occur

Most demonstrations show normal operation. Safety engineering must describe what happens when normal operation is no longer available. A specification should consider single faults, credible combinations, stale data, conflicting sensors, contamination, calibration drift, blocked fields, braking degradation, localization uncertainty, communication loss, map mismatch, load misalignment, low energy, and external equipment faults.

For each condition, define detection, annunciation, allowed behavior, prohibited behavior, safe response, recovery authority, evidence, and escalation. If continued operation is allowed, define the degraded envelope. For example, the robot may be restricted to a lower speed, a limited route, an empty-load state, or manual recovery by trained personnel. If continued operation is not justified, define the stop and isolation state.

Restart deserves its own requirements. Clearing a scanner field does not necessarily mean the application is ready to move. The robot may need to confirm localization, load state, brake status, external interlocks, route clearance, and control ownership. The requirement should state whether restart is automatic, manual, remotely authorized, or prohibited for the initiating event. It should also prevent a reset from bypassing the conditions that caused the stop.

Plan Validation While Writing the Requirement

If the team cannot describe how a requirement will be tested, the requirement is probably incomplete. Validation planning should begin before the design is frozen. This makes sensors, logs, measurement points, test fixtures, and access needs visible early enough to include them in the system.

A complete test case should identify the requirement ID, configuration baseline, preconditions, environment, load, speed and direction, trigger position, repeatable steps, expected response, measurement tools, sampling or time synchronization needs, acceptance criterion, evidence files, result, deviation, corrective action, and approval.

AMR safety validation should include normal operation, boundary conditions, reasonably foreseeable misuse, faults, maintenance, recovery, and degraded modes. Factory testing can establish product and configured-system evidence. Site testing must address the installed routes, loads, traffic, workstations, floors, lighting, communication, and human interactions. The existing AMR deployment validation guide provides the wider commissioning context; the SRS supplies the requirement IDs and acceptance logic that make those tests auditable.

Use evidence levels transparently

Not every statement has the same strength. A standards source supports a statement about its published scope. A manufacturer manual supports a declared product limit under stated conditions. A calculation supports an engineering relationship under disclosed assumptions. Simulation expands scenario coverage but depends on model validity. A measured FAT or SAT result supports the tested configuration and conditions. An illustrative example explains a method but cannot prove a real application.

Label those differences. Do not turn a single test, average value, simulation, or catalog statement into a universal safety claim. Record units, conditions, uncertainty, sample size, versions, anomalies, and the boundaries beyond which the result should not be extrapolated.

Map Standards to Responsibilities, Not to Marketing Claims

The standards map should identify the object, market, version, status, responsible role, and evidence implication. At the time of writing, ISO lists ISO 12100:2010 as current but under revision, and ISO 3691-4:2023 as published with a draft successor under development. ISO 13849-1:2023 provides methodology for safety-related parts of control systems, but its published abstract explicitly states that it does not specify the safety functions or required performance levels for particular applications. That is why a project must determine its functions and integrity needs through applicable requirements and risk assessment rather than copying a value from another robot.

For the United States, the official A3 material distinguishes responsibilities across the R15.08 series: Part 1 addresses the industrial mobile robot, Part 2 addresses IMR systems and integration, and Part 3 addresses use of IMR applications. A3 published Part 3 in April 2026 and highlights risk assessment, management of change, the current operating environment, and lifecycle safety. The phrase ANSI A3 R15.08 should therefore lead to a responsibility map, not a vague “compliant” badge.

Similarly, an ISO 3691-4 AMR discussion should state whether the vehicle and system fall within the standard's scope, which edition was reviewed, what the operating-zone assumptions are, and which organization is responsible for implementation and verification. Standards numbers do not approve a project by themselves.

Control the Specification Through Procurement and Integration

The SRS should become a project control document, not an appendix written after installation. During procurement, it helps buyers ask for evidence rather than adjectives. During design, it tells suppliers and integrators what behavior must be implemented. During FAT and SAT, it defines what will be tested. During operation, it defines the controlled baseline and the changes that require review.

Useful contract deliverables may include the approved requirements specification, responsibility matrix, risk-assessment record, safety-function list, interface control document, configuration baseline, validation plan, FAT and SAT procedures, test data, deviations, training content, maintenance checks, change-control procedure, and final evidence index. Commercial agreements should also identify who updates each artifact and who approves safety-related changes.

An AMR risk assessment checklist can help teams prepare, but it should not replace the risk assessment or the SRS. A checklist is good at reminding the team to review modes, loads, crossings, docking, charging, maintenance, and recovery. It is weak at capturing project-specific causal chains, assumptions, interfaces, and acceptance evidence unless those items are linked to controlled records.

Common SRS Failure Patterns

Starting with a component brand

“Use scanner model X” is a design choice, not a complete safety requirement. State the required function and evidence first. Then verify whether the selected component and architecture can achieve it under the configured conditions.

Copying requirements from another site

Two sites can use the same robot but have different loads, floors, traffic, workstations, speeds, and recovery practices. Reuse a document structure if helpful, but re-evaluate the hazards, operating modes, required functions, and acceptance criteria.

Writing only for automatic travel

Many serious gaps appear during maintenance, manual recovery, commissioning, or restart. Include every lifecycle task in which people can be exposed to motion, stored energy, load movement, or unexpected commands.

Mixing performance and safety evidence

A high detection rate in a perception dataset does not automatically establish a safety function. Navigation uptime does not prove safe fault response. A certificate for one component does not validate the complete control chain or installed application.

Using a requirement with no owner or test

Every requirement should have an implementation owner, validation method, status, and evidence reference. Otherwise it can disappear between the manufacturer, integrator, software supplier, and site team.

Freezing the document at go-live

A map revision, higher speed, new payload, changed workstation, firmware update, replacement scanner, altered floor coating, or new traffic rule may invalidate assumptions. The SRS must identify change triggers and the required impact analysis.

An Illustrative Hazard-to-Test Example

Illustrative only: The following example demonstrates structure. It contains no project-approved values and cannot be used as a compliance result.

This example is stronger than “the robot stops for pedestrians” because it exposes the configuration, control path, stopping envelope, restart conditions, fault response, and evidence. The actual project must insert measured values, applicable criteria, and qualified approval.

A Ten-Step Workflow for Building the SRS

1. Freeze the review baseline. Record the robot, load, software, map, interfaces, site, and operating-zone versions being assessed.
2. Map tasks and modes. Include automatic work, human interaction, maintenance, rescue, startup, shutdown, and degraded operation.
3. Identify hazardous situations. Consider intended use, foreseeable misuse, environmental limits, external equipment, and lifecycle stages.
4. Select risk-reduction layers. Begin with design and site measures before relying on warnings or procedure.
5. Define safety functions. Give each function a unique identifier, trigger, response, safe state, fault behavior, and reset logic.
6. Assign integrity and performance bases. Document the project-specific rationale; do not infer it from a component name or another site's design.
7. Write validation with the requirement. Define method, configuration, conditions, measurement, acceptance, and evidence before design release.
8. Create traceability. Link hazards, requirements, designs, interfaces, tests, results, deviations, and approvals.
9. Review across organizations. Manufacturer, integrator, site operations, maintenance, EHS, and qualified safety reviewers should resolve boundary and ownership gaps.
10. Control change and revalidation. Identify triggers, perform impact analysis, run the required regression or site tests, and issue a new approved baseline.

Focused FAQ

What is an AMR safety requirements specification?

It is a controlled set of project requirements that translates identified hazards, operating modes, and risk-reduction decisions into testable safety functions, safe states, fault responses, reset rules, validation methods, and evidence obligations for an industrial mobile robot application.

Is an SRS the same as an AMR risk assessment?

No. Risk assessment identifies hazardous situations, evaluates risk, and selects risk-reduction measures. The SRS converts the resulting safety-function decisions into implementable and testable requirements. The two records should be traceable to each other.

Who should own the AMR safety specification?

Ownership should be explicit and may be shared across manufacturer, integrator, and user responsibilities. One controlled document owner should manage revisions, while responsible technical and safety reviewers approve the sections within their competence.

Does ISO 13849-1 tell an AMR project which PLr to use?

No. The official ISO abstract states that ISO 13849-1:2023 does not specify the safety functions or required performance levels for particular applications. The project must determine them from risk assessment, applicable product or application requirements, and qualified engineering judgment.

Can a navigation LiDAR or camera be listed as a safety measure?

Only when the claimed safety function is supported by the complete device, architecture, control path, diagnostics, operating limits, and validation evidence required for that use. Navigation perception should not be credited as a safety-rated function merely because it detects or classifies objects.

What makes an AMR safety requirement testable?

It identifies the applicable mode and configuration, initiating condition, required response, safe state, measurable boundary, fault behavior, reset and restart conditions, validation method, acceptance criterion, and evidence record.

Should FAT and SAT use the same requirements?

They should trace to the same approved requirements, but their evidence scopes differ. FAT can verify product and configured-system behavior in a controlled environment. SAT must validate the installed application with real routes, loads, floors, traffic, workstations, interfaces, and operating procedures.

When must an AMR SRS be updated?

Update or formally review it when a change can affect a hazard, safety function, operating limit, interface, validation result, or responsibility. Common triggers include new payloads, speed changes, map or route revisions, software updates, sensor substitution, braking changes, workstation changes, and altered human or forklift traffic.

Can a generic template prove compliance?

No. A template improves completeness and traceability, but compliance and safe release depend on the applicable market, actual system, qualified risk assessment, implemented functions, project evidence, and approval by responsible competent persons.

Conclusion: The SRS Is the Contract Between Risk and Evidence

A serious mobile robot project does not begin safety engineering with a scanner brand, a certificate, or a generic checklist. It begins by defining the system, tasks, modes, hazardous situations, responsible roles, and risk-reduction decisions. Those decisions become testable safety requirements. The requirements become design inputs. The design is linked to verification and site validation. The results become evidence. Changes return through the same chain.

That chain makes safety review more rigorous and project delivery more efficient. Suppliers know what they must implement. Integrators know which interfaces and site conditions must be controlled. Buyers know what evidence to request. Test teams know what constitutes pass or fail. Operations teams know which changes require revalidation.

Autonomous mobile robot safety is therefore not demonstrated by the presence of technology alone. It is demonstrated by a controlled relationship between hazards, requirements, implementation, measured behavior, responsibility, and lifecycle evidence. A well-built SRS makes that relationship visible before production pressure makes missing requirements expensive.

Authoritative Reference Entrances

• ISO 12100:2010 - Safety of machinery: risk assessment and risk reduction
• ISO 3691-4:2023 - Driverless industrial trucks and their systems
• ISO 13849-1:2023 - Safety-related parts of control systems: design
• ISO 13849-2:2012 - Safety-related parts of control systems: validation
• A3 industrial mobile robot safety standards entrance
• ANSI/A3 R15.08-3-2026 official product page

Editorial boundary: This guide explains an engineering documentation method. It does not replace paid standards, manufacturer instructions, a project risk assessment, qualified functional-safety work, legal review, or formal validation and approval of an actual AMR application.

#AMRSafetyRequirements #AutonomousMobileRobotSafety #IndustrialMobileRobotSafety #RobotRiskAssessment #SafetyRequirementsSpecification #AMRSafetyValidation #ISO36914 #ANSIA3R1508 #FunctionalSafety #NavigationSafetyModules