DO-178C Certification - Your Complete Verification Journey

Pub­lished May 6, 2026

DO-178C/ED-12C (referred to here as DO-178C) is the pri­ma­ry doc­u­ment ref­er­enced by cer­ti­fi­ca­tion author­i­ties includ­ing the Fed­er­al Avi­a­tion Admin­is­tra­tion (FAA), Euro­pean Union Avi­a­tion Safe­ty Agency (EASA) and Trans­port Cana­da to approve soft­ware used in com­mer­cial civil air­borne sys­tems. It is jointly pub­lished by RTCA (for­mer­ly the Radio Tech­ni­cal Com­mit­tee for Aero­nau­tics) and the Euro­pean Organ­i­sa­tion for Civil Avi­a­tion Equip­ment (EUROCAE).

For devel­op­ers of air­borne soft­ware, the DO-178C process defines how cor­rect­ness, con­trol, and con­fi­dence must be demon­strat­ed for cer­ti­fi­ca­tion.

It requires a “Safe­ty by Design” approach. Assur­ance is built into the soft­ware develop­ment life­cy­cle through rig­or­ous process­es, trace­abil­i­ty, and ver­i­fi­ca­tion.

DO-178C Soft­ware Con­sid­er­a­tions in Air­borne Sys­tems and Equip­ment Cer­ti­fi­ca­tion is a for­mal process stan­dard that cov­ers the com­plete soft­ware life­cy­cle. It includes the plan­ning, develop­ment, and inte­gral process­es need­ed to ensure cor­rect­ness and robust­ness in soft­ware devel­oped for civil avion­ics sys­tems.

The inte­gral process­es include soft­ware ver­i­fi­ca­tion, soft­ware qual­i­ty assur­ance, con­fig­u­ra­tion man­age­ment, and cer­ti­fi­ca­tion liai­son with reg­u­la­to­ry author­i­ties. Defense pro­grams also increas­ing­ly use DO-178C too, as estab­lished best prac­tice.

In Jan­u­ary 2012 DO-178C replaced the long-stand­ing DO-178B stan­dard as the de facto ref­er­ence for the develop­ment of air­borne embed­ded soft­ware. Togeth­er with its sup­port­ing doc­u­ments, DO-178C improved safe­ty require­ments and addressed new tech­nolo­gies in civil avion­ics sys­tems.

DO-178B is still rec­og­nized and may be used for lega­cy projects. How­ev­er, the FAA rec­om­mends that new appli­cants or devel­op­ers estab­lish their soft­ware life cycle process­es in accor­dance with DO-178C.

LDRA has con­tributed to the evo­lu­tion of DO-178 guid­ance over many years, includ­ing par­tic­i­pa­tion in both DO-178B and DO-178C work­ing groups. Its work has helped shape indus­try approach­es to auto­mat­ed ver­i­fi­ca­tion, includ­ing struc­tur­al cov­er­age analy­sis.

DAL is an abbre­vi­a­tion for Design Assur­ance Level, some­times referred to as a Level. ARP 4754A requires that func­tion­al haz­ard analy­ses and sys­tem safe­ty assess­ments are com­plet­ed prior to sys­tem develop­ment.

A Design Assur­ance Level (DAL) is assigned accord­ing­ly for that sys­tem, and for the sub­sys­tems that imple­ment its hard­ware and soft­ware require­ments. The DO-178C stan­dard then pro­vides detailed guid­ance for the develop­ment and ver­i­fi­ca­tion of safe­ty crit­i­cal air­borne soft­ware sys­tems in accor­dance with the assigned DAL. For exam­ple, the effort and expense of pro­duc­ing a flight con­trol sys­tem is nec­es­sar­i­ly high­er than that required to pro­duce a bath­room smoke detec­tor.

DO-178C com­pli­ance requires a struc­tured approach across the soft­ware life­cy­cle, includ­ing plan­ning, develop­ment, and inte­gral process­es.

These include ver­i­fi­ca­tion, qual­i­ty assur­ance, con­fig­u­ra­tion man­age­ment, and cer­ti­fi­ca­tion liai­son with reg­u­la­to­ry author­i­ties.

