Chapter 17 · Prove FleetOps across regression, interfaces, safety, and commissioning

Today in the field story

One problem, then the next

Review the aisle application with a qualified-owner boundary in view. Distinguish an application stop request from emergency stop, protective stop, and safe torque off; identify zones, speed-dependent separation, restart conditions, and periodic checks at awareness level. Do not validate a safety function in classroom software. Instead, produce the questions, evidence gaps, and interface assumptions that competent safety and site owners must accept or block.

Why now: A technically correct FleetOps test can still omit physical hazards and independently engineered protective functions.
Ignore today: Ignore certification and safety-PLC implementation; document scope and escalate ownership correctly.
Unlocks next: A bounded safety-awareness record that prevents software evidence from being overstated.

Understand

Build the physical picture first

Robot safety is an independently engineered envelope: the application may request motion, but validated protective functions decide when energy or motion is permitted and how restart is controlled.

ISO 3691-4:2023 addresses safety requirements and verification for driverless industrial trucks and their systems, including AGVs and AMRs, and recognizes that the operating zone materially affects safe operation. ISO 13849-1:2023 provides a methodology for designing and integrating safety-related parts of control systems; it does not choose the required safety functions or performance level for a particular application. Obtain the applicable standards and local requirements, then involve a qualified machinery-safety professional.

An emergency stop is a complementary protective measure for an emergency, not the normal cycle stop, isolation procedure, or universal answer to every hazard. Safe Torque Off prevents torque-producing energy as defined by the drive function but does not necessarily apply a brake, prevent gravity motion, or establish a complete safe state. A normal ROS command, mission cancellation, or navigation stop can be valuable operational behavior, yet it is not automatically safety-rated or independent of the failure it is meant to control.

Protective fields and zones should be derived from risk assessment, validated sensing and control architecture, worst credible speed and load, floor and slope, detection and control latency, stopping performance, measurement uncertainty, and required margins. An outer field may request reduced speed and an inner field may trigger a protective stop, but names and behavior depend on the actual safety design. Releasing an E-stop or clearing a field removes one stop condition; it must not cause unexpected automatic restart.

Use stopping arithmetic only to expose variables and test assumptions. The simple constant-deceleration estimate d = v·t + v²/(2a) omits jerk, controller and network tails, sensor geometry, brake variation, tire and floor effects, slope, payload, uncertainty, and standards-required margins. Measure the real system under qualified procedures before setting protective distances, and treat software simulation or this calculation as awareness evidence rather than certification.

Words you need

Name each idea precisely

Risk assessment: The documented process of identifying tasks and hazards, estimating and evaluating risk, selecting controls, and reviewing residual risk across intended use and foreseeable misuse.
Physical example:
The team examines normal delivery, charging, jam recovery, cleaning, maintenance, manual movement, and a pedestrian entering an aisle before selecting safeguards.
Emergency stop: A manually initiated emergency function intended to avert or reduce an arising hazard, designed and validated within the applicable safety architecture.
Physical example:
A reachable red actuator triggers the declared emergency response, latches, reports diagnostics, and requires deliberate reset without restarting motion.
Safe Torque Off: A drive safety function that prevents torque-producing energy, subject to its specified architecture, limitations, and validation.
Physical example:
STO can remove motor torque while a vertical load may still need a separately engineered brake or support against gravity.
Protective field: A monitored region whose intrusion triggers a defined safety-related response under specified sensing, speed, and operating conditions.
Physical example:
A validated scanner field causes the AMR’s protective-stop function before a person can reach the hazardous motion.
Reset interlock: The rule that clearing or resetting a protective condition restores readiness only and does not itself command hazardous motion.
Physical example:
After an E-stop is released, an operator inspects the area, performs a deliberate reset, and issues a separate new start command.

Math, one line at a time

Work through today’s relationship

Prerequisite rescue · optionalRisk priority, trial denominators, and recovery time

Validation turns hazards into traceable tests and reports every planned trial, including the failures that make a result uncomfortable.

