Process · Safety & Security
Tool qualification
Showing that a software tool used to develop or verify a safety-related or airborne product can be trusted for the credit taken from its output, so that its errors cannot go undetected.
ISO 26262, IEC 61508 and DO-330 each set how much evidence is needed.
- Also known as
- Software tool qualification
- Type
- Process
- Domain
- Safety & Security, Safety lifecycle
Overview
Tool qualification is the work of showing that a software tool used to develop or verify a safety-related product can be trusted for the job it does, so that an error in the tool cannot slip unnoticed into the product. Safety standards scale the effort to the risk: a tool whose mistakes would be caught by later checks needs little evidence, while one whose output is relied on without further checking needs much more. In chip projects the tools concerned can include simulators, synthesis and formal tools, fault injection tools, compilers and test automation.
How it works
Under ISO 26262, confidence in the use of software tools is one of the supporting processes in Part 8. For each use case, the team judges the tool impact, meaning whether a malfunction could introduce an error into the product or fail to detect one, and the tool error detection, meaning how likely it is that such a malfunction would be caught by other measures. Together these give a tool confidence level from TCL1 to TCL3. A tool at TCL1 needs no qualification; tools at the higher levels need qualification evidence, with more expected for higher ASILs.
Other sectors have their own rules. In airborne systems, DO-330, Software Tool Qualification Considerations, sits alongside DO-178C and assigns tool qualification levels (TQLs); the US Federal Aviation Administration recognises both documents. In industrial functional safety, IEC 61508-3 sets requirements for support tools, including design tools, language translators, test and debugging tools and configuration management tools.
Tool vendors help by having tools assessed and certified for stated use cases. That evidence supports, but does not replace, the user's own classification, because the confidence level depends on how the tool is used and what other checks surround it in a particular flow.
Examples
- An automotive chip team listing every tool in its flow, with use cases, tool impact, error detection and confidence level, in a tool classification report.
- Synopsys stating that its test automation, simulation and virtual prototyping tools are certified for ISO 26262 use.
- An avionics software project qualifying the tools in its flow under DO-330, the tool qualification document the FAA recognises alongside DO-178C in Advisory Circular 20-115D.
- An industrial controller project applying IEC 61508-3 requirements to its compiler and configuration management tools.
Why it matters
Without tool qualification, a safety case has a gap: a bug in a simulator, synthesis tool or compiler could hide a defect that every downstream check trusts. Functional safety engineers own the tool classification, CAD and methodology teams keep tool versions and flows under control, verification engineers supply validation evidence, and EDA vendors have tools certified for automotive use.
In the chip lifecycle, tools are classified when the safety plan is written at the start of a project, evidence is collected through design and verification, the classification is checked again when tool versions or flows change, and the records form part of the safety case reviewed before production release.
It matters most to: CAD / Design Methodology Engineer, EDA Release & Quality Engineer, Functional Safety Assessor, Functional Safety Engineer, Functional Safety Verification Engineer
Common confusions
- Not the same as product qualification
- Product qualification, for example to AEC-Q100, shows that a chip survives stress testing. Tool qualification concerns the software used to design and verify it.
- Not the same as tool certification
- A vendor certificate from an assessor covers stated use cases of the tool. The project still has to classify its own use of the tool and keep the evidence.
- Not the same as an ASIL for the tool
- Tools are not given ASILs. They receive a tool confidence level, and the ASIL of the product decides how much qualification evidence that level requires.
Related standards
- ISO 26262-8 (road vehicles functional safety: supporting processes, including confidence in the use of software tools)
- IEC 61508-3 (functional safety: software requirements, including support tools)
Sources
- ISO 26262-8:2018 Road vehicles, Functional safety, Part 8: Supporting processes (opens in a new tab), ISO, 2026-10-22
- ISO 26262: Functional Safety Requirements for Automotive E/E Systems (opens in a new tab), Semiconductor Engineering, 2026-10-22
- IEC 61508-3:2010 Functional safety of electrical/electronic/programmable electronic safety-related systems, Part 3: Software requirements (opens in a new tab), IEC, 2026-10-22
- Advisory Circular 20-115D: Airborne Software Development Assurance Using EUROCAE ED-12( ) and RTCA DO-178( ) (21 July 2017) (opens in a new tab), Federal Aviation Administration, 2026-10-22
- What is ISO 26262? (opens in a new tab), Synopsys, 2026-10-22
Related terms
Part of the Safety & Security glossary, with every term in the topic and the lifecycles, tools and standards that use them.
Where it appears on the Hub
Used on 20 pages of the Hub. In each group, the pages that mention it most come first.
Lifecycle stages and gates
Suggest an improvement
Suggest an improvement to this entry
A clearer definition, an example, a correction or a source an editor can check. Editors review every suggestion before the entry changes.
Last reviewed . Written by The Semiconductor Hub editorial team. The full glossary