DO-332/ED-217 Object-Oriented Technology Supplement

Pub­lished June 11, 2026

“DO-332 – Object-Ori­ent­ed Tech­nol­o­gy and Relat­ed Tech­niques Sup­ple­ment to DO-178C and DO-278A” describes con­cepts and key fea­tures of object-ori­ent­ed tech­nolo­gies and relat­ed tech­niques in the con­text of DO-178C and 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-332 intro­duces addi­tion­al con­sid­er­a­tions for projects using object-ori­ent­ed tech­nolo­gies and relat­ed tech­niques, includ­ing inher­i­tance, poly­mor­phism, dynam­ic dis­patch, and dynam­ic mem­o­ry man­age­ment. TASKING tech­nolo­gies help teams address these chal­lenges through sta­t­ic analy­sis, cod­ing stan­dards enforce­ment, require­ments trace­abil­i­ty, and com­pre­hen­sive ver­i­fi­ca­tion capa­bil­i­ties for object-ori­ent­ed soft­ware.

Struc­tur­al cov­er­age analy­sis, includ­ing MC/DC, source-to-object code trace­abil­i­ty, data cou­pling and con­trol cou­pling analy­sis, and low-level test­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, object-ori­ent­ed tech­nol­o­gy was viewed in the com­mer­cial avion­ics space as novel and unproven. Around that time the Cer­ti­fi­ca­tion Author­i­ties Soft­ware Team (CAST) pub­lished papers to enu­mer­ate con­cerns and lim­i­ta­tions. These were called CAST 4 and CAST 8 and were pub­lished in 2000 and 2002 respec­tive­ly.

As DO-178B was updat­ed to DO-178C, it was decid­ed that these con­cerns, vul­ner­a­bil­i­ties, and sub­se­quent addi­tion­al objec­tives asso­ci­at­ed with object-ori­ent­ed tech­nolo­gies would be addressed not by the orig­i­nal stan­dard but rather by a sup­ple­ment: “DO-332 – Object-Ori­ent­ed Tech­nol­o­gy and Relat­ed Tech­niques Sup­ple­ment to DO-178C and DO-278A”.

This sup­ple­ment describes con­cepts and key fea­tures of object-ori­ent­ed tech­nolo­gies and relat­ed tech­niques, 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.

The RTCA and EUROCAE ver­sions are har­mo­nized and were both pub­lished in Jan­u­ary 2012. Togeth­er, they con­sti­tute one of four tech­nol­o­gy sup­ple­ments intro­duced when DO-178C replaced DO-178B.

The pur­pose of DO-332/ED-217 is to pro­vide guid­ance on safe­ly using object-ori­ent­ed pro­gram­ming (OOP) in safe­ty-crit­i­cal soft­ware. It sup­ple­ments DO-178C and DO-278A by address­ing risks and fea­tures spe­cif­ic to OOP, includ­ing inher­i­tance, poly­mor­phism, and dynam­ic mem­o­ry.

Accord­ing to the doc­u­ment itself, DO-332 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 OOT&RT — Object-Ori­ent­ed Tech­nol­o­gy and Relat­ed Tech­niques — are used as part of the develop­ment life cycle.

OOT&RT is an abbre­vi­a­tion used in the stan­dards which ref­er­ences Object-Ori­ent­ed Tech­nol­o­gy and Relat­ed Tech­niques.

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 includ­ing FAA, EASA, TCCA, and ANAC to approve 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 extend the guid­ance in the doc­u­ment to a spe­cif­ic tech­nique. Sup­ple­ments are used in con­junc­tion with the core doc­u­ment and may be used with one anoth­er. DO-332/ED-217 falls into that cat­e­go­ry of sup­ple­ment. Sup­ple­ments are also ref­er­enced in DO-178C Appen­dix A.

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

DO-332/ED-217 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-331/ED-216, which pro­vides guid­ance for model-based develop­ment and ver­i­fi­ca­tion; 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.

Fea­tures such as inher­i­tance, poly­mor­phism, dynam­ic dis­patch, and dynam­ic mem­o­ry man­age­ment can improve soft­ware main­tain­abil­i­ty and reuse, but they can also make soft­ware behav­iour more dif­fi­cult to analyse, ver­i­fy, and pre­dict. DO-332 there­fore intro­duces addi­tion­al ver­i­fi­ca­tion activ­i­ties intend­ed to ensure that these tech­nolo­gies do not com­pro­mise the deter­min­ism, robust­ness, and assur­ance expect­ed of safe­ty-crit­i­cal soft­ware.

