DO-330 Software tool qualification considerations

Pub­lished June 11, 2026

Today’s com­plex safe­ty-crit­i­cal sys­tems depend heav­i­ly on soft­ware tools to achieve the lev­els of automa­tion, effi­cien­cy, and ver­i­fi­ca­tion demand­ed by mod­ern develop­ment process­es. Tool qual­i­fi­ca­tion helps ensure that those tools are suf­fi­cient­ly depend­able for their intend­ed use, in pro­por­tion to the risks asso­ci­at­ed with any fail­ures or errors they might intro­duce.

RTCA DO-330/EUROCAE ED-215, “Soft­ware Tool Qual­i­fi­ca­tion Con­sid­er­a­tions”, pro­vides guid­ance for the qual­i­fi­ca­tion of soft­ware tools used in safe­ty-crit­i­cal develop­ment envi­ron­ments. Although DO-330/ED-215 was devel­oped pri­mar­i­ly as a tech­nol­o­gy sup­ple­ment sup­port­ing civil avi­a­tion stan­dards such as DO-178C and DO-278A, the doc­u­ment itself also states that it may be applied in other domains, includ­ing auto­mo­tive, space, elec­tron­ic hard­ware, aero­nau­ti­cal data­bas­es, and safe­ty assess­ment process­es.

TASKING and DO-330 com­pli­ance

DO-330 qual­i­fi­ca­tion activ­i­ties can apply across the safe­ty-crit­i­cal soft­ware tool­chain. Develop­ment tools such as com­pil­ers and code gen­er­a­tors may require qual­i­fi­ca­tion because they can direct­ly influ­ence the exe­cutable soft­ware. Ver­i­fi­ca­tion, debug, and trace tools may also require qual­i­fi­ca­tion where their out­puts con­tribute to cer­ti­fi­ca­tion evi­dence.

The LDRA tool suite has a long his­to­ry of sup­port­ing DO-330 qual­i­fi­ca­tion activ­i­ties in civil avi­a­tion and other projects through proven ver­i­fi­ca­tion tech­nolo­gies and ded­i­cat­ed Tool Qual­i­fi­ca­tion Sup­port Packs. Beyond ver­i­fi­ca­tion, mod­ern safe­ty-crit­i­cal develop­ment increas­ing­ly relies on inte­grat­ed tool­chains span­ning com­pi­la­tion, debug, trace, test­ing, and analy­sis. TASKING com­pil­er and debug tech­nolo­gies are already estab­lished in demand­ing auto­mo­tive, indus­tri­al, and other safe­ty-crit­i­cal envi­ron­ments, demon­strat­ing the assur­ance and reli­a­bil­i­ty expect­ed of tools used in high-integri­ty soft­ware develop­ment.

RTCA DO-330 and EUROCAE ED-215 are effec­tive­ly the same doc­u­ment, devel­oped jointly by RTCA and EUROCAE work­ing groups. Togeth­er, they define the prin­ci­ples and objec­tives for qual­i­fy­ing soft­ware tools used in safe­ty-crit­i­cal develop­ment envi­ron­ments.

DO-330/ED-215, “Soft­ware Tool Qual­i­fi­ca­tion Con­sid­er­a­tions”, was intro­duced along­side DO-178C as one of the tech­nol­o­gy sup­ple­ments cre­at­ed to sup­port mod­ern soft­ware develop­ment and ver­i­fi­ca­tion prac­tices.

The doc­u­ment itself explains that:

Soft­ware tools are wide­ly used in mul­ti­ple domains, to assist in devel­op­ing, ver­i­fy­ing, and con­trol­ling other soft­ware… Exam­ples are auto­mat­ed code gen­er­a­tors, com­pil­ers, test tools, and mod­i­fi­ca­tion man­age­ment tools. This doc­u­ment explains the process and objec­tives for qual­i­fy­ing tools.

Unlike some of the other DO-178C sup­ple­ments, DO-330/ED-215 was writ­ten as a domain-inde­pen­dent, stand-alone doc­u­ment. Before the intro­duc­tion of DO-178C, tool qual­i­fi­ca­tion guid­ance formed part of the main DO-178B doc­u­ment. DO-330 sep­a­rat­ed those activ­i­ties out into a doc­u­ment intend­ed not only in projects com­pli­ant with such as DO-178C, DO-278A, DO-254, and DO-200C, but also for use in other safe­ty-crit­i­cal domains.