DO-178C rec­og­nizes that soft­ware safe­ty must be addressed sys­tem­at­i­cal­ly through­out the soft­ware life cycle. This involves life cycle trace­abil­i­ty, soft­ware design, cod­ing, val­i­da­tion, and ver­i­fi­ca­tion process­es. In com­bi­na­tion, these help to ensure cor­rect­ness, con­trol, and con­fi­dence in the soft­ware.

The stan­dard defines sev­er­al mech­a­nisms to help ensure that the process­es are fol­lowed and to pro­vide objec­tive evi­dence of com­pli­ance.

Col­lec­tive­ly, the plan­ning doc­u­ments spec­i­fied in DO-178C pro­vide a frame­work for the develop­ment and cer­ti­fi­ca­tion of air­borne soft­ware. They ensure that activ­i­ties are planned, con­trolled, and ver­i­fied against require­ments, as fol­lows:

Plan for Soft­ware Aspects of Cer­ti­fi­ca­tion (PSAC): Defines how the soft­ware develop­ment process will com­ply with DO-178C require­ments.

Soft­ware Develop­ment Plan (SDP): Defines soft­ware develop­ment activ­i­ties includ­ing method­olo­gies, stan­dards, the develop­ment envi­ron­ment, con­fig­u­ra­tion man­age­ment prac­tices, and sched­ul­ing.

Soft­ware Ver­i­fi­ca­tion Plan (SVP): Defines how the soft­ware ver­i­fi­ca­tion activ­i­ties are to be con­duct­ed to ensure com­pli­ance with DO-178C.

Soft­ware Con­fig­u­ra­tion Man­age­ment Plan (SCMP): Defines how soft­ware con­fig­u­ra­tion man­age­ment will be imple­ment­ed.

Soft­ware Qual­i­ty Assur­ance Plan (SQAP): Defines which qual­i­ty assur­ance activ­i­ties will be applied, and when.

Tool Qual­i­fi­ca­tion Plan (TQP): Defines how tools used in develop­ment and ver­i­fi­ca­tion will be qual­i­fied.

DO-178C defines four Stages of Involve­ment (SOI), which func­tion as for­mal review points. They ensure that soft­ware develop­ment process­es and out­puts meet the require­ments of the stan­dard.

Cer­ti­fi­ca­tion author­i­ty rep­re­sen­ta­tives such as FAA Des­ig­nat­ed Engi­neer­ing Rep­re­sen­ta­tives (DERs) and EASA Sub­ject Mat­ter Experts (SMEs) are active­ly involved with SOIs. The reviews pro­vide struc­tured check­points across the soft­ware develop­ment life cycle, ensur­ing a dis­ci­plined path to com­pli­ance.

The Soft­ware Accom­plish­ment Sum­ma­ry doc­u­ments the DO‑178C soft­ware develop­ment and ver­i­fi­ca­tion activ­i­ties. It includes sum­maries of develop­ment activ­i­ties and ver­i­fi­ca­tion results, and find­ings from the qual­i­fi­ca­tion of ver­i­fi­ca­tion tools.

DO-178C Sec­tion 5.0 out­lines the key process­es involved in soft­ware develop­ment for air­borne sys­tems. It includes the Soft­ware Require­ments Process (5.1), Soft­ware Design Process (5.2), Soft­ware Cod­ing Process (5.3), Inte­gra­tion Process (5.4), and Soft­ware Develop­ment Process Trace­abil­i­ty (5.5).

Sec­tion 5.3 spec­i­fies soft­ware cod­ing process objec­tives, such as the imple­men­ta­tion of low-level require­ments and the con­for­mance to a defined lan­guage sub­set (or “cod­ing stan­dard”).

Sec­tion 5.5 requires arte­facts to demon­strate that each develop­ment phase is com­plete, coher­ent, and trace­able to its pre­de­ces­sor.

These activ­i­ties are typ­i­cal­ly sup­port­ed by auto­mat­ed tools for code analy­sis, stan­dards com­pli­ance, and trace­abil­i­ty.

