Skip to main content
Magline joins Rapita Trailblazer Partnership Program to support DO-178 Certification
Eve Air Mobility joins Rapita Systems Trailblazer Partnership Program for eVTOL projects
Rapita Systems launches MACH178 Foundations for multicore DO-178C compliance
Collins Aerospace and Rapita present award winning paper at DASC 2024
How to certify multicore processors - what is everyone asking?
Data Coupling Basics in DO-178C
Control Coupling Basics in DO-178C
Components in Data Coupling and Control Coupling
DO-278A Guidance: Introduction to RTCA DO-278 approval
ISO 26262
Data Coupling & Control Coupling
Verifying additional code for DO-178C
DO-178C Multicore In-person Training (Fort Worth, TX)
DO-178C Multicore In-person Training (Bristol)
DO-178C Multicore In-person Training (Toulouse)
Data coupling and control coupling (DCCC) coverage analysis is a required activity for DO-178C certification which can demonstrate sufficiency of integration testing and detect problems arising from software integration. On this page, you can learn about DCCC and how DCCC coverage can be verified.
What are data coupling and control coupling?
"Data coupling" and "control coupling" (collectively “DCCC”) refer to the way software components interact with each other in an integrated system to perform a higher-level function. Data couplings involve the exchange or sharing of data between different software components, while control couplings relate to the way components invoke and impact the execution paths of other components.
Data coupling
Data couplings involve the sharing or passing of data between different components. The CAST-19 supplement for DO-178C released by the CAST team defined data coupling as follows:
“Data Coupling is the dependence of a software component on data not exclusively under the control of the software component.”
The example below shows interactions that may be considered data couplings between two components in a flight control system, “sensors” and “airspeed”. In the example, one of 3 different values (SP1-3) can be written to global_static_pressure in the “sensors” component, and this is used to assign a value to a variable in the “airspeed” component. In this case, we consider this to yield 3 independent data couplings.
Control Coupling
Control couplings concern how components invoke and impact the execution paths of other components. CAST-19 defined control coupling as follows:
“Control Coupling is the manner, or degree, by which one software component influences the execution of another software component.”
The example below shows an interaction that may be considered a control coupling between the same two components in a flight control system, “sensors” and “airspeed” shown above. In the example, a call is made from the “sensors” component to the “airspeed” component. As the call is between different components, it can be considered a control coupling.
What is a component?
DO-178C defines a component as
“a “self-contained part, combination of parts, subassemblies, or units that performs a distinct function of a system””
Each component's scope can be influenced by a number of factors, such as where it is appropriate to elaborate high-level into low-level requirements, and the boundaries created by the different ways software functions are intended to be combined.
Components are effectively defined by the allocation of software functions to subsystems with their own internal interfaces. It is this allocation and the definition of these interfaces that ultimately defines the boundaries of the components in your system i.e. components should typically be defined by architecture and design rather than the way the code is organised.
In the implemented code, components may correspond to compilation units such as source files, classes or packages, with object code linking as the primary means of integration, and in the early days of DO-178 this was probably the norm. However, modern airborne systems use a broad variety of mechanisms to integrate software components and this interpretation is arguably too restrictive to apply generally.
As with many aspects of DO-178C, it’s up to you as the certification applicant to define a suitable approach for defining your components that meets the intent of DO-178C and aligns properly with your software design strategy.
DCCC-related objectives in DO-178C
DO-178C objective 6.4.4.d requires that certification applicants provide evidence that data coupling and control coupling structural coverage has been achieved during requirements-based testing. The objective is required for DAL A-C projects and is required with independence for DAL A and B projects.
DO-178C includes several objectives that may relate or overlap with the objective for DCCC coverage analysis. Examples include “Source Code complies with Architecture” A5-2; 6.3.3.b “Software Architecture is consistent” A4-9; 6.3.4.f “Source Code is accurate and consistent” A5-6.
It is important to understand the relationships between objectives when planning and later documenting your DO-178C verification results. Considerations include where to present evidence and how it is structured and cross-referenced.
The two schools of thought in DCCC analysis
There are two major schools of thought regarding the type of activities that should be carried out for DCCC coverage analysis.
The first approach relates to attempts to formalize DCCC as a structural coverage criterion analogous to other criteria such as MC/DC. This approach has had limited success, and proposed coverage definitions are not universally accepted.
The second school of thought accepts that the types of interfaces in modern software systems are varied and that there is no one-size fits all approach to DCCC analysis. In this school of thought, DCCC is regarded more as a process by which common problems can be mitigated and risk reduced. The approach is typified by the “Rierson list”, a list of high-level checks that can form the basis of DCCC (Rierson 2013).
Many DO-178C projects use methods from either or both approaches.
Data coupling and control coupling solutions for critical software
Learn how our data coupling and control coupling solutions for DO-178C and ISO 26262 can help you implement an efficient approach to DCCC analysis that meets your project's needs.
RapiCoupling Preview DCCC ServicesDefining coupling coverage criteria
A major challenge of DCCC analysis is that there are no accepted standard criteria to identify coverage goals, so you’ll need to define and justify these. To determine your coupling coverage criteria, you’ll need to answer questions for which there is no straightforward or agreed answer, including the following:
- What rules govern the correct usage of the inter-component interfaces in your software, and what must you observe during testing to have confidence that these rules are respected? Examples of things you’ll need to consider include range and relationship constraints and call sequencing constraints.
- What are the significant behaviors that you must observe to be confident that a representative set of interactions have been exercised during testing and therefore your testing is complete? Some considerations for this include patterns and locality of reads and writes, parameter handling, treatment of compound objects, depth of exploration of interface, equivalence classes (on parameters or return values), and interrupt patterns.
The answers to these questions depend on your software. When you have answered them, you will be able to identify a precise set of coverage goals. You will also need to justify your criteria by demonstrating that you have understood and reduced risk.
DCCC for multithreaded and multicore systems
Meeting the DO-178C objective is generally more challenging when parts of a system execute concurrently (whether concurrency is simulated e.g. by a scheduler, or real). This is because the interactions at the interfaces between concurrently-executing subsystems can be significantly more complex than they are in sequential systems. Concurrent systems can also exhibit non-determinism, which is problematic in testing regardless of how you approach DCCC.
Despite the additional complexity, modern airborne systems are becoming increasingly multithreaded in nature, especially due to the increased adoption of multicore platforms.
A(M)C 20-193 provides guidance on additional activities needed to demonstrate airworthiness for multicore software when meeting DO-178C. One of the two software verification objectives in A(M)C 20-193, MCP_Software_2, specifically asks certification applicants to demonstrate that the effects of distributing software functionality across multiple cores have been addressed during DCCC analysis.
To address the DCCC objective effectively, you’ll need to provide an argument that your testing is sufficient, and to do that you’ll need to consider all of the ways that the data passing across the interfaces can be produced and consumed by software executing at different and varying rates of progression. You will also need to understand the control mechanisms that moderate those interactions, such as those that ensure synchronization and mutual exclusion.
Additionally, you will need to provide evidence that the interference channels in the multicore hardware cannot introduce software behaviours you have not been able to check in testing. Considerations can include: i) scenarios where the execution time of a task on one core is extended due to the cache accesses of software running on other cores; ii) scenarios where cache coherency protocols at their stress limit can potentially introduce functional changes in the way the software executes.
Solutions for DCCC analysis
If you’re looking for a DCCC solution or partner, you should consider the capabilities and flexibility of analysis that they offer.
Different DCCC solutions may support the analysis of different properties of a system, and you should ensure that the solution you choose lets you perform the types of analysis you want to perform. The capabilities you should look for include handling of parameters and appropriate patterns and locality of reads and writes, expression of couplings on compound objects both atomically and non-atomically, allowing the exploration of different depths of interface, allowing the specification of constraints such as over call sequencing, support for coverage of equivalence classes e.g. on parameters and return values, and support for the analysis of interrupt patterns. If you are developing multicore software or expect to do so in the near future, you should also ensure that your solution provider has a plan to address A(M)C 20-193.
There is no “one size fits all” approach to DCCC, and adopting a flexible approach to DCCC will not only ensure that you can tune the approach to meet your needs, but also that you won’t be forced to apply extra effort to the analysis that has negligible value. Different projects may be based on different models of interactions (e.g. linked code, interrupt-driven periodic thread execution, OS-managed context switching). Each type of interaction prompts a different set of considerations and requires different types of analysis to manage risk appropriately. The same is true of different interfaces within projects, and event different elements of those interfaces. Ensuring that your solution is flexible will allow you to apply the right forms of analysis, in the right ways, to the right problems.
How we can help
Rapita Systems provides a complete suite of Engineering Services to support DCCC coverage analysis for DO-178C projects. Whether you want to outsource your DCCC V&V, want training on DCCC and how to identify and verify couplings, or want guidance on how to make your DCCC analysis approach more efficient, we can help. While automation is important to the efficiency of our approach, we adopt a broader view in how we support our customers, for example, we can conduct independent manual assessments of code and architecture. Our philosophy is risk-based and we apply state-of-the art best practice to provide evidence that the interfaces in the system and their integration are well understood and that associated risks are understood and reduced. We're currently developing RapiCoupling, an automation tool to support data coupling and control coupling (DCCC) analysis for DO-178C and ISO 26262 software and meet the needs of modern critical software.
Join our specialized mailing list to learn more about DCCC analysis.
References
Rierson, L. (2013) Developing Safety-Critical Software: A Practical Guide for Aviation Software and DO-178C Compliance. CRC Press
