Structural coverage identifies which code structures and component interfaces have been exercised during the execution of requirements-based test procedures, facilitating the empirical measurement of requirements-based test effectiveness. As the name implies, structural coverage analysis involves the scrutiny of the structural coverage to determine if there are any parts of the code which have not been sufficiently exercised, and if not, why.

DO-178C Section 6.4.4 details requirements for the achievement of 100% MC/DC, decision, and statement coverage, depending on Design Assurance Level (DAL)  From table A-5 of DO-178C:

Collation of structural coverage metrics is typically achieved by “instrumenting” a copy of the source code (that is, superimposing function calls to collate coverage data) and executing that instrumented code using requirement-based test cases. These test cases primarily reference high-level requirements, supplemented by low-level requirements as needed.

Structural coverage analysis is then applied to assess the effectiveness of this testing by measuring how much of the code has been exercised.  Coverage of portions of code that have not been executed thus far may require additional test cases or modifications to existing test cases, changes to requirements, removal of dead code, or perhaps the identification of deactivated code and resulting unintended functionality. An iterative “review, analyze, verify” cycle is typically needed to ensure that the software coverage objectives are fulfilled, and the graphical representation provided by the LDRA tool suite can be a great help (below).

Graphical visualisation of code coverage in a flow graph in the LDRA tool suite.

System requirements can be shown to have been correctly decomposed, implemented, and verified by combining a complete trace from requirements through to code and test cases, with the achievement of comprehensive functional test coverage and structural coverage objectives.

DO-178C, Statement Coverage, and Decision/Branch Coverage

Statement coverage and decision coverage are the two simplest forms of coverage metric leveraged by DO-178C. (In this context, decision coverage and branch coverage are synonyms). Statement coverage ensures that every executable statement in the code has been run at least once during testing, while decision coverage ensures that every decision point (e.g., if/else, loops) has taken all possible outcomes (true and false) at least once.

DO-178C and Modified Condition / Decision Coverage (MC/DC)

In addition to statement and branch coverage, for level A software MC/DC is obligatory. MC/DC requires that “Each condition in a decision has been shown to independently affect that decision’s outcome” (DO-178C Glossary).

It might be supposed that where there are multiple conditions in decisions, the right course of action would be to test every possible combination. However, as soon as there are more than two or three conditions involved, the amount of testing that would require becomes prohibitive (below).

MC/DC is a coverage metric for multiple condition decisions. It does not require every possible combination to be executed and in the ideal case requires only one more test than the number of conditions involved. In the example shown there are 6 conditions, and so a total of 64 possible combinations – and yet only 7 tests are needed to achieve MC/DC coverage.

However, those tests must show that each of the conditions independently affect the result, and it is not always obvious which input values might achieve that. The use of an MC/DC planner makes the selection of appropriate values much easier.

DO-178C and source to object code traceability

For Level A systems, structural coverage at the source level isn’t enough. Compilers often add additional code or alter control flow, and often their behaviour is not deterministic. To ensure that functionality is not compromised, DO-178C Section 6.4.4.2.b states that:

“…if the software level is A and a compiler, linker, or other means generates additional code that is not directly traceable to Source Code statements, then additional verification should be performed to establish the correctness of such generated code sequences.”

An automated mechanism to provide evidence of that source to object code traceability can make this process much more efficient. Because there is a direct one-to-one relationship between object code and assembly code, one way for a tool to represent this is to display both a graphical representation of the source code and the equivalent representation of the assembly code. Object Code Verification (OCV) measures code coverage at both the source and the assembly level by instrumenting each in turn.

This approach provides a means for the demonstrable and deterministic verification of the Executable Object Code (EOC) on the target system. For OCV to be effective, it therefore needs to support the microprocessor, associated instruction set, and compiler deployed on that system.
Three discrete modes are used for each test case to quickly identify the “additional code” referenced in the standard and dramatically reduce laborious manual analysis.

1. The test case is executed without instrumentation to confirm correct functionality.
2. The test case is executed by leveraging instrumentation at the source code level.
3. Finally, the test case is executed with instrumentation at the assembly code level to identify any uncovered statements or branches that may have been inserted or altered during the compilation and linking process.

Typically, a few more requirements-based tests can be added to verify this additional code to meet the objectives of DO-178C Section 6.4.4.2.b. Automated source code instrumentation and coverage data analysis reduces space and time overhead which in turn makes the technology scalable and adaptable to a wide array of cross compilers, targets, in-circuit emulators, and other embedded environments. Target integrations are highly extensible and support processors from simple 8-bit devices to high-performance multicore architectures, IDEs, and I/O integrations.

In summary

Structural coverage analysis plays a vital role in demonstrating the effectiveness of requirements-based testing under DO-178C. From basic statement and decision coverage to advanced MC/DC and object code verification, achieving compliance requires rigorous testing, traceability, and tooling support to ensure that no unintended or unverified code remains.

Further information

Webinar-on-demand: MIL-STD-882E and DO-178C Entanglement

Website: Aerospace & Defense

Website: Demystify the who, what, when and why of successful DO-178C compliance.

Website: Understanding A(M)C 20-193

Brochure: LDRA Certification Services