Functional Safe States and Fault Reaction Strategies
Overview
A safe state is a predefined condition that ensures the system cannot cause harm after a fault.
Each function—actuator, sensor, communication interface, or control algorithm—must define its own safe state based on its safety goals and operational context.
Safe states must be:
- deterministic
- reachable within bounded time
- verifiable
- consistent across subsystems
They represent the final step of the fault‑reaction chain:
detection → classification → reaction → safe state
Safe-State Transition Flow
Safe-state behavior is the final step of the safety mechanism chain. It depends on fault detection, classification, reaction strategy, and timing constraints defined by the system’s safety goals.
Why Safe States Must Be Defined Early
Safe states influence:
- system architecture and partitioning
- board‑level fault signaling
- power and reset strategies
- watchdog behavior
- FCCU configuration
- diagnostic coverage and timing
- actuator and sensor selection
- communication fallback modes
If safe states are defined late, the architecture may not support them, leading to redesign or non‑compliance with ASIL requirements.
Safe State Categories
Different functions require different safe states. Typical categories include:
De‑energized state
Actuators disabled or driven to zero output.
Neutral or passive state
Mechanical or electrical outputs moved to a neutral position.
Open‑circuit or high‑impedance state
Outputs disconnected to avoid unintended activation.
Fallback mode
Reduced functionality with guaranteed safety (e.g., limp‑home).
Silent communication state
Interfaces stop transmitting to avoid interference.
Reset or restart state
System rebooted into a known safe configuration.
Shutdown state
Power removed from critical domains.
Each safe state must be justified by hazard analysis and aligned with ASIL requirements.
Safe States by Function Type
Actuators
Actuators must enter a condition that prevents unintended motion or force.
- motors → disabled or torque‑free
- valves → closed or neutral position
- brakes → released or mechanically locked (depending on design)
- power stages → switched off or limited to safe current
The choice depends on hazard analysis and controllability.
Sensors
Sensors must avoid providing misleading data.
- report invalid or out‑of‑range values
- freeze output to last known safe value
- trigger fallback logic
- enter diagnostic mode
A sensor must never silently provide corrupted data.
Communication Interfaces
Interfaces must avoid transmitting unsafe or misleading information.
- enter silent mode
- transmit error frames (e.g., CAN)
- reduce bandwidth or switch to degraded mode
- disconnect from the bus if required
Communication safe states prevent propagation of faults across the system.
Control Algorithms
Control loops must avoid generating unsafe commands.
- freeze outputs
- switch to degraded control mode
- disable closed‑loop control and revert to open‑loop safe values
- trigger system‑level safe‑state transitions
Control algorithms must be designed with deterministic fallback paths.
Power and Reset Domains
Power and reset logic must ensure safe transitions.
- controlled power‑down
- reset to known safe configuration
- isolation of faulty domains
- activation of PMIC safe‑state outputs
Power management is often the final arbiter of safe‑state enforcement.
Fault Reaction Timing
Safe states must be reached within a bounded reaction time defined by:
- ASIL level
- hazard severity
- system dynamics
- mechanical inertia
- electrical response time
ISO 26262 requires that reaction times be validated through analysis and testing.
Integration with FCCU and Watchdog
Safe states are enforced through:
- FCCU reaction mechanisms (reset, safe‑state outputs, interrupts)
- watchdog expiration (software failure detection)
- PMIC fault lines (power‑related safe states)
- external watchdogs (redundant supervision)
- board‑level signaling (cross‑device coordination)
The safe state is the end point of the entire safety mechanism chain.
Relationship with Security
Safe states intersect with Security because:
- attackers may try to force or prevent safe‑state transitions
- fault injection attacks may mimic safety faults
- safe‑state outputs must be protected from spoofing
- secure boot ensures safe‑state configuration cannot be altered
Safety and security must be co‑designed to avoid conflicting behaviors.
