ISO 26262 is the functional safety standard for electrical and electronic systems in road vehicles, and Part 6 addresses software. For engineering teams, the practical question is how test automation can give fast feedback while also producing the verification evidence the standard calls for. Dedicated verification tools can help collect and organize that evidence. Compliance and vehicle safety still depend on the team’s engineering work, documented decisions and verification results.
What ISO 26262 expects from software verification
ISO 26262:2018 is organized into 12 parts. Part 6 covers software unit verification, software integration verification and testing of the embedded software. Automotive Safety Integrity Levels (ASIL A through D) are determined through hazard analysis and risk assessment. ASIL D is the most stringent.
Part 6 identifies structural coverage measures, which show what code the tests exercise. Its tables use ++ for highly recommended measures and + for recommended ones, and the recommendations vary by ASIL.
Modified condition/decision coverage (MC/DC) is highly recommended for software unit verification at ASIL D. It checks whether each condition can independently change a decision’s outcome. The standard recommends coverage types by ASIL rather than fixed percentage thresholds, so document your coverage criteria and the rationale behind them.
The independence required for confirmation reviews and assessments depends on the ASIL and the activity. Plan responsibilities early so the necessary reviewers are available.
From generic automation to a safety-focused strategy
The test pyramid places many fast unit tests at the base and fewer integration tests in the middle. A smaller number of slower end-to-end tests sit at the top. That layered approach to automated unit, integration and end-to-end testing supports frequent feedback, but it isn’t a compliance framework. The balance must reflect the software’s safety requirements and the behavior each test level can verify.
Three adjustments make this approach more useful for safety work:
- Link safety-related tests to the requirements or design elements they verify.
- Collect structural coverage alongside behavioral results so gaps remain visible.
- Use continuous integration (CI) checks to flag failed tests, broken trace links, and violations of agreed analysis or coverage criteria before release.
Build the safety-aware automation stack
Use complementary verification methods and keep enough context to reproduce their results. Part 6 addresses software verification. Part 8 covers supporting processes, such as confidence in software tools.
Static analysis and coding standards
Run static analysis, which checks code without executing it, early in CI. Select coding rules that suit the language and project, such as MISRA C or applicable AUTOSAR C++ guidelines. Record findings and approved deviations so reviewers can see what was flagged and why an exception was accepted.
Requirements-based unit testing
Write unit tests from requirements, using stubs and mocks to replace dependencies where needed. Maintain traceability between requirements, implementation and verification results. Modern approaches to AI for software testing can also assist QA teams with test generation and analysis, but safety-related verification still requires controlled requirements, reviewable results and appropriate human oversight. For each test, keep the expected result, the actual result and the tested software version so a reviewer can follow the evidence.
Structural coverage by ASIL
Select statement, branch and MC/DC coverage measures according to the applicable ASIL and the verification plan. Treat gaps as questions to investigate:
- Are tests missing?
- Is the code unreachable?
- Does a defensive branch need another verification method?
Coverage supports requirements-based testing. It doesn’t prove that the requirements or the test expectations are correct.
Integration and system layers
For model-based development, use back-to-back testing where appropriate to compare model and code behavior with the same inputs. Depending on the workflow, this may involve model-in-the-loop (MIL), software-in-the-loop (SIL) or processor-in-the-loop (PIL) testing. Run selected tests on target hardware or a hardware-in-the-loop bench. That checks timing, interfaces and platform effects that host-based tests may miss.
Tool qualification
Assess any tool that could introduce errors or fail to detect them. Under ISO 26262-8, tool impact (TI) and tool error detection (TD) determine the tool confidence level, from TCL1 to TCL3. The assessment considers the tool’s intended use and how errors in its output would be detected.
TCL1 requires no additional qualification methods. Higher levels require appropriate qualification measures. Keep the assessment and supporting evidence as controlled project records.
Where a compliance-focused toolchain helps
Look for C/C++ static analysis, unit testing, structural coverage, traceability, CI integration, reporting and qualification support. When evaluating testing platforms or AI testing services, the important question is not simply how much they automate, but whether their capabilities fit the project’s verification, reporting and evidence requirements. The more relevant functions a toolchain covers in one place, the less manual work it takes to assemble evidence for reviewers.
For teams using C/C++, Parasoft’s ISO 26262 Software Compliance solutions can bring testing, coverage and evidence collection into a shared workflow. The company states that its C/C++ test tools are TÜV SÜD certified for ISO 26262 and include a tool qualification kit. Its GoogleTest integration with C/C++test CT also supports teams that want to keep a familiar test framework.
Tool certification supports the project’s qualification argument, but it doesn’t certify the software being tested. Check the available certification and qualification material against the exact tool version, configuration and intended use. A useful evaluation should include a sample evidence report, not just a successful test run.
Alternatives and complements
Other tools address similar verification needs:
- VectorCAST provides statement, branch and MC/DC coverage, with reporting for safety-related projects.
- LDRA offers automotive coverage analysis, including MC/DC.
- MathWorks pairs Polyspace with an IEC Certification Kit for relevant workflows.
- Jama, a requirements platform, can maintain requirements-to-test links.
Compare the options against your language mix, your use of models, your existing tools and your evidence needs.
Common pitfalls and quick fixes
Watch for four recurring issues when reviewing the test strategy.
- Overreliance on end-to-end tests. Full-vehicle tests are necessary, but they can be slow and don’t replace unit-level structural coverage. A layered software automation testing strategy can use unit and integration tests for earlier feedback while keeping the required system-level verification in place.
- Missing MC/DC rationale at ASIL D. Coverage numbers alone aren’t enough. Investigate gaps, add tests where needed, and document the reasoning for any remaining exclusions.
- Weak traceability. Manually maintained records can drift. Generate links from controlled sources where possible, and archive the traceability report with the tested build.
- Skipped tool assessment. New test tools sometimes arrive without a TI/TD analysis. Record the TCL and complete any required qualification before relying on a tool’s results as safety evidence.
Action checklist
Use this checklist to review readiness for the next planned release:
- Map software safety requirements to verification methods, and link automated tests where suitable.
- Define CI checks for static analysis, coverage and traceability.
- Choose coverage criteria by ASIL and document the rationale.
- Plan confirmation measures and the required reviewer independence.
- Assess relevant tools and record their confidence levels and qualification needs.
- For model-based components, plan suitable back-to-back tests.
- Agree on an evidence report format with the reviewers or assessor.
The goal is a defensible safety case
More tests alone don’t make a safety case. A defensible case needs tests linked to requirements, appropriate coverage, investigated gaps and justified confidence in the tools used. A well-chosen toolchain can reduce the effort of collecting and organizing that evidence. Engineering judgment and responsibiity still remain with the team.
AI Agentic Platform For Building Portable AI Agents
Say Hello To Agentic AI That Connects With Your CRM And Even Other Agents
