WIXLIB

DO-178C complianceMaking the skies safer for software to flyThe companies designing and building safetycritical systems need robust processes andcollaborative platforms. This paper introducesbest practices for software developmentleveraging the DO-178C standard, and howthe IBM Engineering Lifecycle Managementsolution can help organizations deliver safetycritical products, improve collaboration, andincrease efficiency and profitability.The cost of designing andbuilding safety-critical systemsis dramatically increasing.The aerospace and defense (A&D) industry, isseeing new levels of innovation and disruptionat every turn1 – putting significant pressureon A&D companies to do more with less byoptimizing their development processes tomeet cost pressures. Software developmentand testing alone may be a significant factor inthese rising costs, and the DO-178C standardand its related technology supplements havethe potential of adding even further stress ifnot handled optimally.Projects that need to comply with DO-178Cstandards could see cost increases anywherefrom 25 percent to 40 percent compared toprojects that don’t require compliance.2The sources of additional impacts mayinclude the following:– Reduced developer productivity due toincreases in process complexity– Manual reporting and documentationprocesses that are not suited to the levelof detail required to comply with DO178C– Qualification activities involved incompliance

DO-178C overviewDO-178C provides guidance for developingaviation software systems to ensure thatthey perform their intended function witha level of confidence commensurate withthe projects’ airworthiness requirement.The standard is objective driven, andcompanies may use a variety of means toachieve compliance as long as they meetthe objective(s) in question. To complywith DO-178C, companies must providemultiple supporting documents and recordssurrounding their development processes.Different airworthiness levels within DO-178C— A, B, C, D and E — directly correspond to theconsequences of a potential software failure:catastrophic, hazardous/severe-major, major,minor or no effect, respectively as shown inIBM EngineeringDO-178C complianceTable 1. Each software level has a definednumber of objectives that need to be satisfied(some with interdependence). These differentsoftware level certifications determine therigor required in testing, with the softwareverification being the most challenging part ofthis process.Levels / Failures conditionObjectives / With independenceA / Catastrophic71 / 33B / Hazardous69 / 21As you can see, compliance involves sixkey processes: planning, development,verification, configuration management,quality assurance (QA) and certificationliaison. Because the certification liaisonprocess is not a development activity, thispaper only focuses on the first five areas.C / Major62 / 8D / Minor26 / 5E / No safety impact0/0One of the significant changes in DO-178Cfrom DO-178B is that there are four additionalTable 1: Objectives for each software level2

DO-178C overview continuedsupplements that may be used in conjunctionwith the DO-178C. These supplements areused to avoid the need to update or expandthe text inside the main DO-178C document.For example, the software tool qualificationhas been deleted in the main DO-178C andhas been replaced with Section DO-330. Inaddition to DO-330, the other criteria are:– DO-331 - model-based development andverification– DO-332 - object-oriented technology andrelated techniques– DO-333 - formal methodsIBM EngineeringDO-178C compliance3

Planning and developmentAs with the other processes involved inproving compliance with DO-178C, planningrequires associated output documentation,including the following:– Plan for Software Aspects of Certification(PSAC)– Software Development Plan (SDP)– Software Verification Plan (SVP)– Software Configuration Management Plan(SCMP)– Software Quality Assurance Plan (SQAP)– System Requirements Standard (SRS)– Software Design Standard (SDS)– Software Code Standard (SCS)IBM EngineeringDO-178C complianceOutput documents associated with meetingDO-178C standards across the developmentprocess include software requirements data,software design descriptions, source codeand executable object code.According to DO-178C stipulations, withoutverifiable, unambiguous, consistent andwell-defined requirements, the developmentteam is required to create a problemreport and submit the issue back to therequirements input source to be clarifiedand corrected. The development team mustbe able to trace system requirements thatwill be implemented in high level softwarerequirements to one or more low-levelsoftware requirements, and a low-levelrequirement to one or more high-levelsoftware requirements.In addition, the development team needs toprovide all of their derived requirements tothe system safety assessment process. Ina nutshell, this means that all of the sourcecode developed needs to be traceable,verifiable and consistent, and it needsto correctly fulfill the low-level softwarerequirements.DO-178C requires effective processes formeasuring and reporting project statusdeliverables. Leveraging automatedmeasurement and reporting tools can helpfulfill the DO-178C standard by:– Allowing access to data in multiple toolsacross the development workflow toavoid slow, costly and error-prone manualdata collection– Automatically generating reports anddashboards to help generate consistentevidence of compliance and providestakeholders with the correct informationin a timely manner4

