Hello, Engineers! This is Hermes Solution.
Today, we want to talk about ISO 26262, the standard for ensuring the safety and reliability of automotive software, with a particular focus on Part 6. In this article, we’ll discuss what static and dynamic analysis are and how they help achieve software safety.
The ISO 26262 standard for functional safety in automobiles provides essential guidelines to ensure the safety of vehicle software. This article will simplify the concepts of static analysis, dynamic analysis, and coverage as required by Part 6 of ISO 26262 and share practical tips for real-world implementation.
ISO 26262 Part 6
ISO 26262 Part 6 explains the software development process step by step. Understanding this flow makes it easier to approach:

Software Requirements Definition (Clause 6)
Based on system and hardware requirements, define the functional and safety requirements the software must meet.
Software Architecture Design (Clause 7)
Define modules, interfaces, and hierarchical structures to ensure the design aligns with safety requirements (e.g., ASIL levels).
Software Unit Design and Implementation (Clause 8)
Develop detailed designs for each module (unit) and write code. Static analysis is applied during this phase to prevent errors early.
Software Unit Verification (Clause 9)
Test developed units to verify they meet the requirements, utilizing both static and dynamic analysis.
Software Integration and Testing (Clause 10)
Integrate units and test interactions between modules to ensure seamless operation.
Embedded Software Testing (Clause 11)
Run the software on actual ECUs or simulations (HIL environments) to test performance and stability under real-world conditions.
Static Analysis: Ensuring Quality in Early Stages
What is static analysis?
Static analysis involves reviewing software code without executing it. It helps identify errors early and is supported by tools like MISRA C Checker, SonarQube, and Polyspace.
Why is it important?
- Detect errors early during the coding phase.
- Required by ISO 26262 as part of formal documentation.
- Easily identifies logical errors (e.g., uninitialized variables, incorrect pointer usage).
Practical tips
- CI/CD integration: Automate static analysis to run whenever code is modified.
- Manage false positives: Systematically review and address false positives detected by the tools.
- Dynamic Analysis: Runtime Verification
What is dynamic analysis?
Dynamic analysis involves executing the software to detect runtime issues like memory leaks and stack overflows.
Key dynamic analysis techniques
- Unit testing: Test individual functions or classes to verify they meet requirements.
- Integration testing: Test interactions between modules and address timing constraints.
- Runtime analysis: Monitor metrics like memory usage and CPU load.
Embedded software testing
- Validate interactions between hardware and software.
- Detect embedded-specific issues such as hardware interrupts or real-time scheduling problems.
Coverage: Meeting ISO 26262 Requirements
What is coverage?
Coverage measures how much of the code is executed during testing. ISO 26262 specifies coverage metrics to ensure test completeness.
Key coverage types

- Statement coverage: Ensures every statement is executed at least once.
- Branch coverage: Ensures all decision paths (e.g., if, switch) are tested.
- MC/DC (modified condition/decision coverage): Ensures each condition in a decision impacts the result independently. This is mandatory for high safety levels like ASIL D.
Architecture-level coverage
- Function coverage: Confirms all functions are executed.
- Call coverage: Verifies the relationships between function calls.
Practical tips
- For high ASIL levels (especially ASIL D), aim to achieve MC/DC.
- Use tools like VectorCAST or Tessy to automate coverage data generation and management.
Why use both static and dynamic analysis?
- Static analysis prevents structural errors during the coding phase.
- Dynamic analysis identifies runtime errors during execution.
Combining these methods enhances code quality and safety.
Practical Guide for ISO 26262 Compliance
Tool selection
- Choose tools that suit your project’s language and environment (e.g., Polyspace, Coverity for C).
- Prioritize tools certified for ISO 26262.
Automation systems
- Integrate static and dynamic analysis into your CI/CD pipeline for automatic testing.
- Automate build tests and coverage measurement.
Documentation and traceability
- Systematically document the results of static and dynamic analysis.
- Maintain traceability between requirements, test cases, and coverage results.
Conclusion
ISO 26262 Part 6 emphasizes using static and dynamic analysis to ensure software safety. Use static analysis to improve quality early, dynamic analysis to prevent runtime issues, and coverage to verify test completeness.
Apply today’s insights to develop safe and reliable software. If you have any questions about automotive functional safety, feel free to reach out to Hermes Solution. Safety first!