RPN = S×O×D: an ordinal FMEA priority from severity, occurrence, and detection ratingsUnit: relative score
p̂ = k/N: observed passes k divided by all planned trials NUnit: fraction or percent
Tᵣ: time from a declared failure event until every recovery condition remains trueUnit: seconds (s)

A hazard is rated severity S=5, occurrence O=2, and detection difficulty D=4, so its relative RPN is 5×2×4 = 40.
A frozen matrix planned N=20 trials and passed k=17, so the observed pass rate is 17/20 = 85%; the three failures stay in the denominator.
If valid sensing returns at 12.0 s and all stability criteria hold from 15.5 s onward, report recovery time Tᵣ = 3.5 s and preserve the trace.

Programmer analogy

Treat it like a release test matrix with trace IDs, except the failed requirement can concern motion, collision, or loss of control rather than a screen defect.

A frozen suite passes 27 of 30 planned trials. What observed pass rate must be reported?

27/30 = 0.90 = 90%, with all three failures retained and categorized.

The simplified estimate is

d=vt+\frac{v^2}{2a}.

With $v=1\ \mathrm{m/s}$ , $t=0.15\ \mathrm{s}$ , and $a=1.5\ \mathrm{m/s^2}$ ,

d=1(0.15)+\frac{1^2}{2(1.5)}\approx0.48\ \mathrm{m}

before margin.

Use a stop estimate to identify evidence still missing

For an awareness calculation only, an AMR travels at 0.8 m/s, assumed reaction time is 0.18 seconds, and assumed constant deceleration is 1.2 m/s².

Calculate reaction distance as v × t = 0.8 × 0.18 = 0.144 m.
Calculate ideal braking distance as v² / (2a) = 0.8² / (2 × 1.2) = 0.64 / 2.4 ≈ 0.267 m.
Add the simplified terms: 0.144 + 0.267 ≈ 0.411 m before any margin, uncertainty, field geometry, or system-specific requirement.
List missing evidence: worst credible payload, floor and slope, speed tolerance, sensor and control tails, brake variability, tire condition, battery state, jerk, measurement error, and applicable standard margins.
Map the related protective function to detection, safety-related logic, actuator response, diagnostic coverage, safe state, reset, and qualified validation method rather than assigning it to the FleetOps application.
Label 0.411 m as an illustrative lower-information estimate only and prohibit its use as a protective-field setting until the complete qualified design and measured stopping validation are approved.

Result

The arithmetic exposes a nominal 0.411 m estimate and, more importantly, a concrete list of evidence that prevents it from becoming an unsafe design distance.

What this proves

A transparent calculation supports questions; it never replaces risk assessment, safety architecture, standards application, measurement, margin, or qualified validation.

Physical examples

Where this appears in real life

Nested paper safety fields

Place an unpowered cardboard AMR inside inner and outer paper boundaries. Move a person token toward it while separate cards show nominal, reduced-speed request, protective stop, reset-required, and ready states.

Look for:

Crossing a boundary changes the declared state, but clearing it never moves the token; readiness and a new motion command remain separate.

Vertical load after torque removal

Hold a book with a string over a pencil pulley, then support it on the table before loosening the drive string; do not suspend weight over hands or feet.

Look for:

Removing the pulling torque does not inherently hold a gravity-loaded axis, illustrating why STO alone may not define the whole mechanical safe state.

Hands-on exercise

Make the idea observable

Work only in simulation or with an unpowered diagram and cardboard layout. Do not open safety circuits, change scanner fields, bypass interlocks, energize drives, or validate a real protective function.