VerificationTo help ensure that your software fulfills theDO-178C standard, your development teammust submit a verification report that showsthe absence of errors — not just that theyhave tested for and detected no errors.Your development team needs to provethat all lower-level artifacts satisfy higherlevel artifacts, that there is traceabilitybetween requirements and test cases viarequirements-based coverage analysis, andthen demonstrate traceability between codestructure and test cases through a structuralcoverage analysis. Each requirement inyour software development process mustbe traceable not only to the code thatimplements it, but also to the review, test oranalysis through which it has been verified.Your development team must also ensure thatit can trace implemented functionality back toIBM EngineeringDO-178C compliancerequirements and that testing can prove this,while eliminating any dead code or code thatis not traceable to requirements.The output documentation associated withDO-178C requires:– Software verification cases andprocedures (SVCP)– Software verification results (SVR)– Review of all requirements, design andcode– Testing of executable object code– Code coverage analysisLine, decision and condition coveragerequirements are determined by thecompliance level (A-E) as shown in Table 2.Levels / CoverageCoverage requirementsA / MCDCLevel B 100 percent Modified Condition/Decision CoverageB / DCLevel C 100 percent Decision CoverageC / SCLevel D 100 percent Statement (or line) CoverageD100 percent Requirements CoverageENo coverageTable 2: Coverage requirements by DO-178C levels5

Verification continuedAs listed, DO-178C defines specificverification objectives, includingrequirements-based testing, robustnesstesting and coverage testing, dependingon the software level for which you arecomplying. Each level builds upon theprevious level starting with Level E. Eachtype of coverage is defined in the standard— for example, statement coverage meansthat every statement in the program hasbeen invoked at least once, while decisioncoverage means that every point of entryand exit in the program has been invoked atleast once and every decision in the programhas reached all possible outcomes at leastonce. The Coverage criteria List referencesTable 2, highlighting test requirements bycompliance level.– Every point of entry and exit in the program has been invoked at least once. Decision coverage Condition coverage Condition/Decision coverage Modified condition/Decision coverage Multiple condition/Decision coverage– Every statement in the program has been invoked at least once. Statement coverage– Every decision in the program has reached all possible outcomes at least once. Decision coverage Condition/Decision coverage Modified condition/Decision coverage Multiple condition/Decision coverage– Every condition in a decision in the program has reached all possible outcomes at least once. Condition coverage Condition/Decision coverage Modified condition/Decision coverage Multiple condition/Decision coverage– Every condition in a decision has been shown to independently affect that decision’s outcome. Modified condition/Decision coverage Multiple condition/Decision coverage– Every combination of condition outcomes within a decision has been invoked at least once. Multiple condition/Decision coverageList – Coverage criteria: DO-178C stipulates coverage testing requirements by compliance levelIBM EngineeringDO-178C compliance6

Configuration managementand quality assuranceTo support compliance with DO-178Celements surrounding configurationmanagement, companies are required to dothe following:– Uniquely identify each configuration item– Protect baselines of configuration itemsfrom change– Trace a configuration item to theconfiguration item from which it wasderived (lineage and history)– Trace baselines to the baselines fromwhich they were derived– Reproduce builds (replicate executableobject code)– Provide evidence of change approvals– Produce output documentation fora software configuration index (SCI)and a software lifecycle environmentconfiguration index (SECI)IBM EngineeringDO-178C complianceQuality assurance (QA)The QA process in DO-178C requires reviewsand audits to demonstrate compliance. Keyoutput documents in this process includesoftware quality assurance records (SQARs),a software conformity review (SCR) and asoftware accomplishment summary (SAS).DO-178C also requires that companiesimplement a problem reporting systemto document any change to the formaldesign baseline.7

IBM solutions to supportDO-178C standardAs you can see implementing anddemonstrating compliance to DO-178C can bea challenge in terms of the rigor, traceabilityand reporting required. To be competitiveyour company needs to adopt a solution thatcan help reduce both the burden and thecosts of compliance. The IBM EngineeringLifecycle Management (ELM) solution forsystems and software development providescross-team and cross-lifecycle collaboration,automation and reporting capabilities to helpcomply with the DO-178C standard.The IBM ELM platform provides a rich setof capabilities for managing your entiredevelopment lifecycle. Which includesmanaging requirements, test, workflow,as well as modelling and systems designactivities. The integrated design of the IBMELM suite ensures the seamless sharing ofinformation enabling full transparency andtraceability across the entire developmentIBM EngineeringDO-178C compliancelifecycle to help you meet the DO-178Cstandard. Figure 1 illustrates the impliedinformation model that is expected by DO178C in terms of the necessary engineeringartifacts and the respective traceability.As illustrated, the DO-178C standardspans requirements, design, test, andsoftware development – with accompanyingtraceability. Each one of those artifacts ismanaged by a dedicated ELM application asdescribed below. Figure 1 also shows howthe different artifacts are managed by thedifferent ELM applications: DOORS Next,Rhapsody, ETM, and EWM.IBM Engineering RequirementsManagement (DOORS or DOORS Next)manages the requirements artifacts andtheir respective traceability which is a coreDO-178C certification requirement, asillustrated in Figure 1. It also helps maintainrequirements configurations and audit trailsFigure 1: DO-178C stipulates coverage testing requirements by compliance level.8