A Hazard and Risk Assessment (HARA) is the structured process of identifying what can go wrong with a system, evaluating the consequences, and determining what level of risk reduction each hazard requires.
It’s the first functional safety activity and the most consequential one. Every safety requirement flows from the HARA. Every safety function design is justified by the HARA. Every reliability target traces back to it. Get the HARA wrong, and everything downstream is built on a flawed foundation. Get it right, and the rest of the safety program has a clear, defensible starting point.
This is a practical guide to conducting a HARA for robotics and automation systems using the ISO 12100 methodology.
| HARA step | What happens | Output |
|---|---|---|
| 1. Define intended use and foreseeable misuse | Document all operational scenarios, interfaces, and predictable misuse | System boundary definition |
| 2. Identify hazards | Systematically enumerate all hazard categories for the system type | Hazard list |
| 3. Assess severity | Score the worst-case consequence of each hazard | Severity ratings (S1-S3 or similar scale) |
| 4. Assess probability | Estimate likelihood of exposure and occurrence | Probability ratings |
| 5. Determine required risk reduction | Apply risk graph or risk matrix to derive required PL or SIL | Safety integrity requirements |
| 6. Define safety functions | Specify the function that will reduce each hazard to acceptable risk | Safety function list with integrity targets |
Before you start: define the system boundary
A HARA can only be thorough if the scope is clear. Before identifying hazards, define:
Intended use. What is the system designed to do, in what environment, with what human interfaces? An AMR operating in a shared human-worker facility has a different hazard profile than the same AMR in a lights-out warehouse. The intended use defines which hazards are relevant.
Reasonably foreseeable misuse. ISO 12100 requires considering not just intended use but any use the manufacturer can reasonably anticipate, including predictable errors. An operator who tries to manually redirect an AMR. A technician who bypasses a guard to access a stuck part. These scenarios generate hazards that must be analyzed even if the user manual says not to do them.
System interfaces. Where does your system interact with other systems, with humans, or with the environment? Each interface is a potential hazard source. Missing an interface means missing the hazards it creates.
For robotics teams, this means specifying: payload, speed, reach envelope, sensing modalities, communication interfaces, power systems, environmental range, and human interaction modes (supervised, collaborative, autonomous).
Step 1: Identify hazards systematically
Hazard identification for robotics systems covers predictable failure modes across several categories. Working through these categories systematically prevents the gaps that come from brainstorming alone.
Mechanical hazards: Crushing, shearing, cutting, entanglement, impact, friction, high-pressure fluid ejection. Any physical interaction between the robot and a person or another object.
Electrical hazards: Electric shock, short circuit, electromagnetic interference, fault current paths.
Kinetic hazards: Unexpected motion, loss of braking, runaway behavior, path deviation during navigation or manipulation.
Software and control hazards: Sensor failure, communication loss, incorrect perception, command execution after a stop command, software state errors leading to unexpected motion.
Interaction hazards: Human-robot collaboration scenarios where the robot may not detect a person in its workspace, or where its motion prediction assumptions about human behavior fail.
Environmental hazards: Wet floors, electromagnetic interference from other equipment, temperature extremes, lighting conditions that degrade sensing.
Each identified hazard gets an entry in the hazard log with a unique identifier, description, affected scenario, and initial severity estimate.
Step 2: Assess severity and probability
ISO 12100 uses a two-dimensional risk estimation. Each hazard gets assessed on:
Severity of harm (S): How bad is the worst-case outcome if this hazard results in an incident?
- S1: Slight (reversible injury, no lost time)
- S2: Serious (irreversible injury, permanent disability)
- S3: Death (one or more fatalities)
Probability of occurrence: A combination of frequency of exposure, likelihood of the hazardous event occurring given exposure, and probability of avoiding harm once the event occurs.
The risk graph or risk matrix combines these estimates to derive a required risk reduction level. For ISO 13849, this maps to required Performance Level (PLa-PLe). For IEC 61508, it maps to required Safety Integrity Level (SIL 1-4).
This step requires judgment. Two engineers working from the same failure mode data may assign different severity or probability values. That’s expected. Document the reasoning. The assessor will evaluate the logic, not just the numbers. Undocumented rationale is a gap that generates questions.
Step 3: Define safety functions
For each hazard with a required risk reduction level, you need a safety function — a designed system capability that achieves the required risk reduction when it operates correctly.
Safety functions for robotics commonly include:
- Safe stop functions: Bring the robot to a safe state when a triggering condition is detected (person in workspace, communication loss, sensor fault)
- Safe speed monitoring: Prevent operation above a speed threshold during human-robot collaboration modes
- Safety-rated soft axes and space limiting: Constrain motion to pre-defined safe zones
- Emergency stop (E-stop): Manual stop by any person in the vicinity
- Enabling device monitoring: Require continuous intentional input for certain operating modes (teaching, manual guidance)
Each safety function needs a target PL or SIL derived from the hazard analysis. This becomes the requirement that drives the reliability design, which gets verified by the reliability calculation (PL calculation per ISO 13849, SIL verification per IEC 61508).
A safety function without a specified integrity target is incomplete. An integrity target without a documented link to the hazard that requires it is undefended.
What makes HARA results defensible
The HARA is the document an assessor examines most carefully, because it’s the foundation for everything else. Three properties that determine whether a HARA holds up:
Completeness. Every reasonably foreseeable hazard is identified. Teams that brainstorm ad-hoc miss hazards at system interfaces, under failure conditions, and in reasonably foreseeable misuse scenarios. Systematic enumeration by category — mechanical, electrical, kinetic, software, interaction, environmental — catches hazards that freeform lists miss.
Consistent methodology. The same risk estimation approach is applied to every hazard. If you use the ISO 13849 risk graph for one hazard and a qualitative matrix for another, the assessor will ask why. Consistent methodology produces a defensible, comparable set of results.
Documented rationale. Why did you assess H-023 as S2 rather than S3? Why is the exposure probability rated as rare rather than frequent for this hazard? The reasoning behind each assessment needs to be explicit. Conclusions without reasoning generate follow-up questions. Reasoning alongside conclusions answers them before they’re asked.
Amazon’s methodology for the ASAP platform was developed over five years protecting more than 1 million robots in 24/7 operation. ASAP provides an ISO 12100-compliant HARA workflow with pre-configured templates for AMR, cobot, and humanoid robot applications. The hazard categories, risk parameters, and required documentation are built in. The live risk assessment updates dynamically when mitigations are added, so the relationship between residual risk and implemented safety functions is always current.
Teams using pre-configured HARA templates aren’t constrained — they’re starting from a validated baseline and customizing for their specific system rather than building the framework from scratch on every project.
FAQ: How to Conduct a HARA
What is a HARA in functional safety?
A Hazard and Risk Assessment (HARA) is the structured analysis of what can go wrong with a system, what the consequences are, and how much risk reduction is required. It’s conducted at the start of the safety lifecycle and produces the hazard list, risk estimates, and safety integrity requirements that drive every subsequent safety engineering activity. Under ISO 12100, it’s the required risk assessment methodology for machinery and robotics.
What is the difference between a HARA and an FMEA?
A HARA identifies hazards at the system level and determines required risk reduction. An FMEA (Failure Mode and Effects Analysis) analyzes individual component failure modes and their effects on the system. A HARA answers “what hazards does this system create?” An FMEA answers “what happens when this component fails?” Both are used in functional safety, often in sequence: HARA first to establish safety requirements, FMEA later to verify the design meets them.
What methodology should I use for a HARA on a robotics system?
ISO 12100 defines the risk assessment methodology for machinery, which includes most robotics and automation systems. It’s the standard reference. For the risk estimation (severity × probability), you can use the ISO 13849 risk graph to derive required Performance Level, or a risk matrix approach tied to IEC 61508 for systems requiring SIL assessment. The methodology should be documented and applied consistently across all hazards.
How detailed should a HARA be?
Detailed enough that an independent assessor can follow the logic from hazard identification through risk estimation to the derived safety integrity requirement without asking for additional information. That means: unique identifiers for each hazard, explicit severity and probability reasoning, a documented risk estimation, and a derived safety integrity requirement. “Detailed” doesn’t mean exhaustive, it means complete and defensible.
What are the most common HARA mistakes?
Incomplete hazard identification (missing interaction hazards or software failure modes), undocumented rationale for severity and probability ratings, inconsistent methodology across different hazards in the same analysis, and failure to update the HARA when the design changes. Any of these can surface during assessment as gaps that require explanation and may require rework.
This post covers general functional safety engineering principles and is for educational purposes only. It is not engineering advice. Consult a qualified functional safety professional and your applicable standards body before making safety-critical design decisions.
ASAP provides an ISO 12100-compliant HARA workflow with pre-configured templates for AMR, cobot, and humanoid applications. The live risk assessment updates dynamically as mitigations are added. See the platform.