DO-178C Sec­tion 6.0 defines the objec­tives and meth­ods used to demon­strate that soft­ware meets its require­ments and behaves cor­rect­ly. Ver­i­fi­ca­tion activ­i­ties include reviews, analy­ses, and test­ing at mul­ti­ple lev­els, includ­ing low-level test­ing, soft­ware inte­gra­tion test­ing, and hardware/software inte­gra­tion.

In prac­tice, these activ­i­ties are sup­port­ed by auto­mat­ed tools for test exe­cu­tion, cov­er­age analy­sis, and results man­age­ment.

Dynam­ic analy­sis exer­cis­es Exe­cutable Object Code (EOC) on a rep­re­sen­ta­tive tar­get using defined test cases and pro­ce­dures. It pro­vides evi­dence of cor­rect func­tion­al­i­ty and iden­ti­fies which parts of the code have been exer­cised (struc­tur­al cov­er­age). Test cases may include low-level (unit), inte­gra­tion, and sys­tem tests.

Low-level test­ing ver­i­fies the com­plete and exclu­sive imple­men­ta­tion of low-level require­ments defined in the Soft­ware Ver­i­fi­ca­tion Plan (SVP). Soft­ware inte­gra­tion test­ing ver­i­fies inter­ac­tions between soft­ware com­po­nents against the soft­ware archi­tec­ture and asso­ci­at­ed require­ments. In prac­tice, the mech­a­nisms used for low-level test­ing often extend nat­u­ral­ly to inte­gra­tion test­ing, enabling ver­i­fi­ca­tion of behav­ior across the call tree.

When changes are made, impact­ed low-level and inte­gra­tion tests must be re-run as part of regres­sion test­ing. This ensures that exist­ing func­tion­al­i­ty con­tin­ues to behave as expect­ed as develop­ment pro­gress­es.

Struc­tur­al cov­er­age analy­sis pro­vides evi­dence that require­ments-based tests have exer­cised the code to a defined extent.

By mea­sur­ing which parts of the soft­ware struc­ture are exe­cut­ed dur­ing test­ing, it sup­ports both com­pli­ance and safe­ty assur­ance. The required level of cov­er­age depends on Design Assur­ance Level (DAL).

Mod­i­fied Condition/Decision Cov­er­age (MC/DC)
Required for DAL A. Each con­di­tion with­in a deci­sion must be shown to inde­pen­dent­ly affect the out­come.

Deci­sion Cov­er­age
Required for DAL A and B. Each deci­sion must eval­u­ate to both true and false at least once.

State­ment Cov­er­age
Required for DAL A, B, and C. Every exe­cutable state­ment must be exer­cised at least once.

Data Cou­pling and Con­trol Cou­pling Cov­er­age
Required for DAL A and B, and rec­om­mend­ed for DAL C. Data exchanges and con­trol inter­ac­tions between mod­ules must be exer­cised.

Source to Object Code Ver­i­fi­ca­tion (OCV)
Required for DAL A. Addi­tion­al ver­i­fi­ca­tion is required for object code that can­not be direct­ly traced to source, such as com­pil­er-gen­er­at­ed con­structs.

Struc­tur­al cov­er­age analy­sis strength­ens con­fi­dence that test­ing is com­plete and rep­re­sen­ta­tive. It sup­ports dis­ci­plined ver­i­fi­ca­tion, trace­abil­i­ty, and com­pli­ance with DO-178C objec­tives. Achiev­ing this typ­i­cal­ly relies on auto­mat­ed tools to mea­sure cov­er­age and iden­ti­fy gaps.

MC/DC is a cov­er­age met­ric for deci­sions with mul­ti­ple con­di­tions. It does not require every pos­si­ble com­bi­na­tion of inputs to be exe­cut­ed. Instead, it requires a min­i­mum set of tests in which each con­di­tion is shown to inde­pen­dent­ly affect the out­come.

For exam­ple, a deci­sion with six con­di­tions has 64 pos­si­ble input com­bi­na­tions, yet only seven care­ful­ly con­struct­ed tests are need­ed to achieve MC/DC cov­er­age.

Iden­ti­fy­ing those tests is not always straight­for­ward. Each con­di­tion must be var­ied in iso­la­tion while all oth­ers are held con­stant, and it is not always obvi­ous which input val­ues will achieve this.

