emmtrix
Dependency
Analyzer (eDA)

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.

Your Benefits

• 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.