Safety Architecture as an Early Design Phase
Overview
Safety architecture is not a late-stage add‑on or a set of patches applied after the system is designed. It is a foundational phase that must be addressed at the very beginning of the device definition process. According to ISO 26262 and other functional safety standards, safety goals, hazard analysis, and architectural decisions must be established before hardware and software design begins. Early safety planning ensures that the system can meet its safety integrity requirements and that all components, interfaces, and diagnostics are designed with safety in mind.
Figure 1: Safety Architecture in the Design Lifecycle
Safety activities must begin at the concept phase, where item definition, hazard analysis, and safety goals are established. These early decisions drive the safety architecture, influence hardware and software design, and ensure that diagnostics, redundancy, and safe‑state behavior are built into the system from the start. Safety cannot be retrofitted; it must be part of the architecture.
Why Safety Must Be Defined Early
Safety architecture influences every aspect of the system:
- Hardware topology — redundancy, monitoring units, watchdogs, FCCU, ECC, power supervision.
- Software structure — partitioning, scheduling, safety mechanisms, timing constraints.
- Interfaces and protocols — safe-state signaling, diagnostics, plausibility checks.
- Component selection — PMICs, sensors, MCUs, actuators with safety capabilities.
- Board design — fault lines, isolation, power domains, routing constraints.
- Lifecycle and manufacturing — configuration locking, OTP programming, safety configuration.
If safety is added late, the architecture may not support the required safety integrity level (ASIL), leading to redesign, cost escalation, or non‑compliance.
ISO 26262 Perspective
ISO 26262 mandates that safety activities begin at the concept phase:
- Item definition — understanding the system’s purpose and boundaries.
- Hazard analysis and risk assessment (HARA) — identifying hazards and determining ASIL levels.
- Functional safety concept — defining safety goals and high‑level safety mechanisms.
- Technical safety concept — translating goals into architectural requirements.
- System design — implementing the architecture with safety mechanisms built‑in.
Safety is therefore a top‑down process, not a bottom‑up correction.
Strategic Safety Decisions
Early safety architecture requires making strategic decisions that shape the entire system:
- Redundancy strategy — lockstep CPUs, dual sensors, redundant communication paths.
- Diagnostic coverage — ECC, CRC, watchdogs, BIST, plausibility checks.
- Safe-state definition — what each function must do after a fault.
- Fault reaction timing — how quickly the system must detect and react to faults.
- Partitioning — separating safety‑critical and non‑critical functions.
- Monitoring infrastructure — FCCU, PMIC fault lines, external watchdogs.
- Safety mechanisms in peripherals — ADC self-tests, timer monitors, communication diagnostics.
These decisions cannot be retrofitted without major redesign.
Consequences of Late Safety Integration
If safety is treated as an afterthought:
- Diagnostics may be insufficient or impossible to add.
- Hardware may lack redundancy or monitoring capabilities.
- Safe-state transitions may not be achievable within required timing.
- Fault lines and board‑level signaling may be missing.
- Software may not meet timing or partitioning constraints.
- Certification may become impossible or prohibitively expensive.
- The system may fail to meet ASIL requirements.
Late safety integration often leads to architectural dead ends.
Safety as a Design Mindset
Safety architecture is not only a set of mechanisms—it is a mindset:
- Every function must define its safe state.
- Every interface must define its fault behavior.
- Every component must define its diagnostic coverage.
- Every subsystem must define how it reacts to faults.
- Every design choice must consider safety implications.
This mindset must be present from the first system diagrams to the final implementation.
Relationship with Security
Although safety and security are distinct domains, early safety architecture benefits from early security planning:
- Fault injection attacks resemble safety faults.
- Secure boot protects safety configuration.
- Lifecycle states prevent unauthorized modification of safety mechanisms.
- Board‑level fault lines must be protected from spoofing.
Safety and security reinforce each other when planned together from the start.
