“DO-332 – Object-Oriented Technology and Related Techniques Supplement to DO-178C and DO-278A” describes concepts and key features of object-oriented technologies and related techniques in the context of DO-178C & DO-278A compliant projects. It discusses their impact on the planning, development, and verification processes, and enumerates their vulnerabilities.
In the early 2000s, object-oriented technology was viewed in the commercial avionics space as novel and unproven. Around that time the Certification Authorities Software Team (CAST) published papers to enumerate concerns and limitations. These were called CAST 4 and CAST 8 and were published in 2000 and 2002 respectively.
As DO-178B was updated to DO-178C it was decided that these concerns, vulnerabilities, and subsequent additional objectives associated with object-oriented technologies would be addressed not by the original standard but rather a supplement, “DO-332 – Object-Oriented Technology and Related Techniques Supplement to DO-178C and DO-278A”. This new supplement describes concepts and key features of object-oriented technologies and related techniques, discusses their impact on the planning, development, and verification processes, and enumerates their vulnerabilities.
The RTCA & EUROCAE versions are harmonized and were both published in January 2012. Together, they constitute one of four technology supplements introduced when DO-178C replaced DO-178B.
The purpose of DO-332/ED-17 is to provide guidance on safely using object-oriented programming (OOP) in safety-critical software. It supplements DO-178C/DO-278A by addressing risks and features specific to OOP, including inheritance, polymorphism, and dynamic memory.
According to the document itself, DO-332 “contains modifications and additions to DO-178C [and DO-278A] objectives, activities, explanatory text, and software lifecycle data that should be addressed when OOT&RT [Object Oriented Technology and Related Techniques] are used as part of the development life cycle”
OOT&RT is an abbreviation used in the standards which references Object Oriented Technology and Related Techniques.
RTCA DO-178C (DO-178C/ED-12C) Software Considerations in Airborne Systems and Equipment Certification is the principal document referenced by certification authorities (FAA, EASA, TCCA, ANAC…) to approve all commercial software-based aerospace systems. It is a formal process standard that covers the complete software lifecycle to ensure correctness and robustness in software systems for civil airborne applications.
DO-178C §1.4b states that “One or more supplements to this document exist extend the guidance in this document to a specific technique. Supplements are used in conjunction with this document and may be used in conjunction with one another”. DO-332/ED-217 falls into that category of supplement. Supplements are also references in DO-178C Appendix A.
RTCA DO-278A (DO-278A/ED-190A). “Software Integrity Assurance Considerations for Communication, Navigation, Surveillance and Air Traffic Management (CNS/ATM) Systems” is a sister document to DO-178C/ED-12C and adheres to similar principles to ensure correctness and robustness in software systems for CNS/ATM applications.
DO-278A §1.4o states that “One or more supplements to this document exist extend the guidance in this document to a specific technique. Supplements are used in conjunction with this document and may be used in conjunction with one another”. DO-332/ED-217 falls into that category of supplement.
RTCA DO-330 (DO-330/ED-215) “Software tool qualification considerations” describes the processes to be followed to ensure that software tools used in the development of safety-critical applications are fit for purpose.
DO-330/ED-215 was primarily written as a technology supplement to support the civil aviation standards typified by DO-178C/ED-12C and DO-278A/ED-209. However, it also asserts that “It may also be used by other domains, such as automotive, space, systems, electronic hardware, aeronautical databases, and safety assessment processes.”
Like DO-332/ED-217, DO-330/ED-215 is one of the technology supplements introduced when DO-178C replaced DO-178B.
RTCA DO-331 (DO331/ED-216) “Model Based Development and Verification” describes adjustments to the principles described in DO-178C that apply when using model-based design.
Like DO-332/ED-217, DO-331/ED-216 is one of the technology supplements introduced when DO-178C replaced DO-178B.
RTCA DO-333 (DO-333/ED-218). “Formal Methods Supplement to DO-178C and DO-278A” identifies additional objectives and advice pertinent to the use of formal methods in compliant applications. Like DO-332/ED-217, DO-333/ED-218 is one of the technology supplements introduced when DO-178C replaced DO-178B.
DO-332 describes key features of object-oriented technologies and related techniques, discusses their impact on the planning, development, and verification processes, and enumerates their vulnerabilities. Two objectives were included in the DO-332 supplement to that effect, both of which are identified in Table A-7.
§OO.6.7 “Local Type Consistency Verification” discusses the use of inheritance with method overriding and dynamic despatch and specifies that additional verification activities are necessary in this regard.
§OO.6.7.1 simply states that the objective is to “verify that all type substitutions are safe”, leaving §OO.6.7.2 to identify approaches that can be used to provide that verification.
Liskov’s Substitution Principle
It is useful to understand Liskov’s Substitution Principle in this context.
“Let q(x) be a property provable about objects x of type T. Then q(y) should be true for objects y of type S where S is a subtype of T”
This can be visualized by reference to an example. In common parlance, a square is a type of rectangle. The term “is a” suggests a relationship that could be represented through inheritance in programming.
It would seem reasonable to have SetWidth and SetHeight methods in a Rectangle class. But using SetWidth and SetHeight for a Rectangle object that is a Square necessitates ensuring that both dimensions are the same, leading to the possibility of incongruities.
Liskov Substitution Principle tests check for such problems. Consider Figure 28.
Parent and child class showing code that violates type consistency
In object-oriented languages, inheritance allows the behaviour of “superclasses” to be overridden by subclasses. Ensuring safe use of inheritance, method override, and dynamic dispatch is challenging as the nature of these techniques can make it unclear from a simple review which method is executed at any call point in a program (DO-332 Appendix B FAQ #14). Overridden behaviour in instantiated subclasses may alter the behaviour beyond the intended scope of the superclass and violate type consistency.
As DO-332 §OO.6.7.1 further describes, this means that the preconditions of the parent class must not be strengthened, and the postconditions and invariants defined on the state of a class must not be weakened.
From a verification standpoint, DO-332 §OO.6.7.2 suggests that one of the following activities must be performed:
The first of these applies to the small minority of development teams who are using formal methods, whilst the third (once commonly referred to as flattened class testing) requires that each possible dispatch is tested at every call point in a program. That can easily cause a combinatorial explosion of test cases, dramatically increasing the verification burden.
That leaves the second option as the most practical for most people – to ensure type consistency, without the burden of pessimistic testing. Doing so requires that each class and its methods must pass all tests of every superclass for which it can be substituted (DO-332 Appendix B FAQ #34).
In the Rectangle and Square example, type consistency is violated. Reusing test cases from the parent class Rectangle on the subclass Square highlights that.
§OO.6.8 “Dynamic Memory Management Verification” discusses the vulnerabilities inherent in the use of dynamic memory management and gives guidance on how best to avoid falling victim to them.
§OO.6.8.1 confirms that the objective is to “verify the use of dynamic memory management is robust”, and §OO.6.8.2 (supported by Annex OO.D.1.6.1) details appropriate methods to be considered. These include range of static and dynamic analysis techniques.
Tracking memory allocation and deallocation helps to ensure the proper freeing of memory, as do associated checks prior to dereferencing. Low-level testing (also known as unit testing) provides a mechanism to explore various allocation/deallocation scenarios to help ensure that vulnerabilities are addressed. Timing hooks within low-level tests help characterize allocation/deallocation timing, and dynamic data flow analysis monitors data elements in runtime to detect lost updates and stale references.
In addition to supporting the two additional DO-332 objectives, the LDRA tool suite also underpins many other significant considerations that apply when using object-oriented technologies or related techniques in the development of compliant applications. These include:
Source to object code traceability
As mentioned in §OO.D.1.2.1, source to object code traceability may be more difficult to correlate in object-oriented languages. OCV solutions (below) provide a graphical comparison of assembly code coverage and high-order language coverage (i.e. C++) to ensure that the source coverage data accounts for variations in the structure of executable object code (EOC) as compared to the source code.
Source to object code traceability with the TBobjectbox component of the LDRA tool suite
Traceability to child classes
§OO.5.2.2i states “Develop a locally type consistent class hierarchy with associated low-level requirements whenever substitution is relied upon”. In other words, a requirement that traces to a method implemented in a class should also trace to the method in its subclasses when the method is overridden in that subclass (DO-332 Appendix B FAQ #9). Static analysis and code visualization exposes inheritance relationships within the analyzed code, making traceability gaps across class hierarchies easier to detect and remedy.
Coding standard for object-oriented languages
Languages such as C++ allow for tremendous syntactic/semantic flexibility. Standards such as MISRA C++ 2023 and JSF AV++ help quickly define a language subset and best practices to provide a baseline for software coding standards used in specific projects.
Challenges with structural coverage and low-level testing
Structural coverage of destructors, instantiating complex data types for testing, testing templated classes and overloaded operators, and accessing private members, are just some of the challenges that arise when working with object-oriented technologies or related techniques. Tools need to be equipped to address these challenges and reduce the cost of verification, while preserving the integrity/credibility of the verification activities.
DO-332/ED-217 addresses the challenges and vulnerabilities introduced when object-oriented technologies and related techniques are used in safety-critical software development. By extending and modifying the core guidance of DO-178C and DO-278A, it ensures that features such as inheritance, polymorphism, and dynamic memory management are rigorously planned, verified, and validated. Together with the other technology supplements and supported by LDRA tools and services, DO-332 enables modern object-oriented development practices to be safely and effectively incorporated into certifiable systems, maintaining the high levels of assurance required by certification authorities.
Technical white paper: Verification of Airborne Software in Compliance with DO-178C
Technical white paper: Developing compliant critical software systems with multicore processors
Technical white paper: Technical white paper: Following the recommendations of CAST-32A & A(M)C 20-193
Technical briefing: DO-178C demystified: Strategies for efficient certification
Technical briefing: Getting to grips with CAST-32A & A(M)C 20-193
Technical note: Achieve DO-178C compliance with LDRA tool suite
Data sheet: DO-178C with the LDRA tool suite
Data sheet: LDRA Productivity Package – Aerospace and Defense
Website: DO-330 Software tool qualification considerations: When, where, and how it applies
Technical briefing: Achieve DO-178C compliance with LDRA tool suite
Technical briefing: DO-330 Test tool qualification for aerospace applications
News article: Ensuring the compliance of avionics software with DO-178C
Training: On Demand DO-178C “First Flight” Self-paced online training course
Case study: Richland technologies case study
Email: info@ldra.com
EMEA: +44 (0)151 649 9300
USA: +1 (855) 855 5372
INDIA: +91 80 4080 8707