ISO 26262 Part 6 Explained – Product Development at the Software Level
Software has become the defining element of modern vehicles.
From braking and steering to battery management, powertrain control, and advanced driver assistance systems (ADAS), software now performs many of the functions that directly influence vehicle safety.
As software complexity continues to increase, so does the importance of developing it according to a structured Functional Safety process.
This is the purpose of ISO 26262 Part 6 – Product Development at the Software Level.
Part 6 defines how Software Safety Requirements are transformed into a safe software architecture, implemented using structured development practices, and verified to ensure compliance with Functional Safety objectives.
In this article, we explain the structure of ISO 26262 Part 6 and its key activities.
If you want to deepen your understanding of ISO 26262, ASPICE, Automotive Cybersecurity, and other engineering standards for safety-critical systems, explore our complete online training portfolio:
Why Software Development Matters
Unlike hardware, software does not fail because of physical wear.
Instead, software failures are typically caused by design errors, incorrect requirements, implementation mistakes, timing issues, or unexpected interactions between software components.
Without a structured software development process, organizations may face:
- incomplete or ambiguous software requirements
- unsafe software architectures
- insufficient software verification
- integration defects
- inconsistent implementation
- increased development costs
ISO 26262 Part 6 provides a systematic framework for developing embedded software that supports the overall Functional Safety objectives established during the earlier phases of ISO 26262.
Structure of ISO 26262 Part 6
Clause 5 – General Topics
Clause 5 establishes the overall framework for Product Development at the Software Level.
It defines the engineering principles that guide software development throughout the project.
Typical activities include:
- planning software development
- maintaining bidirectional traceability
- managing software interfaces
- coordinating safety activities
- supporting communication between system, hardware, and software engineering
These general topics ensure that software development remains aligned with the Technical Safety Concept and the overall Functional Safety objectives.
Clauses 6 & 7 – Software Safety Requirements and Software Architecture
The first technical step is transforming Technical Safety Requirements into Software Safety Requirements.
These requirements are then allocated to the software architecture.
Typical activities include:
- deriving Software Safety Requirements
- defining software interfaces
- developing the software architecture
- allocating requirements to software components
- establishing software communication paths
- defining software safety mechanisms
Examples of software safety mechanisms include:
- range checks
- timeout monitoring
- plausibility checks
- watchdog supervision
- memory protection
- error handling strategies
A well-designed software architecture forms the foundation for reliable implementation and efficient verification.
Clause 8 – Software Unit Design and Implementation
After the software architecture has been established, individual software units are designed and implemented.
Typical activities include:
- detailed software design
- implementation of software units
- coding according to established guidelines
- interface implementation
- internal consistency checks
ISO 26262 also recommends a variety of software development methods depending on the assigned ASIL.
These recommendations help reduce systematic software faults before they reach later verification activities.
The objective is to develop software units that are understandable, maintainable, testable, and robust.
Clause 9 – Software Unit Verification
Software implementation alone is not sufficient.
Each software unit must be verified to ensure that it satisfies its allocated Software Safety Requirements.
Typical verification activities include:
- requirements-based testing
- interface verification
- code reviews
- static analysis
- control flow analysis
- boundary value analysis
- unit testing
Verification demonstrates that the software unit has been implemented correctly before integration begins.
Detecting defects early significantly reduces both development costs and project risk.
Clauses 10 & 11 – Software Integration, Verification and Embedded Software Testing
Individual software units are then integrated into larger software components until the complete embedded software is available.
Typical activities include:
- software integration
- interface verification
- integration testing
- embedded software testing
- verification of Software Safety Requirements
- evaluation of software behavior under normal and fault conditions
These activities confirm that software components interact correctly and collectively satisfy the intended Functional Safety objectives.
Comprehensive integration testing also helps identify interface-related issues that may not be visible during unit verification.
How Part 6 Fits into ISO 26262
ISO 26262 follows a structured development lifecycle in which each part builds upon the outputs of the previous one.
The relationship can be summarized as follows:
- Part 3 establishes the Concept Phase, including HARA, ASIL determination, Safety Goals, and the Functional Safety Concept.
- Part 4 develops the Technical Safety Concept and the overall system architecture.
- Part 5 implements the hardware architecture and evaluates hardware safety.
- Part 6 develops, verifies, and integrates the embedded software that fulfills the allocated Software Safety Requirements.
Part 6 therefore represents the software implementation layer within the overall Functional Safety lifecycle.
It ensures that embedded software contributes to achieving the vehicle’s Safety Goals through structured engineering practices and comprehensive verification.
Summary
ISO 26262 Part 6 defines how Functional Safety is implemented during Product Development at the Software Level.
Its key activities include:
- General Topics
- Software Safety Requirements
- Software Architecture
- Software Unit Design and Implementation
- Software Unit Verification
- Software Integration
- Embedded Software Testing
Together, these activities establish a structured software development process that supports the creation of safe, reliable, and maintainable embedded software for automotive systems.
For Functional Safety Engineers, Embedded Software Engineers, Software Architects, Systems Engineers, and Project Managers, understanding ISO 26262 Part 6 is essential for developing safety-critical automotive software and achieving compliance with Functional Safety requirements.
