Report Purpose and Compliance
The HARA (Hazard Analysis and Risk Assessment) report fulfills ISO 26262 Part 3 requirements for:
- Systematic hazard identification across all operational situations
- Risk classification using the S × E × C matrix (Severity, Exposure, Controllability)
- ASIL determination (Automotive Safety Integrity Level: QM, A, B, C, D)
- Safety goal derivation linking each hazard to its corresponding safety requirement
- Traceability from hazard to ASIL to safety goal to downstream verification
The report auto-generates from your Risksheet HARA analysis and validates completeness of all classifications before rendering.
Report Structure
1. Executive Summary
| Component | Description |
|---|
| ASIL Distribution Summary | Pie chart and percentage breakdown of all hazards by ASIL level (QM, A, B, C, D) |
| Project Risk Profile | Color-coded summary cards showing count and percentage of each ASIL level |
| Assessment Completeness | Warning indicators if any hazards lack S/E/C ratings or ASIL assignment |
| High-Integrity Requirements Alert | Alert box if ASIL C or D hazards present, listing required actions |
2. Classification Reference Tables
Severity Scale (S0–S3)
| Level | Injury Outcome | Definition |
|---|
| S0 | No Injuries | Hazardous event causes no injuries. |
| S1 | Light Injuries | Minor injuries (e.g., whiplash, minor abrasions) not requiring medical intervention. |
| S2 | Serious Injuries | Serious injuries (e.g., broken bones, concussion, temporary disability) requiring hospitalization. |
| S3 | Fatal or Life-Threatening Injuries | Injuries with potential for fatality or permanent disability (e.g., head trauma, spinal injury, loss of consciousness). |
Assess severity as the worst-case harm that could result from the hazard in the absence of any safety mechanism. Severity is independent of how likely the hazard is to occur; it reflects only the consequence magnitude. For automotive systems, consider injury outcomes per ISO 26262-3 Table B.1.
Exposure Scale (E0–E4)
| Level | Probability of Operational Situation | Definition |
|---|
| E0 | Incredible | Operational situation virtually never occurs during vehicle lifetime (e.g., extreme weather + sensor failure + driver distraction simultaneously). |
| E1 | Very Low | Operational situation occurs with low probability (e.g., icy roads in desert climate). Frequency: <0.001% of operating time. |
| E2 | Low | Operational situation occurs with moderate probability (e.g., parking on sloped surface). Frequency: 0.001–0.01% of operating time. |
| E3 | Medium | Operational situation occurs regularly (e.g., highway driving at night). Frequency: 0.01–0.1% of operating time. |
| E4 | High | Operational situation occurs frequently or during most of operating time (e.g., urban stop-and-go traffic). Frequency: >0.1% of operating time. |
Exposure probability should account for all operational scenarios where the hazard can manifest. Consider vehicle use cases (urban vs. highway), driving conditions (day/night, wet/dry, seasonal), and temporal factors. Document the scenario basis—for AEB, high-frequency scenarios include stop-and-go urban traffic (E4) and following scenarios on highways (E3).
Controllability Scale (C0–C3)
| Level | Driver Controllability | Definition |
|---|
| C0 | Controllable in General | Hazard can be controlled in general by the average driver. >99% of drivers successfully avoid harm. No special skill or attention required. |
| C1 | Simply Controllable | Hazard is simply controllable with minimal driver effort or attention. >99% of drivers successfully respond. Examples: steady steering correction, gradual speed adjustment. |
| C2 | Normally Controllable | Hazard is normally controllable by most drivers under normal conditions. >90% of drivers successfully respond. Examples: moderate steering correction, moderate braking. May challenge inexperienced drivers. |
| C3 | Difficult to Control or Uncontrollable | Hazard is difficult to control or completely uncontrollable by drivers. <90% driver controllability. Examples: total brake failure at highway speed, complete steering loss, sudden loss of engine power on mountain road. |
Controllability depends on: (1) awareness time (how long driver has to recognize the hazard), (2) reaction time available (milliseconds to seconds), (3) action complexity (simple vs. complex control input), and (4) environmental conditions (wet road, ice, darkness). ISO 26262 assumes an average, attentive driver under normal conditions. Degraded controllability (C2/C3) typically requires design-level risk controls or safety mechanisms.
3. ASIL Determination Matrix
The ASIL matrix is the normative lookup per ISO 26262-3 Table 4, determining ASIL outcome for all combinations of Severity, Exposure, and Controllability:
| Severity \ Controllability | C1 (Simply) | C2 (Normally) | C3 (Difficult) |
|---|
| S1 (Minor), E4 | QM | ASIL A | ASIL B |
| S2 (Moderate), E4 | ASIL A | ASIL B | ASIL C |
| S3 (Severe), E4 | ASIL B | ASIL C | ASIL D |
| S3 (Severe), E3 | ASIL A | ASIL B | ASIL C |
| S2 (Moderate), E3 | QM | ASIL A | ASIL B |
| S1 (Minor), E3 | QM | QM | ASIL A |
| Level | Risk Profile | Requirements |
|---|
| QM | No ASIL | No functional safety requirement; manage via normal quality processes. |
| ASIL A | Lowest Safety Integrity | Single-point faults permitted; periodic diagnosis acceptable. Design reviews, basic traceability. |
| ASIL B | Low–Medium Safety Integrity | Single-point fault mitigation recommended; periodic or continuous diagnosis. Formal design reviews, comprehensive traceability, verification evidence. |
| ASIL C | Medium–High Safety Integrity | Single-point fault mitigation required; continuous diagnosis or redundancy. Formal V&V, safety mechanisms mandatory, ISO 26262 Part 6 (Software) requirements apply. |
| ASIL D | Highest Safety Integrity | Dual-point fault mitigation required; continuous diagnosis with fast reaction time. Full ISO 26262 compliance (Parts 2–10), independent safety mechanism, comprehensive verification, traceability audit. |
For any hazard classified as ASIL C or D, the following actions are mandatory:
- Develop safety goals — Explicit functional safety requirements to prevent or control the hazard
- Implement safety mechanisms — Design-level or operational mitigations (e.g., redundant sensors, diagnostics)
- Ensure verification coverage — All safety requirements must have corresponding verification test cases
- Maintain traceability — Documented links from hazard → safety goal → risk control → verification → validation
- Document compliance evidence — Design reviews, FMEA, failure mode analysis, functional safety concept, safety specifications
4. Hazard Register (Main Table)
The hazard register is the core table listing all hazards with classifications:
| System Element | Hazardous Situation | Severity | Exposure | Controllability | ASIL | Safety Goal(s) | Status |
|---|
| Sensor Module | Power supply failure to AEB ECU | S3 | E4 | C1 | ASIL D | SG-01: Ensure continuous power availability | Documented |
| Obstacle Detection | Failure to detect obstacle in braking zone | S3 | E3 | C3 | ASIL D | SG-02: Ensure obstacle detection reliability | Documented |
| Brake Control | Insufficient braking force application | S3 | E3 | C2 | ASIL C | SG-03: Ensure adequate braking force | Documented |
| Sensor Fusion | Degraded sensor fusion with insufficient AEB capability | S2 | E4 | C1 | ASIL B | SG-04: Ensure sensor fusion availability | Documented |
| Timing | Delayed braking activation (>100 ms) | S3 | E3 | C2 | ASIL C | SG-05: Ensure timely AEB activation | Documented |
5. Safety Goals Section
| Safety Goal ID | Associated Hazards | Safety Goal Description | Derived ASIL | Verification Method | Status |
|---|
| SG-01 | Power-Supply-Failure | Ensure continuous electrical power to AEB system throughout mission phases | ASIL D | Redundant power supply + diagnostic self-test | Open |
| SG-02 | Obstacle-Detection-Failure | Obstacle detection system shall achieve ≥99.9% detection probability for vehicles within 80 m | ASIL D | SIL-rated sensor module + field test validation | In Progress |
| SG-03 | Insufficient-Braking-Force | AEB braking force shall meet or exceed specification across temperature and pressure ranges | ASIL C | Component FMEA + test bench validation | Documented |
Each safety goal addresses one or more hazards and inherits the maximum ASIL of its associated hazards. Safety goals become functional requirements in the System Specification and drive design verification. Ensure every hazard (especially ASIL B/C/D) has at least one linked safety goal.
Key Properties and Enumerations
HARA Custom Fields
| Field | Type | Enum | Usage |
|---|
haraseverity | Enum | S0, S1, S2, S3 | Pre-mitigation harm magnitude; required for all hazards |
haraExposure | Enum | E0, E1, E2, E3, E4 | Operational situation probability; required for all hazards |
haraControllability | Enum | C0, C1, C2, C3 | Driver controllability; required for all hazards |
asil | Computed | QM, A, B, C, D | Auto-derived from S × E × C lookup; read-only |
operationalSituation | Text | (free) | Description of the scenario where hazard can occur (e.g., “urban stop-and-go traffic at night”) |
operationalPhase | Enum | (project-defined) | Vehicle lifecycle phase: ignition, normal driving, parking, maintenance, deactivation |
hazardSource | Text | (free) | Root cause or triggering mechanism (e.g., “sensor degradation due to dirt/ice buildup”) |
hazardMechanism | Text | (free) | Sequence from source to hazardous event (e.g., “source → loss of signal → ECU timeout → braking disabled”) |
hazidCause | Text / Link | (free or work item) | HAZID-phase cause description; evolves to linked Cause work items in formal FMEA |
hazidConsequence | Text / Link | (free or work item) | HAZID-phase consequence; evolves to linked Harm work items with severity |
Safety Goal Custom Fields
| Field | Type | Enum | Usage |
|---|
sgAsil | Enum | QM, A, B, C, D | Inherited from linked hazards; maximum ASIL if multiple hazards |
sgState | Enum | (project-defined) | Workflow: Draft, Under Review, Approved, Verified, Validated |
ftti | Integer | (milliseconds) | Fault Tolerance Time Interval—maximum allowed time from fault detection to safe state |
safetyMechanism | Text / Link | (free or work item) | Design approach or architecture to achieve the safety goal |
Common Workflow Patterns
Pattern: Assess a New Hazard
- Create hazard work item in Risksheet HARA view
- Enter hazardous situation description and system element
- Assign severity (S) from enum: consider worst-case harm (S1–S3)
- Assign exposure (E) from enum: estimate operational situation frequency (E1–E4)
- Assign controllability (C) from enum: evaluate driver response capability (C0–C3)
- Review auto-calculated ASIL (S × E × C matrix lookup)
- If ASIL ≥ B: Derive at least one safety goal; plan risk controls
- If ASIL = D: Flag for design review; safety mechanisms mandatory
Pattern: Derive Safety Goals from Hazards
- Review all hazards sorted by ASIL (highest first)
- For each ASIL C/D hazard, create safety goal work item
- Link safety goal to source hazard(s) via
mitigatesHazard link role
- Set safety goal ASIL to maximum ASIL of linked hazards (auto-computed)
- Document safety goal description as functional requirement (e.g., “Obstacle detection shall achieve 99.9% recall within 80 m”)
- Assign to System Specification (as requirement) and Design (as risk control)
Pattern: Complete Pre-Mitigation Assessment
- Validate all hazards have S/E/C assigned (check report alerts)
- Validate ASIL distribution (no hazards stuck in “Pending”)
- For ASIL D hazards, plan dual-point fault mitigation; document assumptions
- Cross-check with FMEA (hazards should map to top-level failure modes in System FMEA)
- Generate report and include in Concept Phase specification package (ISO 26262 Part 3 deliverable)
Report Generation and Export
The HARA report is generated via:
- Risksheet HARA view → review hazards and S/E/C classifications interactively
- Risks Space dashboard → click “ISO 26262 HARA Report” link (Velocity-rendered wiki page)
- PDF export → Polarion → Export → PDF (includes all tables, matrices, and safety goals)
The report queries:
Work Item Type: hazard
Fields: operationalSituation, haraseverity, haraExposure, haraControllability, asil
Links: mitigatesHazard (to safety goals)
Work Item Type: safetyGoal
Fields: sgAsil, sgState, title, description
Links: mitigatedByHazard (back-reference to hazards)
Validation and Completeness Checks
The report will display warnings if:
- Any hazard is missing S/E/C ratings (appears as “Pending” in ASIL column)
- ASIL C/D hazards lack linked safety goals
- Safety goals lack assigned ASIL (compute as max ASIL of linked hazards)
- ASIL D hazards lack documented safety mechanisms (check risk control links)
- Hazard completeness: Every system element should have ≥1 hazard identified
- ASIL balance: Projects with >50% ASIL D typically require extensive verification; >30% ASIL D is high-risk
- Safety goal clarity: Write safety goals as bounded functional requirements, not design solutions (e.g., ✓ “Detection probability ≥99.9%” vs. ✗ “Use redundant sensors”)
- Traceability: Link every ASIL C/D hazard to downstream design requirements, risk controls, and verification test cases
