DO-178C brings modern technology to safety-critical software development

Story

March 07, 2012

Avionics software technology has improved by leaps and bounds since DO-178B was introduced in 1992. DO-178C will bring safety-critical software development into the modern era, adding support for advanced techniques such as UML and mathematical modeling, object-oriented programming, and formal methods. The ready availability of third-party tools, platforms, and certification services will hasten the adoption and deployment of DO-178C.

As software becomes more complex, it becomes hard to manage the design of that software at the code level. Object oriented programming (C++, Ada, and Java) and modeling (UML, mathematical, and so on) simplify the development of complex software by enabling designers to conceptualize, architect, and encapsulate their design at a higher level. Formal methods, which are related to model based development, make it easier to assess correctness of complex software functions like control loops.

DO-178C inherits the DO-178B core document, principles, and processes, while adding support for high-level modeling, object oriented programming, and formal methods, with an emphasis on two-way traceability from model to executable code and back (Sidebar 1). DO-178C also provides a tools supplement for addressing in detail the qualification and capabilities of the tools used for not only modeling, object-oriented programming, and formal methods, but also for other development technologies such as procedural software and assembly-level programming.

The DO-178C supplements

The DO-178C working group has produced three development technology supplements: Object Oriented Technology and Related Techniques (OOT & RT), Model Based Development and Verification, and Formal Methods. It also greatly expanded the tool qualification guidance present in DO-178B. These four supplements have been published by the RTCA as:

DO-330, Software Tool Qualification Considerations
DO-331, Model-Based Development and Verification Supplement to DO-178C and DO-278A
DO-332, Object-Oriented Technology and Related Techniques Supplement to DO-178C and DO-278A
DO-333, Formal Methods Supplement to DO-178C and DO-278A

Note that DO-278A is the ground system equivalent of DO-178C.

Object Oriented Technology and Related Techniques

The Object Oriented Technology and Related Techniques (OOT & RT) is a comprehensive safety-critical software guide for hand code development and verification. It encompasses not only object oriented software development, but also techniques that are used in procedural languages. These related techniques include such things as dynamic memory management, overloading, parametric polymorphism (such as templates in C++ and generics in Ada) type conversions, and virtualization. The net result is that the OOT & RT supplement could be invoked on most projects utilizing procedural languages as well as OOT.

Sidebar 1: The incorporation of advanced modeling and object oriented programming techniques in DO-178C places new demands on verification.

(Click graphic to zoom)

The most significant addition to the OOT & RT is the definition of new objectives. Objectives identify which development assets, integrated processes, and verification artifacts must be produced for a product to be certifiable. The OOT & RT defines two new verification objectives: The first verifies local type consistency, which enables subclass methods to safely override parent class methods. The second verifies that the use of the dynamic memory management system is robust. In particular, it verifies the following characteristics of the dynamic memory management system: reference ambiguity, fragmentation starvation, deallocation starvation, memory exhaustion, premature deallocation, lost updates and stale references, and unbound allocation or deallocation time.

Model Based Development and Verification (MBD&V)

The biggest and most contentious challenge in reviewing and approving the MBD&V supplement was determining the final verification method used on the Executable Object Code (EOC) compiled, linked, and loaded on the target system. In the context of the MBD&V systems under consideration, the EOC is directly traceable to the source code automatically generated by the model. Historically, there has been a precedent set in the verification of some avionics software that was tested both by and in the model itself without doing target testing on the EOC, effectively obviating the objectives for EOC testing in the DO-178C “core document.” Instead, the DO-178C plenary agreed that a form of independent verification must be performed on the EOC on the target system, thereby preserving the EOC objectives of DO-178C.

Notwithstanding the consensus reached with respect to EOC verification, the MBD&V supplement did add many objectives that provide certification credit for verification activities performed by the model, or at least defined by the model, on the model architecture and model code. These verification activities are primarily performed by “simulation cases,” which are run in lieu of test cases and other forms of verification.

