Overview
Safety Goal work items represent the top-level safety objectives that mitigate identified hazards. Custom fields capture the safety goal identifier, ASIL classification inherited from parent hazards, the required safe state definition, and the fault-tolerant time interval (FTTI) for achieving that safe state. Together, these fields ensure compliance with ISO 26262-3 (Concept Phase) and establish the foundation for allocating functional safety requirements to system components.
Safety Goal ASIL is inherited from the parent Hazard via the ‘derives’ link role. PowerSheet and Risksheet formulas auto-compute this inheritance, ensuring consistency across the safety lifecycle. Never manually override Safety Goal ASIL unless formally justified and documented.
Field Specifications
| Name | Type | Default | Description |
|---|
sgId | String | (empty) | Unique Safety Goal identifier following ISO 26262 numbering conventions (e.g., SG-01, SG-02, SG-03). Used in traceability matrices, reports, and RTM expansion hierarchies. May be auto-generated via sequence or manually assigned during HARA review. This field enables cross-referencing safety goals in specifications, design documents, and audit trails. Example format: SG-{hazard-index:02d}. |
sgAsil | Enum (hara-asil) | QM | ASIL Classification (QM, ASIL A, ASIL B, ASIL C, ASIL D) inherited from parent Hazard analysis. Represents the required development rigor level and verification/validation intensity. Automatically computed via PowerSheet formula from parent Hazard ASIL or manually assigned during safety concept review. Drives downstream requirement allocation, FMEA scope, and test planning. See ASIL Classification for detailed definitions. |
sgState | Text (2000 char) | (empty) | Free-text description of the safe state that the system must reach or maintain when this safety goal is violated or the hazard is detected. Must define the specific safe condition, fallback behavior, or failsafe action required by the functional safety concept. Examples: ‘Vehicle enters limp-home mode with reduced braking authority’, ‘System transitions to monitoring-only with operator alert’, ‘Engine output is reduced to idle and steering assist disabled’. The safe state must be reachable within the FTTI and achievable with the available system resources. |
ftti | String | (empty) | Fault Tolerant Time Interval: maximum permissible duration between fault detection and transition to safe state, expressed with units (e.g., ‘100ms’, ‘2.5s’, ‘500µs’). Derived during ISO 26262 architectural analysis and constrained by vehicle dynamics, braking distance, or other operational safety margins. Example: for AEB system, FTTI ≤ 100ms ensures sufficient braking distance at highway speeds. Used to derive diagnostic coverage and control strategy timing requirements. Must be technically justified and documented in safety analysis. |
Field Relationships and Workflow
The Safety Goal custom fields form a cohesive model for capturing safe-state requirements that bridge hazard analysis and functional architecture:
Safety Goal ASIL is never independently determined—it is derived from the parent Hazard’s ASIL classification via the ‘derives’ link role. Risksheet and PowerSheet formulas auto-compute this using a MAX() aggregation to ensure the Safety Goal inherits the highest ASIL if multiple hazards derive it:
sgAsil = MAX(parent_hazard.asil, parent_hazard_2.asil, ...)
- ASIL D safety goals from ASIL D hazards are never downgraded
- Multiple hazards mapping to the same safety goal preserve the highest ASIL
- PowerSheet formatters render ASIL badges with color-coding (QM=green, A=yellow, B=orange, C=light red, D=dark red)
If a Safety Goal’s computed ASIL differs from expectations, investigate the parent Hazard classification—do not override at the Safety Goal level. ASIL inheritance ensures traceability and compliance audits remain consistent across the safety lifecycle.
Safe State Definition (sgState)
The safe state is the cornerstone of functional safety design. A complete safe-state description must specify:
- What condition is achieved — the specific safe state (e.g., ‘vehicle braking disabled’, ‘engine at idle’, ‘sensor fusion inactive’)
- How it is reached — the architectural transition mechanism (e.g., ‘via watchdog timeout’, ‘upon redundancy failure detection’)
- System resources available — whether the safe state relies on powered actuators, springs, friction, or gravity
- Occupant impact — consequences for driver and passengers (e.g., ‘reduced deceleration of 0.3g’, ‘no steering assistance’, ‘warning light displayed’)
Safe State Examples
| Hazard | Safe State | FTTI | Technical Justification |
|---|
| Power supply loss to braking ECU | Vehicle enters failsafe braking mode using redundant hydraulic circuit; ABS disabled | 50ms | Failsafe design allows unpowered braking; within AEB braking distance requirement |
| Sensor fusion fault detection | System transitions to monitoring-only mode; operator alert generated; autonomous braking inhibited | 100ms | Diagnostic coverage 99% ensures rapid detection; alert gives driver control authority |
| Loss of CAN bus heartbeat | Engine output reduced to idle; brake apply commanded; steering assist disabled | 200ms | Hybrid redundancy: mechanical engine governor + electro-hydraulic brake backup |
| Degraded object classification accuracy | AEB engagement inhibited; visual/audible warning; system logs event | 150ms | Diagnostic monitors feature confidence threshold; operator retains full steering/braking |
Fault-Tolerant Time Interval (ftti) Derivation
FTTI is the maximum allowable time from fault occurrence to safe state entry. It is derived from vehicle dynamics, operational scenarios, and safety margins during ISO 26262 architectural analysis and constrained by:
Physical Constraints
- Braking distance: AEB system at highway speeds requires ≤ 100–150ms to command brake apply and remain within acceptable stopping distance
- Steering response: Lane-keeping systems with steering actuation may tolerate 200–500ms before driver can manually correct
- Sensor latency: Fusion algorithm processing time consumes part of the available FTTI budget
Diagnostic Requirements
FTTI directly drives the required diagnostic coverage and test interval:
Diagnostic Coverage Requirement = 1 - [Failure Rate × (FTTI + Test Interval) / 2]
Typical FTTI Values (Automotive)
| System Function | Typical FTTI | Rationale |
|---|
| Autonomous Emergency Braking (AEB) | 50–100ms | Preserve braking distance at 100+ km/h; ~28m per 100ms at highway speeds |
| Lane-Keeping Assist (LKA) | 200–500ms | Steering wheel torque feedback alerts driver; manual intervention available |
| Adaptive Cruise Control (ACC) | 300–1000ms | Slower speed profiles allow longer fault-to-safe-state transition |
| Power Steering Loss | 100–200ms | Manual steering still available with increased effort; gradual power loss acceptable |
| Engine Control Loss | 500–2000ms | Limp-home strategies tolerate longer transition; mechanical throttle backup available |
FTTI represents a time budget shared among: fault detection delay (sensor latency), diagnostic confirmation (voting windows), safe state computation, and actuator response time. When designing the functional safety architecture, allocate the FTTI across each stage and document assumptions.
Integration with RTM Model and PowerSheet
Safety Goal custom fields are tightly integrated with the RTM (Requirements Traceability Model) and PowerSheet configurations:
PowerSheet Column Binding
Safety Goal fields appear in PowerSheet configurations for traceability and safety requirement allocation:
| PowerSheet | Column Group | Visible Fields | Purpose |
|---|
| Whole RTM | Functional Safety | sgId, sgAsil, sgState | Show safety goal inheritance from hazards; link to functional requirements |
| System Verification | Safety Allocation | sgId, ftti | Verify that diagnostic and actuator response times meet FTTI budgets |
| Design Verification | Safe State Requirements | sgState, sgAsil | Trace safety goals to design requirements and architectural mechanisms |
Risksheet Integration
In HAZID/HARA Risksheet documents, Safety Goal fields are often rendered as a single “Safety Goal” column group containing read-only summaries pulled from linked Safety Goal work items:
columnGroup:
name: "Safety Goals"
columns:
- name: "SG ID"
source: "sgId"
width: "80px"
readonly: true
- name: "SG ASIL"
source: "sgAsil"
width: "80px"
decorator: "asil-badge" # Color-coded by ASIL level
readonly: true
- name: "Safe State"
source: "sgState"
width: "300px"
readonly: true
Custom Field Examples in Context
Example 1: AEB System Power Supply Failure Safety Goal
Work Item: Safety Goal SG-02
Title: "Ensure power loss does not prevent emergency braking"
sgId: SG-02
sgAsil: ASIL B
sgState: "Upon loss of primary power to AEB ECU, vehicle shall command emergency
braking via backup hydraulic solenoid valve within 50ms and maintain
deceleration capability of 0.4g for minimum 5 seconds or until vehicle
stops. Driver shall receive audible and visual alert indicating AEB
engagement and limited steering assist availability."
ftti: "50ms"
Parent Hazard: HAZ-03 "Power supply failure to braking subsystem"
Derived Requirements:
- FSR-42: Dual-channel power supply with watchdog monitoring
- FSR-43: Fail-safe solenoid valve design for brake pressure application
- FSR-44: Diagnostic self-test of backup power path on startup
Example 2: Sensor Degradation Safety Goal
Work Item: Safety Goal SG-05
Title: "Maintain sensor reliability through diagnostics and redundancy"
sgId: SG-05
sgAsil: ASIL D
sgState: "If sensor fusion confidence metric falls below 95% or any individual
sensor reports fault, system shall:
1. Inhibit autonomous braking (AEB function off)
2. Issue visual/audible warning (3-second alert cycle)
3. Log fault event with timestamp and sensor status
4. Retain manual braking and steering full authority
5. Transition to standby monitoring mode"
ftti: "100ms"
Technical Justification:
- Diagnostic coverage: 98.5% (dual-sensor cross-check)
- Sensor self-test interval: 50ms (within FTTI budget)
- Hardware redundancy: triple-modular voting (TMV) for safety-critical path
- Operator control: steering/brake always available for manual intervention
Validation and Compliance Checklist
When creating or reviewing Safety Goal custom fields, verify:
