Control Coupling and Data Coupling
Some parts of DO-178C are more demanding than the equivalent sections in earlier versions. For example, in the cases of data and control flow, it now requires testing to confirm the dynamic exercising of the coupling, rather than just providing static evidence of it. This requires the dynamic analysis of the code, with quantifiable measurement of the results to confirm that they meet requirements.
Figure 3. The DO-178C tools supplement becomes especially important as third-party tools facilitate testing and verification of critical software.
DO-178C defines control coupling as, “the manner or degree by which one software component influences the execution of another software component.” In other words, a given routine can be called by more than one other component under different conditions so it is not enough to know that the routine has run, but where the call came from and why. Thus, not only must all potential components be called, but all possible calls to each component must be examined.
DO-178C also requires the examination of each software component that is dependent on data not exclusively under the control of that component. For example, suppose there is a routine to display airspeed, and that the data needed for that display is produced by a separate routine that calculates the airspeed. That data may be available not only to the “display” routine, but to other routines in the system as well. In order to ensure that the correct airspeed is displayed, the routine to calculate it must execute before the display routine. One way to accomplish this is for the “display” routine to invoke the “calculate” routine before executing the display function. In this situation, the “display” and “calculate” routines together represent an example of a set/use pair, the implementation of which can be verified by data coupling analysis.
Keeping Up with Technology
In addition to the formal methods discussed here, DO-178C has added two more technology-specific “legs.” They are to include model-based development and object-oriented technologies, as well as a tools supplement to support them (Figure 3).
Model-based development (MBD), such as the Sparx environment, works at higher levels of abstraction than source code, providing one means of coping with the enormous growth of software in airborne systems and equipment. Research indicates that early-stage prototyping of software requirements using an executable model effectively routs out “defects” at the requirements and design levels, a huge saving step. With MBD, it is also possible to automatically generate source code from the executable model. Although the key to verification remains traceability from high-level requirements to model-based requirements, DO-178C simply considers the models to be the requirements so traceability becomes self-evident.
The challenges of auto-generated 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. Still, whether code is written from textual requirements, from design models or auto-generated from a tool, tried and tested practices of coding standards adherence are still applicable, and the verification of the executable object code is still primarily performed by testing.
The Object-Oriented Technology (OOT) “leg” of DO-178C focuses on languages such as C++, Java, and Ada 2005. For example, in the world of object orientation, “subtyping” is the ability to create new types or subtypes in an OO language. DO-178C addresses the issue of subtype verification for the safe use of OOT, which was not dealt with in DO-178B. DO-178C requires verification of local type consistency as well as verifying the proper use of virtual memory.
Design Verification Testing (DVT) 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. Thus, a class and its methods needs to pass all tests for any superclass for which it can be substituted. As an alternative to DVT, developers can use formal methods in conformance with the formal methods supplement.
In some senses, complexity may be viewed as the enemy of safety, but the growing complexity and software dependence of modern avionics systems cannot be denied. The best guarantee of maintaining the industry’s exemplary safety record in airborne systems and equipment must be to deploy tools that can manage complex details in ways that developers can readily understand and control. The DO-178C document provides developers of avionic systems with a standard that accommodates new technologies, and embraces the use of appropriate tools such that compliance can be achieved cost effectively.
This article was written by Shan Bhattacharya, Director of Business Development, and Mark Pitchford, Technical Specialist, LDRA (Wirral, Merseyside,UK).
