What is control flow

Complete requirements with data and control flow analysis

The implementation of a data and control flow analysis is required in almost all functional safety standards. Compared to other methods and measures, the data and control flow analysis is more of a shadowy existence. The main reason for this is that the technological capabilities to carry out such an analysis have so far been lacking.

The non-intrusive system monitoring technology from Accemic (www.accemic.de) now offers the possibility of verifying the data and control flows through tests. This in turn makes it possible to systematically check the functional completeness of the requirements.

Definition of data and control flow

Wikipedia defines the data flow as follows:

“In computer science and structured analysis, data flow means an element of a data flow diagram and names the data structures that are exchanged between two functions. The data flow defines the causal dependency of the functions and thus makes it possible to determine the concurrency of individual sub-processes.

According to Wikipedia, control flow means:

In computer science, the control flow or program sequence describes the chronological sequence of the individual commands of a computer program. The control flow of a program is usually specified by the order of the commands within the program, but control structures allow deviating from the sequential processing of the program.

The goal of the data and control flow analysis is to analyze the data and control flow of a software and to prove its correctness.

Challenges of data and control flow analysis

First of all, in practical application it is very difficult to clearly differentiate between data and control flow. At many points in a software program there is a close coupling between a data flow and a control flow.

In addition, there tend to be an infinite number of data and control flows in software. A complete proof of the correctness of all data and control flows is therefore impossible in practice.

In addition, a dynamic verification of the data and control flows was previously not possible for technological reasons. In the aviation industry, unit tests or software integration tests have so far been used to prove important data and control flows. However, since these tests are not carried out with the real hardware, no data and control flows under stress conditions could be detected for the entire embedded system. This evidence could also not be provided for time-critical applications, which represent a large part of the embedded systems.

Non-intrusive system observation

In the future, non-intrusive system monitoring offers the possibility of observing software parameters and other external and internal events at the same time without influencing the behavior of the overall system. Since such tests can be fully automated compared to tests with the debugger, it is possible to systematically prove data and control flows in the integration and system tests.

Since the functional requirements are also verified in these tests, this technology offers the possibility of checking the completeness of the requirements. Important data and control flows are always reflected in the functionalities of the system.

Activity diagrams specify the data and control flows

The new possibilities that result from the non-intrusive system observation, however, also draw attention to another weakness of the previous procedure. This is the specification of the data and control flows. In hardly any project that I have accompanied in recent years, the data and control flow has been systematically specified. This weakness of most projects will move more into the focus of considerations in the future. Both the systematic verification by test, of the data and control flows, as well as the completion of any existing functional specification gaps, are only really successful if at least the most important data and control flows are defined in the software architecture. When describing the software architecture in UML, activity diagrams are a good means of doing this.

Conclusion

The ISO 26262 (part 6, table 7 points 1f and 1g) in the automotive industry, the DO178C (table A-7 point 8) in the aviation and the EN 50128 and EN 50657 (respectively table A19 points 3 and 4) in the rail industry a data and control flow analysis.

So far, only static analyzes or unit and software integration tests could be used as evidence of the data and control flow for this verification.

The non-intrusive system observation makes it possible in the future to systematically prove data and control flows at the integration and overall system level. In addition to the possibility of testing complex error scenarios, this new technology also offers the possibility of checking the completeness of the functional requirements. This becomes a powerful quality instrument in particular when the software architecture systematically specifies the data and control flows. UML offers a good method with the activity diagrams.

Are you ready for a FuSi workshop to identify the potential for improvement? Then send an email to info [at] heicon-ulm.de or make an appointment on +49 (0) 7353 981 781.

/ 0 Comments / by HEICON Global Engineering GmbHKeywords:CENELEC, data and control flow analysis, DO178C, en 50657, EN50128, functional safety, ISO 26262, non-intrusive coverage