HARA
Artifact
Topic overview
Quick facts
A HARA is a work product, not a standard. Under it evaluates hazardous events at vehicle level against severity, exposure, and controllability, producing safety goals with ratings; under machinery standards the analogous activity is the risk assessment, and rail programs perform preliminary hazard analysis feeding the safety case.
Whatever the domain, the HARA is the document that converts an open-ended question, what can go wrong, into a bounded engineering contract: this list of safety goals, at these integrity levels.
A competent HARA works from defined operational situations and operating modes, not just component failures. The same malfunction, unintended acceleration for example, carries very different risk in a parking lot versus a highway merge, and the HARA must evaluate the credible combinations rather than only the worst case or only the typical case.
Foreseeable misuse belongs in scope; deliberate sabotage generally does not.
Because every downstream safety requirement traces to it, the HARA is audited heavily during certification, and changes to it late in a program ripple through the entire requirements tree. Mature organizations treat the HARA as a living document under configuration control, revisited whenever the system's functions, operating environment, or usage assumptions change.
The case for HARA
The HARA is where a program's safety scope and cost are actually decided. Every integrity target that drives architecture, staffing, and test volume originates here, so an unexamined pessimistic HARA silently inflates the budget while an optimistic one produces a product that fails assessment or harms someone.
It is also the first document a certification body, customer safety team, or post-incident investigator reads; a thin or obviously templated HARA undermines confidence in everything built on top of it.
HARA in practice
Safety lifecycle
The HARA is produced in the concept phase, before architecture is fixed, by a cross-functional team: safety engineering facilitates, while systems, controls, and people who understand real operation and misuse contribute scenarios.
Inputs are the item definition or machine specification, intended use and environment, operating modes, and field or incident data from comparable products.
Hazards are identified systematically (guidewords, checklists, function-by-function malfunction analysis), each hazardous event is rated with the domain's parameters, and safety goals or risk reduction requirements are derived with their integrity levels.
Assessors look for completeness arguments (how the team knows it covered the function and situation space), justification of each rating parameter, consistency with field data, traceability into requirements, and evidence of review and update as the design evolved.
Where teams get HARA wrong
Standards related to HARA
ISO 26262 sets the requirements that HARA work has to satisfy: automotive functional safety standard defining asil levels and the automotive safety lifecycle.
Assessors evaluate HARA against ISO 12100, the foundational machinery safety standard establishing risk assessment methodology and the hierarchy of risk reduction.
HARA ownership and review
| Aspect | Detail |
|---|---|
| Produced by | System safety engineer with domain experts |
| Inputs | Item definition, operating scenarios, field data |
| Outputs | Hazardous events, S/E/C ratings, ASILs, safety goals |
| Reviewed by | Independent reviewer; assessor at confirmation review |
| Updated when | Item definition or usage assumptions change |
HARA by industry
Autonomous Systems programs lean on HARA because the sector covers autonomous mobile equipment, off-highway autonomy, and driverless platforms.
Industrial Machinery programs lean on HARA because the sector covers fixed and mobile machinery, packaging lines, and manufacturing equipment.
Ask our team about HARA
Ben TwomblyFounder & CEOLeads CSA's functional-safety, certification, and engineering programs for safety-critical products and organizations. His assessor-side background informs practical programs that connect standards, engineering work, and credible evidence.
Tom CyrPrincipal Safety Engineer, IFSPSupports industrial and rail functional-safety programs with safety analysis, requirements, lifecycle planning, and certification-readiness guidance.HARA: related terms
How each connects to HARA:
Functional Safety appears in the same lifecycle work as HARA and is usually produced or reviewed alongside it.
ASIL appears in the same lifecycle work as HARA and is usually produced or reviewed alongside it.
Risk Assessment appears in the same lifecycle work as HARA and is usually produced or reviewed alongside it.
Hierarchy of Risk Reduction is governed by ISO 12100 as well, which is why the two show up together in audits.
Both HARA and FMEA sit under ISO 26262, so evidence for one usually references the other.
ISO 12100 connects the two: HARA and CE Marking are assessed against the same lifecycle.
Both HARA and Functional Safety Plan sit under ISO 26262, so evidence for one usually references the other.
ISO 26262 connects the two: HARA and Safety Manager are assessed against the same lifecycle.
ISO 26262 connects the two: HARA and V-Model are assessed against the same lifecycle.
Both HARA and Functional Safety Assessment sit under ISO 26262, so evidence for one usually references the other.
ISO 26262 connects the two: HARA and Functional Safety Audit are assessed against the same lifecycle.