For this rea­son, deriv­ing and exe­cut­ing MC/DC test sets is typ­i­cal­ly sup­port­ed by auto­mat­ed approach­es.

Orga­niz­ing soft­ware into well-defined func­tion­al units with clear inter­faces (mod­u­lar­iza­tion) is a foun­da­tion­al prin­ci­ple. In DO-178C, this is not only good prac­tice but a reg­u­la­to­ry expec­ta­tion. Data cou­pling and con­trol cou­pling (DCCC) are sub­ject to explic­it ver­i­fi­ca­tion.

Con­trol cou­pling is defined as “the man­ner or degree by which one soft­ware com­po­nent influ­ences the exe­cu­tion of anoth­er soft­ware com­po­nent.” Data cou­pling is defined as “the depen­dence of a soft­ware com­po­nent on data not exclu­sive­ly under the con­trol of that soft­ware com­po­nent.”

Both forms of cou­pling must be exer­cised and ver­i­fied through require­ments-based test­ing. Sec­tion 6.4.4.2.c calls for analy­sis to con­firm that test­ing has exer­cised data and con­trol cou­pling between soft­ware com­po­nents.

In prac­tice, evi­dence is derived from test exe­cu­tion. Pro­ce­dure and func­tion call cov­er­age are used to assess con­trol cou­pling, while data flow analy­sis is used to assess data cou­pling. Struc­tur­al cov­er­age analy­sis sup­ports these activ­i­ties and helps meet objec­tive A-7.8, which requires cov­er­age of soft­ware struc­ture, includ­ing data and con­trol cou­pling.

Achiev­ing struc­tur­al cov­er­age typ­i­cal­ly relies on auto­mat­ed tools to mea­sure cov­er­age and iden­ti­fy gaps.

Sev­er­al relat­ed stan­dards and doc­u­ments are used along­side DO-178C in the develop­ment of civil air­borne soft­ware, and in the con­text of sys­tems and equip­ment cer­ti­fi­ca­tion.

DO-178C cer­ti­fi­ca­tion stan­dards frame­work for aero­space soft­ware sys­tems.

SAE ARP4754B Guide­lines for Develop­ment of Civil Air­craft and Sys­tems pro­vides the over­ar­ch­ing frame­work for sys­tem-level develop­ment. DO-178C defines soft­ware spe­cif­ic guid­ance with­in it.

SAE ARP4761A Guide­lines and Meth­ods for Con­duct­ing the Safe­ty Assess­ment Process on Civil Air­borne Sys­tems and Equip­ment guides safe­ty assess­ments for sys­tems and equip­ment devel­oped in accor­dance with the ARP4754 frame­work. DO-178C defines soft­ware spe­cif­ic guid­ance with­in that frame­work.

RTCA DO-278A Guide­lines for com­mu­ni­ca­tion, nav­i­ga­tion, sur­veil­lance, and air traf­fic man­age­ment (CNS/ATM) sys­tem soft­ware integri­ty assur­ance was devel­oped in par­al­lel with DO-178C. It serves a sim­i­lar pur­pose for ground-based sys­tems.

RTCA DO-330 Soft­ware tool qual­i­fi­ca­tion con­sid­er­a­tions guides tool qual­i­fi­ca­tion in com­pli­ance with DO- 278A and DO-178C. It is equal­ly applic­a­ble to other safe­ty-crit­i­cal sec­tors.

RTCA DO-331 Model-Based Develop­ment and Ver­i­fi­ca­tion Sup­ple­ment to DO-178C and DO-278A defines how design assur­ance lev­els (DAL), model‑based develop­ment, and model‑based ver­i­fi­ca­tion are applied togeth­er with­in the cer­ti­fi­ca­tion process.

RTCA DO-332 Object Ori­ent­ed Tech­nol­o­gy and relat­ed tech­nolo­gies sup­ple­ment to DO-178C and DO-278A defines addi­tion­al objec­tives for the use of object-ori­ent­ed pro­gram­ming and com­ple­men­tary prac­tices and guides the appli­ca­tion of DO-178C & DO-278A objec­tives with­in an object-ori­ent­ed (OO) envi­ron­ment.

