You are two months into an ASIL D engine control unit program. The safety assessor asks a simple question: show me the tool qualification for every tool in your development toolchain. You count them — compiler, linker, Simulink code generator, MISRA checker, unit test harness, coverage tool, static analyzer, configuration management tool, requirements tool, and four custom Python scripts that transform DBC files into CAN driver code. Ten tools minimum. How many need qualification? At which Tool Confidence Level (TCL)? Which qualification method applies? Get this wrong and you either do weeks of unjustified rework or — worse — ship with a qualification gap that surfaces in the final assessment.
ISO 26262-8 Clause 11 is the part of the standard that answers these questions. It is also one of the most frequently misunderstood clauses, because engineers conflate tool impact with tool criticality, and because the TI × TD matrix looks simpler than it is.
What ISO 26262-8 Clause 11 Actually Requires
Clause 11 of ISO 26262-8 (Supporting Processes) defines the requirements for the qualification of software tools used in the development of safety-related items. Clause 11.4.5 specifies the process in two explicit phases: first determine the required Tool Confidence Level for every tool used in the safety lifecycle, then — if the TCL is higher than TCL1 — apply a qualification method commensurate with the ASIL of the item or element the tool contributes to.
The scope is the toolchain that produces, modifies, or verifies any work product referenced by your safety case. That means tools used for requirements engineering, architectural design, code generation, compilation, testing, measurement, configuration management, change management, and static/dynamic analysis — if the tool's output goes into a safety-related work product, it is in scope.
One misread that trips new teams: ISO 26262 does not require you to qualify tools used purely for documentation or presentation (e.g., Word, PowerPoint), nor for administrative tools that do not touch the safety artifacts. But it does require qualification of a spreadsheet if that spreadsheet computes PMHF, tracks safety requirements allocations, or performs traceability mapping — because the spreadsheet output is now a safety-related work product.
Step 1: Classify TI (Tool Impact)
Before you can assign TCL, you must classify Tool Impact (TI). Clause 11.4.5.2 gives two values:
- TI1 — the tool cannot introduce or fail to detect errors in a safety-related item or element. No qualification is required; the tool is TCL1 by default.
- TI2 — the tool can introduce or fail to detect errors in a safety-related item or element. Further classification is required.
TI is not about whether the tool "feels safety critical." It is about whether a malfunction of the tool can cause a fault in, or fail to catch a fault in, a safety-related work product. A code generator that produces ASIL D source from a model has TI2. A requirements management tool that stores ASIL D requirements has TI2 (because tool malfunction could silently alter a requirement). A log viewer that is read-only and produces no downstream artifact is TI1.
You must justify the TI assignment in writing. "The tool has been used for years" is not a justification — it is a prerequisite for one of the qualification methods (1a), not a substitute for the classification itself.
Step 2: Classify TD (Tool error Detection)
If TI is TI2, you must classify Tool error Detection (TD). Clause 11.4.5.3 gives three values based on how reliably your process detects tool-induced errors:
- TD1 — there is a high degree of confidence that a malfunction and corresponding erroneous output will be prevented or detected.
- TD2 — there is a medium degree of confidence.
- TD3 — low or no confidence.
TD assignment is process-driven, not tool-driven. If you run a bit-accurate back-to-back comparison between model and generated code on every commit, your code generator might qualify for TD1. If you rely only on manual code review to catch code generator defects, TD3 is more defensible. TD is often where programs lose credibility at assessment — the TD assertion must be backed by verification activity in your safety plan.
Step 3: The TI × TD → TCL Matrix
Clause 11.4.5.4 gives the combination table. This is the only table most engineers memorize, but it only works if steps 1 and 2 are done honestly.
| Combination | TD1 | TD2 | TD3 |
|---|---|---|---|
| TI1 | TCL1 | TCL1 | TCL1 |
| TI2 | TCL1 | TCL2 | TCL3 |
Three observations engineers miss:
- If TI is TI1, TCL is always TCL1 regardless of TD.
- If TI2 and TD1, TCL is still TCL1 — but achieving TD1 is hard and requires documented, automated error-detection measures.
- TCL3 is the default when the toolchain has no meaningful error detection. Most "legacy" or unverified custom scripts start here.
Step 4: Choose a Qualification Method
If TCL is TCL2 or TCL3, the tool must be qualified. ISO 26262-8 Table 4 specifies four methods and their recommendation level at each ASIL:
| Method | Description | ASIL A | ASIL B | ASIL C | ASIL D |
|---|---|---|---|---|---|
| 1a — Increased confidence from use | Historical proven-in-use argument | ++ | ++ | + | + |
| 1b — Evaluation of the tool development process | Tool vendor followed a recognized process (e.g., Automotive SPICE, ISO 9001) | ++ | ++ | + | + |
| 1c — Validation of the software tool | Systematic validation of the tool's functions against documented requirements | + | + | ++ | ++ |
| 1d — Development in accordance with a safety standard | Tool developed to a safety standard (e.g., ISO 26262 itself) | + | + | ++ | ++ |
++ means "highly recommended" — you deviate at your own risk and must justify the deviation. + means "recommended." For a TCL3 tool used on an ASIL D item, you will usually combine Method 1c (validation) with Method 1d (if the vendor provides a safety manual and certificate). Method 1a — "we've used this compiler for five years" — is weak for ASIL C/D because proving systematic use under comparable conditions with statistically meaningful defect data is difficult.
The Toolchain Classification You Will Actually Produce
A typical ASIL D ECU program ends up with something like the following. The table below is a realistic snapshot, not a template to copy — your TD assignment depends on your verification activities.
| Tool | Purpose | TI | TD (with process) | TCL | Typical Method |
|---|---|---|---|---|---|
| GCC / IAR C compiler | Compiles C to object code | TI2 | TD2 | TCL2 | 1a + 1b (vendor qualification kit) |
| Simulink Embedded Coder | Model → C code generation | TI2 | TD2 | TCL2 | 1c (back-to-back testing) + 1d (vendor cert) |
| Polyspace / Coverity | Static analysis | TI2 | TD1 | TCL1 | None required — justify TD1 |
| VectorCAST / Tessy | Unit test harness | TI2 | TD2 | TCL2 | 1b (vendor SPICE L3) |
| MISRA C checker | Coding rule compliance | TI2 | TD1 | TCL1 | None required |
| DOORS / Polarion | Requirements tool | TI2 | TD2 | TCL2 | 1b |
| Custom Python DBC-to-code script | CAN driver gen | TI2 | TD3 | TCL3 | 1c — full validation needed |
Note that custom scripts are where TCL3 appears most often. Teams build a 200-line Python script to transform configuration files and assume it is "just a utility" — but if its output ends up in flashed firmware, it is TI2 and with no error-detection process it is TD3 and therefore TCL3. That single overlooked script can consume more qualification effort than the compiler.
Qualification Reports and Integration Assumptions
For each tool that requires qualification, you must produce a Tool Qualification Report or equivalent work product per Clause 11.4.9. The report documents:
- Tool identification and version
- Use case (what the tool is used for in your project)
- Environment (OS, dependencies, configuration)
- TI/TD classification with justification
- TCL with justification
- Qualification method applied and evidence
- Limitations and known errata
- Use restrictions (the assumptions under which the qualification is valid)
The last item is where integration bites you. Most vendor TCL3 certificates are valid only under specific configurations — specific compiler flags, specific optimization levels, specific OS versions. If your build invokes the tool outside that envelope, the qualification does not transfer. You must verify every tool use against the qualification assumptions at integration time, every release.
Where Tool Qualification Breaks Down
Three failure modes show up repeatedly in assessments:
Incomplete toolchain inventory. Teams list the obvious tools (compiler, code generator) and miss the glue — scripts that pre-process ARXML, utilities that flash binaries, merge tools in CI that resolve MATLAB model conflicts. Anything that touches the safety artifact must be on the list.
TD assertions not backed by process evidence. A team claims TD1 for the compiler because "GCC is well tested." Without a back-to-back comparison, execution-level diversity, or equivalent detection mechanism, TD1 is not defensible.
Qualification evidence scattered across tools. The safety case must trace from every safety-related work product back to the qualified tools that produced it. Spreadsheets listing tool versions, vendor PDFs in a shared drive, and emails with version numbers do not constitute a traceable qualification chain. When the assessor asks which compiler built the v2.3.1 binary of module X, you need a single answer in seconds.
How ISO WIZ Handles Tool Qualification
Tool qualification is a traceability and version-control problem disguised as a documentation problem. ISO WIZ treats it that way. Every tool in your project has a record with TI/TD classification, TCL, assigned qualification method, linked evidence (vendor certificates, validation test reports, process audit records), and per-use restrictions. Each safety-related work product — requirement, design element, unit test case, build artifact — carries the toolchain fingerprint used to produce it, so the traceability from safety requirement → source code → compiled binary is paired with the qualified-tool chain at every link.
When a tool version changes, ISO WIZ flags every safety artifact produced by the superseded version and prompts an impact analysis before the next release build. When a vendor issues an errata that narrows the qualification envelope, the platform cross-references all current uses against the new envelope and raises gaps on any use that now falls outside it. The same record is shared across ISO 26262, ISO 21434, SOTIF (ISO 21448), and Automotive SPICE PAM 3.1 workflows — so when the cybersecurity toolchain and the safety toolchain overlap (as they almost always do), you qualify once and reference once.
The tool qualification chapter of a safety case is usually assembled in the last six weeks of a program. With ISO WIZ, it is assembled continuously, and the assessor sees the same view the engineers do.
Try It
If tool qualification is eating weeks of your program — and it almost certainly is — put your toolchain into ISO WIZ and see what a single source of qualification truth looks like. Sign up at isowiz.com and move your TI/TD classification out of spreadsheets and into a traceable, cross-standard record.