DO-332 describes key fea­tures of object-ori­ent­ed tech­nolo­gies and relat­ed tech­niques, 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. Among the con­sid­er­a­tions addressed by the sup­ple­ment are two ver­i­fi­ca­tion objec­tives iden­ti­fied in Table A-7. Both focus on ver­i­fy­ing local type con­sis­ten­cy and demon­strat­ing the robust use of dynam­ic mem­o­ry man­age­ment.

§OO.6.7 “Local Type Con­sis­ten­cy Ver­i­fi­ca­tion” dis­cuss­es the use of inher­i­tance with method over­rid­ing and dynam­ic dis­patch and spec­i­fies that addi­tion­al ver­i­fi­ca­tion activ­i­ties are nec­es­sary in this regard.

§OO.6.7.1 states that the objec­tive is to “ver­i­fy that all type sub­sti­tu­tions are safe”, leav­ing §OO.6.7.2 to iden­ti­fy approach­es that can be used to pro­vide that ver­i­fi­ca­tion.

Liskov’s Sub­sti­tu­tion Prin­ci­ple

It is use­ful to under­stand Liskov’s Sub­sti­tu­tion Prin­ci­ple in this con­text.

Let q(x) be a prop­er­ty prov­able about objects x of type T. Then q(y) should be true for objects y of type S where S is a sub­type of T.

This can be visu­al­ized by ref­er­ence to an exam­ple. In com­mon par­lance, a square is a type of rec­tan­gle. The term “is a” sug­gests a rela­tion­ship that could be rep­re­sent­ed through inher­i­tance in pro­gram­ming.

It would seem rea­son­able to have SetWidth and SetHeight meth­ods in a Rectangle class. But using SetWidth and SetHeight for a Rectangle object that is a Square neces­si­tates ensur­ing that both dimen­sions are the same, lead­ing to the pos­si­bil­i­ty of incon­gruities.

Liskov Sub­sti­tu­tion Prin­ci­ple tests check for such prob­lems.

Par­ent and child class show­ing code that vio­lates type con­sis­ten­cy.

In object-ori­ent­ed lan­guages, inher­i­tance allows the behav­iour of “super­class­es” to be over­rid­den by sub­class­es. Ensur­ing safe use of inher­i­tance, method over­ride, and dynam­ic dis­patch is chal­leng­ing because it can be unclear from a sim­ple review which method is exe­cut­ed at any call point in a pro­gram. Over­rid­den behav­iour in instan­ti­at­ed sub­class­es may alter the behav­iour beyond the intend­ed scope of the super­class and vio­late type con­sis­ten­cy.

As DO-332 §OO.6.7.1 fur­ther describes, this means that the pre­con­di­tions of the par­ent class must not be strength­ened, and the post­con­di­tions and invari­ants defined on the state of a class must not be weak­ened.

From a ver­i­fi­ca­tion stand­point, DO-332 §OO.6.7.2 sug­gests that one of the fol­low­ing activ­i­ties must be per­formed:

• Ver­i­fy sub­sti­tutabil­i­ty using for­mal meth­ods.
• Ensure that each class pass­es all the tests of all its par­ent types which the class can replace.
• For each call point, test every method that can be invoked at that call point, some­times called pes­simistic test­ing.

The first of these applies to the small minor­i­ty of develop­ment teams who are using for­mal meth­ods, while the third — once com­mon­ly referred to as flat­tened class test­ing — requires that each pos­si­ble dis­patch is test­ed at every call point in a pro­gram. That can eas­i­ly cause a com­bi­na­to­r­i­al explo­sion of test cases, dra­mat­i­cal­ly increas­ing the ver­i­fi­ca­tion bur­den.

That leaves the sec­ond option as the most prac­ti­cal for most peo­ple: to ensure type con­sis­ten­cy with­out the bur­den of pes­simistic test­ing. Doing so requires that each class and its meth­ods must pass all tests of every super­class for which it can be sub­sti­tut­ed.

In the Rec­tan­gle and Square exam­ple, type con­sis­ten­cy is vio­lat­ed. Reusing test cases from the par­ent class Rectangle on the sub­class Square high­lights that.

§OO.6.8 “Dynam­ic Mem­o­ry Man­age­ment Ver­i­fi­ca­tion” dis­cuss­es the vul­ner­a­bil­i­ties inher­ent in the use of dynam­ic mem­o­ry man­age­ment and gives guid­ance on how best to avoid falling vic­tim to them.

§OO.6.8.1 con­firms that the objec­tive is to “ver­i­fy the use of dynam­ic mem­o­ry man­age­ment is robust”, and §OO.6.8.2, sup­port­ed by Annex OO.D.1.6.1, details appro­pri­ate meth­ods to be con­sid­ered. These include a range of sta­t­ic and dynam­ic analy­sis tech­niques.

