Overcoming the challenges of data coupling and control coupling introduced by modern avionics architectures

Data Coupling and Control Coupling (DC/CC) analysis is a key Software Verification objective for DO-178C projects. The analysis exists to ensure that the interfaces between components verified against low-level requirements have been fully exercised during integration test. As such it provides evidence towards the claim that the integration testing conducted is sufficient.

Several factors make DC/CC analysis challenging. These include lack of clear guidance on what it means to exercise an interface, and absence of industry-agreed metrics for claiming to have done so. Approaches tend to be ad hoc and vary significantly between applicants, and one of the reasons this is the case is the diversity of modern airborne software architectures. Architectures based on partitioning, tasking and multithreading are common, and there is a push towards multicore platforms as the processing hardware on which such architectures are realised. For most modern architectural styles, we would argue that credible metrics have not been proposed, do not exist in the public domain, and therefore no automation exists to support them.

In this presentation, we will focus on one such style of architecture and explain what Rapita is doing to support it via its RapiCoupling DC/CC solution. We will briefly describe some of the generic features of RapiCoupling that apply to more traditional architectures before focusing on what we call a “managed data” architecture.

To develop software safely, efficiently and flexibly for modern product lines, there has been a move towards data-driven, configurable architectures. Such architectures are characterized by highly modular pre-verified applications whose configuration for a particular product in the line is defined by reference data. The data will include, for example:
•    Information on the scheduling of the tasks making up each of the modules – for example, ordering, rates etc.
•    A specification of how I/O data items are represented in the different modules – for example, what the outputs from a computation in one module map to as inputs to a computation in another module
•    Any dimensionality and range conversions that need to be considered when relating data items

Crucially, the data coupling between tasks in different modules are not defined over the same set of program variables, and control couplings are not associated with direct transfers of control. It is the underlying platform that interprets the configuration data and manages the execution and transport of the data from one module to another.

The solution we will describe has been developed in close collaboration with an end-user customer.