Tool qualification
DO-330 tool-qualification support for development and verification tools
DO-330 tool-qualification support helps an avionics or equipment supplier substantiate the qualification of a software tool whose output the program relies on for certification credit. It is used by software and hardware teams that automate generation or verification and need the right tool qualification level established and met before the credit is taken. The work reviews the determination of which tools need qualification, the tool qualification level assigned, the tool operational requirements, the tool verification evidence, and the configuration and problem-report data behind the tool. You receive a tool-qualification gap assessment keyed to the assigned level, a tool operational requirements and verification view, and a prioritized list of the qualification evidence to close.
When this review is needed
- A program is taking certification credit for a tool's output and the qualification has to be established before the credit is relied on.
- A verification tool removes or reduces a manual check, which can raise the tool qualification level the tool must meet.
- A tool's version or configuration changed and whether the prior qualification still applies needs to be confirmed.
- A commercial tool is being used and its tool operational requirements and verification evidence have to be assembled for the project's use of it.
- A supplier wants an independent read of the tool qualification before a stage-of-involvement review questions the credit.
The problem
Tool qualification is where credit quietly outruns evidence. A team automates code generation or test execution, takes credit for the tool's output, and only later asks whether the tool needed qualification at all. The determination of the tool qualification level depends on what the tool does and whether its error could go undetected, yet that reasoning is often skipped, and the tool operational requirements that should define what the tool must do correctly are thin or missing. Commercial tools arrive with vendor data that does not match how the project actually uses them.
What gets reviewed
- The determination of which tools need qualification and the basis for it
- The tool qualification level assigned and how the tool's use drives it
- The tool operational requirements that define what the tool must do correctly
- The tool verification evidence against the operational requirements at the assigned level
- The tool's configuration management and problem-report records
- The match between the tool's qualification and the way the project actually uses it
- Vendor-supplied qualification data and the gap to the project's specific use
What gets validated
- The need-for-qualification determination is documented for each tool the program takes credit for
- The assigned qualification level reflects what the tool does and whether its error could go undetected
- Operational requirements define the tool's required behavior for the project's use
- Verification evidence covers the operational requirements at the assigned level
- The qualification matches the tool version and configuration actually used on the program
- Vendor-supplied data is reconciled to the project's specific use rather than assumed sufficient
- Open problem reports are reflected in the qualification status and any limitations recorded
Evidence normally required
- The list of development and verification tools the program takes credit for
- The need-for-qualification determination and the assigned qualification level
- The operational requirements and the tool qualification plan
- The verification evidence and results assembled so far
- The configuration records, version data, and open problem reports for each tool
- Any vendor-supplied qualification data for a commercial tool
Common discrepancies
- A tool the program takes credit for with no documented need-for-qualification determination
- A qualification level set without analyzing whether a tool error could go undetected
- Operational requirements that are absent or too thin to verify against
- Verification evidence that does not cover the operational requirements at the assigned level
- A qualification that matches a tool version other than the one actually used
- Vendor data accepted as sufficient without reconciling it to the project's specific use
- Open problem reports against behavior the project relies on, with no recorded limitation
What is at stake
When a tool that warranted qualification was used without it, the credit taken for its output is not defensible, and the verification or generation it replaced may have to be redone by hand or the tool qualified after the fact under schedule pressure. A tool qualification level set too low forces the qualification evidence to be rebuilt, and either path lands on the same software or hardware completion date the tool was meant to protect.
Move from findings to resolution
Identify gaps against the means of compliance.
How the work runs
Determine the need
For each tool the program takes credit for, establish whether it needs qualification and the tool qualification level its use drives.
Define the use
Confirm the tool operational requirements describe what the tool must do correctly for the project's specific use of it.
Test the evidence
Check the tool verification evidence against the operational requirements at the assigned level and reconcile any vendor data.
Package the gaps
Produce a tool-qualification gap assessment and a prioritized closure list so the credit holds at review.
What the buyer receives
- A tool-qualification gap assessment keyed to the assigned tool qualification level
- A tool operational requirements and verification view per qualified tool
- A reconciliation of vendor-supplied data against the project's actual use
- A prioritized list of the qualification evidence to close before the credit is relied on
Who uses the output
- Certification leads defending the tool credit at a stage-of-involvement review
- Software and hardware teams closing the tool operational requirements and verification gaps
- Verification and tools teams managing the tool versions and problem reports
How the work fits into the transaction or program
The support protects the certification credit that the software and hardware work depends on, so the DO-178C and DO-254 evidence produced or checked by a tool stands when the credit is examined. It pairs with the software and hardware compliance work, since the tools serve those lifecycles, and surfaces where a tool drives a heavier qualification than the program assumed.
Start with a single asset
Confirm requirements trace through verification.
Regulatory limits
Endeavor Elements supports the applicant's tool-qualification data. It does not act as the authority or a delegate, make compliance findings, issue any approval, or guarantee that tool credit will be accepted. The applicant and the authority keep their roles, and the tool qualification level and the credit claimed remain the applicant's to justify.
What this review does not cover
- Making official compliance findings or acting as the authority or its delegate
- Issuing any approval, authorization, or design approval
- Developing the tool or running the tool verification campaign itself
Specific to this review
- DO-330 separates tools by whether they could insert an error into the product or fail to detect one, which is what drives the tool qualification level, so a verification tool that removes a manual check can warrant a higher level than expected.
- Tool qualification level is distinct from software level: a tool used on a high-level software program does not automatically inherit that level, and the determination depends on the tool's role.
- Tool operational requirements describe what the tool must do correctly for the project's use, so a qualification built around generic tool capability rather than the project's use is incomplete.
- A tool qualification is tied to a specific tool version and configuration, so an unverified version change can invalidate the credit the program relies on.
Sources
U.S. Government (eCFR). Type certificates, STCs (Subpart E), TSO authorizations (Subpart O), PMA (Subpart K), and export airworthiness approvals (Subpart L).
RTCA. Objectives and lifecycle data for airborne software assurance, by design assurance level (DAL A-E).
RTCA. Design assurance objectives and lifecycle data for airborne electronic hardware (FPGA/ASIC/PLD).
Federal Aviation Administration. FAA type certification process, certification basis establishment, and compliance findings.
Frequently asked questions
Does every tool we use need qualification?
No. Only tools whose output the program takes certification credit for need qualification, and the level depends on whether a tool error could go undetected. The review starts by determining which tools need it before assessing the evidence.
Is the tool qualification level the same as our software level?
No. The tool qualification level is determined from the tool's role under DO-330, not inherited from the software level of the program it serves. A tool used on a high-assurance program can still carry a different qualification level.
Relevant glossary terms
Related pages
Where this fits
Talk to an engineer who has done this work
We will walk through your current state, the records or evidence involved, and a scoped first engagement.
Walk through your situation with an engineer who has done this work.