Control Coupling

Control Coupling is defined as “the manner or degree by which one software component influences the execution of another software component” in the “Clarification of Structural Coverage Analyses of Data Coupling and Control Coupling” document edited by the Certification Authorities Software Team (CAST). For more information, see https://www.faa.gov/aircraft/air_cert/design_approvals/air_software/cast/cast_papers/media/cast-19.pdf. The purpose is 'to provide a measurement and assurance of the correctness of these modules/components’ interactions and dependencies'.
OneTest Embedded introduces a new coverage level call “control coupling” for C language that consists of verifying that all the interactions between modules have been covered by at least one test. This new coverage level is implemented in OneTest Embedded as follows:
  • Modules on C language and compilation units (i.e. C files that are independently compiled).
  • Interactions are calls between 2 functions that are in 2 different compilation units.
  • Control Coupling is not a simple interaction. It is a control flow in the calling module that ends with an interaction with another module.

So, to identify the Control Couplings, OneTest Embedded analyzes all the external calls (i.e. calls between 2 different files) and statically identifies all the possible paths in the calling module that end with each external call, excluding the one that starts with a static function (i.e. a function that can't be called from another module). This constitutes the set of Control Coupling of the application.

For each of them, OneTest Embedded provides the following information:
  • The calling and the called modules.
  • The complete control flow (i.e. the set of successive calls, the last one is the external call).
  • Is it the longest one that leads to this external call (it is not the longest when there is another Control Coupling that includes the current one)
  • Is it the shortest one that leads to this external call (it is not the shortest when there is another Control Coupling that is included by the current one)
  • It is covered or not.
  • The list of test cases that covered each Control Coupling.
  • The list of requirements that are related to the test cases.

How Control Coupling Works

When an application node is executed, the source code is instrumented by the Instrumentor (attolcc4 for C language) that produces a static file with the extension .tsf containing information on the Control Couplings. The resulting source code is then compiled, linked and executed and the Control Coupling feature outputs a dynamic file with the extension .tgf.

These 2 types of files are the input of the report generator that produces a report in HTML format (and optionally the raw data can be generated in a Json file). A template is provided for this generator. You can provide your own template to modify the report.

If the Control Coupling feature is used with unit testing feature, the report generator can take the .tdc files as input files. This allows to have also in the report the test cases that covered each Control Coupling and the associated requirements declared in the .ptu file. If not, the test cases are identified by its execution date, and there is no requirement.

Important: To visualize your report in Eclipse, if you are using the default browser option, be sure that JavaScript is enabled. Otherwise, you can choose another browser that is compatible with your version of JavaScript by changing it in Window> Preferences> General > Web Browser.


Feedback