Acronym

15.1 Introduction to Object-Oriented Technology

Object-oriented technology (OOT) has been around since the late 1960s with the introduction of the Simula programming language [1]. OOT is a software development paradigm for analysis, design, modeling, and programming that centers around objects. The Institute of Electrical and Electronics Engineers (IEEE) refers to OOT as “a software development technique in which a system or component is expressed in terms of objects and connections between those objects” [2]. An object is like a black box at the software level; each object is capable of receiving messages, processing data, and sending messages to other objects. An object contains both code (methods) and data (structures). The user does not require insight into the internal details of the object in order to use the object—hence, the comparison to a black box. An object can model real-world entities, such as a sensor or hardware controller, as separate software components with defined behaviors. A major concept in OOT is that of a class. A class defines attributes, methods, relationships, and semantics that share a common structure and behavior representative of a real-world entity.

DO-332 section OO.1.6.1.1 provides the following description of objects and classes [3]:

The feature that distinguishes OOT is the use of classes to define objects along with the ability to create new classes via subclassing. In procedural programming, a program’s behavior is defined by functions, and the state of a running program is defined by the contents of the data variables. In object-oriented programming, functions and data that are closely related are tightly coupled to form a coherent abstraction known as a class…

A class is a blueprint from which multiple concrete realizations can be created. These concrete realizations are known as objects…

The subprograms defined for a class are referred to as its methods, or member functions. Methods that operate on or use the data contained within an object instance are referred to as instance methods. This is in contrast to class methods that are associated only with a class, and do not require an associated instance to be invoked.

Throughout DO-332, the term subprogram is used to refer generically to all forms of methods (instance methods and class methods), functions, or procedures. DO-332 also explains:

Data variables associated with a class are referred to as attributes, fields, or data members. An attribute may be classified as an instance attribute, in which case a separate copy of the attribute exists for each object, or it may be a class attribute, in which case a single, shared copy of the attribute exists for all objects of the class [3].

15.2 Use of OOT in Aviation

OOT is used widely in non-safety-critical software development (e.g., in web-based and desktop applications) and is taught almost exclusively in universities. OOT has also been used in safety-critical medical and automotive systems. OOT is appealing to the aviation industry for several reasons, including strong tool support, availability of programmers, perceived cost savings, and potential for reusability.

However, OOT has not been widely used in aviation to date. The Federal Aviation Administration (FAA) and the aviation industry have been researching and investigating the use of OOT in safety-critical systems and developing guidelines for its safe implementation for over 10 years. There are several technical challenges related to OOT (mostly related to the programming languages) that have delayed its widespread use in real-time systems and in aviation. FAA issue papers and European Aviation Safety Agency (EASA) certification review items (CRIs) have been issued for projects using OOT to ensure the issues were addressed.

15.3 OOT in Aviation Handbook

In 1999, the FAA and the industry began actively exploring the use of OOT in aviation. Several projects were considering using the approach, but little research existed to evaluate its suitability for safety-critical and real-time applications. An Aerospace Vehicle Systems Institute (AVSI)^* team supported by Boeing, Honeywell, Goodrich, and Rockwell Collins collaborated on a project titled “Certification Issues for Embedded Object-Oriented Software,” the goal of which was to mitigate the risk that individual projects face when certifying airborne systems with object-oriented software. The AVSI project proposed a number of guidelines for producing objectoriented software that complies with DO-178B [4]. The AVSI work became input into an FAA and National Aeronautics and Space Administration (NASA) effort called object-oriented technology in aviation (OOTiA). NASA’s Langley Research Center and the FAA hosted two workshops to gather input from the industry and to collaborate on the development of a four-volume document entitled Handbook for Object-Oriented Technology in Aviation, which was completed in October 2004 [5].

The issues identified in the OOTiA Handbook became the foundation for evaluating OOT in aviation projects. Applicants and software developers were requested to ensure that their OOT approach addressed the issues identified in volume 2 of the OOTiA Handbook. Volume 3 of the OOTiA Handbook suggested some ways to address the issues raised in the following 10 areas: (1) single inheritance and dynamic dispatch, (2) multiple inheritance, (3) templates, (4) inlining, (5) type conversion, (6) overloading and method resolution, (7) dead and deactivated code and reuse, (8) object-oriented tools, (9) traceability, and (10) structural coverage.

15.4 FAA-Sponsored Research on OOT and Structural Coverage

