The Tool to Analyze the Data Dependencies of Your Application
emmtrix Dependency Analyzer (eDA) assists you with the safety analysis of your applications: Results from a data dependency analysis of the source code can be used to:
- Verify freedom from interference
- Propagate different safety levels of variables
- Detect mixed-criticality dependencies (variables with different safety levels)
- Verify event chains between input and output signals of the system
A further use case is the optimization of your testing strategies by identifying which subsystems are affected by a change in the source code and, more importantly, which subsystems are not and therefore do not have to be tested again. The tool can easily be integrated into CI flows offering automation, versioning and logging.
See our tool in action. Contact us to request a demo or to set up a chat or meeting.
emmtrix Dependency Analyzer Example
A small source code example is shown in the next figure. The code uses three global variables g1. g2 and g3 as well as two output variables out1 and out2. The dependency analysis extracts how the output depend on the input variables.
The results are shown in the XML file in the next figure. Variable out1 depends on g3 and g2 whereas the dependency to g3 is a control dependency and to g2 a data dependency. Variable out2 only depends on g1.
More information can be seen as comments inside of the C code. The next figure shows all use (read) and def (write) accesses to all variables in the program. Control dependencies are marked with (c), delayed dependencies that depend on values from a previous iteration by ^-1. Phi statements are virtual instructions that are placed when the value of a variable depends on a condition. This kind of representation is useful to see the dependencies directly where they come from in the source code.
An extract from the full dependency graph can be seen in the next figure. It shows statements from the source code and how they depend on each other:
- SSA: there exists a use/def dependency where one signal writes a value and another one reads it
- Control: a control dependency caused by a condition (branch) instruction exists
- CallArg: the statement depends on an argument of the function
- Expr: the statement is part of the previous expression.
This kind of visualization can help pinpoint the root of a specific dependency.
- Analysis takes all possible paths of the control flow graph into consideration to ignore dependencies that can never occur
- Data and control dependencies between variables are calculated
- All calls to sub-functions are taken into account
- Supports analysis of programs consisting of multiple compilation unit (source files)
- Supports analysis of delayed dependencies where values are stored in a variable and only fed to the output when the function is called again
- Verify your expected dependencies
- Ensure that there are no unwanted connections between input and output signals
- Track down and document all modules affected by an input signal
- Identify which code will be affected by code changes to minimize re-testing effort
- Document all dependencies for any required certification process
Dependency Analysis of AUTOSAR Software Components
Together with customers from automotive, we have implemented support for a use case so that our emmtrix Dependency Analyzer (eDA) can be used to extract and visualize the internal data dependencies between AUTOSAR R-Ports and P-Ports of software components (SWCs) by analyzing their internal behavior.
A typical development flow in automotive is the usage of AUTOSAR to specify different software components and runnable entities. Simulink and Stateflow are used to implement the actual functionality and TargetLink is then used to generate the C code for the target platform. All data exchange in the application is typically modelled using AUTOSAR Runnables while the source code of the runtime environment is generated at the end when all components are integrated.
eDA can be used to automatically analyze the generated C code regarding its data dependencies. The AUTOSAR model is used as basis to generate analyzable code and the results of the source code analysis are mapped back to the data prototypes, variables and SWC ports as defined in the AUTOSAR model. This approach allows the verification that in the generated C code, all data dependencies are according to the model and no undesired connections exist between input and output ports of the model.
Results can be exported in exchange formats like XML or JSON or visualized like in the image / in interactive graphical representations below.