RTCA DO-333 For­mal Meth­ods Sup­ple­ment to DO-178C and DO-278A defines addi­tion­al objec­tives for the use of for­mal meth­ods and guides the appli­ca­tion of DO-178C & DO-278A objec­tives when they are used.

RTCA DO-326B Air­wor­thi­ness Secu­ri­ty Process Spec­i­fi­ca­tion defines a frame­work for man­ag­ing secu­ri­ty risks in air­borne sys­tems and com­ple­ments DO-178C by address­ing secu­ri­ty con­sid­er­a­tions along­side soft­ware develop­ment and ver­i­fi­ca­tion activ­i­ties.

RTCA DO-356A Air­wor­thi­ness Secu­ri­ty Meth­ods and Con­sid­er­a­tions pro­vides detailed guid­ance on per­form­ing secu­ri­ty analy­ses and imple­ment­ing pro­tec­tive mea­sures, sup­port­ing the appli­ca­tion of DO-326B along­side DO-178C objec­tives.

RTCA DO-200B Stan­dards for Pro­cess­ing Aero­nau­ti­cal Data defines cri­te­ria for man­ag­ing the qual­i­ty of aero­nau­ti­cal data used in nav­i­ga­tion, flight plan­ning, ter­rain and obsta­cle aware­ness, flight deck dis­plays, sim­u­la­tors, and relat­ed appli­ca­tions. It cov­ers the develop­ment, val­i­da­tion, and main­te­nance of aero­nau­ti­cal data­bas­es that may inter­face with DO-178C com­pli­ant air­borne soft­ware.

A(M)C 20-193 Use of Multi-Core Proces­sors defines addi­tion­al DO-178C and DO-278A objec­tives for mul­ti­core proces­sors (MCPs) and guides the appli­ca­tion of DO-178C and DO-278A objec­tives in a mul­ti­core con­text.

Achiev­ing DO-178C com­pli­ance requires a struc­tured approach across the soft­ware life­cy­cle, from com­pi­la­tion and debug­ging through to ver­i­fi­ca­tion and evi­dence gen­er­a­tion. The activ­i­ties described above, includ­ing stan­dards-com­pli­ant cod­ing, ver­i­fi­ca­tion, struc­tur­al cov­er­age, and trace­abil­i­ty, are typ­i­cal­ly sup­port­ed by inte­grat­ed tools to ensure con­sis­ten­cy and auditabil­i­ty.

TASKING brings these capa­bil­i­ties togeth­er with­in a uni­fied work­flow, com­bin­ing com­pil­er tech­nol­o­gy, advanced debug­ging, and ver­i­fi­ca­tion to sup­port DO-178C objec­tives.

DO-178C places strong empha­sis on the integri­ty of the soft­ware build process, as the exe­cutable object code is the arte­fact that must be ver­i­fied. Con­fi­dence in it depends on the cor­rect and con­sis­tent oper­a­tion of the com­pil­er, link­er, and asso­ci­at­ed build tools.

TASKING com­pil­ers are designed for use in safe­ty-crit­i­cal envi­ron­ments, pro­vid­ing deter­min­is­tic and repeat­able code gen­er­a­tion across sup­port­ed archi­tec­tures. This helps ensure that the behav­ior observed dur­ing ver­i­fi­ca­tion accu­rate­ly reflects the deployed soft­ware.

Build integri­ty also depends on con­fig­u­ra­tion con­trol and the abil­i­ty to repro­duce results. TASKING sup­ports this through sta­ble tool­chains and well-defined build process­es, enabling you to gen­er­ate con­sis­tent out­puts and main­tain con­fi­dence in the rela­tion­ship between source code and object code.

Where object code can­not be direct­ly traced to source code, DO-178C requires addi­tion­al ver­i­fi­ca­tion. As stat­ed in DO-178C Sec­tion 6.4.4.2.b:

“…if the soft­ware level is A and a com­pil­er, link­er, or other means gen­er­ates addi­tion­al code that is not direct­ly trace­able to Source Code state­ments, then addi­tion­al ver­i­fi­ca­tion should be per­formed to estab­lish the cor­rect­ness of such gen­er­at­ed code sequences.”

