Software reuse and DO‑178C: Adapting to a new deployment context 

“We’ve devel­oped this soft­ware under ISO 26262 / ISO 61508 / what­ev­er. Sure­ly, we don’t have to start again?” 

It’s a ques­tion that’s becom­ing increas­ing­ly com­mon as more orga­ni­za­tions move into aero­space pro­grams.  

You’ll be relieved to know that the answer is “no”. DO-178C does not require suc­cess­ful soft­ware to be dis­card­ed sim­ply because it was­n’t orig­i­nal­ly devel­oped for an air­borne appli­ca­tion. Equal­ly, it does­n’t assume that soft­ware which has per­formed flaw­less­ly in one envi­ron­ment can auto­mat­i­cal­ly be deployed in anoth­er. The chal­lenge isn’t decid­ing whether exist­ing soft­ware can be reused. It’s under­stand­ing what changes when that soft­ware is intro­duced into a new deploy­ment con­text.

Modern software is built on reuse 

Very few embed­ded soft­ware projects begin with an empty source tree. Even when the appli­ca­tion itself is devel­oped specif­i­cal­ly for a new prod­uct, it almost cer­tain­ly depends on soft­ware that already exists. Oper­at­ing sys­tems, board sup­port pack­ages, com­mu­ni­ca­tion stacks, mid­dle­ware, cryp­to­graph­ic libraries, com­pil­er run­time libraries, gen­er­at­ed code and inter­nal­ly devel­oped frame­works all con­tribute to the final exe­cutable image. 

This isn’t poor engi­neer­ing; it’s how mod­ern embed­ded sys­tems are built. Reusing proven soft­ware reduces costs, short­ens develop­ment sched­ules, and allows engi­neer­ing teams to build on years of accu­mu­lat­ed expe­ri­ence.  

Mov­ing into aero­space does­n’t change that real­i­ty. But it does intro­duce a new set of ques­tions that need answer­ing before the soft­ware can become part of a cer­ti­fied air­borne sys­tem.

A different deployment context changes the certification argument

DO-178C rec­og­nizes that appli­ca­tion soft­ware never exists in iso­la­tion. It is deployed on a par­tic­u­lar proces­sor, devel­oped, com­piled and test­ed using a par­tic­u­lar tool chain, inter­acts with spe­cif­ic hard­ware, com­mu­ni­cates with other soft­ware com­po­nents, and con­tributes to a sys­tem per­form­ing a defined func­tion at an assigned Soft­ware Level.  

Change any of those fac­tors and you’ve changed the deploy­ment con­text – and that’s what DO-178C is con­cerned with. Oper­a­tional suc­cess, valu­able though it may be, can­not replace the evi­dence need­ed for a new air­borne appli­ca­tion. It con­tributes to con­fi­dence, but it does­n’t demon­strate com­pli­ance. 

Closing the evidence gap 

If you’ve expe­ri­ence of IEC 61508 or one of its deriv­a­tives (ISO 26262, IEC 62304, EN 50716…), much of the engi­neer­ing dis­ci­pline expect­ed by DO-178C will already be famil­iar. Require­ments man­age­ment, bidi­rec­tion­al trace­abil­i­ty, reviews, sta­t­ic analy­sis, test­ing and con­fig­u­ra­tion man­age­ment all have clear par­al­lels with­in func­tion­al safe­ty. 

The dif­fer­ence lies in the assur­ance argu­ment. Func­tion­al safe­ty asks whether suf­fi­cient mea­sures have been imple­ment­ed to achieve the required integri­ty level. DO-178C asks whether every applic­a­ble life­cy­cle objec­tive has been sat­is­fied and can be demon­strat­ed through objec­tive, review­able evi­dence. 

This dis­tinc­tion also affects the effort required to reuse exist­ing soft­ware. Soft­ware devel­oped under a recog­nised func­tion­al safe­ty process may already be sup­port­ed by require­ments, design doc­u­men­ta­tion, reviews, tests and trace­abil­i­ty. Soft­ware that has evolved more infor­mal­ly may have lit­tle more than work­ing source code. Nei­ther is auto­mat­i­cal­ly accept­able or unac­cept­able; the dif­fer­ence is sim­ply the size of the evi­dence gap that must be closed.

Existing software isn’t disqualified by “safety by design” 

Although aero­space talks about safe­ty by design, that doesn’t imply the soft­ware must have been devel­oped with­in the cur­rent DO-178C life­cy­cle. 

DO-178C does­n’t ask you to recre­ate his­to­ry, nor to pre­tend that exist­ing soft­ware was writ­ten yes­ter­day. What it does require is suf­fi­cient evi­dence that the soft­ware can sup­port its intend­ed use in the new deploy­ment con­text. 

That means under­stand­ing what the soft­ware is intend­ed to do, the assump­tions it makes, the inter­faces on which it depends and the envi­ron­ment in which it will oper­ate. Where that infor­ma­tion already exists, it can often be reused. Where it does­n’t, it may need to be recov­ered, doc­u­ment­ed and ver­i­fied before the soft­ware can par­tic­i­pate fully in the DO-178C life­cy­cle. 

In short, the objec­tive isn’t to rewrite work­ing soft­ware. It is to demon­strate that the soft­ware is appro­pri­ate for its new role.

Building an evidence chain, not a document set 

Per­haps the biggest con­cep­tu­al shift for orga­ni­za­tions enter­ing aero­space is rec­og­niz­ing that cer­ti­fi­ca­tion evi­dence doesn’t con­sist of col­lec­tions of dis­parate reports. 

Require­ments, archi­tec­ture, source code, reviews, ver­i­fi­ca­tion results, struc­tur­al cov­er­age, tar­get mea­sure­ments and com­pli­ance reports all con­tribute to a sin­gle evi­dence chain. As the soft­ware evolves, that chain evolves with it. Dur­ing Stage of Involve­ment (SOI) reviews, cer­ti­fi­ca­tion author­i­ties are inter­est­ed not only in the indi­vid­ual arte­facts but also in the con­sis­ten­cy and trace­abil­i­ty that con­nects them. 

Main­tain­ing those rela­tion­ships man­u­al­ly quick­ly becomes dif­fi­cult as projects grow and become more com­plex. This is where qual­i­fied and trust­ed develop­ment and ver­i­fi­ca­tion tool­chains become invalu­able.

The LDRA tool suite sup­ports require­ments trace­abil­i­ty, sta­t­ic and dynam­ic analy­sis, test­ing, struc­tur­al cov­er­age and com­pli­ance report­ing, while TASKING Blue­Box and winIDEA pro­vide real-tar­get vis­i­bil­i­ty into exe­cu­tion, tim­ing and trace behav­ior. Togeth­er they help main­tain the integri­ty of the evi­dence chain while reduc­ing repet­i­tive engi­neer­ing effort.

Building an evidence chain, not a document set 

Exist­ing soft­ware rep­re­sents years of engi­neer­ing invest­ment. It embod­ies expe­ri­ence, domain knowl­edge and, in many cases, proven behav­iour. DO-178C does­n’t ask organ­i­sa­tions to aban­don that invest­ment.

It does, how­ev­er, ask them to look at that soft­ware through the lens of its new deploy­ment con­text, and to adapt both the soft­ware and its sup­port­ing evi­dence accord­ing­ly.