emmtrix
Dependency
Analyzer (eDA)

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.

Use Cases

Enhancing Emissions Compliance

In response to the 2015 emissions scandal, global regulatory bodies have significantly strengthened the requirements for vehicle emissions compliance and the integrity of On-Board Diagnostics (OBD) systems. Key authorities such as the Environmental Protection Agency (EPA) in the United States, the California Air Resources Board (CARB), and equivalent bodies in the European Union, under frameworks like the Euro Norms, are at the forefront of enforcing these enhanced regulations. Automobile manufacturers are now mandated to rigorously demonstrate that their vehicles, particularly the OBD software, are devoid of any manipulations and adhere to the prevailing emissions standards. This rigorous demonstration includes the submission of comprehensive documentation detailing the operation of their OBD systems. Such documentation must encompass thorough descriptions of the algorithms deployed for monitoring emissions, ensuring transparency and accountability. This step is crucial in rebuilding trust in automotive compliance and ensuring that vehicles on the road minimise emissions, aligning with initiatives like the Emission Neutral Default Action (ENDA) to mitigate any adverse environmental impacts.

The issue: Auto manufacturers face the challenge of ensuring their OBD software is fully compliant with stringent emission regulations. This entails not only adhering to legal requirements but also maintaining transparency and traceability in how the software manages and influences emissions. With regulatory scrutiny intensifying, manufacturers need a reliable method to analyze and document the behavior of their OBD systems under various conditions. 

The solution: emmtrix Dependency Analyzer offers a groundbreaking solution for auto manufacturers seeking to navigate the complexities of emissions compliance. This static code analysis tool delves into the source code of OBD software, mapping out how specific input variables affect emission outputs. By identifying the intricate relationships between different components and variables, emmtrix Dependency Analyzer provides an unparalleled level of insight into the software’s operational logic. 

Freedom from Interference Analysis

In the development of safety-critical automotive software, ensuring the integrity and reliability of systems across varying levels of safety requirements is paramount. The emmtrix Dependency Analyzer offers a sophisticated solution to address the challenges associated with ensuring “Freedom from Interference” between components operating at different Automotive Safety Integrity Levels (ASILs). This use case outlines how the emmtrix Dependency Analyzer can be applied to identify and manage potential interference risks, thereby supporting compliance with ISO 26262 standards.

The issue: In modern automotive systems, software components with different safety requirements often share resources, such as CPUs, memory, or I/O systems. This shared environment raises the risk that lower-criticality components might interfere with the functioning of higher-criticality components, potentially leading to safety hazards. Ensuring freedom from interference is a regulatory requirement and critical for achieving functional safety certification under ISO 26262. However, manually identifying potential interference paths and ensuring isolation between components of different ASIL levels is both time-consuming and prone to human error.

The solution: emmtrix Dependency Analyzer automates the process of identifying and analyzing dependencies between software variables across different ASIL levels. By performing a comprehensive static code analysis, the tool maps out how each variable influences others, creating a detailed dependency graph that highlights potential interference risks between components of varying criticality.

Event Chain Analysis

In today’s complex software environments, understanding the dependencies and interactions between different parts of a system is critical. The emmtrix Dependency Analyzer is designed to address this challenge by providing deep insights into how variables within individual runnables influence each other across time. This use case explores the application of the emmtrix Dependency Analyzer for conducting an Event Chain Analysis, a method crucial for identifying and managing risks in software development projects.

The issue: In large-scale software projects, especially those involving real-time systems, it’s common to encounter issues related to timing, sequencing, and dependencies between tasks. Developers and project managers often struggle to trace how changes in one part of the system can affect others, potentially leading to unforeseen delays, bugs, or system failures. Without a detailed understanding of these dependencies, mitigating risks and ensuring system reliability becomes a shot in the dark.

The solution: emmtrix Dependency Analyzer offers a powerful solution by enabling users to perform a detailed analysis of dependencies within their software. By focusing on individual runnables, the tool can identify how changes in input variables affect output variables, including the detection of delay elements that indicate when a variable change will impact the system in the next time step. This capability is invaluable for constructing an accurate Event Chain Analysis, which is essential for risk identification and management.

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

Additional Support