FuSaCert · Functional safety learning
ISO 26262 Part 6: software development and verification guide
Part 6 concerns product development at the software level. Understand each development activity through its inputs, outputs and verification basis, and connect implementation back to upstream safety requirements.
This page paraphrases the scope and activities of ISO 26262-6:2018 and adds original FuSaCert learning guidance. Practice outputs are teaching examples, not standard text, a complete deliverable list or a conformity judgement.
Where Part 6 fits in the lifecycle
Software development starts from allocated software safety requirements and design constraints, coordinating with the system level, hardware interfaces and supporting processes. Checking code alone cannot establish conformity of an entire project with ISO 26262.
Understand the safety behaviour first, then examine architectural allocation, unit implementation and verification of deviations. Study supporting activities such as software tools, configuration management and change management alongside the relevant parts.
Build a learning chain through six stages
This table follows the activities in Clauses 6 through 11 of ISO 26262-6:2018. The practice column connects activities with evidence; it is not a complete project work-product list.
| Stage and reference | Question to understand | Suggested practice output |
|---|---|---|
| Software safety requirements (Clause 6) | What safety behaviour must software implement? Are inputs, responses and interfaces clear? | A verifiable requirement and its upstream basis. |
| Software architecture (Clause 7) | How do components share requirements and control fault effects through interfaces and data flow? | Component and interface diagram with requirement allocation. |
| Unit design and implementation (Clause 8) | How does a unit implement design intent using applicable design and coding rules? | Unit design description connected to code. |
| Software unit verification (Clause 9) | How is the unit shown to satisfy its design and allocated requirements? | Justified test conditions, results and analysis. |
| Software integration and verification (Clause 10) | Do combined interfaces, interactions and architectural behaviour meet expectations? | Integration sequence, interface tests and results. |
| Testing of embedded software (Clause 11) | Does embedded software satisfy software safety requirements? | Requirement-linked tests, environment description and results. |
Practise tracing one requirement
Teaching task: take a draft requirement such as reporting an anomaly within a specified time constraint under defined abnormal input conditions. Identify missing input, timing and interface details before implementation rather than hiding unresolved constraints in code.
Record the upstream basis, allocated component, contributing units, what unit and integration verification check, and how the software requirement is finally verified. Follow this chain to assess design and test impact when the requirement changes.
Coverage is not the whole verification argument
Coverage helps show which code structures tests executed. It does not alone prove that requirements are correct, all fault effects are controlled, or software conforms to the standard. Applicable verification methods depend on ASIL, activity and specific clauses.
Check requirement coverage, expected results, abnormal conditions, interface interactions and the test environment. Explain uncovered or untestable elements and their treatment rather than pursuing a percentage alone.
Suggested reading and practice sequence
Read requirements and architecture first
Identify upstream inputs, allocations and interfaces before code details.
Pair implementation with verification
After each development activity, identify what its verification must demonstrate and the evidence needed.
Revisit supporting processes
Use a small change to examine configuration, tools, review and traceability, and see how development remains controlled.
Common questions
- Is Part 6 only for C?
- This guide does not bind Part 6 to one language. Real projects need to select and justify methods based on language, toolchain, architecture and applicable clauses.
- Does ASIL D mean a particular coverage percentage is sufficient?
- No. Verification activities have different purposes and coverage is only part of the evidence. Requirements, design, method applicability and results also matter.
- Can this table become my project deliverable checklist?
- It is a learning map, not a project checklist. A real checklist needs applicable clauses, project scope, tailoring rationale and organisational processes.
Sources and scope
- ISO 26262-6:2018 · ISO catalogue
Scope from the official ISO catalogue; activities correspond to Clauses 6–11 of the 2018 edition. Explanations and practice tasks are original FuSaCert content.