Track­ing mem­o­ry allo­ca­tion and deal­lo­ca­tion helps to ensure the prop­er free­ing of mem­o­ry, as do asso­ci­at­ed checks prior to deref­er­enc­ing. Low-level test­ing, also known as unit test­ing, pro­vides a mech­a­nism to explore var­i­ous allo­ca­tion and deal­lo­ca­tion sce­nar­ios to help ensure that vul­ner­a­bil­i­ties are addressed.

Tim­ing hooks with­in low-level tests help char­ac­ter­ize allo­ca­tion and deal­lo­ca­tion tim­ing, and dynam­ic data flow analy­sis mon­i­tors data ele­ments at run­time to detect lost updates and stale ref­er­ences.

Broad­er ver­i­fi­ca­tion con­sid­er­a­tions for object-ori­ent­ed soft­ware

In addi­tion to sup­port­ing the two addi­tion­al DO-332 objec­tives, the LDRA tool suite also under­pins many other sig­nif­i­cant con­sid­er­a­tions that apply when using object-ori­ent­ed tech­nolo­gies or relat­ed tech­niques in the develop­ment of com­pli­ant appli­ca­tions. These include source-to-object code trace­abil­i­ty, trace­abil­i­ty to child class­es, cod­ing stan­dards for object-ori­ent­ed lan­guages, and the prac­ti­cal chal­lenges of struc­tur­al cov­er­age and low-level test­ing.

Source to object code trace­abil­i­ty

As men­tioned in §OO.D.1.2.1, source-to-object code trace­abil­i­ty may be more dif­fi­cult to cor­re­late in object-ori­ent­ed lan­guages. OCV solu­tions pro­vide a graph­i­cal com­par­i­son of assem­bly code cov­er­age and high­er-order lan­guage cov­er­age, such as C++, to ensure that the source cov­er­age data accounts for vari­a­tions in the struc­ture of exe­cutable object code (EOC) as com­pared to the source code.

Source to object code trace­abil­i­ty with the TBob­ject­box com­po­nent of the LDRA tool suite.

Trace­abil­i­ty to child class­es

§OO.5.2.2i states: “Devel­op a local­ly type con­sis­tent class hier­ar­chy with asso­ci­at­ed low-level require­ments when­ev­er sub­sti­tu­tion is relied upon”. In other words, a require­ment that traces to a method imple­ment­ed in a class should also trace to the method in its sub­class­es when the method is over­rid­den in that sub­class. Sta­t­ic analy­sis and code visu­al­iza­tion expos­es inher­i­tance rela­tion­ships with­in the ana­lyzed code, mak­ing trace­abil­i­ty gaps across class hier­ar­chies eas­i­er to detect and rem­e­dy.

Cod­ing stan­dard for object-ori­ent­ed lan­guages

Lan­guages such as C++ allow for tremen­dous syn­tac­tic and seman­tic flex­i­bil­i­ty. Stan­dards such as MISRA C++ 2023 and JSF AV++ help quick­ly define a lan­guage sub­set and best prac­tices to pro­vide a base­line for soft­ware cod­ing stan­dards used in spe­cif­ic projects.

Chal­lenges with struc­tur­al cov­er­age and low-level test­ing

Struc­tur­al cov­er­age of destruc­tors, instan­ti­at­ing com­plex data types for test­ing, test­ing tem­plat­ed class­es and over­loaded oper­a­tors, and access­ing pri­vate mem­bers are just some of the chal­lenges that arise when work­ing with object-ori­ent­ed tech­nolo­gies or relat­ed tech­niques. Tools need to be equipped to address these chal­lenges and reduce the cost of ver­i­fi­ca­tion while pre­serv­ing the integri­ty and cred­i­bil­i­ty of the ver­i­fi­ca­tion activ­i­ties.

DO-332/ED-217 address­es the chal­lenges and vul­ner­a­bil­i­ties intro­duced when object-ori­ent­ed tech­nolo­gies and relat­ed tech­niques are used in safe­ty-crit­i­cal soft­ware develop­ment. By extend­ing and mod­i­fy­ing the core guid­ance of DO-178C and DO-278A, it ensures that fea­tures such as inher­i­tance, poly­mor­phism, and dynam­ic mem­o­ry man­age­ment are rig­or­ous­ly planned, ver­i­fied, and val­i­dat­ed.

Togeth­er with the other tech­nol­o­gy sup­ple­ments, DO-332 enables mod­ern object-ori­ent­ed develop­ment prac­tices to be safe­ly and effec­tive­ly incor­po­rat­ed into cer­ti­fi­able sys­tems, main­tain­ing the high lev­els of assur­ance required by cer­ti­fi­ca­tion author­i­ties.

• 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: 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

• 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