DO-330 tool qualification for ML development and verification toolchains

This article is about the toolchain, not the trained model that flies. For why that model is usually a DO-178C software item rather than a DO-330 tool, see How to map an AI model to DO-178C / DO-330 tool qualification. Here the question is different: if you rely on training pipelines, code generators, test generators or robustness analyzers to skip reviewing their output, when does DO-178C subsection 12.2 send you to DO-330?

What counts as a tool

RTCA’s DO-330 product page defines a tool as a computer program used to help develop, transform, test, analyze, produce or modify another program, its data or its documentation, for example code generators, compilers and test tools. FAA Order 8110.49A, which tells Aircraft Certification staff how to apply DO-178B/C, says references to DO-178C include use of supplements (DO-331, DO-332, DO-333) and DO-330, as applicable, and that tool qualification is the process necessary to obtain certification credit for a software tool within the context of a specific airborne system (citing DO-178B/C Section 12.2).

That last clause matters for ML stacks. Qualification is within the context of a specific airborne system, not a vendor certificate you reuse unchanged.

When 12.2 says qualification is necessary

RTCA’s Forum for Aeronautical Software topic paper FTP1055 is the public page that states the 12.2 decision without reproducing DO-178C. If the tool outputs are verified independently of the tool, then no qualification is necessary. For a tool that cannot introduce an error in the software but could fail to detect an error, independent verification of the output, including confirmation of the activity the tool is eliminating, reducing or automating, likewise means no qualification is necessary. In all other cases qualification is necessary. The criteria live in DO-178C subsection 12.2; DO-330 provides the guidance.

Analysis, labeled as such: an ML training job that emits weights you then treat as the airborne design without reviewing them against data-set requirements is in the “all other cases” bucket. A robustness analyzer whose every finding you independently confirm is not. FTP1055 does not name neural-network trainers; that mapping is ours.

TQL-5 versus TQL-1

FTP1055 says most tools are TQL-5, and only need to meet 14 DO-330/ED-215 objectives (versus TQL-1 must meet 76 objectives). TQL-5 tools are those that are used in a verification manner and cannot directly modify the software product itself. Qualifying at TQL-5 does not require any artifact on how the tool has been developed: it is a full black box approach. TQL-1 applies when some development objectives of airborne software at level A are automated by the software tool; the example is an auto code generation tool that creates source code from diagrams for Level A software whose source is not reviewed against those diagrams.

We did not find an FAA or RTCA table that assigns TQL-1 through TQL-5 to training frameworks, data-labeling services, coverage tools or neural-network verifiers. DO-178C remains an acceptable means, but not the only means of showing software compliance; AC 20-115D does not constitute a regulation.

What vendors publish (not a qualification)

MathWorks’ DO Qualification Kit provides documentation, test cases, and procedures that let you qualify Simulink and Polyspace software verification tools for projects based on DO-178C, DO-278A, DO-254, and related supplements. Kits are available for specific versions of Simulink and Polyspace verification tools based on DO-330. The same page says the kit does not “prequalify” tools: tool qualification must be performed in the context of each specific project and operational environment. That matches Order 8110.49A’s specific airborne system wording.

A MathWorks airborne deep-learning worked example includes the development and verification activities required by DO-178C, ARP4754A, and prospective EASA and FAA guidelines and points readers to a DO Qualification Kit case study. That is a vendor example, not an FAA means of compliance. See the listings for the DO Qualification Kit and AI Verification Library. Ansys SCADE Suite names KCG as qualified … for DO-178C/DO-330 at TQL-1. Rapita RVS names qualification kits for DO-178C. Those pages describe conventional code generation and verification tools, not an ML-toolchain TQL table.

What is not a replacement process standard yet

The FAA roadmap supports the application, and possible extension, of existing standards including DO-178C/ED-12 and DO-330/ED-215. “Possible extension” is not a published table of ML-tool TQLs. EUROCAE still lists ED-324 / ARP6983 as a draft, target publication 31/12/2026. Until that document is issued and accepted, there is no public G-34 process standard that replaces DO-330 for ML toolchains. Status is on the SAE G-34 / ARP6983 status article and the SAE G-34 explainer.

What we searched for and did not find

We did not find an FAA advisory circular, EASA acceptable means of compliance, or RTCA topic paper that assigns TQL-1 through TQL-5 to ML training, data-labeling, or robustness-verification products. We also did not find a sentence that says qualifying the training stack to DO-330 replaces DO-178C assurance of the airborne software those tools produce. Treat TQL as a 12.2 question for the certification authority. Broader ML-versus-DO-178C gaps are in DO-178C and machine learning.

Questions

If I independently review every training run, do I still qualify the trainer?

FTP1055 says that if the tool outputs are verified independently of the tool, then no qualification is necessary. Whether your review is independent in that sense is a project-level 12.2 determination, not a directory claim.

Does a TQL-5 robustness analyzer cover the airborne model?

No source we cite says that. TQL-5 is for tools used in a verification manner that cannot directly modify the software product. The model that executes on the aircraft is still in the DO-178C conversation.