Accord­ing to the doc­u­ment itself, DO-330/ED-215 was devel­oped for three pri­ma­ry rea­sons:

• To pro­vide tool-spe­cif­ic guid­ance for both tool devel­op­ers and tool users
• To pro­vide a stan­dard focused specif­i­cal­ly on soft­ware tools rather than appli­ca­tion soft­ware, help­ing to avoid “con­fu­sion and mis­in­ter­pre­ta­tion”
• To pro­vide guid­ance applic­a­ble not only to air­borne and ground-based avi­a­tion sys­tems, but poten­tial­ly to “other domains such as auto­mo­tive, space, sys­tems, elec­tron­ic hard­ware, aero­nau­ti­cal data­bas­es, and safe­ty assess­ment process­es”

Prior to the intro­duc­tion of DO-330, tool qual­i­fi­ca­tion guid­ance formed part of the main DO-178B doc­u­ment. Sep­a­rat­ing those activ­i­ties out made the objec­tives clear­er and reflect­ed the increas­ing­ly sig­nif­i­cant role that inte­grat­ed develop­ment and ver­i­fi­ca­tion tool­chains play in mod­ern safe­ty-crit­i­cal develop­ment.

RTCA DO-178C / EUROCAE ED-12C “Soft­ware Con­sid­er­a­tions in Air­borne Sys­tems and Equip­ment Cer­ti­fi­ca­tion” is the prin­ci­pal soft­ware guid­ance doc­u­ment ref­er­enced by cer­ti­fi­ca­tion author­i­ties (includ­ing FAA, EASA, TCCA, and ANAC) to approve soft­ware used in com­mer­cial air­borne sys­tems. It defines the soft­ware life­cy­cle objec­tives and process­es used to demon­strate their cor­rect­ness and robust­ness.

DO-178C §12.2.3 states that:

The objec­tives, guid­ance, and life cycle required for each Tool Qual­i­fi­ca­tion Level are described in DO-330/ED-215, ‘Soft­ware Tool Qual­i­fi­ca­tion Con­sid­er­a­tions.’

RTCA DO-278A / EUROCAE ED-109A “Soft­ware Integri­ty Assur­ance Con­sid­er­a­tions for Com­mu­ni­ca­tion, Nav­i­ga­tion, Sur­veil­lance and Air Traf­fic Man­age­ment (CNS/ATM) Sys­tems” is a sis­ter doc­u­ment to DO-178C/ED-12C and adheres to sim­i­lar prin­ci­ples to ensure cor­rect­ness and robust­ness in soft­ware sys­tems for CNS/ATM appli­ca­tions.

DO-278A §12.2.3 states that:

The objec­tives, guid­ance, and life cycle required for each Tool Qual­i­fi­ca­tion Level are described in DO-330, ‘Soft­ware Tool Qual­i­fi­ca­tion Con­sid­er­a­tions.’

RTCA DO-254 / EUROCAE ED-80 “Design Assur­ance Guid­ance for Air­borne Elec­tron­ic Hard­ware” applies the prin­ci­ples of DO-330/ED-215 to soft­ware tools used in sup­port of air­borne elec­tron­ic hard­ware develop­ment and ver­i­fi­ca­tion.

RTCA DO-200C / EUROCAE ED-76B “Stan­dards for Pro­cess­ing Aero­nau­ti­cal Data” pro­vides addi­tion­al guid­ance for projects using model-based develop­ment and ver­i­fi­ca­tion tech­niques in con­junc­tion with DO-178C and DO-278A.

RTCA DO-331 / EUROCAE ED-216 “Model-Based Develop­ment and Ver­i­fi­ca­tion” describes adjust­ments to the prin­ci­ples described in DO-178C that apply when using model-based design. Like DO-330/ED-215, DO-331/ED-216 is one of the tech­nol­o­gy sup­ple­ments intro­duced when DO-178C replaced DO-178B. How­ev­er, DO-331/ED-216 is not applic­a­ble to domains other than avi­a­tion.

RTCA DO-332 / EUROCAE ED-217 “Object-Ori­ent­ed Tech­nol­o­gy and Relat­ed Tech­niques” pro­vides addi­tion­al objec­tives and guid­ance relat­ing to object-ori­ent­ed tech­nolo­gies and com­ple­men­tary soft­ware tech­niques used with­in DO-178C and DO-278A projects. Like DO-331 and DO-333, DO-332 is avi­a­tion-spe­cif­ic, where­as DO-330 was writ­ten as a domain-inde­pen­dent stan­dard.

RTCA DO-333 / EUROCAE ED-218 “For­mal Meth­ods Sup­ple­ment to DO-178C and DO-278A” pro­vides addi­tion­al guid­ance relat­ing to the use of for­mal meth­ods in com­pli­ant DO-178C and DO-278A appli­ca­tions. As with DO-331 and DO-332, the sup­ple­ment is avi­a­tion-spe­cif­ic, where­as DO-330 was designed for broad­er applic­a­bil­i­ty across mul­ti­ple safe­ty-crit­i­cal sec­tors.

Tool qual­i­fi­ca­tion is the process used to ensure that the risk of a soft­ware tool error impact­ing on the safe­ty of a sys­tem is accept­ably low. That may be because poten­tial errors are unlike­ly to occur, because they can be detect­ed else­where in the life­cy­cle, or because they can­not affect safe­ty-crit­i­cal behav­ior.

Many safe­ty and cer­ti­fi­ca­tion guid­ance doc­u­ments describe how tool qual­i­fi­ca­tion should be approached based on how the tool is used, and the envi­ron­ment in which it is deployed.

The appli­ca­tion per­spec­tive focus­es on ensur­ing that the tool is used in a way that allows poten­tial errors to be avoid­ed or detect­ed. Con­verse­ly, the envi­ron­men­tal per­spec­tive focus­es on ensur­ing that the tool oper­ates cor­rect­ly with­in the wider develop­ment tool chain and oper­a­tional envi­ron­ment in which it is deployed.

Across the var­i­ous safe­ty-crit­i­cal sec­tors, four pri­ma­ry approach­es to tool qual­i­fi­ca­tion are com­mon­ly applied:

• Proof in use
• Eval­u­a­tion of the tool develop­ment process
• Develop­ment in accor­dance with a safe­ty stan­dard
• Tool ver­i­fi­ca­tion

Of these approach­es, only tool ver­i­fi­ca­tion is direct­ly addressed by DO-330.

Tool ver­i­fi­ca­tion is the most thor­ough but most time-con­sum­ing approach to tool qual­i­fi­ca­tion. It is the only per­mit­ted approach for civil avi­a­tion projects, and is the only approach dis­cussed in DO-330/ED-215. It is often the only viable approach for the most crit­i­cal appli­ca­tions in other sec­tors, too.

Tool ver­i­fi­ca­tion activ­i­ties involve ana­lyz­ing each fea­ture of the tool with­in its intend­ed oper­a­tional envi­ron­ment and doc­u­ment­ing the results – often using a ven­dor val­i­da­tion suite. For sta­t­ic analy­sis, that means ensur­ing that fea­tures such as endi­an­ness and inte­ger size are cor­rect­ly con­fig­ured. Dynam­ic analy­sis is more depen­dent on the tool­chain because it involves build­ing and exe­cut­ing instru­ment­ed code on tar­get.

Any poten­tial errors in these fea­tures with the poten­tial to impact the safe­ty of the prod­uct are fur­ther assessed to deter­mine the prob­a­bil­i­ty of them being detect­ed or avoid­ed with­in the process.

Although DO-330/ED-215 was writ­ten to sup­port sec­tors beyond civil avi­a­tion, aero­space is still where it is most wide­ly used. Before the intro­duc­tion of DO-178C, tool qual­i­fi­ca­tion guid­ance formed part of the main DO-178B doc­u­ment, so the under­ly­ing qual­i­fi­ca­tion con­cepts and process­es will already feel famil­iar to many aero­space soft­ware teams.

DO-330 defines some qual­i­fi­ca­tion activ­i­ties that are per­formed by the tool devel­op­er. How­ev­er, respon­si­bil­i­ty ulti­mate­ly rests with the tool user to show that the tool is appro­pri­ate and suf­fi­cient­ly depend­able for its intend­ed use with­in the project.

Many safe­ty-crit­i­cal projects out­side civil avi­a­tion use less demand­ing approach­es to tool qual­i­fi­ca­tion, often rely­ing on evi­dence of prior assess­ment or the use of TÜV-cer­ti­fied tools. How­ev­er, the high­est crit­i­cal­i­ty appli­ca­tions in sec­tors such as auto­mo­tive, rail, indus­tri­al, and med­ical may still require qual­i­fi­ca­tion activ­i­ties approach­ing the level of tool ver­i­fi­ca­tion described by DO-330/ED-215.

Many func­tion­al safe­ty guid­ance doc­u­ments, includ­ing IEC 61508, EN 50716, and IEC 62304, define tool qual­i­fi­ca­tion expec­ta­tions with­out pre­scrib­ing the detailed process­es need­ed to achieve them. In these cases, the prin­ci­ples described in DO-330 can pro­vide a struc­tured and wide­ly under­stood approach.

Even where qual­i­fi­ca­tion sup­port is pro­vid­ed by the tool ven­dor, the orga­ni­za­tion devel­op­ing the safe­ty-crit­i­cal appli­ca­tion remains respon­si­ble for demon­strat­ing that the tool is suit­able and suf­fi­cient­ly depend­able for the required level of crit­i­cal­i­ty.

DO-330/ED-215 defines Tool Qual­i­fi­ca­tion Lev­els (TQLs) accord­ing to how a soft­ware tool could affect the safe­ty of the air­borne sys­tem. In prac­tice, that depends on:

• where the tool sits with­in the develop­ment life­cy­cle
• whether it can intro­duce errors into the exe­cutable soft­ware
• whether it is used as part of the ver­i­fi­ca­tion process

Dif­fer­ent cat­e­gories of tools there­fore align with dif­fer­ent qual­i­fi­ca­tion cri­te­ria.

Develop­ment tools can direct­ly influ­ence the exe­cutable object code deliv­ered to the tar­get sys­tem. These tools are typ­i­cal­ly asso­ci­at­ed with Cri­te­ri­on 1 because their out­put forms part of the air­borne soft­ware and could there­fore intro­duce an error.

Typ­i­cal exam­ples include:

• com­pil­ers
• assem­blers
• link­ers
• code gen­er­a­tors
• model-based auto-cod­ing tools

Com­pil­er tech­nol­o­gy is par­tic­u­lar­ly impor­tant in this con­text because opti­miza­tion, tar­get-spe­cif­ic code gen­er­a­tion, mem­o­ry mod­els, and lan­guage han­dling can all influ­ence the final exe­cutable image. Qual­i­fi­ca­tion activ­i­ties there­fore focus on ensur­ing that the com­pil­er behaves cor­rect­ly in con­text.

Ver­i­fi­ca­tion tools sup­port activ­i­ties designed to detect errors through­out the soft­ware life­cy­cle. Depend­ing on how their out­put is used, they typ­i­cal­ly align with Cri­te­ri­on 2 or Cri­te­ri­on 3.

Exam­ples include:

• sta­t­ic analy­sis tools
• struc­tur­al cov­er­age analy­sis tools
• unit test envi­ron­ments
• auto­mat­ed ver­i­fi­ca­tion frame­works

Where a ver­i­fi­ca­tion tool is used to jus­ti­fy reduc­ing or elim­i­nat­ing other ver­i­fi­ca­tion activ­i­ties, high­er qual­i­fi­ca­tion expec­ta­tions may apply.

The LDRA tool suite, for exam­ple, pro­vides sta­t­ic analy­sis, unit test­ing, struc­tur­al cov­er­age analy­sis, and require­ments trace­abil­i­ty capa­bil­i­ties wide­ly used in safe­ty-crit­i­cal soft­ware projects requir­ing qual­i­fi­ca­tion in accor­dance with DO-330.

Debug­gers and trace tech­nolo­gies occu­py a more nuanced posi­tion with­in DO-330 because their qual­i­fi­ca­tion require­ments depend heav­i­ly on oper­a­tional con­text.

A debug­ger used infor­mal­ly dur­ing soft­ware develop­ment may not require qual­i­fi­ca­tion at all. How­ev­er, where debug or trace data con­tributes to cer­ti­fi­ca­tion evi­dence, qual­i­fi­ca­tion activ­i­ties may become nec­es­sary. Exam­ples include:

• struc­tur­al cov­er­age analy­sis
• tim­ing ver­i­fi­ca­tion
• mul­ti­core inter­fer­ence analy­sis
• require­ments-based test­ing

Mod­ern debug and trace envi­ron­ments increas­ing­ly pro­vide deep vis­i­bil­i­ty into soft­ware exe­cu­tion on tar­get hard­ware. TASKING winIDEA, for exam­ple, com­bines debug, trace, test, and analy­sis capa­bil­i­ties with­in an inte­grat­ed envi­ron­ment sup­port­ing both intru­sive and non-intru­sive ver­i­fi­ca­tion approach­es.

Tool Qual­i­fi­ca­tion Lev­els (TQLs) are deter­mined based on three cri­te­ria.

Soft­ware Level (derived from DAL)	Cri­te­ri­on 1	Cri­te­ri­on 2	Cri­te­ri­on 3
A	TQL-1	TQL-4	TQL-5
B	TQL-2	TQL-4	TQL-5
C	TQL-3	TQL-5	TQL-5
D	TQL-4	TQL-5	TQL-5

Cri­te­ri­on 1

A tool whose out­put forms part of the air­borne soft­ware and could there­fore intro­duce an error.

Cri­te­ri­on 2

A tool that auto­mates ver­i­fi­ca­tion activ­i­ties and whose out­put is used to jus­ti­fy reduc­ing or elim­i­nat­ing other ver­i­fi­ca­tion or develop­ment process­es.

Cri­te­ri­on 3

A tool that, with­in the scope of its intend­ed use, could fail to detect an error.

The result­ing Tool Qual­i­fi­ca­tion Level depends on both:

• the applic­a­ble cri­te­ri­on
• the Design Assur­ance Level (DAL) of the air­borne soft­ware

For exam­ple, a com­pil­er will typ­i­cal­ly align with Cri­te­ri­on 1 because it direct­ly affects the gen­er­at­ed exe­cutable code. Ver­i­fi­ca­tion and debug tools more com­mon­ly align with Cri­te­ri­on 2 or Cri­te­ri­on 3, depend­ing on how their out­puts are used with­in the cer­ti­fi­ca­tion process.

Under the terms of DO-330/ED-215, tool qual­i­fi­ca­tion is assessed on a project-by-project basis. TÜV cer­ti­fi­ca­tion and sim­i­lar third-party approvals can be valu­able in many func­tion­al safe­ty con­texts, but they do not replace DO-330 qual­i­fi­ca­tion where DO-178C or DO-278A objec­tives apply.

Many tool ven­dors pro­vide qual­i­fi­ca­tion sup­port mate­r­i­al to help users com­plete that project-spe­cif­ic activ­i­ty. Usu­al­ly known as Tool Qual­i­fi­ca­tion Kits or Tool Qual­i­fi­ca­tion Sup­port Packs (TQSPs), these arte­facts may include doc­u­men­ta­tion, ver­i­fi­ca­tion pro­ce­dures, test cases, expect­ed results, and report­ing mate­r­i­al designed to help demon­strate that a tool behaves cor­rect­ly with­in the envi­ron­ment in which it will be used.

That dis­tinc­tion mat­ters across the wider develop­ment tool­chain. TASKING com­pil­er tech­nolo­gies are TÜV cer­ti­fied for func­tion­al safe­ty stan­dards includ­ing ISO 26262 and IEC 61508, while TASKING winIDEA pro­vides qual­i­fi­ca­tion sup­port for safe­ty-crit­i­cal debug and trace activ­i­ties in those envi­ron­ments. Togeth­er, these tech­nolo­gies are already proven in demand­ing safe­ty-crit­i­cal appli­ca­tions, help­ing to under­pin their poten­tial use with­in civil avi­a­tion develop­ment and ver­i­fi­ca­tion work­flows where project-spe­cif­ic DO-330 qual­i­fi­ca­tion activ­i­ties are required.

The LDRA tool suite is sup­port­ed by a DO-330/ED-215 Tool Qual­i­fi­ca­tion Sup­port Pack (TQSP) for ver­i­fi­ca­tion activ­i­ties. The TQSP con­sists of five sub-packs, each of which can be spec­i­fied as an oper­a­tional require­ment for the rel­e­vant develop­ment project:

• Pro­gram­ming Rules Check­ing
• Struc­tur­al Cov­er­age Analy­sis
• Data Cou­pling and Con­trol Cou­pling
• Assem­bler Cov­er­age Analy­sis
• Unit Test / Low Level Test

It includes four key doc­u­ments designed to guide the user through the val­i­da­tion process. The process defined by these doc­u­ments ensures the cre­ation of evi­den­tial arte­facts and the com­pi­la­tion of reports designed to sum­ma­rize find­ings in a form appro­pri­ate to the stan­dard. These four doc­u­ments are as fol­lows:

The Tool Ver­i­fi­ca­tion Plan pro­vid­ed by the TQSP for con­fig­u­ra­tion to suit the appli­ca­tion includes source code, test cases, and expect­ed results, for use in ver­i­fy­ing the effec­tive­ness of the tool in the intend­ed instal­la­tion envi­ron­ment.

The TQSP pro­vides a gener­ic Tool Accom­plish­ment Sum­ma­ry tem­plate for cus­tomiza­tion by the user in accor­dance with the TVP. The TAS describes:

• the tool and its archi­tec­ture
• the tool­chain and deploy­ment envi­ron­ment
• the results of the ver­i­fi­ca­tion activ­i­ties asso­ci­at­ed with the qual­i­fi­ca­tion process

Extracts from the Tool Accom­plish­ment Sum­ma­ry pro­vid­ed as part of the DO-330/ED-215 TQSP are shown below.

For qual­i­fi­ca­tion under RTCA DO-330/EUROCAE ED-215, Tool Oper­a­tional Require­ments (TORs) must be defined clear­ly and unam­bigu­ous­ly.

To sup­port qual­i­fi­ca­tion activ­i­ties, the TORs should:

• be ver­i­fi­able
• remain inter­nal­ly con­sis­tent
• define the intend­ed func­tion­al­i­ty of the tool in suf­fi­cient detail
• demon­strate that the result­ing out­puts cor­re­spond cor­rect­ly to the life­cy­cle activ­i­ties sup­port­ed or replaced by the tool

An extract from the TOR tem­plate pro­vid­ed with­in the TQSP is shown below.

The Tool Qual­i­fi­ca­tion Plan cap­tures project-spe­cif­ic qual­i­fi­ca­tion infor­ma­tion iden­ti­fied dur­ing the ver­i­fi­ca­tion process. In civil avi­a­tion appli­ca­tions, the TQP will typ­i­cal­ly align close­ly with the wider cer­ti­fi­ca­tion plan­ning activ­i­ties, includ­ing the Plan for Soft­ware Aspects of Cer­ti­fi­ca­tion (PSAC) as illus­trat­ed below.

Select­ing tools for safe­ty-crit­i­cal soft­ware develop­ment is no longer just a ques­tion of fea­tures or pro­duc­tiv­i­ty. In a DO-330 envi­ron­ment, com­pil­ers, debug­gers, trace tech­nolo­gies, and ver­i­fi­ca­tion tools may all con­tribute direct­ly or indi­rect­ly to cer­ti­fi­ca­tion evi­dence.

That changes the con­ver­sa­tion con­sid­er­ably.

A com­pil­er can influ­ence the gen­er­at­ed exe­cutable code. A debug or trace envi­ron­ment may con­tribute to struc­tur­al cov­er­age or tim­ing evi­dence. Ver­i­fi­ca­tion tools may sup­port require­ments trace­abil­i­ty, sta­t­ic analy­sis, test­ing, or cov­er­age assess­ment activ­i­ties.

The impor­tant ques­tion is not sim­ply whether the tools work indi­vid­u­al­ly, but whether they can work togeth­er con­sis­tent­ly, pre­dictably, and with suf­fi­cient evi­dence to sup­port the cer­ti­fi­ca­tion process.

That means look­ing beyond func­tion­al­i­ty alone. Qual­i­fi­ca­tion sup­port, tool­chain inte­gra­tion, tar­get behav­ior, and long-term main­tain­abil­i­ty all mat­ter in safe­ty-crit­i­cal projects.

DO-330 PDFs – free down­load

Tech­ni­cal brief­ing – DO-330 test tool qual­i­fi­ca­tion for aero­space appli­ca­tions

Tech­ni­cal brief­ing – Lever­ag­ing DO-330 and ISO 26262 tool ver­i­fi­ca­tion tech­niques for devel­op­ments com­pli­ant with other func­tion­al safe­ty stan­dards

Tech­ni­cal white paper – Test tool qual­i­fi­ca­tion for func­tion­al safe­ty

DO-330 – fur­ther infor­ma­tion

Cer­ti­fi­ca­tion and Reg­u­la­to­ry Sup­port