It works in a fixed sequence: the item is defined, operational situations and driving scenarios are enumerated, malfunctioning behaviours of the item are identified, and their combinations yield hazardous events — a vehicle-level hazard occurring in a specific situation. Each hazardous event is then rated on three parameters: Severity (S0–S3) for the harm that could result, Exposure (E0–E4) for how often the situation arises, and Controllability (C0–C3) for whether the driver or others involved can avert that harm. The combination maps to one of ASIL A–D — or to QM, where normal quality management suffices — and every hazardous event carrying an ASIL receives a Safety Goal, the top-level safety requirement from which the Functional Safety Concept, Technical Safety Concept, and all downstream hardware and software requirements are derived. HARA applies to any item in scope of ISO 26262 — series-production road-vehicle electrical and electronic systems — and is performed by whoever defines the item, typically the OEM or the Tier-1 developing the system. It is the safety twin of the TARA in ISO/SAE 21434: HARA asks what happens if the system malfunctions, TARA asks what happens if someone attacks it, and on modern programmes the two share the item definition and are reviewed jointly, because an attack that triggers a hazardous event inherits the severity the HARA already assigned to it.
Why it matters
The HARA fixes the ASIL, and the ASIL scales the cost and rigour of nearly everything downstream — hardware fault metrics, software coverage targets, Tool Qualification, and the depth of the Safety Case. Over-rating a hazard buys unnecessary engineering effort; under-rating one leaves a compliance gap an assessor will find. And because safety and cybersecurity converge on the same functions, a HARA that is inconsistent with the TARA produces contradictory evidence that surfaces at the worst possible time: during assessment.