Object-oriented technology

Supplement DO-3329 to DO-178C 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.

A-7 OO.10 Verify local type consistency (OO.6.7.1)Ensuring that that “each class passes all the tests of all its parent types which the class can replace” is usually the most practical approach here. Consider a superclass Rectangle whose methods explicitly set the height and width, and a Square subclass that sets both in the SetWidth function. Type consistency is violated because test cases for the SetWidth method of the Rectangle class may not pass those for its subtype Square.

In this example, type inconsistencies can be highlighted by applying the same test cases to the parent class Rectangle and the subclass Square.A-7 OO.11 Verify the use of dynamic memory management is robust (OO.6.8.1)A range of static and dynamic analysis techniques can be deployed in order to fulfil DO-332 A-7 OO.6.8.1 and the related vulnerabilities outlined in Annex OO.D.1.6.1.

Tracking memory allocation and deallocation helps to ensure the proper freeing of memory, as do associated checks prior to dereferencing. Low-level 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.

Model-Based Development

Supplement DO-3311 to DO-178C addresses Model-Based Development (MBD), asserting that specification models or design models take the place of high-level and low-level requirements respectively. Textual requirements may be linked to models upstream or downstream.

Popular tools such as MathWorks® Simulink®, IBM® Rational® Rhapsody®, and ANSYS® SCADE can generate code automatically. DO-331 MB.5.0 (Software Development Processes) addresses traceability, model standards and more for both software requirements and design processes where such tools are used. MB.5.3 (Software Coding Processes) is simply a cross-reference to DO-178C, emphasizing that best-practice coding-related process activities still apply.

Projects using auto-generated code almost always contain some hand-code too. It is possible to apply different coding standards to these different code subsets, such as MISRA C:2012 for hand-code, MISRA C:2012 Appendix E for auto-generated code, and a custom coding standard for legacy code.

DO-331 MB 6.0 (Software Verification Process) expands on how best practice applies to MBD, with DO-331 MB.6.8.2 (Model Simulation for Verification of Executable Object Code) expanding upon which verification objectives must be performed at the target level.

The objectives listed requiring at least some verification at the target level include EOC robustness, compliance with low-level requirements, test coverage of low-level requirements, confirmation of compatibility with the target hardware, and hardware/software integration testing. The supplement also lists various types of errors that can only be detected on the target hardware.

DO-331 MB.B.11 (FAQ #11) addresses the questions of model coverage activity, stating that model coverage analysis can be considered in very specific scenarios, “…on a case-by-case basis and agreed upon by the certification authorities...”. As a result, most organizations do some of the verification activities within the model but then re-affirm the results of those activities on the target.

The integration of the LDRA tool suite and modelling tools help to achieve that seamlessly, including the static analysis of generated code, the collection of code coverage from model execution, and the migration of model tests into an appropriate form for execution on the target hardware.

Object-oriented technology and model based development