Probably the most definitive of the FAQs added to any of the DO-178C tech supplements were those added to the MBD&V supplement. The scope of the new FAQs spans development and verification, including not only standard high- and low-level software requirements and the associated specification and design models, but also the system requirements allocated to software. Historically, the gaps between these model types and requirements hierarchies and their various provenances have been a leading cause of ambiguity and poorly realized designs in MBD&V projects.

Formal methods supplement

The Formal Methods supplement follows a similar trajectory to that of MBD&V in that it also eventually agrees to preserve the EOC objectives of the core document by stipulating independent verification for the EOC ultimately produced by formal methods or mathematical proofs. A key question that has not been definitively addressed by either the Formal Methods or MBD&V supplements is the obvious domain overlap that can occur between these supplements. That is, Formal Methods (FM) as a development and verification technology utilizes a form of model based development itself. This and other potential domain overlaps will be addressed by the FAA in circulars, which will be published this year.

Software tool qualification considerations

Qualification of a tool is needed when processes of DO-178C are eliminated, reduced, or automated by the use of a software tool without its output being verified as specified in the standard. The purpose of the tool qualification process is to ensure that the tool provides confidence at least equivalent to that of the process(es) eliminated, reduced, or automated.

The Software Tool Qualification Considerations document introduces a new tool qualification structure that consists of three criteria and five Tool Qualification Levels (TQLs) as shown in Table 1.

Table 1: The Software Tool Qualification Considerations document introduces a new tool qualification structure that consists of three criteria and five Tool Qualification Levels (TQLs).

(Click graphic to zoom by 1.9x)

Criteria 1’s applicable TQL is the replacement for the development tool in DO-178B.
Criteria 2 is new for DO-178C and is intended to address the expansion of tool use in new methodologies. Criteria 2 basically requires an increased level of rigor over DO-178B criteria for tools used on software level A and B in order to increase the confidence in the use of the tool.
Criteria 3, which consists entirely of the level TQL-5, is the replacement for the verification tool in DO-178B.

To help safety-critical developers take full advantage of DO-178’s advanced capabilities, tools that automate and streamline the development, verification, and certification process have become essential. For example, DO-178C, section 11 introduces Trace Data, which it describes as reference links among life-cycle data items such as requirements, design, source code, and test cases. A key aspect of tools that automate life-cycle data traceability is a facility for establishing traceability forwards and backwards, from requirements down through the decomposition tree, onto the executable code and back again, including verification tasks.

Automated tools greatly reduce the time and cost associated with developing DO-178-compliant software. DO-178 certification, however, is still an expensive, time consuming, and arduous process. To help expedite this process for avionics equipment makers, some companies, such as DDC-I, offer Eclipse-based development tools and RTOS platforms that have already undergone DO-178B Level A certification, in addition to turnkey development and certification services for both DO-178B and DO-178C.

DO-178C simplifies avionics development

DO-178C marks a big step forward for developers of complex avionics software that must be certified to the highest levels of safety criticality. DO-178C simplifies the development process by embracing formal methods, high-level modeling, and object oriented techniques that enable designers to conceptualize and encapsulate their software at a higher level. It also streamlines the verification and certification process by providing two-way traceability that extends from the models and requirements to the executable code and back again. Together with automated tools, platforms, and certification services, DO-178C greatly clarifies the risk and potential means of reducing the costs associated with developing, certifying, and deploying complex safety-critical avionics software.

Tim King is the Technical Marketing Manager at DDC-I. He has more than 20 years of experience developing, certifying, and marketing commercial avionics software and RTOSs. Tim is a graduate of the University of Iowa and Arizona State University, where he earned Master’s degrees in Computer Science and Business Administration, respectively. He can be contacted at [email protected].

DDC-I 602-275-7172 www.ddci.com

Bill StClair is currently Director, US Operations for LDRA Technology in San Bruno, California and has more than 25 years in embedded software development and management. He has worked in the avionics, defense, space, communications, industrial controls, and commercial industries as a developer, verification engineer, manager, and company founder. He is an inventor of a patent-pending embedded requirements verification system. He can be contacted at [email protected].

LDRA 650-583-8880 www.ldra.com