Tool-qualification evidence review for avionics and equipment suppliers

When this review is needed

• Verification or code generation was automated and the credit taken from the tools has to be substantiated before submittal.
• A tool was upgraded mid-program and the qualification on record was never re-run against the new version.
• A reviewer is asking which tool output is relied on and what stops a tool error from reaching the certified article.
• Credit was claimed for a tool that eliminates a verification activity, and the qualification level has to match that reliance.

The problem

Tools quietly become load-bearing. A generator replaces hand coding, a checker replaces a manual review, and the credit for that activity now rests on the tool behaving correctly. The qualification that should back the credit is often assigned by habit rather than by what the tool actually does, runs against an older tool version, or is missing the operational requirements that define correct output. When the tool credit outruns its qualification, the activity the tool replaced has no real assurance behind it.

What gets reviewed

• The tool use analysis and what each tool's output is relied on to do
• The tool qualification level assigned against the criteria the use sets
• The operational requirements that define correct behavior for each tool
• The qualification data and whether it exercises those operational requirements
• The tool version on record against the version the program actually used
• The credit each tool is claimed to support in the lifecycle data

What gets validated

• Each tool taking credit appears in the tool use analysis with its claimed effect
• The assigned tool qualification level matches the criteria the tool's use triggers
• Operational requirements define correct output for the way each tool is used
• Qualification data exercises the operational requirements the tool is qualified against
• The qualified tool version matches the version that produced the certification data
• Tools that eliminate a verification activity carry the qualification that reliance demands
• Tool credit in the lifecycle data is consistent with the qualification actually on record

Evidence normally required

• The tool use analysis and the list of tools in the development and verification flow
• The tool qualification plan and the assigned qualification levels
• The operational requirements and qualification data for each qualified tool
• The tool versions used to produce the certification data
• The lifecycle data showing where tool credit was claimed

Common discrepancies

• A tool qualification level assigned below what the tool's actual use requires
• Qualification data run against a tool version the program has since upgraded past
• Operational requirements that do not cover the way the tool was actually used
• Tool credit claimed in the lifecycle data with no qualification record behind it
• A generation tool relied on without the qualification that eliminating verification demands
• Tools present in the flow that never appear in the tool use analysis

What is at stake

Credit taken from an under-qualified tool is credit a reviewer can withdraw, which puts the eliminated verification activity back on the program. Re-establishing that assurance late, by hand or by re-qualifying the tool, costs far more than confirming the tool credit before the package goes out.

How the work runs

What the buyer receives

• A tool register listing each tool's claimed credit, qualification level, and evidence status
• A list of tools whose use exceeds the qualification on record
• A version-match check between qualified tools and the tools that produced the data
• A prioritized closure list ordered by how much credit each gap puts at risk

Who uses the output

• Certification leads confirming the tool credit before submittal
• Software engineering teams re-aligning qualification with tool use
• Process assurance leads tracking which tools the package depends on

How the work fits into the transaction or program

The review checks the tool layer that the software and hardware evidence quietly rely on. It pairs with a qualification-test-report review when the tooled outputs feed the test campaign, and with a quality-assurance records review when the question is whether the tool process was controlled.

Jurisdiction-specific considerations

FAA and EASA both recognize tool qualification through the same RTCA and EUROCAE guidance, so the technical criteria align closely. What can differ is how a program documents the tool case within its lifecycle plans, so the review checks the qualification against the criteria the use triggers regardless of which authority the submittal is bound for.

Regulatory limits

Endeavor Elements checks the applicant's tool-qualification evidence for completeness, consistency, and traceability. It does not qualify tools, make compliance findings, or issue any approval. The applicant and the authority keep their roles.

What this review does not cover

• Qualifying the tools or generating the qualification data
• Making official compliance findings or issuing any approval
• Selecting or operating the supplier's development and verification tools

Specific to this review

• Tool credit grows silently: an automated step replaces a manual one without anyone re-checking that the tool's qualification still backs the activity it now stands in for.
• The qualification level a tool needs is set by what its output is relied on to do, so a generator that removes verification carries a heavier burden than a tool whose output is independently checked.
• A tool upgrade can invalidate qualification: data run against an older version does not automatically cover the version the program actually used.
• Operational requirements are the contract the qualification tests against; without them a tool can be qualified for a behavior nobody on the program actually uses.

Sources

Frequently asked questions

Relevant glossary terms

Related pages

Where this fits