AMR — ISO 3691-4

This pattern is for Autonomous Mobile Robot vendors pursuing ISO 3691-4 conformity. For vendors selling into the US market, the pattern extends to dual-claim with ANSI/RIA R15.08; the structural workflow is identical with both standards pinned.

Roboticks is audit-readiness tooling, not a certified toolchain. We assemble the evidence your notified body, certification body, or QA process ingests. We do not replace tool qualification (DO-178C, ISO 26262-8 TCL) and we do not issue conformity assessments. Verify the regulatory interpretations on this page against the standard text and your accredited assessor.

Scenario

You manufacture an AMR — autonomous mobile robot for industrial material handling. Conformance target: ISO 3691-4:2023 under EU MR 2023/1230 (and R15.08-1:2023 for US sales). Your obligations:

Demonstrate the AMR’s personnel detection system (PDS) detects operators in time to stop before contact, across the operational design domain.
Document detection-zone geometry per truck speed and payload.
Demonstrate safe behaviour in edge cases — operator step-out, low-contrast obstacles, mixed-traffic scenarios.
Document fault behaviour — sensor occlusion, communication loss, charging-station interactions.
Provide verification evidence — primarily sim, anchored by hardware spot tests.

Prerequisites

Off-platform	Why
Risk assessment per ISO 12100 with detection-zone analysis	Drives the scenario grid
Certified safety scanners (IEC 61496-3) from supplier	Their certs reference; you integrate
Detection-zone geometry definition	Pinned per-release in Roboticks
Validated sim environment (Gazebo or Webots with sensor models)	Sim-based evidence is the dominant strategy for AMR scale
Hardware test track / fixture	Spot-validation anchor

Project setup

Pin the standards stack

rbtk standard template apply amr-eu --project acme-amr/firmware

Pins: ISO 3691-4:2023, ISO 12100, EN ISO 13849-1, IEC 62061, EU MR 2023/1230, IEC 61496-1, IEC 61496-3. For US dual-claim, additionally:

rbtk standard pin ansi-ria-r15-08-1-2023 --project acme-amr/firmware

Declare detection zones

# roboticks/zones.yaml
zones:
  - name: forward_warning
    geometry: polygon
    speed_band: [0.5, 2.0]  # m/s
    payload_band: [0, 1500]  # kg
    # …
  - name: forward_protective
    # …

The platform pins this configuration per-release; the evidence pack documents the geometry in force when each scenario ran.

Build the scenario grid

Scenarios are parameterised across speed × payload × obstacle-type × obstacle-position. A typical AMR project has 500–5,000 scenarios. The grid is auto-generated from scenarios/grid.yaml:

grid:
  speeds_ms: [0.5, 1.0, 1.5, 2.0]
  payloads_kg: [0, 500, 1000, 1500]
  obstacles:
    - kg-box-30x40
    - operator-mannequin-standing
    - operator-mannequin-crouching
    - pallet-empty
  obstacle_positions:
    # forward straight, forward-left, forward-right, pinch-point
    - [3.0, 0.0]
    - [2.5, 0.5]
    - [2.5, -0.5]
    # …

The grid expands at test-time.

Author the requirements

Requirements are coarse-grained — one per (speed band, payload band, scenario category). See ISO 3691-4 derivation example.

Test patterns

The dominant test is a parameterised stopping-distance assertion:

import pytest
from roboticks import confirms
from roboticks.gazebo import distance_to_obstacle

SCENARIOS = expand_grid("scenarios/grid.yaml")

@pytest.mark.parametrize("s", SCENARIOS, ids=lambda s: s.id)
@confirms("REQ-AMR-014")
def test_stopping_distance(amr, s):
    amr.load_world(s.world)
    amr.set_payload_kg(s.payload_kg)
    amr.command_velocity(s.speed_ms)
    amr.spawn_obstacle(s.obstacle, s.position)
    amr.wait_until_stopped()
    distance = distance_to_obstacle(amr, s.obstacle)
    assert distance > 0.0, f"{s.id}: contact occurred"

Each run captures an MCAP of TF, scanner topics, motion commands, and stop-confirm topics. The evidence pack references every MCAP.

Edge-case scenarios

Beyond the grid, build explicit scenarios for the corner cases assessors scrutinise:

Scenario	What it tests
`step_out_from_rack`	Operator emerges from behind a static obstacle
`low_contrast_pallet`	Black pallet on dark floor
`partial_sensor_occlusion`	Scanner partially blocked by dust simulation
`pinch_point_corridor`	Narrow corridor, operator in path with no escape
`mixed_traffic_amr_amr`	Two AMRs approaching, both must yield
`manual_mode_safety`	Safety functions remain active in manual mode
`recovery_no_restart`	Verifies AMR does not auto-restart with obstacle present

These scenarios are typically derived from individual requirements (e.g., REQ-AMR-EDGE-step-out), so the requirement is explicitly tested.

Hardware spot-validation

Run a subset of the scenario grid on the hardware test track — typically 30–80 scenarios anchoring the speed × payload corners and the edge cases. The hardware results enter the evidence pack as JUnit XML the same way sim results do. Author a sim-vs-hardware-equivalence requirement (similar to the cobot pattern) to defend sim-broad-coverage to the assessor.

Release and handoff

Cut releases on every firmware version, generate the evidence pack, hand to the notified body. Expect the assessor to:

Scrutinise scenario-grid coverage — what speed × payload × obstacle combinations did you skip and why.
Drill into edge-case scenarios — particularly pinch-point and step-out cases.
Restore MCAPs for representative failures (if any acknowledged gaps) and representative passes from Glacier.
Question communication-loss and sensor-occlusion fault handling — these are common conformity-assessment focus areas.
Request a live hardware demo of a few scenarios, with the evidence pack PDF as the script.

Maintenance

Event	Action
ISO 3691-4 amendment	Re-conformity workflow
New AMR variant in the product line	New project (or new repository in the same project); apply the same pattern
New scanner / lidar model	Re-verify the requirements that derive from the sensor’s IEC 61496-3 characteristics
Field incident report	Ad-hoc pack scoped to the field-build’s commit; investigate; add new scenarios; re-verify
New customer site with different environmental constraints	Site-acceptance testing is off-platform; reference the site-specific tests in the evidence pack

Next steps

ISO 3691-4 standard page

Standard reference.

ANSI/RIA R15.08

Dual-claim for US market.

IEC 61496

The scanner standard your sensors are certified to.

EU MR conformity

Full technical-file assembly.

Quick Start

GitHub App

Requirements

Traceability

Testing

SDK

Self-Hosted Runners

AI Features

CLI

Evidence Packs

Standards Coverage

Compliance Patterns

Integrations

Pricing

Resources

AMR - ISO 3691-4

AMR — ISO 3691-4

Scenario

Prerequisites

Project setup

Test patterns

Edge-case scenarios

Hardware spot-validation

Release and handoff

Maintenance

Next steps

ISO 3691-4 standard page

ANSI/RIA R15.08

IEC 61496

EU MR conformity

​AMR — ISO 3691-4

​Scenario

​Prerequisites

​Project setup

​Test patterns

​Edge-case scenarios

​Hardware spot-validation

​Release and handoff

​Maintenance

​Next steps

ISO 3691-4 standard page

ANSI/RIA R15.08

IEC 61496

EU MR conformity

AMR — ISO 3691-4

Scenario

Prerequisites

Project setup

Test patterns

Edge-case scenarios

Hardware spot-validation

Release and handoff

Maintenance

Next steps