Skip to main content
ISO 26262 Tool Qualification: A Practical Guide for Automotive Teams, featured image

ISO 26262 Tool Qualification: A Practical Guide for Automotive Teams

GSAS Engineering · · 1 min read

ISO 26262 Part 8 establishes the requirements for qualifying software tools used in the development of safety-related automotive systems. Every tool that can introduce or fail to detect errors in a safety-related work product must be classified and potentially qualified. Understanding the Tool Confidence Level (TCL) classification system, TCL1 through TCL3, is essential for automotive engineering teams aiming to streamline their qualification efforts without compromising safety integrity.

The qualification burden varies significantly depending on the tool’s impact on safety work products and its error detection capability. TCL1 tools require no additional qualification beyond standard use, while TCL3 tools demand comprehensive qualification through methods such as validation of the tool output, development in accordance with a safety standard, or evaluation of the tool development process. The practical difference between qualifying a tool from scratch versus adopting a pre-qualified tool can be measured in months of engineering effort.

GSAS’s portfolio includes several tools with existing TUV SUD qualification certificates, including TESSY for unit testing and Arm Compiler 6 for code generation. These pre-qualified tools come with Tool Qualification Support Packages that significantly reduce the qualification effort for automotive teams, providing the evidence artifacts, safety manuals, and known-limitations documentation that assessors expect.

Tool Confidence Level (TCL) classification in practice

The TCL is not assigned arbitrarily, it is the output of a two-axis classification defined in ISO 26262-8:2018 Clause 11. Each candidate tool is first evaluated for Tool Impact (TI): TI1 means an error in the tool cannot introduce or fail to detect an error in the safety-related work product; TI2 means it can. The same tool is then evaluated for Tool error Detection (TD): TD1 means there is a high degree of confidence that a malfunction will be prevented or detected (for example, by a downstream check or a redundant tool); TD2 means medium confidence; TD3 means low confidence.

The two axes combine in a fixed matrix. TI1 always yields TCL1 regardless of TD, the tool needs no further qualification beyond documented intended use. TI2 with TD1 also yields TCL1. TI2 with TD2 yields TCL2. TI2 with TD3 yields TCL3: the highest qualification burden, typically required for compilers, code generators, and static analysers whose output is shipped into the safety-related product without independent verification. Most automotive teams find that compilers and code generators land at TCL3, while configuration utilities and editors land at TCL1.

What a Tool Qualification Support Package contains

A pre-qualified tool ships with a Tool Qualification Support Package (TQSP), the evidence bundle an assessor expects to see. For tools in the GSAS portfolio, the package typically includes:

  • A tool safety manual describing the intended use, operating environment, and use-case constraints (the Arm Compiler for Embedded FuSa documentation set is built around this artefact).
  • The TI/TD classification rationale explaining why the vendor reached a given TCL, the argument the assessor will challenge first.
  • A validation report with the test suite executed against the exact build, plus pass/fail evidence (TESSY’s TUV SUD certified status from Razorcat is supported by exactly this kind of validation evidence).
  • A known-problems and limitations report: the defects open at the time of certification, with workarounds. Adopting teams must read this; ignoring a known limitation invalidates the qualification argument.
  • A version-pinned reference identifying the exact tool build, patch level, and configuration the certificate applies to. Upgrading to a newer build without an updated certificate breaks the qualification chain and forces re-assessment.

When all five artefacts are present and the project’s intended use matches the safety manual, the tool can usually be adopted as-is. When any artefact is missing, the team has to reconstruct it, which is where the months of effort go.

Interested in Arm tools?

Talk to our application engineers for personalized tool recommendations.

Stay in the Loop

Get monthly compliance updates, product insights, and engineering best practices delivered to your inbox.