LDRA ver­i­fi­ca­tion capa­bil­i­ties sup­port this require­ment by enabling analy­sis of both source and object-level behav­ior, help­ing you estab­lish con­fi­dence in gen­er­at­ed code and main­tain align­ment with DO-178C expec­ta­tions.

DO-178C requires you to demon­strate that your soft­ware behaves cor­rect­ly on the tar­get, not just that it com­piles. This means exer­cis­ing the exe­cutable object code through require­ments-based test­ing and under­stand­ing how it behaves in its real exe­cu­tion envi­ron­ment.

TASKING sup­ports this through inte­grat­ed debug and test capa­bil­i­ties, com­bin­ing exe­cu­tion con­trol with detailed vis­i­bil­i­ty of soft­ware behav­ior on tar­get hard­ware. Using the winIDEA debug­ger, you can con­trol exe­cu­tion, set break­points, inspect vari­ables, and observe how your soft­ware responds to test inputs.

Where required, Blue­Box hard­ware pro­vides non-intru­sive access to exe­cu­tion and trace data, enabling deep­er insight into tim­ing behav­ior, con­cur­ren­cy, and mul­ti­core inter­ac­tions.

Ver­i­fi­ca­tion is per­formed through both low-level and inte­gra­tion test­ing. Low-level tests demon­strate the com­plete and exclu­sive imple­men­ta­tion of soft­ware require­ments, while inte­gra­tion tests ver­i­fy how soft­ware com­po­nents inter­act with­in the sys­tem archi­tec­ture.

Under­stand­ing tim­ing behav­ior is as impor­tant as func­tion­al cor­rect­ness. This can be achieved using instru­ment­ed code or non-intru­sive, hard­ware-based trace. LDRA tools sup­port instru­ment­ed approach­es that cap­ture detailed exe­cu­tion and cov­er­age data, while Blue­Box pro­vides hard­ware-based trace with­out mod­i­fy­ing the soft­ware.

This dis­tinc­tion becomes impor­tant where tim­ing, con­cur­ren­cy, or mul­ti­core inter­ac­tions are involved, and where instru­men­ta­tion may affect the behav­ior being ver­i­fied. Hard­ware-based trace pre­serves deployed char­ac­ter­is­tics while still pro­vid­ing detailed exe­cu­tion insight.

Togeth­er, these approach­es help you under­stand not just whether the soft­ware works, but how it behaves in its deployed envi­ron­ment.

DO-178C requires you to demon­strate that your soft­ware meets its require­ments, behaves cor­rect­ly on tar­get, and has been ver­i­fied to the appro­pri­ate Design Assur­ance Level. This is achieved through a com­bi­na­tion of analy­sis, test­ing, and evi­dence gen­er­a­tion applied con­sis­tent­ly across the life­cy­cle.

TASKING sup­ports this through an inte­grat­ed approach to sta­t­ic analy­sis, dynam­ic test­ing, struc­tur­al cov­er­age, and trace­abil­i­ty, giv­ing you con­trol over both the ver­i­fi­ca­tion process and the evi­dence it pro­duces.

DO-178C expects your code to com­ply with defined cod­ing stan­dards and remain free from defects that could affect sys­tem behav­ior. That means apply­ing analy­sis con­sis­tent­ly, not just at the start of develop­ment, but every time the code changes.

TASKING sup­ports this through the LDRA tool suite and the LDRA Pro­duc­tiv­i­ty Pack­age for Aero­space and Defense, giv­ing you a con­sis­tent way to assess code qual­i­ty and enforce cod­ing stan­dards across your project. This applies whether you are using C or C++, includ­ing object-ori­ent­ed develop­ment aligned with DO-332, and whether your code is hand­writ­ten, auto gen­er­at­ed, or a com­bi­na­tion of both.

You can check com­pli­ance with lan­guage sub­sets such as MISRA or CERT, iden­ti­fy poten­tial defects includ­ing data flow anom­alies and unini­tial­ized vari­ables, and assess code com­plex­i­ty. Lan­guage sub­set enforce­ment helps you detect issues early and pre­vent them from prop­a­gat­ing into later ver­i­fi­ca­tion activ­i­ties.

