Tool Qualification (ISO 26262)
Tool qualification is the evidence according to ISO 26262-8 that a software tool is sufficiently trustworthy for use in safety-related development. Whether it is necessary is determined by the Tool Confidence Level (TCL), derived from tool impact and tool error detection. The procedure is defined in clause 11 of ISO 26262-8 — it applies to compilers and code generators as much as to modelling, test and analysis tools.
When does a tool have to be qualified?
The standard does not demand blanket qualification, but a precise risk and confidence assessment along two questions:
- Error injection (tool impact): can an error in the tool itself inject a safety-relevant error into the product — or prevent an already existing error from being detected in the process?
- Error detection (tool error detection): how likely is it that such a tool error is detected or prevented by the surrounding process?
The combination yields the Tool Confidence Level:
| Classification | Result |
|---|---|
| No influence on the safety outcome (TI1) | TCL 1 — no qualification needed |
| Influence possible, error detected with high confidence (TD1) | TCL 1 — no qualification needed |
| Influence possible, error detection only medium likely (TD2) | TCL 2 — qualification required |
| Influence possible, error detection unlikely (TD3) | TCL 3 — qualification with highest rigour |
The four qualification methods
For TCL 2 and TCL 3, ISO 26262-8 names four methods whose recommendation strength depends on the ASIL of the function being developed: increased confidence from use (documented, relevant operating history), evaluation of the tool development process, validation of the software tool (targeted evidence against the requirements of the use case) and development in accordance with a safety standard. For high ASIL classifications combined with TCL 3, validation or standard-compliant development are preferred.
The often overlooked lever: process safeguards
Before a tool is qualified, it is worth looking at the process around it: often, safeguarding through redundant checks or reviews in downstream development steps is already sufficient. If all generated code is checked anyway through qualified tests or independent reviews, error detection increases — and the TCL drops, in the best case to TCL 1. The cheapest qualification is the one that a well-designed process makes unnecessary.
Make or buy: the qualification question as an engineering decision
With increasing automation in the safety lifecycle, tool qualification is turning from a rare compliance obligation into a recurring, strategic decision:
- Buy (qualified product): for standard tasks and deeply integrated development tools — such as compilers — the vendor supplies the qualification kit, saving immense internal validation effort.
- Make (qualify your own tool): for highly specific, proprietary in-house scripts or tailor-made toolchains, qualifying your own tool secures the team’s highly efficient workflow.
Tool qualification in practice
Related concepts also exist outside the automotive domain — IEC 61508, for example, classifies tools into classes T1 to T3. The practical guideline is the same in all cases: first assess the tool’s real influence on the safety outcome, then exhaust error detection in the process, and only qualify what remains afterwards. This keeps the principle achievable: as much automation as possible with as little qualification effort as necessary — within functional safety, one of the most economically consequential decisions.