DO-178C Certification - Your Complete Verification Journey

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.

What is DO-178C?

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 increas­ing­ly use DO-178C too, as estab­lished best prac­tice.

Is DO-178B still relevant?

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.

What does DAL mean in the context of DO-178C?

DAL is an abbre­vi­a­tion for Design Assur­ance Level, some­times referred to as a Level. ARP4754B 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 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 rigor demand­ed in the develop­ment and ver­i­fi­ca­tion of safe­ty-crit­i­cal air­borne soft­ware sys­tems depends on the assigned DAL. As a result, the effort and expense of pro­duc­ing (say) a flight con­trol sys­tem is nec­es­sar­i­ly high­er than that required to imple­ment a bath­room smoke detec­tor.

Software levels and DALs

Sys­tem-level DALs are decom­posed into hard­ware DALs and “Soft­ware Lev­els” for the con­tribut­ing sub­sys­tems, with DO-178C defin­ing the objec­tives that apply to each soft­ware level.

Impor­tant­ly, soft­ware lev­els do not nec­es­sar­i­ly cor­re­spond direct­ly to sys­tem DALs. The level assigned to a soft­ware com­po­nent depends on the con­tri­bu­tion that soft­ware makes to the sys­tem-level fail­ure con­di­tion being con­sid­ered.

What is involved with DO-178C compliance?

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.

What are the planning documents required by DO-178C?

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.

What are the “Stages of Involvement (SOI)”?

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.

What is the DO-178C “Software Accomplishment Summary (SAS)”?

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.

What does DO-178C Section 5.0: “SOFTWARE DEVELOPMENT PROCESSES” cover?

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 arti­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, all of which are deployed as part of the ver­i­fi­ca­tion process­es.

What does DO-178C Section 6.0: “SOFTWARE VERIFICATION PROCESSES” cover?

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 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.

Static analysis and code quality

DO-178C expects your code to com­ply with a defined lan­guage sub­set (whether an estab­lished stan­dard such as MISRA or CERT, or one devel­oped in-house), remain free from defects includ­ing data flow anom­alies and unini­tial­ized vari­ables, and be assessed for com­plex­i­ty.

That means apply­ing analy­sis con­sis­tent­ly, not just at the start of develop­ment, but every time the code changes. 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. 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.

How is executable object code verified on target?

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. Ver­i­fi­ca­tion is per­formed through require­ments-based test­ing at both low level and inte­gra­tion level. 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.

Dynam­ic analy­sis exer­cis­es exe­cutable object code on a rep­re­sen­ta­tive tar­get using defined test cases and pro­ce­dures. Under­stand­ing how the soft­ware behaves in its real exe­cu­tion envi­ron­ment is there­fore as impor­tant as the analy­sis and test­ing activ­i­ties that pre­cede it.

Achiev­ing that vis­i­bil­i­ty can involve instru­ment­ed approach­es which cap­ture detailed exe­cu­tion and cov­er­age data, or trace-based cov­er­age which pre­serves the tim­ing char­ac­ter­is­tics of the deployed soft­ware. The dis­tinc­tion mat­ters 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.

Structural coverage and DO-178C

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 Soft­ware Level.

• Mod­i­fied Condition/Decision Cov­er­age (MC/DC)
  Required for Soft­ware Level 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 Soft­ware Level 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 Soft­ware Level A, B, and C. Every exe­cutable state­ment must be exer­cised at least once.
• Data Cou­pling and Con­trol Cou­pling (DCCC) cov­er­age
  Required for Soft­ware Level A and B, and rec­om­mend­ed for Level C. Data exchanges and con­trol inter­ac­tions between mod­ules must be exer­cised.
• Source to object code trace­abil­i­ty
  Required for Soft­ware Level 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, bidi­rec­tion­al 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.

How are statement and decision coverage achieved?

Require­ments-based test­ing must demon­strate that every part of the soft­ware has been exer­cised. State­ment cov­er­age and deci­sion cov­er­age are the foun­da­tion­al met­rics for doing so.

State­ment cov­er­age con­firms that every exe­cutable state­ment has been exer­cised at least once dur­ing test­ing. Deci­sion cov­er­age goes fur­ther, requir­ing that every deci­sion in the code (such as an “if” state­ment) has eval­u­at­ed to both true and false at least once. Com­bin­ing the two ensures that all state­ments are exer­cised fully, includ­ing both out­comes of any state­ment con­tain­ing a deci­sion.

DO-178C defines state­ment cov­er­age as an objec­tive for soft­ware at Lev­els A, B, and C. Deci­sion cov­er­age is an objec­tive for Lev­els A and B. Nei­ther met­ric alone guar­an­tees the absence of defects, but togeth­er they pro­vide a mea­sur­able, ver­i­fi­able base­line that test­ing has been thor­ough and com­plete.

How is Modified Condition/Decision Coverage (MC/DC) achieved?

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. Deriv­ing and exe­cut­ing an effec­tive MC/DC test set is a pre­cise exer­cise, and one that lends itself well to auto­mat­ed sup­port.

