Aerospace and Defence
Document

DO-178B to DO-178C: The evolution of a standard

4 Sections None

DO-178B was a comprehensive and levelled set of software development activities and objectives.  F ive Safety Integrity Levels (SILs)  were  included in the standard – levels A, B, C, D, and E – with level A being the most safety critical and Level E having no impact on aircraft safety.  Obligatory  a ctivities”  were  to be  completed in order to achieve  specific “objectives.” A comprehensive cross-referencing of these objectives  was  provided in the standard against each of the five SILs. In this way, DO-178B  wa s well structured and its intent clearly defined.  

DO-178B assume d  a traditional software development life cycle that progresses linearly from requirements through design and code to integration and test. Its process model resemble d  a waterfall or V model in which validated requirements  we re a given (DO-178B d id  not mention requirements validation), and there  was  a de facto partitioning of the requirements engineering and software development processes. “Derived Requirements,” non-functional requirements derived from the design or implementation process,  we re  an  exception to this.  

Verification in DO-178B c a me primarily from top-down testing, an approach that  often  represent ed  60 to 80 percent of the project budget and  wa s driven up because “testing”  wa s first performed on the integrated software system long after the requirements and design commitments ha d  been made.  

DO-178B verification focuse d  on test coverage of functional requirements and software structures via structural coverage analysis, as well as data and program-control structures. The measurement of data and control coverage  wa s typically performed as a manual, ad hoc analytical process, escalating verification costs.  

Finally, in DO-178B, traceability (causal links between requirements at different levels and associated software development art e facts)  had to  be established before the software system  wa s considered certifiable. These causal links include d  both static links that  had to  be established and maintained (such as mapping from low-level requirements to source code) and dynamic links (as determined by structural coverage analysis).  

Typically,  certification readiness include d  a verification of traceability called “slice analysis,” which follow ed  one high-level software requirement to its low-level requirement(s) and associated test cases through design to source code and then to object code.  

Learn more

REGISTER FOR FREE OR REQUEST LINK

Background

REGISTER FOR FREE OR REQUEST LINK

DO-178B Overview

REGISTER FOR FREE OR REQUEST LINK

DO-178C: Enabling 21st century avionics

Pen