Modularization has long been a foundational principle in software engineering—dividing systems into clearly defined modules with unambiguous interfaces. This approach has consistently delivered higher quality, more maintainable software.
In safety-critical systems, modularisation alone isn’t enough. It’s essential to verify how modules interact—specifically their data coupling (sharing of variables) and control coupling (influence over each other’s execution flow). These interactions must be examined and verified to ensure system-level correctness and safety.
For example, this necessity is reflected in DO-178C – a document that is central to the approval of safety critical software in civil aviation. DO-178C elevates Data Coupling and Control Coupling (DCCC) analysis to a verification objective such that it must be exercised, observed, and evidenced.
There are several definitions of coupling in circulation, many of which differ subtly. The definition in the 1980 book “The Practical Guide to Structured Systems Design” by Meiler Page-Jones is appropriate here;
“The degree of dependence of one module upon another; specifically, a measure of the chance that a defect in one module will appear as a defect in the other, or the chance that a change in one module will necessitate a change to another.”
Modules demonstrating a high degree of interdependence are said to be “tightly coupled”, rather than “loosely coupled”.
Cohesion is a little more difficult to understand than coupling and is perhaps best explained by reference to examples. A module that has well-defined interfaces and that operates independently of other modules is considered to have high levels of cohesion. For example, an MD5 cryptographic hash generator module is likely to demonstrate high levels of cohesion. The input is a data object of any description (e.g., a file), and the output is a base-64 hash representation. Because the hash generator takes a single input, provides a single output, and has no external dependencies, it is considered to demonstrate “strong” or “high” cohesion.
At the other end of the spectrum is a flight control module. Such a module would be highly dependent on the current state of the plane (e.g., is the aircraft presently banking, or changing elevation) and an incoming flight data stream (e.g., air speed, altitude, attitude, etc.), so therefore has “weak” or “low” cohesion.
If modules are not truly cohesive, then testing each module in isolation from others becomes challenging.
Annex B of DO-178C includes a definition of data coupling that is applicable across the sectors. It is:
“The dependence of a software component on data not exclusively under the control of that software component.”
The response of an engine control module that is determined by temperature and altitude has a tight data coupling with the modules that provide the relevant data streams.
Annex B of DO-178C also includes a definition of control coupling that is equally applicable across other sectors. It defines control coupling as:
“The manner or degree by which one software component influences the execution of another software component.”
In practical terms, control coupling exists wherever a module alters another’s behaviour—often via:
For example, tight control coupling exists between an engine control module that responds differently when an aircraft is airborne, and a landing gear module that provides a “weight-on-wheels” signal.
In the context of DO-178C, a Computer Software Configuration Item (CSCI) is a discrete, identifiable unit of software that is developed, managed, and verified as a standalone component within a system’s configuration management and certification framework.
Coupling analysis across these CSCI boundaries is a critical activity that leverages requirements-based tests to allow developers to isolate and verify the intended interactions within well-defined software boundaries.
The manual analysis of coupling using debuggers or trace logs is fraught with overhead, scalability, and fallibility issues. Automating the analysis process significantly reduces the effort required and improves consistency across verification activities.
Ensuring that control coupling and data coupling are sound is good practice for all critical software. Some standards make specific reference to that practice.
Table 3 of ISO 26262 recommends an architectural design that encompasses the principles of strong cohesion, and loose coupling. Verifying that these principles are also reflected in the resulting code base supports the ethos of traceability that is also encapsulated by ISO 26262.
DO-178C § 6.4.4.2.c requires “analysis to confirm that the requirements-based testing has exercised the data and control coupling between code components.” Objective A-7.8 of the standard requires that “Test coverage of software structure, both data and control coupling, is achieved.”
This essentially means that data coupling and control coupling analysis needs to be concluded post execution, and generated artefacts reviewed against the system requirements and architecture. A mechanism to do so is provided by the LDRA tool suite.
A(M)C-193 (formerly CAST-32A) MCP_Software_2 requires that “the data and control coupling between all the individual software components hosted on the same core or on different cores of the MCP has been exercised during software requirement-based testing, including exercising any interfaces between the applications via shared memory and any mechanisms to control the access to shared memory, and that the data and control coupling is correct.”
The control and data coupling features of the LDRA tool suite support the analysis of explicit data and control flow between software components and applications. The guidance in the documents also references the possibility of coupling on a platform level, and the WCET capabilities of the LDRA tool suite support analyses relate to that.
Its predecessor, DO-178B, provided a vague definition of the required treatment of software coupling. While the standard required verification of software integration and interface consistency, it offered no explicit guidance on analysing how components interact through shared data or control logic. Coupling analysis was often overlooked or addressed informally, with no consistent expectation across projects or certification authorities.
DO-178C resolved this ambiguity by introducing an explicit requirement to analyse both data coupling and control coupling. At Design Assurance Level A,
These objectives formalised the expectation that component interactions must not only be analysed but actively exercised and verified through test execution. As clarified in the civil aviation advisory document CAST-19 “Data Coupling and Control Coupling”, meeting the objective demands evidence gathered through requirements-based testing.
Dynamic analysis is essential to show that actual data and control couplings behave as expected during execution. But it can only expose what the tests exercise, leaving any untested paths or conditions unnoticed.
Static analysis addresses this by providing a complete view of all potential data and control dependencies, regardless of runtime behaviour. It can uncover hidden or indirect couplings that tests may not trigger, ensuring that no critical interactions are overlooked.
Used together in an integrated hybrid approach, static and dynamic analysis offer both completeness and precision: static identifies all possible couplings, while dynamic confirms which ones occur and behave correctly. This combined approach is essential for robust, standards-compliant verification.
The patented hybrid approach adopted in the LDRA tool suite integrates static and dynamic techniques to provide thorough, standards-aligned verification of both data and control coupling across software components.
The process begins with static analysis, using LDRA’s software comprehension and data & control flow engines to identify instances of data coupling and control coupling.
Once the couples are identified, the tool suite defines targeted test runs that are executed using dynamic analysis. These tests are applied to instrumented code, allowing the behaviour of identified couples to be observed at runtime.
The outcomes of both analyses are consolidated into a single DCCC coverage report.
The upper image shows a report where 17 control calls have been identified, with 2 relating to intra-file calls (within this file) and the remainder relating to external calls.
The lower image shows a report that identifies the procedures within a particular file, the control couples associated with procedures, and the extent to which they have been exercised.
These reports help to identify any gaps and guide targeted verification activities and ultimately provide evidence that all couples have been validated.
Multicore processors (MCPs) offer clear benefits in airborne systems—improved performance, reduced power consumption, and lower size and weight. However, they introduce significant complexity in development and verification, not least in relation to Data Coupling and Control Coupling (DCCC).
Shared resources such as interconnects, memory, and caches (below) can create interference channels between cores, potentially:
For instance, a producer task writing to shared memory on one core and a consumer reading it on another may be affected by:
Similarly, control coupling via flags or shared variables may be timing-sensitive and indirect, requiring runtime verification to confirm correct behaviour.
Even if two tasks are logically separate, their interaction through shared infrastructure may affect system behaviour, requiring dynamic verification to confirm that DCCC is exercised correctly and deterministically.
A(M)C 20-193 highlights these challenges, stressing the need to understand how shared resources affect timing and behaviour. In such contexts, static & dynamic hybrid verification becomes essential to ensure DCCC is exercised and verified across cores, maintaining determinism and safety.
The LDRA hybrid approach to DCCC addresses the challenges posed by multicore systems. The static analysis phase recognises shared variables, control parameters, global state, and inter-task interactions – whether they are intra- or inter-core.
As for the general case, the process continues with dynamic analysis, where requirements-based test cases are applied to instrumented software. LDRA’s instrumentation technology isolates coverage metrics and coupling observations on a per-core basis. This allows for precise evaluation of inter-core interactions without conflating behaviours from unrelated tasks.
Graphically presented results enable engineers to visualise data and control coupling paths, trace them back to the original requirements, and identify gaps or anomalies in execution. When interactions span multiple cores, the tools determine whether the coupling is both observable and verifiable (below) – whether explicitly through application-level interaction or implicitly due to shared memory or cache behaviour.
This detailed insight into inter-core interaction and shared resource interference enables engineers to identify root causes and shape targeted test scenarios for interference and execution time analysis.
Email: info@ldra.com
EMEA: +44 (0)151 649 9300
USA: +1 (855) 855 5372
INDIA: +91 80 4080 8707