How is Data Coupling and Control Coupling (DCCC) coverage achieved?

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 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 cou­pling 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 cou­pling 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.

How is source to object code traceability verified using Object Code Verification (OCV)?

When struc­tur­al cov­er­age is mea­sured at source code level, there is an implic­it assump­tion that the com­pil­er faith­ful­ly repro­duces the devel­op­er’s intent in the result­ing object code. That assump­tion does not always hold.

Com­pil­ers are per­mit­ted to mod­i­fy code in any way they choose, pro­vid­ed the bina­ry behaves as if the orig­i­nal source had been exe­cut­ed. Opti­miza­tions and com­pil­er-gen­er­at­ed con­structs can pro­duce object code struc­tures with no direct equiv­a­lent in the source. The con­se­quence is that 100% source code cov­er­age does not guar­an­tee that all object code paths have been exer­cised.

For Level A soft­ware, DO-178C §6.4.4.2b is explic­it: where the com­pil­er gen­er­ates object code that can­not be direct­ly traced to source code state­ments, addi­tion­al ver­i­fi­ca­tion should be per­formed.

Because object code and assem­bly code have a one-to-one rela­tion­ship, demon­strat­ing source-to-assem­bly trace­abil­i­ty is equiv­a­lent to demon­strat­ing source-to-object trace­abil­i­ty. Object Code Ver­i­fi­ca­tion (OCV) uses this rela­tion­ship to expose which object code paths remain unex­er­cised, enabling addi­tion­al tests to be devised to address them.

Timing, multicore, and interference analysis

Mod­ern air­borne sys­tems increas­ing­ly rely on mul­ti­core proces­sors, and that intro­duces ver­i­fi­ca­tion chal­lenges that go beyond those addressed by DO-178C alone. Shared hard­ware resources, con­cur­rent exe­cu­tion across cores, and inter­fer­ence between soft­ware com­po­nents can all affect tim­ing behav­ior in ways that are dif­fi­cult to pre­dict and hard­er to bound.

A(M)C 20-193 pro­vides guid­ance for demon­strat­ing that these effects are under­stood and con­trolled. It requires devel­op­ers to iden­ti­fy inter­fer­ence chan­nels, ver­i­fy that mit­i­ga­tion mea­sures are effec­tive, and demon­strate that resource demands do not exceed avail­abil­i­ty under real­is­tic oper­at­ing con­di­tions. Worst-Case Exe­cu­tion Time (WCET) analy­sis is cen­tral to meet­ing those objec­tives, but on a mul­ti­core proces­sor, inter­fer­ence from shared resources means that exe­cu­tion times can be wide and unpre­dictable. Demon­strat­ing safe bounds requires mea­sure­ment under real­is­tic load con­di­tions, not just analy­sis of the code in iso­la­tion.

What other standards are related to DO-178C?

DO-178C does not oper­ate in iso­la­tion. It sits with­in a broad­er frame­work of stan­dards and guid­ance doc­u­ments that togeth­er cover sys­tem safe­ty, tool qual­i­fi­ca­tion, model-based develop­ment, object-ori­ent­ed tech­nol­o­gy, for­mal meth­ods, cyber­se­cu­ri­ty, and mul­ti­core proces­sors. Under­stand­ing how they relate helps you nav­i­gate your cer­ti­fi­ca­tion oblig­a­tions with con­fi­dence.

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

DO-178C and SAE ARP4754B

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.

DO-178C and SAE ARP4761A

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.

DO-178C and DO-278A/ED-109

RTCA DO-278A “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” was devel­oped in par­al­lel with DO-178C. It serves a sim­i­lar pur­pose for ground-based sys­tems.

DO-178C and DO-330/ED-215

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.

DO-178C and DO-331/ED-218

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.

DO-178C and DO-332/ED-217

RTCA DO-332 “Object-Ori­ent­ed Tech­nol­o­gy and Relat­ed Tech­niques 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 and DO-278A objec­tives with­in an object-ori­ent­ed (OO) envi­ron­ment.

DO-178C and DO-333/ED-216

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 and DO-278A objec­tives when they are used.

DO-178C and DO-326B/ED-202A

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.

DO-178C and DO-356A/ED-203A

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.

DO-178C and DO-200B/ED-76A

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.

DO-178C and A(M)C 20-193

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.

Additional information

DO-178C PDF free downloads

Whitepa­per: DO-178C demys­ti­fied: Strate­gies for effi­cient cer­ti­fi­ca­tion
Whitepa­per: Fol­low­ing the rec­om­men­da­tions of CAST-32A & A(M)C 20-193
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­sisCer­ti­fi­ca­tion and Reg­u­la­to­ry Sup­port

DO-178C further information

Web­site: DO-330 Soft­ware tool qual­i­fi­ca­tion con­sid­er­a­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

DO-178C FAQs