Skip to main content

​
Why Safety Goals Matter

When a HARA (Hazard Analysis and Risk Assessment) identifies a hazard like “Failure to detect obstacle - no braking” with ASIL D classification, the organization faces a critical question: What must the system achieve to prevent this hazard from causing harm? The safety goal answers this question by defining a top-level safety requirement that, if satisfied, eliminates or mitigates the hazard to an acceptable residual risk level. Safety goals serve three essential purposes:
  1. Traceability anchor — They establish the starting point for the functional safety requirements hierarchy, linking hazards (the problem) to system requirements (the solution)
  2. ASIL inheritance propagator — They carry the ASIL classification from hazards down to derived functional safety requirements, ensuring appropriate development rigor is applied throughout the V-Model
  3. Verification boundary — They define what must be validated at the vehicle level to demonstrate that the hazard has been adequately controlled
Without properly derived safety goals, the gap between hazard analysis and system design becomes a traceability black hole where safety requirements lack clear justification and ASIL ratings appear arbitrary.

​
The Derivation Process

Safety goal derivation follows a structured transformation from hazard characteristics to requirement attributes: diagram

​
Transformation Rules

The derivation process applies these logical transformations:
Hazard AttributeSafety Goal AttributeTransformation Logic
hazardDescriptiontitle + descriptionInvert from negative (failure) to positive (requirement): “Failure to detect” → “Ensure detection reliability”
Computed ASILinheritedASILDirect propagation via formula: safety goal inherits parent hazard’s ASIL
operationalPhaseRequirement contextOperational boundaries become requirement preconditions or scope constraints
SeverityRequirement stringencyHigher severity (S2/S3) demands quantified reliability targets (e.g., 99.9% availability)
Exposure + ControllabilitysafeState definitionDetermines whether fail-operational, fail-safe, or fail-degraded strategies are acceptable
The safety goal must inherit the full ASIL classification from its parent hazard. Attempting to assign a lower ASIL (e.g., ASIL B safety goal for an ASIL D hazard) violates ISO 26262-3:2018 Clause 8.4.3 and creates non-compliance. The only way to reduce ASIL is through hazard decomposition with independence arguments—a separate, rigorous process requiring safety management approval.

​
Safe State and Fault Tolerance

Every safety goal must specify a safe state—the operational mode the system transitions to when it can no longer guarantee normal function. The choice of safe state depends on the hazard’s controllability and exposure profile: In TestAuto2, the safe state specification appears in the safety goal’s description field and drives architectural decisions documented in system requirements. For ASIL C/D hazards, the safe state often necessitates redundant hardware, diverse software implementations, or fail-operational architectures—requirements that must trace back to this derivation point.

​
ASIL Inheritance Mechanism

TestAuto2 implements automatic ASIL inheritance using a Risksheet formula in the HARA configuration: 
// inheritASIL formula (from HARA risksheet.json)
function inheritASIL(workItem) {
    const parentHazard = workItem.getLinkedWorkItems('derivedFrom', 'hazard');
    if (parentHazard && parentHazard.asil) {
        return parentHazard.asil;  // Propagate ASIL classification
    }
    return null;  // No parent hazard linked yet
}
This formula ensures that whenever a safety goal work item links to its parent hazard via the derivedFrom relationship, the ASIL value automatically propagates. The inheritance continues as safety goals refine into functional safety requirements (system requirements with safety classification), creating an unbroken ASIL traceability chain from hazard → safety goal → functional requirement → safety mechanism → verification test case.
Manual ASIL assignment is error-prone. If a safety engineer mistypes “ASIL C” when the hazard requires “ASIL D,” the entire downstream development process operates under incorrect assumptions about required verification rigor, fault tolerance, and diagnostic coverage. Automated inheritance eliminates this class of human error and ensures consistency across thousands of traceability links.

​
Common Misconceptions

Misconception 1: Safety goals are just requirements with a different name
Safety goals are a specific category of requirement defined by ISO 26262. They must be stated at the vehicle level (not subsystem or component level), must be verifiable through testing or analysis, and must directly address the hazard scenario. A system requirement like “The ECU shall process sensor data within 50ms” is not a safety goal because it doesn’t specify why the timing matters or what hazard it mitigates. Misconception 2: One hazard = one safety goal (1:1 relationship)
While common, this is not mandatory. A single high-level safety goal may address multiple related hazards (e.g., “Maintain braking system availability” covers power loss, hydraulic failure, and ECU malfunction hazards). Conversely, a complex hazard may require multiple safety goals to fully mitigate (e.g., sensor fusion failure might need separate goals for detection reliability, false positive prevention, and graceful degradation). Misconception 3: Safety goals must specify implementation details
Safety goals operate at the functional level, not the technical solution level. “Ensure obstacle detection reliability” is correct. “Implement dual-radar architecture with voting logic” is incorrect—that’s a design requirement derived from the safety goal. The derivation chain is: hazard → safety goal (what must be achieved) → functional safety requirement (how it will be achieved functionally) → technical safety requirement (implementation approach). Misconception 4: ASIL can be reduced through better design
ASIL reflects the hazard’s inherent severity, exposure, and controllability—characteristics of the vehicle operational scenario, not the system design. Better design reduces residual risk (demonstrated through FMEA post-mitigation ratings), but the ASIL classification remains constant. The only compliant way to reduce ASIL is through hazard decomposition with architectural independence, which requires formal safety case justification per ISO 26262-9.

​
Practical Example: AEB Obstacle Detection

Consider the TestAuto2 project’s hazard HAZ-005: “Failure to detect obstacle - no braking” with ASIL D classification: Hazard Characteristics:
  • Severity: S3 (life-threatening/fatal injuries—collision at urban speed)
  • Exposure: E4 (high probability—occurs whenever vehicle is in motion in traffic)
  • Controllability: C3 (uncontrollable—driver cannot react in time without AEB intervention)
  • Operational Phase: Urban driving at low to moderate speed
Derived Safety Goal (SG-02):
  • Title: “Ensure obstacle detection reliability”
  • Description: “The AEB system shall detect stationary and moving obstacles in the vehicle’s path with ≥99.9% reliability during urban driving scenarios (speeds 5-60 km/h) to prevent collisions. The system shall maintain fail-operational capability with degraded performance or transition to fail-safe mode with driver warning within 100ms of fault detection.”
  • Inherited ASIL: D (from HAZ-005)
  • Safe State: Fail-operational with dual-sensor redundancy; fail-safe transition to driver warning if both sensor paths fail
  • Verification Method: Vehicle-level testing per ISO 26262-4 + fault injection testing for fail-operational modes
This safety goal now serves as the parent requirement for system-level functional safety requirements like “The sensor fusion algorithm shall cross-validate radar and camera inputs with ≤20ms latency” and “The AEB ECU shall implement dual-core lockstep architecture with 99% diagnostic coverage.” Each of these derived requirements inherits ASIL D and must satisfy the corresponding development and verification rigor.

​
Visual Summary: Derivation Flow

diagram For practical application of safety goal derivation: For related conceptual understanding: For technical reference: