DO-331/ED-216 Model-Based Development and Verification Supplement

Pub­lished June 11, 2026

“DO-331 – Model-Based Develop­ment and Ver­i­fi­ca­tion Sup­ple­ment to DO-178C and DO-278A” describes con­cepts and key fea­tures of Model-Based Develop­ment (MBD) and relat­ed tech­niques in the con­text of DO-178C & DO-278A com­pli­ant projects. It dis­cuss­es their impact on the plan­ning, develop­ment, and ver­i­fi­ca­tion process­es, and enu­mer­ates their vul­ner­a­bil­i­ties.

DO-331 intro­duces addi­tion­al con­sid­er­a­tions for projects using model-based develop­ment and model-based ver­i­fi­ca­tion tech­niques. LDRA tools help teams estab­lish trace­abil­i­ty between require­ments, mod­els, source code, tests, and ver­i­fi­ca­tion results, while pro­vid­ing analy­sis and test­ing capa­bil­i­ties for both hand-writ­ten and auto-gen­er­at­ed code. Struc­tur­al cov­er­age analy­sis, includ­ing MC/DC, data cou­pling and con­trol cou­pling analy­sis, and cer­ti­fi­ca­tion report­ing help sup­port ver­i­fi­ca­tion activ­i­ties, while qual­i­fi­ca­tion sup­port mate­r­i­al is avail­able where DO-330 tool qual­i­fi­ca­tion is required.

In the early 2000s, model-based develop­ment (MBD) was gain­ing trac­tion as a pow­er­ful tech­nique in embed­ded soft­ware engi­neer­ing, but its appli­ca­tion in safe­ty-crit­i­cal avion­ics sys­tems raised con­cerns about model fideli­ty, trace­abil­i­ty, and ver­i­fi­ca­tion. In response, in 2002 the Cer­ti­fi­ca­tion Author­i­ties Soft­ware Team (CAST) pub­lished the CAST-16 posi­tion paper to out­line key issues and lim­i­ta­tions asso­ci­at­ed with MBD in the con­text of DO-178B.

As part of the tran­si­tion from DO-178B to DO-178C, it was decid­ed that the spe­cif­ic chal­lenges and addi­tion­al objec­tives asso­ci­at­ed with model-based develop­ment and ver­i­fi­ca­tion would not be addressed with­in the core stan­dard, but rather through a ded­i­cat­ed sup­ple­ment: “DO-331 – Model-Based Develop­ment and Ver­i­fi­ca­tion Sup­ple­ment to DO-178C and DO-278A.” This sup­ple­ment defines the scope, ter­mi­nol­o­gy, life­cy­cle data, and ver­i­fi­ca­tion activ­i­ties applic­a­ble when mod­el­ling is used as part of the soft­ware develop­ment process.

The RTCA and EUROCAE ver­sions are har­mo­nized and were both pub­lished in Jan­u­ary 2012. Togeth­er, they form one of four offi­cial tech­nol­o­gy sup­ple­ments intro­duced to accom­pa­ny DO-178C and DO-278A, enabling the safe and cer­ti­fi­able use of mod­ern soft­ware engi­neer­ing prac­tices in safe­ty-crit­i­cal envi­ron­ments.

The pur­pose of DO-331/ED-216 is to pro­vide guid­ance on the use of Model-Based Develop­ment (MBD) and Model-Based Ver­i­fi­ca­tion (MBV) in safe­ty-crit­i­cal soft­ware sys­tems. It sup­ple­ments DO-178C and DO-278A by iden­ti­fy­ing the addi­tion­al con­sid­er­a­tions, risks, and ben­e­fits spe­cif­ic to using mod­els as part of the soft­ware life­cy­cle — includ­ing model sim­u­la­tion, auto-code gen­er­a­tion, and model-level ver­i­fi­ca­tion.

Accord­ing to the doc­u­ment itself, DO-331 “con­tains mod­i­fi­ca­tions and addi­tions to DO-178C [and DO-278A] objec­tives, activ­i­ties, explana­to­ry text, and soft­ware life­cy­cle data that should be addressed when model-based develop­ment and ver­i­fi­ca­tion are used as part of the soft­ware develop­ment life cycle.”

RTCA DO-178C (DO-178C/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 doc­u­ment ref­er­enced by cer­ti­fi­ca­tion author­i­ties (FAA, EASA, TCCA, ANAC …) to approve all com­mer­cial soft­ware-based aero­space sys­tems. It is a for­mal process stan­dard that cov­ers the com­plete soft­ware life­cy­cle to ensure cor­rect­ness and robust­ness in soft­ware sys­tems for civil air­borne appli­ca­tions.

DO-178C §1.4b states that “One or more sup­ple­ments to this doc­u­ment exist extend the guid­ance in this doc­u­ment to a spe­cif­ic tech­nique. Sup­ple­ments are used in con­junc­tion with this doc­u­ment and may be used in con­junc­tion with one anoth­er”. DO-331/ED-216 falls into that cat­e­go­ry of sup­ple­ment.

Sup­ple­ments are also ref­er­ences in DO-178C Appen­dix A.

RTCA DO-278A (DO-278A/ED-190A). “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 §1.4o states that “One or more sup­ple­ments to this doc­u­ment exist extend the guid­ance in this doc­u­ment to a spe­cif­ic tech­nique. Sup­ple­ments are used in con­junc­tion with this doc­u­ment and may be used in con­junc­tion with one anoth­er”. DO-331/ED-216 falls into that cat­e­go­ry of sup­ple­ment.

DO-331/ED-216 is one of four tech­nol­o­gy sup­ple­ments intro­duced along­side DO-178C and DO-278A. The oth­ers are DO-330/ED-215, which address­es soft­ware tool qual­i­fi­ca­tion con­sid­er­a­tions; DO-332/ED-217, which pro­vides guid­ance for object-ori­ent­ed tech­nol­o­gy and relat­ed tech­niques; and DO-333/ED-218, which cov­ers the use of for­mal meth­ods. These sup­ple­ments may be applied indi­vid­u­al­ly or in com­bi­na­tion, depend­ing on the tech­nolo­gies used with­in a project.

Process that gen­er­ates the life cycle data	MB Exam­ple 1	MB Exam­ple 2	MB Exam­ple 3	MB Exam­ple 4	MB Exam­ple 5
Sys­tem Require­ment and Sys­tem Design Process­es	Require­ments allo­cat­ed to soft­ware	Require­ments from which the Model is devel­oped	Require­ments from which the Model is devel­oped	Require­ments from which the Model is devel­oped	Require­ments from which the Model is devel­oped
Soft­ware Require­ment and Soft­ware Design Process­es	Require­ments from which the Model is devel­oped	Spec­i­fi­ca­tion Model	Spec­i­fi­ca­tion Model	Design Model	Design Model
	Design Model	Design Model	Tex­tu­al descrip­tion
Soft­ware Cod­ing Process	Source Code	Source Code	Source Code	Source Code	Source Code

Both Model-Based Sys­tems Engi­neer­ing (MBSE) and Model-Based Develop­ment (MBD) are addressed with­in DO-331. The MBSE guid­ance pro­vid­ed empha­sizes the over­all system’s require­ments and inter­ac­tions, while MBD rec­om­men­da­tions con­cen­trate on the software’s design and test­ing process­es.

DO-331 takes the approach that spec­i­fi­ca­tion mod­els or design mod­els replace high-level and low-level require­ments respec­tive­ly. Table MB.1-1 shows that tex­tu­al require­ments may be linked to mod­els upstream or down­stream. The stan­dard details some caveats (Notes 1-3) that apply to this table; these are omit­ted here for brevi­ty.

Pop­u­lar tools such as Math­Works® Simulink®, IBM® Engi­neer­ing Sys­tems Design Rhap­sody®, and ANSYS® SCADE Suite can gen­er­ate code auto­mat­i­cal­ly. LDRA tools sup­port the ver­i­fi­ca­tion of code gen­er­at­ed by these and many other mod­el­ling envi­ron­ments, help­ing organ­i­sa­tions main­tain trace­abil­i­ty and pro­duce the evi­dence required for cer­ti­fi­ca­tion.

MB.5.0 address­es trace­abil­i­ty, model stan­dards and more for both soft­ware require­ments and design process­es where such tools are used. §MB.5.3 (Soft­ware Cod­ing Process) is mere­ly a cross-ref­er­ence the equiv­a­lent sec­tion in DO 178C, under­lin­ing the fact that best-prac­tice cod­ing-relat­ed process activ­i­ties still apply whether code is hand-coded based on a set of tex­tu­al require­ments, hand-coded based on design mod­els, or auto-gen­er­at­ed from a tool. LDRA’s tools and ser­vices are there­fore as applic­a­ble here as for hand-writ­ten code.

Projects using auto-gen­er­at­ed code almost always con­tain some hand code (that is, hand­writ­ten code) and can also include lega­cy hand-coded com­po­nents. It is pos­si­ble to apply dif­fer­ent cod­ing stan­dards to these dif­fer­ent code sub­sets, such as MISRA C:2025 for hand code, MISRA AC:2023 for auto-gen­er­at­ed code, and a cus­tom cod­ing stan­dard for lega­cy code.

DO-331 §MB.6.8.2 states:

Ver­i­fi­ca­tion of the Exe­cutable Object Code is pri­mar­i­ly per­formed by test­ing. This can be par­tial­ly assist­ed by a com­bi­na­tion of model sim­u­la­tion and spe­cif­ic analy­sis … This com­bi­na­tion can be used to par­tial­ly sat­is­fy the fol­low­ing soft­ware test­ing objec­tives.

Those objec­tives include the com­pli­ance of EOC with high-level and low-level require­ments, test cov­er­age of soft­ware struc­ture, and data cou­pling and con­trol cou­pling. Addi­tion­al ver­i­fi­ca­tion activ­i­ties must be per­formed on the tar­get hard­ware to fully sat­is­fy these objec­tives. The doc­u­ment goes on to say that when cer­ti­fi­ca­tion cred­it is sought from model sim­u­la­tion to par­tial­ly sat­is­fy soft­ware test­ing objec­tives and test cov­er­age regard­ing high-level require­ments then it must be ensured that the same design model is used for code gen­er­a­tion and to pro­duce the EOC.

It also spec­i­fies that plans are required to define which require­ments and asso­ci­at­ed test and test cov­er­age activ­i­ties are to be sat­is­fied at the model level, and which are to be exer­cised on the tar­get.

DO-331 §MB.6.8.2 goes on to say:

… spe­cif­ic tests should still be per­formed in the tar­get envi­ron­ment … The fol­low­ing soft­ware test­ing and test cov­er­age objec­tives can­not be sat­is­fied by the model sim­u­la­tion since sim­u­la­tion cases should be based on the require­ments from which the model is devel­oped.

These objec­tives list­ed include EOC robust­ness, its com­pli­ance with low-level require­ments, and test cov­er­age of low-level require­ments.

The sup­ple­ment then iden­ti­fies the var­i­ous forms of ver­i­fi­ca­tion objec­tives that can only be met on the tar­get, includ­ing con­fir­ma­tion of com­pat­i­bil­i­ty with the tar­get hard­ware, and hardware/software inte­gra­tion test­ing. It also lists var­i­ous types of errors that can and can­not be revealed at the sim­u­la­tion level and can only be detect­ed on the tar­get hard­ware.

In DO-331 Appen­dix MB.B, §MB.B.11 (FAQ #11) states that:

Model cov­er­age analy­sis is dif­fer­ent than struc­tur­al cov­er­age analy­sis and there­fore model cov­er­age analy­sis does not elim­i­nate the need to achieve the objec­tives of struc­tur­al cov­er­age analy­sis per DO-178C sec­tion 6.4.4.2.

It goes on to state that model cov­er­age analy­sis can be con­sid­ered in very spe­cif­ic sce­nar­ios, “…on a case-by-case basis and agreed upon by the cer­ti­fi­ca­tion author­i­ties …”

As a result, most orga­ni­za­tions do some of the ver­i­fi­ca­tion activ­i­ties with­in the model but then re-affirm the results of those activ­i­ties on the tar­get hard­ware to ensure that they meet the nec­es­sary cri­te­ria for meet­ing objec­tives.

The inte­gra­tion of test and mod­el­ling tools help to achieve that seam­less­ly, includ­ing the sta­t­ic analy­sis of gen­er­at­ed code, the col­lec­tion of code cov­er­age from model exe­cu­tion, and the migra­tion of model tests into an appro­pri­ate form for exe­cu­tion on the tar­get hard­ware.

DO-331/ED-216 pro­vides essen­tial guid­ance for the safe and cer­ti­fi­able appli­ca­tion of model-based develop­ment and model-based ver­i­fi­ca­tion with­in DO-178C and DO-278A com­pli­ant projects. By address­ing the unique chal­lenges of mod­el­ling, code gen­er­a­tion, and sim­u­la­tion, it ensures that projects using these tech­niques main­tain the rigor and trace­abil­i­ty required for cer­ti­fi­ca­tion. Togeth­er with the other tech­nol­o­gy sup­ple­ments intro­duced along­side DO-178C and sup­port­ed by LDRA tools and ser­vices, DO-331 enables mod­ern soft­ware engi­neer­ing prac­tices to be incor­po­rat­ed into safe­ty-crit­i­cal sys­tems with­out com­pro­mis­ing on qual­i­ty or assur­ance.

• Tech­ni­cal white paper: Migrat­ing test cases from mod­el­ling tools to the LDRA tool suite for regres­sion on tar­get
• Tech­ni­cal white paper: Ver­i­fi­ca­tion of Air­borne Soft­ware in Com­pli­ance with DO-178C
• Tech­ni­cal white paper: Devel­op­ing com­pli­ant crit­i­cal soft­ware sys­tems with mul­ti­core proces­sors
• Tech­ni­cal white paper: Fol­low­ing the rec­om­men­da­tions of CAST-32A & A(M)C 20-193
• Tech­ni­cal brief­ing: DO-178C demys­ti­fied: Strate­gies for effi­cient cer­ti­fi­ca­tion
• Tech­ni­cal brief­ing: Get­ting to grips with CAST-32A & A(M)C 20-193
• Tech­ni­cal note: Achieve DO-178C com­pli­ance with LDRA tool suite
• Data sheet: DO-178C with the LDRA tool suite
• Data sheet: LDRA Pro­duc­tiv­i­ty Pack­age – Aero­space and Defense

• Blog: DO-178C & Struc­tur­al Cov­er­age Analy­sis
• Blog: The adop­tion of DO-178C in mil­i­tary appli­ca­tions
• Web­site: DO-330 Soft­ware tool qual­i­fi­ca­tion con­sid­er­a­tions: When, where, and how it applies
• Tech­ni­cal brief­ing: Achieve DO-178C com­pli­ance with LDRA tool suite
• Tech­ni­cal brief­ing: DO-330 Test tool qual­i­fi­ca­tion for aero­space appli­ca­tions
• News arti­cle: Ensur­ing the com­pli­ance of avion­ics soft­ware with DO-178C
• Train­ing: On Demand DO-178C “First Flight” Self-paced online train­ing course
• Case study: Rich­land tech­nolo­gies case study