If you develop software for road vehicles, your toolchain is part of your safety argument. The compilers, generators, static analyzers and coverage tools you rely on can each shape — or quietly corrupt — the product you are certifying. ISO 26262 addresses this directly in Part 8, Clause 11, through a concept called the tool confidence level (TCL): a structured way to decide how much trust a software tool needs to earn before its output can be used without independent re-checking.
The mechanics are not complicated, but they are easy to apply loosely, and a loose application is the kind of thing that surfaces during an assessment. This guide breaks down the two factors that drive the result — Tool Impact (TI) and Tool error Detection (TD) — shows how they combine into a TCL, surveys the four qualification methods ISO 26262 recognizes, and explains where a code coverage tool typically lands and how to build a defensible qualification case around it.
A Tool Confidence Level expresses how much a tool could harm your safety-related product and how likely you are to catch it if it does — and the higher that level, the more rigorous the qualification ISO 26262 expects.
Why tool qualification exists
Functional safety rests on an uncomfortable truth: the tools that build and verify safety-related software are themselves software, and they can be wrong. A code generator might emit subtly incorrect output. A compiler optimization might delete a check the source code clearly intended. A verification tool might report a clean result while quietly failing to detect a real defect.
ISO 26262 does not demand that every tool be flawless — that would be impossible. Instead it asks for confidence proportional to risk. A tool whose malfunction could inject an error into the safety-related item, or could fail to reveal an error that is already there, needs to be qualified to a degree that matches the danger. A tool that cannot plausibly do either needs very little. The TCL framework is simply the rule that decides which case you are in.
The point is not to prove a tool is perfect. It is to make sure the level of trust you place in it is justified by evidence rather than habit.
Tool Impact (TI)
The first factor asks whether the tool can do harm at all. Tool Impact describes the possibility that a malfunction of the tool — together with its corresponding erroneous output — could introduce or fail to detect errors in the safety-related item or element being developed. ISO 26262 defines exactly two classes:
- TI1 — there is no possibility that a tool malfunction could introduce or fail to detect errors in the safety-related product. The tool sits outside the safety path.
- TI2 — in all other cases. If a tool error could plausibly inject a fault into the product, or could let an existing fault slip through undetected, the tool is TI2.
The standard is deliberately conservative here: when you are unsure, assume TI2. Claiming TI1 is an affirmative argument that the tool simply cannot affect the product, and that argument has to hold up. A text editor used only for informal notes might be TI1; almost anything that touches code, configuration, or verification results trends toward TI2.
Tool error Detection (TD)
The second factor asks: if the tool does malfunction, how likely are you to notice? Tool error Detection rates the confidence that a malfunction and its erroneous output will be prevented or detected by measures already present in your development process — downstream reviews, redundant checks, independent verification activities, monitoring, and so on. There are three classes:
- TD1 — high degree of confidence that a tool malfunction is prevented or detected.
- TD2 — medium degree of confidence.
- TD3 — all other cases, i.e. low or no established confidence that the error would be caught.
TD is where your own process earns you credit. The same tool can sit at TD1 in one project and TD3 in another, purely because of what surrounds it. A code generator whose output is fully reviewed against the model, then compiled and verified by independent means, may justify a high TD. The same generator feeding code straight into a build with no downstream check earns no such credit.
A high TD is a claim about your verification activities, and an assessor will expect to see the detecting measures actually described and in place. Listing a review that nobody performs, or that could not in practice catch the relevant class of tool error, will not survive scrutiny.
Determining the Tool Confidence Level
Once you have classified TI and TD, the Tool Confidence Level falls out of a simple combination. ISO 26262 recognizes three levels — TCL1 (lowest required rigor) through TCL3 (highest). The logic is straightforward: if a tool cannot affect the product (TI1), it is always TCL1 regardless of detection. If it can (TI2), the level is then driven down by how confidently you would catch its errors.
| Tool Impact | TD1 (high detection) | TD2 (medium) | TD3 (low / none) |
|---|---|---|---|
| TI1 | TCL1 | TCL1 | TCL1 |
| TI2 | TCL1 | TCL2 | TCL3 |
Read the table as a story. TI1 means the tool is harmless, so the whole row is TCL1. For a TI2 tool, strong detection (TD1) still lands you at TCL1, because even though the tool could err, you would reliably catch it. Medium detection (TD2) gives TCL2, and weak or absent detection (TD3) gives the most demanding TCL3. The practical lesson: you can lower a tool's TCL either by genuinely removing its impact, or by strengthening the process measures that would catch its mistakes.
Qualification methods
For any tool above TCL1, ISO 26262 expects qualification — and the amount of rigor scales with both the TCL and the ASIL of the item being developed. The standard offers four recognized approaches, and you choose among them based on those two inputs:
- Increased confidence from use. An argument built on a documented history of the tool being used, unchanged, for the same purpose, with errors collected and acted upon. Suitable when there is a credible, recorded track record.
- Evaluation of the tool development process. Evidence that the tool itself was developed under a recognized, well-managed process (for example one assessed against an applicable standard), giving confidence in its quality.
- Validation of the software tool. Demonstrating, through systematic testing against its intended use cases and expected behavior, that the tool produces correct results and that malfunctions are detected or handled — including analysis of its reaction to anomalous inputs.
- Development in accordance with a safety standard. The most rigorous option: the tool was developed following a relevant safety standard, with the corresponding evidence available.
For lower TCLs and lower ASILs, the lighter methods may be sufficient; as TCL and ASIL rise toward TCL3 and ASIL D, ISO 26262 recommends the more thorough approaches such as validation or development to a safety standard. The methods are not mutually exclusive — a strong case often combines several.
Where a coverage tool lands
A structural coverage tool is an interesting case because of how it can do harm. It does not generate the shipped code, so it is unlikely to inject a defect directly. But its entire job is to tell you which parts of your code your tests exercised — and if it reports coverage that was never actually achieved, it can cause you to fail to detect missing test coverage. That is exactly the "fail to detect errors in the item" half of the Tool Impact definition, so a coverage measurement tool is typically classified TI2.
Being TI2 does not doom you to TCL3. The goal is to argue a strong TD, qualify the tool, or both. A coverage report that is independently reviewed, cross-checked against requirements-based test results, or corroborated by a redundant measurement provides the kind of confirmation step that can raise TD — and a higher TD pulls the resulting TCL down. Where that confirmation is weaker, the tool itself carries more of the burden and you lean harder on a qualification method such as validation.
The mental model to keep
- TI asks can this tool hurt my product? — two answers, TI1 or TI2, and assume TI2 if unsure.
- TD asks would I catch it if it did? — TD1 (high) to TD3 (none), based on your own process.
- TI × TD gives the TCL: TI1 is always TCL1; for TI2 the TCL rises as detection falls.
- You can lower a TCL by removing impact or by strengthening detection — both are legitimate moves.
Building your tool qualification case
A qualification case is mostly disciplined record-keeping. The work is to classify each tool honestly, capture the reasoning, and keep the evidence where an assessor can follow it.
Inventory the toolchain
List every software tool that touches your safety-related development or verification — compilers, generators, configuration tools, static and dynamic analyzers, and coverage tools included.
Classify TI and TD for each
For every tool, decide its Tool Impact and the Tool error Detection your process provides, and write down the reasoning behind each — especially any TI1 or high-TD claim.
Derive and record the TCL
Combine TI and TD using the matrix above and record the resulting Tool Confidence Level. Tools at TCL1 need no further qualification; the rest do.
Choose a qualification method
For each tool above TCL1, select a method appropriate to its TCL and your ASIL — increased confidence from use, process evaluation, validation, or development to a safety standard.
Collect and retain the evidence
Keep the qualification evidence, the version of the tool it applies to, and the configuration it was qualified in. Re-confirm when the tool, its use case, or its environment changes.
RKTracer and tool qualification
Qualification is ultimately the responsibility of the team deploying the tool in their specific process — no vendor can do it for you, and no tool arrives "pre-qualified" for your project. What a good coverage tool can do is make the case easy to build by producing the evidence you need and behaving predictably enough to argue a strong TD.
RKTracer is built by an ISO 9001-certified vendor and is designed to support exactly that workflow. It measures statement, decision, condition, MC/DC and multi-condition coverage, and the MC/DC metric in particular is what ASIL D effectively requires for software unit verification. It produces detailed coverage reports and documentation — the rkresults HTML and XML output among them — that teams can fold directly into a tool qualification case and the surrounding confirmation activities. To be clear: RKTracer provides qualification-support evidence; it does not remove your obligation to classify, qualify, and confirm the tool within your own process.
Because RKTracer instruments during compilation with no source changes — you simply prefix your existing build command — and works across host, embedded, GPU and simulator targets, the coverage you qualify is the coverage you actually measure on the software that ships. Its AI test generation can also propose the unit tests that close real coverage gaps, so reaching ASIL-D coverage targets is less of a grind.
The bottom line
The Tool Confidence Level is not red tape; it is a proportionate way to decide how much to trust the software that builds and checks your safety-critical product. Get the two inputs right — be honest about whether a tool can affect the product (TI), and be realistic about whether your process would catch it if it did (TD) — and the TCL, and the qualification effort it implies, follow naturally.
For a coverage tool, expect TI2, argue your detection deliberately, and choose a qualification method that fits your TCL and ASIL. Pick a tool that hands you clean, documented evidence and behaves the same on the target that ships, and the part of your safety case that deals with tools becomes one of the easier parts to defend.