Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
ISO 26262-4:2018 — System-Level Product Development for Automotive Functional Safety
Mastering the Technical Safety Concept, System Integration, and Safety Validation for Road Vehicles
Introduction to ISO 26262-4:2018 System-Level Development
ISO 26262-4:2018 is the fourth part of the ISO 26262 series of standards for road vehicle functional safety. It focuses on product development at the system level and serves as the critical bridge between the concept phase (ISO 26262-3) and the detailed hardware and software development phases (ISO 26262-5 and ISO 26262-6). This standard translates functional safety requirements into a concrete technical safety concept, defines the system architectural design, and establishes the integration and validation framework that ensures the final vehicle system meets its safety goals.
The system-level perspective defined in ISO 26262-4 addresses the entire item — a system or array of systems implementing a function at the vehicle level. It covers everything from specifying technical safety requirements through to vehicle integration testing and safety validation. Engineers working on electronic steering, braking, ADAS, or any safety-critical automotive system will find this standard essential for structuring their development process.
When initiating system-level development, always start by reviewing the functional safety concept from ISO 26262-3. The technical safety concept you build must directly trace back to each safety goal defined earlier.
Technical Safety Concept and System Architectural Design
Clause 6 of ISO 26262-4 defines the creation of the technical safety concept (TSC) — one of the most important work products in the entire functional safety lifecycle. The TSC specifies how the functional safety requirements will be implemented at the system level, including the allocation of requirements to hardware and software elements, the definition of safety mechanisms, and the specification of the hardware-software interface (HSI).
Key activities in this clause include:
- Specification of technical safety requirements — refining functional safety requirements into detailed technical requirements with ASIL attribution
- Safety mechanisms definition — implementing fault detection, fault handling, and driver warning mechanisms
- System architectural design — defining the system structure, elements, and their interactions
- Safety analyses — performing FMEA, FTA, or dependent failure analysis (DFA) at the system level
- Hardware-software interface (HSI) specification — documenting all interactions between HW and SW
The HSI specification is often underestimated but is critical for ASIL decomposition. If hardware and software elements are developed by different teams, the HSI must precisely define timing, memory mapping, interrupt assignments, and diagnostic interfaces to prevent integration issues.
System and Item Integration Testing
Clause 7 specifies a structured, four-level integration and testing strategy that follows the V-model approach:
| Integration Level | Description | Key Test Activities |
|---|---|---|
| Hardware-Software Integration | Testing the interaction between the hardware and software on the target ECU | Hardware-specific software tests, register tests, interrupt tests, memory tests |
| System Integration | Integrating all HW and SW elements into the complete system | Functional tests, fault injection tests, timing tests, resource consumption tests |
| Vehicle Integration | Installing the system in the vehicle and testing at the vehicle level | Vehicle-level functional tests, EMI tests, environmental tests |
| Safety Validation | Confirming that the safety goals are achieved at the vehicle level | Vehicle-level safety goal verification, hazardous event avoidance demonstration |
The integration and test strategy must specify test objectives, test methods, test environments (MIL, SIL, HIL, vehicle), and pass/fail criteria for each integration level. Test coverage is ASIL-dependent, with higher ASILs requiring more rigorous methods such as fault injection and expanded environmental ranges.
Safety Validation and Engineering Insights
Clause 8 addresses safety validation — the final confirmation that the item, when installed in the vehicle, is free from unreasonable risk. This is distinct from verification (which checks that requirements are correctly implemented). Safety validation asks: Do the implemented safety measures actually prevent hazardous events in real-world driving scenarios?
Key insights for practicing engineers:
- Validation environments must be sufficiently representative. The standard recommends using the vehicle itself, or if not possible, validated vehicle simulations or hardware-in-the-loop (HIL) systems.
- Validation specifications must cover normal driving scenarios, foreseeable misuse, and system failure modes — all derived from the hazard analysis and risk assessment (HARA) performed in ISO 26262-3.
- ASIL-dependent rigor: For ASIL D, safety validation typically requires extensive vehicle-level testing across multiple environmental conditions (temperature, humidity, road surface, etc.).
- Documentation: The safety validation report must clearly document all validation activities, results, and any deviations from expected behavior.
A well-structured safety validation campaign not only satisfies ISO 26262 requirements but also builds confidence across the organization. Many engineering teams find that safety validation reveals integration issues that unit or subsystem testing missed entirely.
Never skip or abbreviate safety validation for cost or schedule reasons. The most dangerous systematic failures are emergent properties of the integrated system that no amount of component-level testing can detect.
Frequently Asked Questions
Q: What is the difference between technical safety requirements (ISO 26262-4) and functional safety requirements (ISO 26262-3)?
A: Functional safety requirements (from ISO 26262-3) are defined at the vehicle level and specify what the system must do to achieve each safety goal (e.g., “The braking system shall engage within 200ms of fault detection”). Technical safety requirements (ISO 26262-4) refine these into implementation-specific requirements allocated to hardware and software (e.g., “The brake pedal position sensor shall be read at 10ms intervals with CRC checking”).
A: Functional safety requirements (from ISO 26262-3) are defined at the vehicle level and specify what the system must do to achieve each safety goal (e.g., “The braking system shall engage within 200ms of fault detection”). Technical safety requirements (ISO 26262-4) refine these into implementation-specific requirements allocated to hardware and software (e.g., “The brake pedal position sensor shall be read at 10ms intervals with CRC checking”).
Q: Can system integration testing be performed without a full vehicle prototype?
A: Yes. The standard allows for testing in representative environments including hardware-in-the-loop (HIL) test benches, software-in-the-loop (SIL) simulations, and validated vehicle models. However, the validation environment must be justified as sufficiently representative for the specific safety goals being evaluated.
A: Yes. The standard allows for testing in representative environments including hardware-in-the-loop (HIL) test benches, software-in-the-loop (SIL) simulations, and validated vehicle models. However, the validation environment must be justified as sufficiently representative for the specific safety goals being evaluated.
Q: How does ASIL decomposition affect the technical safety concept?
A: ASIL decomposition (ISO 26262-9, Clause 5) allows a safety requirement to be split across redundant elements. For example, an ASIL D requirement can be decomposed into ASIL C(D) + ASIL A(D) requirements. The TSC must clearly document the decomposition strategy, demonstrate independence between decomposed elements, and show that the combined residual risk meets the original ASIL D target.
A: ASIL decomposition (ISO 26262-9, Clause 5) allows a safety requirement to be split across redundant elements. For example, an ASIL D requirement can be decomposed into ASIL C(D) + ASIL A(D) requirements. The TSC must clearly document the decomposition strategy, demonstrate independence between decomposed elements, and show that the combined residual risk meets the original ASIL D target.
Q: What is a hardware-software interface (HSI) specification and why is it important?
A: The HSI specification documents all interactions between hardware and software, including register maps, interrupt assignments, memory mapping, timing requirements, and diagnostic interfaces. It is essential for coordinating HW and SW development teams, supporting ASIL decomposition arguments, and enabling independent development of HW and SW according to their respective ASILs.
A: The HSI specification documents all interactions between hardware and software, including register maps, interrupt assignments, memory mapping, timing requirements, and diagnostic interfaces. It is essential for coordinating HW and SW development teams, supporting ASIL decomposition arguments, and enabling independent development of HW and SW according to their respective ASILs.