In the 2002–2007 timeframe, the FAA sponsored a three-phase research effort, which considered structural coverage issues that may occur when using OOT.^* The first phase surveyed the issues and resulted in a report entitled Issues concerning the structural coverage of object-oriented software [6].

The second phase investigated issues and proposed acceptance criteria for the confirmation of data coupling and control coupling (DC/CC) within OOT in commercial aviation. As noted in Chapter 9, the intent of the confirmation of DC/CC is to provide an objective assessment (measurement) of the completeness of the requirements-based tests for the integrated components. The second phase resulted in a report entitled Object-oriented technology verification phase 2 report—Data coupling and control coupling [7]. This report provided recommendations for the coverage of intercomponent dependencies as a measurable adequacy criterion to satisfy DO-178B (and now DO-178C) Table A-7 objective 8. In addition to the report, the phase 2 effort produced a handbook entitled Object-Oriented Technology Verification Phase 2 Handbook—Data Coupling and Control Coupling [8]. The handbook provides guidelines into issues and acceptance criteria for the confirmation of DC/CC within OOT in commercial aviation.

The third phase of the effort investigated issues and acceptance criteria for the use of structural coverage analysis at the source code versus object code or executable object code levels within OOT in order to satisfy DO-178B (and now DO-178C) Table A-7 objectives 5–8. Like the second phase, the third phase resulted in a report and a handbook:

• Object-Oriented Technology Verification Phase 3 Report—Structural Coverage at the Source-Code and Object-Code Levels [9]

• Object-Oriented Technology Verification Phase 3 Handbook—Structural Coverage at the Source-Code and Object-Code Levels [10]

15.5 DO-332 Overview

DO-332 is entitled Object-Oriented Technology and Related Techniques Supplement to DO-178C and DO-278A. It provides guidance on the use of OOT and techniques that are closely related to OOT. DO-332 is also referred to as the OOT&RT Supplement. The OOTiA Handbook, FAA research reports, FAA issue papers, EASA CRIs, and Certification Authorities Software Team (CAST) position papers were all inputs to DO-332. The supplement modifies and adds to DO-178C objectives, activities, explanatory text, and software life cycle data when OOT and the related techniques are used in the software life cycle. Since OOT terminology and the overall understanding of OOT vary among the aviation industry, the supplement provides an overview of OOT and the related techniques. The related techniques include parametric polymorphism, overloading, type conversion, exception management, dynamic memory management, and virtualization. Most, but not all, object-oriented languages employ these techniques. Additionally, some of these techniques are applicable even beyond OOT. The primary differences between DO-332 and DO-178C are summarized here.

15.6 OOT Recommendations

When considering the use of OOT in safety-critical applications, the following recommendations are offered:

Recommendation 1: Review DO-332 to ensure that the technical challenges related to OOT are understood. It is advisable to do this before making the definite decision to use OOT.

Recommendation 2: If new to OOT, start with a small, less critical project (e.g., level C or D software or a tool) and work up to larger, more complex, and/ or more critical software. This provides the opportunity to work out some of the process issues, as well as technical challenges.

Recommendation 3: Follow the guidance of DO-332. The certification authorities and aviation industry have spent over 10 years investigating OOT, identifying the issues, and exploring sound approaches to addressing the issues. DO-332 is the culmination of the efforts.

Recommendation 4: Provide a mapping to the DO-332 guidance to ensure that the guidance and the identified vulnerabilities are fully addressed. As noted earlier, the vulnerabilities are a critical part of the OOT&RT supplement.

Recommendation 5: Expect some challenges. Implementing a new technology for the first time can be a minefield of unexpected challenges. Instead of leading edge, it is sometimes called bleeding edge. Hopefully, the effort invested by the certification authorities and industry over the last several years has identified the bulk of the issues, but there will undoubtedly be some project-specific surprises.

Recommendation 6: Coordinate closely with the certification authorities. Because OOT is still relatively new in the aviation industry, the certification authorities tend to oversee it closely. Hopefully, as positive experience is gained, there will be less need for such intense oversight. Until that time, the certification authorities will want to know the details of an OOT project.

Recommendation 7: Consider if the guidance applies to any non-OOT projects. As noted earlier, some of the guidance of DO-332 may apply to non-OOT projects. In particular, new technologies that use dynamic memory management or virtualization will likely need to apply the guidance of DO-332.

15.7 Conclusion

With the technical progress over the last several years, as well as the development of clear guidance for OOT in DO-332, the door for OOT in aviation has now been opened. It is likely that OOT will become more commonplace in aviation software.