As develop­ment pro­gress­es, you can apply the same analy­sis repeat­ed­ly to ensure that changes do not intro­duce new issues. This gives you a con­trolled base­line for code qual­i­ty that remains sta­ble across the life­cy­cle.

The same approach can be applied to both auto­mat­i­cal­ly gen­er­at­ed code (per­haps through inte­gra­tion with third-party tools) and man­u­al­ly devel­oped source code. This approach ensures con­sis­tent ver­i­fi­ca­tion regard­less of how you pro­duce your soft­ware.

DO-178C requires you to demon­strate that soft­ware behaves cor­rect­ly on the tar­get through require­ments-based test­ing. This involves exer­cis­ing exe­cutable object code and under­stand­ing behav­ior in the real exe­cu­tion envi­ron­ment.

TASKING sup­ports this through inte­grat­ed debug and test capa­bil­i­ties. Using winIDEA, with or with­out Blue­Box, you can inves­ti­gate soft­ware behav­ior, observe exe­cu­tion across the call struc­ture, and diag­nose issues as they occur.

Ver­i­fi­ca­tion is per­formed through low-level and inte­gra­tion test­ing. Low-level tests demon­strate the com­plete and exclu­sive imple­men­ta­tion of require­ments, while inte­gra­tion tests ver­i­fy inter­ac­tions between soft­ware com­po­nents.

LDRA tools pro­vide a frame­work for defin­ing, exe­cut­ing, and man­ag­ing these tests, togeth­er with analy­sis of how they exer­cise the soft­ware struc­ture. Struc­tur­al cov­er­age is derived from require­ments-based test­ing across both lev­els.

Where detailed exe­cu­tion insight is required, LDRA sup­ports instru­ment­ed test­ing for fine-grained analy­sis. In par­al­lel, Blue­Box pro­vides non-intru­sive hard­ware-based trace, pre­serv­ing tim­ing char­ac­ter­is­tics while allow­ing exe­cu­tion to be observed.

Togeth­er, these approach­es pro­vide clear vis­i­bil­i­ty of soft­ware behav­ior and sup­port effec­tive ver­i­fi­ca­tion aligned with DO-178C expec­ta­tions.

DO-178C requires objec­tive evi­dence that require­ments-based tests have exer­cised the soft­ware struc­ture. This is achieved through struc­tur­al cov­er­age analy­sis, which mea­sures how thor­ough­ly the code has been exe­cut­ed dur­ing test­ing and iden­ti­fies any gaps that require addi­tion­al ver­i­fi­ca­tion.

The LDRA tool suite pro­vides com­pre­hen­sive sup­port for struc­tur­al cov­er­age analy­sis, link­ing test exe­cu­tion direct­ly to cov­er­age results. It enables you to mea­sure state­ment, deci­sion, and Mod­i­fied Condition/Decision Cov­er­age (MC/DC), ensur­ing that the level of cov­er­age achieved aligns with the applic­a­ble Design Assur­ance Level (DAL).

Cov­er­age is derived from require­ments-based test­ing and includes both low-level tests and tests that exer­cise inter­ac­tions between soft­ware com­po­nents. This sup­ports not only con­trol flow analy­sis but also the ver­i­fi­ca­tion of data cou­pling and con­trol cou­pling, as required by DO-178C objec­tives.

Cov­er­age data can be col­lect­ed using instru­ment­ed tech­niques, pro­vid­ing detailed insight into how indi­vid­ual code ele­ments are exer­cised. In par­al­lel, Blue­Box trace capa­bil­i­ties enable non-intru­sive obser­va­tion of exe­cu­tion, allow­ing cov­er­age and tim­ing behav­ior to be ana­lyzed with­out affect­ing the run­time char­ac­ter­is­tics of the soft­ware.

In addi­tion to struc­tur­al cov­er­age, under­stand­ing exe­cu­tion tim­ing is crit­i­cal in many sys­tems, par­tic­u­lar­ly where mul­ti­core archi­tec­tures are used. The LDRA tool suite sup­ports Worst-Case Exe­cu­tion Time (WCET) analy­sis, help­ing you assess tim­ing behav­ior and iden­ti­fy poten­tial inter­fer­ence effects along­side func­tion­al ver­i­fi­ca­tion activ­i­ties.

