DO-178C: Improved certification for cost-effective avionics systems

With the geometric growth in software size and complexity, avionics manufacturers are losing control of project schedules and budgets. Consequently, the Radio Technical Commission for Aeronautics (RTCA) hopes to address software development challenges through DO-178C – a new standard that embraces contemporary technologies and methodologies necessary to achieve these aims.

Current systems require software following the guidelines in , a document developed by the Radio Technical Commission for Aeronautics (RTCA) for the FAA in 1992. But DO-178B’s effectiveness is under question as the complexity of modern avionics software increases. With both Boeing and Airbus projecting a geometric growth in the size and complexity of avionics software (see Figure 1), the only way that suppliers can hope to produce within deadlines the near-zero software defect rate required for avionics is to utilize advances in software technology and methodologies – something that DO-178B does not allow.

Figure 1: Avionics software’s size is projected to double every four years.
(Click graphic to zoom by 1.9x)

Though DO-178B was created to match the rigorous development practices and technologies of the day, it makes little or no allowance for current development and verification technologies and methods, including , Model-Based Development (), and the use of object-oriented technologies. The standard, due to be finalized in late 2010 by a joint RTCA/EUROCAE committee, will address this shortfall and assist in bringing the certification of avionics software in line with these 21st-century technologies.

DO-178B overview

Before we discuss the new DO-178C standard, let’s take a look at where we are today. DO-178B is a comprehensive and leveled set of software development activities and objectives. “Leveled” refers to the five Safety Integrity Levels () 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. “Activities” describes the processes that must be performed to meet specific “objectives.” A comprehensive cross-referencing of these objectives is provided in the standard against each of the five SILs. In this way, DO-178B is well structured and its intent clearly defined.

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

Verification in DO-178B comes primarily from top-down testing, an approach that currently represents 60 to 80 percent of the project budget and is driven up because “testing” is first performed on the integrated software system long after the requirements and design commitments have been made.

Current DO-178B verification focuses 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 is 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 artifacts) must be established before the software system is considered certifiable. These causal links include both static links that must 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 includes a verification of traceability called “slice analysis,” which follows 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.

DO-178C: Enabling 21st century avionics

DO-178C retains the core process rigor from DO-178B, updating it where necessary to consider the need for developers to begin testing, or verifying, early in the process. What is most significant about DO-178C, however, is the addition of three technology-specific legs under the “core document” inherited from DO-178B (depicted in Figure 2):

  • Formal methods
  • Model-based development
  • Object-oriented and related technologies

Figure 2: The DO-178C tools supplement becomes especially important as third-party tools facilitate two of the three technology supplements.
(Click graphic to zoom by 1.5x)

Each leg supplements the technology-agnostic core document. A supplement defines the steps (activities) related to the usage of the technology and any unique “objectives” or criteria for acceptance of the software produced.

Although not addressed in this discussion, it is also worth noting that two of these three technologies are primarily facilitated by third-party tools, so a fourth supplement on tools has been included in DO-178C that addresses issues associated with tool qualification.

Formal methods

The Formal Methods supplement allows avionics manufacturers to use mathematical proofs as an additional means of verification. To complement this, DO-178C’s section 6, Software Verification Process, was written to use the term “verify” instead of “test” to allow functional verification of software using a means other than testing.

Although mathematical verification is considered adequate by current theorists, DO-178C continues to advocate target testing to ensure that the code works correctly on the target and to avoid formal method false positives.

Model-based development

MBD provides support for development at higher levels of abstraction than source code, providing a means of coping with the enormous growth of software. Research indicates that early-stage prototyping of software requirements using an executable model effectively routes out “defects” at the requirements and design levels, a huge saving step considering that it costs 900 times more to correct a defect found post-certification. With MBD, it is also possible to automatically generate source code from the executable model.

Key to software verification in both DO-178B and DO-178C is the traceability from requirements through design and implementation. MBD introduces three significant challenges to this:

  • How to establish and maintain traceability from high-level written requirements to model-based requirements?
  • How to trace from the high-level requirements to the autogenerated code?
  • How to trace from the high-level requirements to the manually written code necessary for running the auto-generated code on a target system?

DO-178C addresses this technology challenge. Establishing and maintaining traceability from high-level requirements to model-based requirements is easily accomplished by adherence to DO-178C, which simply considers the models to be the requirements so traceability becomes self-evident.

The challenges of autogenerated and manually inserted code when using MBD are more significant, however. MBD tools might also insert code that can be rationalized only in the context of the model’s implementation, not the functional requirements. In any case, the answer to all these questions depends on the characteristics of the modeling language and the mechanisms supported by the MBD tool autogenerating the code.

OO and related technologies

The Object-Oriented and Related Technologies () supplement of DO-178C focuses on OO languages used today such as C++, Java, and Ada 2005. In particular, it addresses the issue of subtype verification first discussed in the 2004 Object-Oriented Technology in Aviation (OOTiA) handbook, an FAA sponsored document that makes recommendations for the safe use of OOT in compliance with DO-178B.

Subtyping, the ability to create new types or subtypes in an OO language, although powerful, introduces the challenges of maintaining type consistency and subtype verification. The OOTiA recommendation was to adopt an exhaustive, flattened-class approach, which significantly escalates OOT verification costs.

DO-178C recommends a far more practical approach: Design Verification Testing () performed at the class level proves that all the member functions conform to the class contract with respect to preconditions, post conditions, and invariants of the class state. As an alternative to DVT, developers can use formal methods in conformance with the Formal Methods supplement.

Managing complexity and deadlines

The growing complexity of modern avionics systems is derived not only from their safety criticality, but also from the many combinations of options offered by avionics suppliers. The emerging DO-178C standard aims to go beyond DO-178B’s limited technologies, instead providing avionics suppliers the tools and guidance necessary to achieve cost-effective certification via DO-178C’s new technology supplements: formal methods, model-based development, and object-oriented technologies.

Bill StClair is currently technical evangelist for LDRA Technology in San Bruno, California and has more than 25 years in embedded software development and management. He holds a U.S. patent for a portable storage system and is inventor of a patent-pending embedded requirements verification system. He can be contacted at

Nat Hillary is a Field Applications Engineer with LDRA Technology, Inc., a position that he comes to via an extensive back-ground in software engineering, sales, and marketing. He is also an experienced presenter in the use of software analysis solutions for real-time, safety-critical software. He can be contacted at

LDRA 650-583-8880