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, the supporting processes part. 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.

Related Articles

Classification tree and combination table used to design embedded unit test cases in Razorcat's Classification Tree Editor for TESSY, available in India from GSAS Micro Systems
Compliance & Safety Razorcat Automotive & Mobility

Test Case Design with the Classification Tree Method: Deriving Unit Tests You Can Defend in an Audit

Ad-hoc test cases can be perfectly good tests and still fail an audit, because nothing on file records why that particular set was sufficient. The Classification Tree Method derives test cases from the input space instead: identify the test-relevant aspects as classifications, partition each into equivalence classes, then combine leaf classes in a combination table. Razorcat implements CTM in the Classification Tree Editor, available integrated into TESSY or standalone. GSAS Micro Systems is the authorized Razorcat engineering partner for India, the UAE and Sri Lanka.

1 Aug 2026 · 10 min read
Fault injection and robustness testing for safety-related embedded C and C++ software, explained for Indian engineering teams by GSAS Micro Systems, the authorized Razorcat engineering partner
Compliance & Safety Razorcat Automotive & Mobility

Fault Injection and Robustness Testing for Embedded Software: What ISO 26262, IEC 61508 and DO-178C Actually Ask For

Every safety-related unit contains code that correct inputs never execute: range checks, error returns, timeouts, recovery paths. The functional safety standards require that code to be verified, and they are explicit about how. ISO 26262-6 lists fault injection test as a method for both software unit verification and software integration verification; IEC 61508-3 recommends defensive programming from SIL 2 upward and then concedes that defensive code is exactly what stops teams reaching 100 percent structural coverage. This guide separates robustness testing from fault injection, maps each to the obligation that asks for it, and shows how Razorcat implements automated fault injection in TESSY without leaving instrumentation in production code.

1 Aug 2026 · 11 min read
Buyer-side evaluation framework for embedded unit testing tools, covering compiler and debugger fit, on-target execution, coverage levels and qualification evidence, from GSAS Micro Systems in India
Compliance & Safety Razorcat Automotive & Mobility

How to Evaluate a Unit Testing Tool for Embedded Software: A Buyer's Framework for Indian Teams

Unit test tool evaluations rarely fail on features. They fail because the tool cannot drive the compiler and debugger the project is already committed to, or because the evidence it produces sits outside the scope of the certificate the assessor asks for. This is a buyer-side framework: six questions, what a credible answer looks like in vendor documentation, and a four-week pilot that measures the answers instead of accepting them.

1 Aug 2026 · 10 min read