Manual peer reviews are time-consuming, costly, and error prone. Raising the level of abstraction quickly provides insight into the architecture and behaviour, control flow, and data flow of the code, highlighting potential problem areas. Small wonder Data flow analysis and control flow analysis are fundamental to the standards guiding critical systems development.
Relating the text of a program written using a high-level language to its possible execution sequences is not an intuitive process. Those sequences are dictated by decision points in the software; that is, combinations of one or more conditions that define the conditions for subsequent program behaviour.
Control flow analysis focuses on those decision points to provide a more intuitive representation of that behaviour, known as control flow graphs (or control flow diagrams). In turn, that helps developers to ensure that the code they have written fulfils their intentions.
With the static control flow analysis completed, it is then possible to exercise the code and identify which execution paths have been exercised, and which haven’t. This illustration from the LDRA tool suite shows how flow diagrams can be colour-coded to show whether execution paths have been exercised, or not.
Just as control flow is not easily discernible from the text of a program written using a high-level language, neither is the effect it has on the data it manipulates.
Data flow analysis is a technique for gathering information about the possible set of values calculated at various points in a computer program. It uses information derived from control flow analysis to determine how values assigned to variables might propagate.
With the static data flow analysis completed, it is then possible to exercise the code and identify those points in the code where the data has been manipulated or read. The green areas in this report generated by the LDRA tool suite shows that all data it references has been exercised.
Both data flow analysis and control flow analysis are core principles promoted by DO-178C in civil aviation, IEC 61508 for electronic control systems generally, and the many derivatives of ISO 61508. These include ISO 26262 in automotive, IEC 62304 in medical device, the EN 5012x series in GTS, the ECSS series in space applications, and many more.
For example, IEC 62304 Edition 1.1 § 5.4.4 states that “when present in the design, the MANUFACTURER shall include acceptable criteria as appropriate for … data and control flow”
Control coupling is defined in Annex B of DO-178C as:
“The manner or degree by which one software component influences the execution of another software component.”
The control flow of a program is therefore impacted by the extent of its control coupling. Although DO-178C is specific to aviation, this definition of control coupling is applicable across all sectors.
Data coupling is defined in Annex B of DO-178C as:
“The dependence of a software component on data not exclusively under the control of that software component.”
The data flow of a program is therefore impacted by the extent of its data coupling. Although DO-178C is specific to aviation, this definition of data coupling is applicable across all sectors.
Data flow analysis and control flow analysis are core objectives of many functional safety standards. There relevance is discussed in our standard-specific collateral, including the following examples:
Technical Briefing: DO-178C: Get on a High with your software development
Technical White Paper: Verification of Airborne Software in Compliance with DO-178C
Technical White Paper: Developing software for household appliances in accordance with IEC 60730
Technical White Paper: Implementing the EN 5012X standards with the LDRA tool suite®
Email: info@ldra.com
EMEA: +44 (0)151 649 9300
USA: +1 (855) 855 5372
INDIA: +91 80 4080 8707