Engineering
Robot risk assessment example: from hazard to test
Turn a robot risk assessment into a repeatable test. Use a worked example and worksheet to connect hazards, requirements, results, and limits.
“A person walks into the robot's path” identifies a problem. It does not yet tell an engineer what to test.
Where does the person appear? What blocks the sensor? What should the robot do, and by when?
Those details connect a robot risk assessment to evidence someone can review. Start with one task and hazard. Identify the relevant requirement, then define the scenario, measurement, and acceptance rule. Keep that chain visible in the results.
This guide walks through an illustrative mobile robot example. The worksheet supports test planning. A complete risk assessment also considers other hazards, operating modes, safeguards, and lifecycle tasks.
Start with the task, not a dramatic scene
A useful assessment describes how people and equipment interact. Normal operation is one part of that picture. Cleaning, maintenance, fault recovery, and foreseeable misuse also need attention.
The Occupational Safety and Health Administration's robot safety guidance emphasizes tasks, hazards, risk reduction, and validation. It also recommends involving people who understand the application and its work.
For this example, imagine a mobile robot carrying a load through a warehouse aisle. A worker approaches a crossing behind a loaded cart. The cart blocks part of the worker from a camera's view.
The hazardous situation involves a person and moving equipment sharing the crossing. Occlusion describes one condition that may affect detection. It does not describe every possible cause of contact or injury.
An assessment might lead to layout changes, traffic separation, speed restrictions, or protective functions. The right measures depend on the application. Testing then checks specified requirements for those measures.
Conceptual illustration: partial occlusion at an aisle crossing. This is not a measured test result.
Write the requirement before choosing a pass mark
“The robot notices the person” is too vague to serve as an acceptance rule.
For a perception test, define when detection is required and what counts as a valid detection. For a protective function, define the required system response under the relevant conditions. These are different tests.
A detector can produce the right output while another component responds too late. A successful detection therefore cannot establish stopping performance.
Have the responsible engineer approve the requirement and its acceptance limits before running the evaluation. Record the source of each limit. A convenient number chosen after testing is not a requirement.
Leave missing limits visibly unresolved. A test without an approved acceptance rule cannot receive a pass verdict.
Build one scenario that you can explain
Use a simple starting case before adding variations. Record the robot configuration, sensor placement, load, environment, and human movement. Save the software versions and initial conditions needed to repeat it.
For the aisle example, this worksheet connects the hazard to the evidence:
Field | Illustrative entry |
|---|---|
Task | Transport a load through an aisle crossing. |
Hazardous situation | A person enters space occupied by the moving robot or its load. |
Condition under investigation | A cart partly blocks the camera's view of the person. |
Requirement reference | The project's approved human-detection requirement; identifier still to be assigned. |
Test boundary | Recorded sensor input and detector output. Braking is outside this test. |
Fixed conditions | Robot configuration, camera calibration, route, detector version, and scoring rules. |
Controlled variation | Cart position and the resulting visibility of the person. |
Measurements | Missed detections and time to a valid detection within the defined evaluation interval. |
Acceptance rule | The responsible engineer must supply approved limits before evaluation. |
Evidence | Inputs, labels, timestamps, configuration, outputs, and a reviewable result record. |
Limit | This test alone does not establish protective-stop performance. |
Use a separate record for the complete protective function. That record needs evidence across sensing, control, actuation, and the relevant physical behavior.
Vary conditions with a reason
Changing everything at once makes a failure hard to explain. Start with controlled comparisons, then test interactions between relevant conditions.
For example, compare an unobstructed view with a partly blocked view while keeping the route and lighting fixed. Then examine whether a lighting change affects both cases.
Choose variations from the assessment, operating conditions, and known weaknesses. A worker bending behind the cart may test a different limitation from a worker crossing upright. A larger collection is useful only when its cases answer relevant questions.
Record what you did not cover. One crossing does not represent every aisle layout, load, person, or approach direction.
Conceptual illustration: occlusion, lighting, and posture variations. These scenes do not show measured results.
How can simulation support a robot risk assessment?
Simulation supports a robot risk assessment by testing specific assumptions and requirements. It can make controlled comparisons easier to repeat. It also adds assumptions about sensors, materials, motion, and the environment. Check which assumptions matter for the requirement under test.
Replaying a fixed person trajectory can test a particular encounter. It does not show how that person would react to a different robot action. An interactive test needs a model that responds, with its own limits documented.
For stopping behavior, a convincing animation is insufficient. The model and test must cover the relevant response delays and physical behavior. Physical validation remains necessary where required by the application and applicable standards.
The OSHA guidance makes a related point: visual inspection alone cannot validate an integrated robotic system.
Make the result useful to the next engineer
A useful result explains what changed and what decision follows. “The test passed” hides too much without the requirement, configuration, and acceptance rule.
Record the following beside each verdict:
The exact requirement and test version.
The conditions tested and the conditions excluded.
The measured result and approved acceptance limit.
Invalid runs, missing data, and known model limits.
The reviewer and any required follow-up.
If the partly blocked case fails, preserve it for later comparisons. After a fix, rerun the failing case and the relevant existing cases. Check whether the change introduced a different problem.
What this example can establish
This method makes a narrow claim traceable: a defined test checked a defined requirement under recorded conditions. It does not establish a field failure rate, complete hazard coverage, or certification.
That narrower claim is still useful. It gives the safety owner a reviewable record and gives the engineer a specific problem to investigate.
Use the hazard-to-test worksheet to prepare your first record. For the perception evaluation, read how to test human detection.
SafeWorld develops simulation and testing tools for robots working around people. Bring us one task, one hazard, and the decision your team needs to make. We can discuss a useful scenario and the evidence it should produce.