Create a task-based hazard map for normal travel, docking, transfer, charging, jam clearing, cleaning, maintenance, and foreseeable pedestrian interaction.
Draw operating, warning or awareness, reduced-speed, protective-stop, maintenance, and exclusion regions only as proposed concepts, with assumptions and responsible reviewer beside each.
Build a safety-function table containing trigger, sensing channel, safety-related logic, final element, intended safe state, diagnostics, reset, proof method, owner, and unverified dependencies.
Use the illustrative stop equation at three speeds to show the quadratic braking term, then mark every missing real-world factor and refuse to set a field distance from the worksheet.
Rehearse simulated E-stop, protective-field intrusion, stale safety status, reset, and new-command sequences; assert that clearing or reset alone never restarts motion.
Send the package to a qualified machinery-safety reviewer with the exact AMR, operating zone, payload, tasks, jurisdiction, standards editions, assumptions, and unresolved questions.

Observe

The exercise reveals shared-cause paths, ambiguous resets, missing diagnostics, and physical measurements that application logs or ideal simulation cannot validate.

Done when

The hazard and function tables expose every assumption, simulated reset cannot restart motion, calculations are clearly bounded, and all real safety decisions remain assigned to qualified review.

Build today

Create a risk-linked SIL→HIL acceptance ladder for FleetOps, automate regression scenarios, integrate one external fleet or PLC boundary, and publish FAT/SAT evidence plus an incident report.

Evidence to save

DONE when a 60–120 second uncut “AMR safety awareness: ISO 3691-4, ISO 13849, E-stop, STO, and zones” demo links to its command, logs or plots, result count, and honest failure note.

Common mistakes

Catch the wrong mental model

Wrong

Calling an application-level stop command safety-rated because it usually stops the robot.

Better

Describe its operational value accurately and rely on the independently engineered, validated, and monitored protective architecture required by the risk assessment.

Wrong

Assuming STO always brakes and holds every mechanism.

Better

Review the drive and mechanical system: torque prevention may require separate braking, gravity support, isolation, or other safety functions to reach the intended safe state.

Wrong

Using d = v·t + v²/(2a) as the protective-field distance.

Better

Treat it as an illustrative estimate, then apply the applicable standards, qualified risk assessment, measured worst-case stopping performance, uncertainty, geometry, and required margins.

Wrong

Allowing E-stop release or zone clearance to resume an interrupted mission automatically.

Better

Require area review and deliberate reset to readiness, followed by a separate authorized command under the approved restart procedure.

Job connection

How this becomes employable evidence

Support an AMR safety review by supplying traceable application states, fault timing, reset semantics, operating-zone assumptions, and simulation evidence while keeping safety-function design, performance-level selection, and physical validation with qualified owners.

Relevant target roles

Robotics Deployment, Integration & Validation Engineer
Robotics Application / ROS 2 Integration Engineer
Robotics Software Engineer — ROS 2 / AMR

Chapter 17 interview drill

Interview questions: AMR safety awareness: ISO 3691-4, ISO 13849, E-stop, STO, and zones

Practise a 60–90 second answer: define the idea, connect it to a physical robot, state assumptions, frames, and units when relevant, then finish with the failure signal or evidence you would inspect.

Primary interview scenario

Explain why a Nav2 stop or mission cancel is not an E-stop, what STO does and may not do, why reset cannot restart motion, and how you would prevent an illustrative stopping calculation from becoming an unvalidated scanner-field setting.

Answer shape: clarify the situation → trace the physical and software path → test the most likely boundaries → name the evidence that would confirm the result.

Technical follow-up questions

Q1What is the scope difference between ISO 3691-4 and ISO 13849-1?

Model interview answer

ISO 3691-4 addresses driverless industrial trucks and systems; ISO 13849-1 provides a methodology for safety-related control-system parts but does not select the application’s required safety functions or performance levels.

Q2Why does STO not necessarily mean the mechanism is motionless and held?

Model interview answer

It prevents torque-producing energy as specified, but gravity, stored energy, external force, or coasting may require braking, support, isolation, or another engineered function.

Q3What should happen after a protective condition is cleared?

Model interview answer

The system may become eligible for deliberate reset to readiness, but it must not restart hazardous motion until the separate approved start conditions and command are satisfied.