Robot risk assessment

Why this is the document that matters

Every robot safety standard assumes you are performing a risk assessment, and most of what they contain only makes sense as inputs to one. The assessment is not paperwork produced after the decisions are made. It is the process that makes the decisions.

This page describes how that process works and where it commonly goes wrong. It is not a compliance document and reproduces no requirements; the methodology lives in ISO 12100 and the robot-specific requirements in the ISO 10218 series, and those documents govern.

The shape of the process

The methodology is iterative rather than linear, and the iteration is the point.

• Determine the limits. What the application is, where it operates, who is near it, what it handles, over what lifecycle phases, and what reasonably foreseeable misuse looks like. Scoping errors here invalidate everything downstream.
• Identify hazards. Every way the application could cause harm, across every phase — not just normal operation.
• Estimate risk. For each hazard, the severity of harm, how often and how long people are exposed, and how likely the harm is, including how plausibly it could be avoided.
• Evaluate. Decide whether that risk is acceptable. If it is, document why. If it is not, continue.
• Reduce. Apply controls in the required order of preference, not in order of convenience.
• Re-assess. Controls introduce hazards of their own. A light curtain creates a reset procedure; a fence creates access requirements; an interlock creates a defeat incentive. Each loop must be checked.
• Validate. Confirm the controls work as assumed, in the installed application, under realistic conditions.

The hierarchy of controls

The order is mandatory in intent, and skipping down it is the most common substantive error.

1. Eliminate or design out. Change the task, the layout or the tooling so the hazard does not exist. Moving a process so nobody needs to reach into the working envelope beats every control below it.
2. Safeguard. Guards, interlocks, presence sensing, speed and separation monitoring, force limiting — engineering measures that do not depend on a person behaving correctly.
3. Inform. Warnings, signage, training, procedures. These are the weakest layer, because they depend entirely on compliance, and they are not a substitute for the two above.

Personal protective equipment sits outside the hierarchy for machinery hazards of this kind. If the answer to a crushing hazard is a hard hat, the assessment has gone wrong.

Where it typically goes wrong

• It happens after the equipment is bought. By then elimination and most design-out options are gone, and the assessment degenerates into justifying what was already purchased.
• Only normal operation is considered. Maintenance, fault recovery, teaching, cleaning and clearing jams are the phases where guarding is open and someone is inside the envelope, precisely because something has already gone wrong. An assessment that covers only the normal cycle has left out the conditions under which a person is most exposed.
• Foreseeable misuse is ignored. People take shortcuts under production pressure. An assessment that assumes procedure is followed perfectly has assumed away its own subject.
• Interlock defeat is not considered. If a guard makes a necessary task impossible, it will be bypassed. That is a design failure, not a discipline failure.
• The people who do the work are not consulted. They know the exceptions, the workarounds and the near misses. Nobody else does.
• Validation is skipped. A stop time is assumed rather than measured, a sensor's field is assumed rather than mapped, a reset is assumed to require line of sight rather than checked.
• It is never revisited. The assessment describes the application as commissioned. Tooling changes, throughput targets rise, layouts shift, and the document silently stops describing reality.

What learned software adds to the problem

Risk assessment methodology assumes the machine's behaviour can be characterised. A learned policy complicates that in ways worth naming explicitly, because the standards were not written with it in mind:

• Its behaviour outside the training distribution is difficult to characterise, and deployment produces exactly those situations.
• It may fail confidently, continuing to act after the task has already gone wrong, which defeats assessments that assume failures are detectable.
• Updating the model changes behaviour, which means the assessment's assumptions can be invalidated by a software deployment rather than by a physical change.

The practical response is to keep the learned component inside bounds something else enforces: an independent safety layer whose correctness does not depend on the policy, a validated envelope the policy cannot exceed, and version control tight enough that the machine knows whether what it is running is what was assessed.

What the assessment should actually contain

A risk assessment that cannot be audited is not much use after an incident, and "we did one" is not a record. What a usable document contains:

• The scope and limits, stated explicitly: the application, the space, the lifecycle phases covered, and what is deliberately excluded.
• Each hazard identified, with the phase it occurs in and who is exposed.
• The risk estimate for each, with the reasoning, not just a resulting score. A number without its argument cannot be reviewed.
• The controls chosen, and crucially why the measures above them in the hierarchy were rejected. "Elimination not practicable because..." is the sentence that shows the hierarchy was actually applied.
• The reliability requirement for each protective measure, and what it was implemented to.
• Validation evidence: what was measured, by whom, when, and under what conditions.
• Residual risk, stated plainly, with what the operator must do about it.
• Review triggers: what changes require the assessment to be redone.

Residual risk is not a failure

No application reaches zero risk, and pretending otherwise produces worse outcomes than acknowledging it. The purpose of the process is to reduce risk to an acceptable level and then to be explicit about what remains, so the people working near the machine know what they are dealing with.

Residual risk that has been identified, communicated and trained for is managed. Residual risk that was never written down becomes someone's surprise, usually during a fault recovery, usually at the worst moment. The honest document is the safer one.

Who should do it

Someone competent, which means knowledge of the machinery, the standards, the methodology and the actual task — and ideally not the person whose budget depends on the answer. For a first deployment, involving a qualified safety engineer early is cheaper than involving one after an incident, and considerably cheaper than involving one after an inspection.

Obligations vary by jurisdiction, and what is legally required of an employer, an integrator and a manufacturer differs between them. That allocation is a question for someone who knows your jurisdiction, not for a guide.

What to ask any robotics supplier

• Which risk assessment standard do you work to, and who performs the assessment?
• Which lifecycle phases does it cover beyond normal operation?
• What is the measured stopping performance, not the rated figure?
• Which safety functions are independent of the application software?
• What happens on a software update — is the assessment revisited?
• How is a validated configuration distinguished from an unvalidated one at runtime?

A supplier who finds those questions unreasonable is telling you something useful.

Sources

• ISO — official standards catalogue