Finding and fixing a software defect late in the development cycle costs more than catching it early, a pattern well documented across the software industry, and in automotive embedded systems the stakes are amplified by safety certification requirements. A defect discovered during system integration or vehicle validation can trigger re-verification cascading across multiple ASIL decomposition paths, substantially increasing the remediation cost compared to catching the same issue during unit testing. Shift-left testing strategies address this by moving verification activities as early as possible in the development lifecycle.
Automated unit testing with tools like TESSY enables teams to achieve comprehensive code coverage, including the MC/DC coverage ISO 26262 most strongly recommends at ASIL D, at the function level, before code is integrated into the broader system. By running these tests automatically in CI/CD pipelines triggered by every code commit, teams create a continuous verification loop that catches regressions within minutes rather than weeks.
Virtual prototyping and virtual ECU testing with Arm Virtual Hardware extends the shift-left approach beyond unit testing into integration and system-level validation. Teams can begin testing embedded software against realistic hardware models before physical prototypes are available, compressing the overall development timeline and reducing dependence on scarce hardware resources during the critical early development phases.
Static analysis as the first shift-left layer
Before a single unit test runs, static analysis can catch a substantial class of defects at the desk-check stage. Pre-compilation MISRA C/C++ enforcement via tools like Perforce QAC or Klocwork inspects every translation unit for undefined behaviour, type punning, integer-promotion bugs, and the long list of constructs the MISRA consortium classifies as unsafe in safety-related code. MISRA C:2012 (with Amendment 4) and MISRA C++:2023 are the de-facto coding standards across Tier 1 automotive suppliers, and ISO 26262-6:2018 gives the enforcement of language subsets and coding guidelines its strongest recommendation at every ASIL, ASIL A included, so there is no ASIL at which a language-subset argument becomes optional. Catching a null-pointer dereference or a signed-overflow path here costs minutes, catching it at HIL costs days.
Coverage requirements per ASIL
ISO 26262-6:2018 sets out a recommendation gradient for structural coverage at the software unit level that drives shift-left tooling choices. Its three unit-level metrics are statement coverage, branch coverage and MC/DC. Branch coverage is already recommended at ASIL A rather than introduced at B; statement coverage is relaxed at the higher ASILs rather than dropped, because 100% branch coverage implies 100% statement coverage; and MC/DC carries the standard’s strongest recommendation only at ASIL D. None of it is mandatory, since the strongest rating the standard applies to any method is highly recommended and these metrics are alternative entries, so you apply an appropriate combination and give a rationale. The standard separately calls for structured test case derivation, analysis of requirements, equivalence classes, boundary values and error guessing, at the unit level. GSAS does not reproduce the standard’s clause numbers, table numbers, row letters or rating grids; read them from your licensed copy. Hitting MC/DC by hand is impractical on production-sized ECU code, which is why automated unit-test generators like Razorcat TESSY are the workhorse here: TESSY instruments the code, generates the test vectors needed to exercise each independent condition, and reports coverage in the ISO 26262 format auditors expect.
CI/CD integration patterns
The pattern most Tier 1 teams converge on layers verification by feedback latency. On every commit, a Jenkins or GitLab runner executes Perforce QAC / Klocwork static analysis and rejects MISRA violations before review. On every pull request, TESSY unit tests and coverage reports run against the changed modules, gated against the ASIL coverage threshold above. Nightly pipelines extend into integration tests on Arm Virtual Hardware, virtual Cortex-M models running the same binary that will ship to the ECU, and finally into hardware-in-loop benches once a release candidate is cut. The discipline is not the toolchain itself but the gate placement: each shift-left layer must block merge, not merely report.
Also appears in:
Building for Automotive & Mobility?
Talk to our application engineers for personalized tool recommendations.