Addi­tion­al ver­i­fi­ca­tion is required where com­pil­er-gen­er­at­ed object code can­not be direct­ly traced to source code. The LDRA tool suite sup­ports source-to-object code ver­i­fi­ca­tion (OCV), enabling com­par­i­son between source-level and object-level behav­ior to estab­lish con­fi­dence in the cor­rect­ness of gen­er­at­ed code.

Togeth­er, these capa­bil­i­ties pro­vide a clear and trace­able view of how thor­ough­ly the soft­ware has been exer­cised, sup­port­ing the pro­duc­tion of cer­ti­fi­ca­tion-ready evi­dence and help­ing you achieve the level of rigor expect­ed for DO-178C com­pli­ance.

Mod­ern air­borne sys­tems increas­ing­ly rely on mul­ti­core proces­sors, intro­duc­ing chal­lenges asso­ci­at­ed with shared resources, con­cur­rent exe­cu­tion, and poten­tial inter­fer­ence. A(M)C 20-193 pro­vides guid­ance for demon­strat­ing that these effects do not com­pro­mise sys­tem behav­ior.

Address­ing these chal­lenges requires vis­i­bil­i­ty into how soft­ware exe­cutes over time, includ­ing tim­ing behav­ior, inter­fer­ence paths, and pre­dictabil­i­ty under real­is­tic con­di­tions.

LDRA tools sup­port Worst-Case Exe­cu­tion Time (WCET) analy­sis, help­ing assess tim­ing behav­ior and iden­ti­fy poten­tial inter­fer­ence from shared resources and con­cur­rent activ­i­ty.

Blue­Box com­ple­ments this by pro­vid­ing non-intru­sive hard­ware-based trace on tar­get hard­ware, enabling obser­va­tion of tim­ing behav­ior, task inter­ac­tion, and exe­cu­tion flow with­out mod­i­fy­ing the code.

Togeth­er, these capa­bil­i­ties sup­port the analy­sis and evi­dence need­ed to demon­strate that inter­fer­ence effects are under­stood and con­trolled in line with A(M)C 20-193.

DO-178C requires that every stage of the soft­ware life­cy­cle is trace­able. This implies a need for clear, bidi­rec­tion­al links between require­ments, design, imple­men­ta­tion, ver­i­fi­ca­tion activ­i­ties, and results. Trace­abil­i­ty demon­strates the cor­rect imple­men­ta­tion of all require­ments, and that no unin­tend­ed func­tion­al­i­ty has been intro­duced.

Tool qual­i­fi­ca­tion ensures tool errors can­not com­pro­mise safe­ty or are suf­fi­cient­ly con­trolled. TASKING tools are sup­port­ed by Tool Qual­i­fi­ca­tion Sup­port Packs to stream­line the process.

LDRA tools main­tain trace­abil­i­ty across the develop­ment life­cy­cle, link­ing require­ments to source code, test cases, and ver­i­fi­ca­tion results and inte­grat­ing with any­thing from sim­ple doc­u­ment-based work­flows through to enter­prise ALM/PLM envi­ron­ments.

As develop­ment pro­gress­es and as mod­i­fi­ca­tions are intro­duced, impact analy­sis iden­ti­fies which ele­ments of the soft­ware and asso­ci­at­ed tests are affect­ed by change. Effec­tive regres­sion test­ing can then be based on those find­ings, main­tain­ing com­plete ver­i­fi­ca­tion.

LDRA tools also sup­port the gen­er­a­tion of cer­ti­fi­ca­tion arte­facts, includ­ing reports on cod­ing stan­dards com­pli­ance, ver­i­fi­ca­tion results, struc­tur­al cov­er­age, and trace­abil­i­ty.

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

Tech­ni­cal brief­ing: Get­ting to grips with A(M)C 20-193

Tech­ni­cal white paper: Fol­low­ing the rec­om­men­da­tions of A(M)C 20-193