Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
ISO 26262-6:2018 — Software-Level Functional Safety for Automotive Embedded Systems
Software Safety Requirements, Architectural Design, Unit Implementation, and Verification for Road Vehicles
Introduction to ISO 26262-6:2018 Software Development
ISO 26262-6:2018 defines the requirements for product development at the software level within the automotive functional safety lifecycle. As modern vehicles contain over 100 million lines of code across 100+ electronic control units (ECUs), software has become the dominant contributor to both vehicle functionality and safety risk. This standard provides a comprehensive framework for developing safety-related software that meets the rigor demanded by each ASIL level.
The standard follows a V-model approach for software development, covering the complete software lifecycle from safety requirements specification through architectural design, unit design and implementation, unit verification, software integration and verification, and finally testing of the embedded software.
One of the most important concepts in ISO 26262-6 is freedom from interference (FFI) between software elements of different ASILs. If ASIL D and QM (quality management) software elements run on the same ECU, you must prove that the QM software cannot interfere with the ASIL D software in timing, memory, or information exchange.
Software Safety Requirements and Architectural Design
Clause 6 addresses the specification of software safety requirements, which are derived from the technical safety concept and the hardware-software interface specification. These requirements must be:
- Unambiguous — each requirement has a single interpretation
- Verifiable — it must be possible to confirm through review, analysis, or test that the requirement is satisfied
- ASIL-attributed — each requirement carries its ASIL classification
- Traceable — bidirectional traceability to the source requirements in the technical safety concept
Clause 7 specifies the software architectural design requirements, which define the static and dynamic aspects of the software. The architecture must address:
- Hierarchical structure of software components and their interfaces
- Data flow and control flow between components
- Resource allocation (CPU time, memory, communication bandwidth)
- Error detection and error handling mechanisms
- Freedom from interference between software elements of different ASILs
The standard requires specific design notations depending on the ASIL. For ASIL C and D, the use of semi-formal or formal notations (e.g., Simulink/Stateflow, UML with formal constraints, or AADL) is highly recommended, as shown in the following table:
| Design Method | ASIL A | ASIL B | ASIL C | ASIL D |
|---|---|---|---|---|
| Natural language with informal diagrams | ++ | + | o | o |
| Semi-formal notations (e.g., Simulink, UML) | + | ++ | ++ | ++ |
| Formal notations (e.g., VDM, SCADE) | o | o | + | + |
A common architectural error in safety-critical software is overly coupled components. When a change in one component forces changes in many others, the safety analysis becomes extremely difficult. Use well-defined interfaces and data encapsulation to minimize coupling.
Software Unit Design, Implementation, and Verification
Clause 8 covers software unit design and implementation, where the architectural components are broken down into individual software units (functions, modules, or classes). Key requirements include:
- Use of appropriate modeling, design, and programming languages with a style guide
- Adherence to coding standards such as MISRA C/C++ (which is specifically referenced in the standard’s tables)
- Implementation of defensive programming techniques (range checks, plausibility checks)
- Compliance with software unit design principles (low complexity, high cohesion, low coupling)
Clause 9 specifies software unit verification methods. The standard provides a detailed table of methods and their ASIL-dependent recommendations:
| Verification Method | ASIL A | ASIL B | ASIL C | ASIL D |
|---|---|---|---|---|
| Statement coverage | ++ | ++ | ++ | ++ |
| Branch coverage | + | ++ | ++ | ++ |
| MC/DC (Modified Condition/Decision Coverage) | o | o | + | ++ |
| Requirements-based testing | ++ | ++ | ++ | ++ |
| Back-to-back testing (model vs. code) | + | + | ++ | ++ |
For ASIL D projects, implement MC/DC coverage analysis early in the development cycle. Retrofitting MC/DC coverage to existing code is extremely difficult and often requires significant redesign of conditional logic.
Software Integration, Verification, and Embedded Software Testing
Clause 10 addresses software integration and verification, where individual software units are integrated into larger software components and then into the complete software. Integration testing must verify the functional behavior, resource consumption, and timing behavior of the integrated software. The test environment can range from SIL (software-in-the-loop) simulation to HIL (hardware-in-the-loop) testing.
Clause 11 specifies testing of the embedded software — the final software verification step before system integration. Embedded software testing must be performed on the target hardware (or a representative hardware environment) and must verify:
- Functional correctness of the embedded software
- Timing behavior under worst-case conditions
- Robustness against hardware faults (in coordination with ISO 26262-5 fault injection tests)
- Correct interaction with communication networks (CAN, LIN, FlexRay, Ethernet)
Never rely solely on simulation for ASIL C or D software testing. The target hardware introduces timing effects, memory constraints, and peripheral behavior that cannot be fully modeled in simulation. Always perform embedded software testing on the target ECU or an equivalent hardware platform.
Frequently Asked Questions
Q: What is the difference between software unit verification (Clause 9) and software integration verification (Clause 10)?
A: Unit verification tests individual software units (functions, modules) in isolation, typically using stubs and drivers on a development host. Integration verification tests the interaction between units and their correct assembly into software components and the complete software, including data flow, control flow, and timing across unit boundaries.
A: Unit verification tests individual software units (functions, modules) in isolation, typically using stubs and drivers on a development host. Integration verification tests the interaction between units and their correct assembly into software components and the complete software, including data flow, control flow, and timing across unit boundaries.
Q: Is MISRA C required by ISO 26262-6?
A: The standard does not explicitly mandate MISRA C, but it requires the use of coding guidelines. The informative tables in the standard reference MISRA C as an established coding standard. In practice, most automotive safety projects use MISRA C (or MISRA C++ for C++ projects) as their coding guideline because it is the most widely recognized and accepted standard in the industry.
A: The standard does not explicitly mandate MISRA C, but it requires the use of coding guidelines. The informative tables in the standard reference MISRA C as an established coding standard. In practice, most automotive safety projects use MISRA C (or MISRA C++ for C++ projects) as their coding guideline because it is the most widely recognized and accepted standard in the industry.
Q: Can model-based development (MBD) help with ISO 26262-6 compliance?
A: Yes, model-based development with tools like Simulink/Stateflow, SCADE, or ASCET can significantly streamline ISO 26262-6 compliance. Models serve as executable specifications that can be verified early, automatically generate production code with traceability, and support back-to-back testing between model and code. However, the modeling tools themselves must be qualified according to ISO 26262-8, Clause 11 (tool qualification).
A: Yes, model-based development with tools like Simulink/Stateflow, SCADE, or ASCET can significantly streamline ISO 26262-6 compliance. Models serve as executable specifications that can be verified early, automatically generate production code with traceability, and support back-to-back testing between model and code. However, the modeling tools themselves must be qualified according to ISO 26262-8, Clause 11 (tool qualification).
Q: What is freedom from interference (FFI) and how do I demonstrate it?
A: FFI means that a software element with a lower ASIL (or QM) cannot cause a higher-ASIL software element to fail its safety requirements. FFI must be demonstrated in three dimensions: timing (lower ASIL element cannot starve higher ASIL element of CPU time), memory (lower ASIL element cannot corrupt higher ASIL element’s memory), and information exchange (lower ASIL element cannot pass invalid data to higher ASIL element). This is typically achieved through memory partitioning (MPU/MMU), time-triggered scheduling, and interface validation.
A: FFI means that a software element with a lower ASIL (or QM) cannot cause a higher-ASIL software element to fail its safety requirements. FFI must be demonstrated in three dimensions: timing (lower ASIL element cannot starve higher ASIL element of CPU time), memory (lower ASIL element cannot corrupt higher ASIL element’s memory), and information exchange (lower ASIL element cannot pass invalid data to higher ASIL element). This is typically achieved through memory partitioning (MPU/MMU), time-triggered scheduling, and interface validation.
