Model-based architecture development and simulation

Practical example of driver assistance with AMALTHEA and chronSIM

Authors: Thomas Jäger, Robert Bosch GmbH, Ingo Houben, Dr.-Ing. Ralf Münzenberger, INCHRON GmbH

Contribution – Embedded Software Engineering Congress 2015

A model-based approach, where further process steps are derived from a single source, offers many advantages. The AMALTHEA system model serves as the starting point for designing a robust, dynamic system and software architecture, as well as generating source code and test cases. This article presents a workflow for simulating, analyzing, and optimizing an architecture based on an AMALTHEA system model, particularly in the event of errors.

motivation

The development of driver assistance systems, whether solutions on individual electronic control units (ECUs) such as a camera, or networked systems of multiple sensors and control computers, begins with the conceptualization of the system design and is refined in the resulting software architecture. The challenges lie in mastering the underlying parallel hardware, such as multicore processors, or the concurrency of entire ECU networks. Consequently, the various logical paths of data processing on such systems run in parallel and exhibit synchronization points as well as branching during information compression. Computing times are usually not constant, and call cycles are sometimes physically bound to the sensor or actuator, meaning that a uniform processing frequency is not possible.

The parameters for developing such a system are diverse and, moreover, do not have a static distribution over time. Therefore, support from suitable tools is essential to manage and understand the complexity and variability during system and software development. In particular, the dynamic aspects can only be examined and clarified with the development team and the customer through appropriate visualization.

The requirements for the tool are determined by the diverse application scenarios. Specifically, these are:

• Visualization of static aspects, such as logical data paths
• Visualization of dynamic aspects, such as synchronization of different frequency responses
• Investigation of temporal latencies of data paths (causal chains) and their fluctuations over time
• Investigations into resource utilization such as storage bandwidth or computer utilization (static and over time)
• Identifying design flaws early in the development phase
• Optimization of data paths in the context of the overall system
• Visualizations for training purposes, to clarify problems and as a basis for discussion
• Tool-supported analyses, such as reviewing time requirements and identifying potential optimizations.
• Derivation of test cases; generation of test cases
• Generation of reports and views
• Generation of simulations
• Generation of the control unit code
• Exchange of design models (with developers, customers, tools, etc.)

To prevent inconsistencies in use cases, a single-source approach, as enabled by the AMALTHEA system model, is desirable. In particular, end-to-end traceability is required for requirements, code generation, and test cases.

AMALTHEA

AMALTHEA [1] supports the aforementioned use cases as an open, standardized format for system and software description (Figure 1, PDFIt includes a metamodel whose instances can be serialized in XML. Furthermore, it provides a powerful development environment via the Eclipse platform for working with instances of the XML data models. This allows for the implementation of arbitrary model transformations using Java and Xtend programming.

The individual aspects are presented and practically explained below using the example of a simplified architecture of a camera system.

Application example

The system architecture comprises an imager chip for image acquisition and an integrated module with multiple processing units. These are specialized computers for image preprocessing (preprocessing, feature calculation, and classification) and freely programmable cores. Each osek-scheduler is assigned to exactly one processing unit, such as Sch_Osek_2 dem Core_2 on the microcontroller SOC (see Figure 2, PDF).

Task modeling

The individual logical processing steps can now be assigned to the computing units, as shown in Figure 3 (see PDF). The scheduler Sch_Osek_2 This task involves task_2 linked. This task is triggered periodically by a 40ms time trigger. The task contains the runnable. runn_merge called up.

ISRs and other tasks can be modeled in the same way. All tasks of a scheduler compete for processing time on the same processing unit, while tasks from different processing units can be executed in parallel.

Data flow and functional behavior

Furthermore, it is possible to model the logical data relationships between runnables. Figure 4 (see PDF) receives the runnable runn_merge as input objects from the Runnable runn_algo and classification results from the Runnable runn_hwclass and provides a fused scene description as output for Runnable to the function calculation. runn_func.

An overview of the logical data relationships in the modeled system can be generated as a UML diagram using the AMALTHEA framework (Figure 5, see PDF).

Typically, temporal requirements are defined for a logical data flow (see Figure 5) that must be met during implementation. Typical real-time requirements include, for example, maximum and minimum latency, data loss, or data synchronization, as described in [3].

A purely static analysis of the logical data flow by summing the individual latencies of blocks and edges is insufficient, as it fails to consider the effects of task scheduling or interruptions of ISRs, nor inter-core communication, or communication between processing units in general. A dynamic analysis of system behavior based on a timing model is necessary for this.

Analysis results

In Figure 1 (see PDFSimulation and visualization of dynamic system behavior were identified as important applications of AMALTHEA. The necessary timing model is automatically generated from the AMALTHEA system model.

The resulting timing model was loaded into the INCHRON tool suite [2] and analyzed using the real-time simulator chronSIM. This simulator displays the real-time behavior of the system under investigation from various perspectives. In addition to single-core and multi-core systems, distributed systems with multiple processors can also be analyzed, communicating via simulated CAN and FlexRay buses, Ethernet, or other bus systems.

Figure 6 (see PDFThe diagram shows the data flow in the system under investigation. It depicts the tasks on the various processing units, identifiable by the colored bars on the left. Each row shows the current operating system state of a task. The curved connections represent the logical data flow between the runnables executed within the tasks.

From Figure 6 (see PDF) it is evident that the temporal course of the data flow deviates from the linear representation in Figure 5 (see PDF) differs significantly: The overlapping pattern arises because more than one set of image data is processed in the system at any given time.

In the timing model, the logical data flows are modeled as so-called event chains. These are treated like data in the model and passed on between the individual actors (runnables, tasks, but also bus messages).

Based on the event chains, the latencies of processing chains can be analyzed (Figure 7, see PDFTo do this, a real-time request is defined from the first to the last step of the event chain and displayed as a histogram. The example shows that most of the measured values fluctuate within a defined range, while almost 18% are significantly shorter.

This makes it easy to quickly identify where the designed concept has errors or bottlenecks (see causal chain diagram in Figure 8, PDF) and processing chains may not be completed to the end, and how such errors can have such an effect that data consistency is no longer guaranteed in the following.

The investigations and analyses now provide clues as to why a violation or bottleneck occurred. To this end, the user defines real-time requirements that are automatically evaluated, saving the user the tedious manual search in the causal chain diagram. Figure 9 (see PDF) shows the data flow request Breakdown of the chain of effects. In 17.6% of the cases, the data flow does not complete. The proportion of errors corresponds to the latency distribution in Figure 7 (see PDF).

The latency histogram of the data flow from Figure 7 (see PDF) also helps with error analysis: In detail, it can be seen that the 17,6% broken action chains form a cluster point, and the successful action chains are evenly distributed over a range of 33 ms.

Therefore, of the data delivered every 33ms, only approximately 82.4% are used on average. Calculating the average evaluation period as 33 / 0.824 = 40.05ms, we find the sampling rate of 40ms for the runnable. runn_merge from Figure 3 (see PDF), which is modeled with a 40ms period.

This identifies the cause of the data dropouts: they are due to undersampling of the input signals during the merge step. One way to counteract this is to adjust the sampling rate, for example, by setting the sampling time trigger from 40 ms to 20 ms. The automated evaluation of the data flow request immediately shows the effect (see Figure 10)., PDF): All data flows run to completion; no data inconsistencies occur.

The dynamic effects of the design changes are visualized in various diagrams and can thus be understood. Figure 11 (see PDFThe graph shows the impact on the causal chain processes. Data gaps no longer occur.

Since the results of the simulation analyses and the design changes are made in the central AMALTHEA model, consistent continuity is ensured from the modified system design, through further simulation and visualizations, customer reports to the control unit code and testing.

Summary

This article describes a workflow for executing key process steps based on the AMALTHEA system model as a single-source resource. Modeling logical data flows (event chains) and verifying real-time requirements are central components of this workflow. A significant advantage of this systematic approach is that timing errors can be detected early in the design phase, which would otherwise only be found late in the development process through hardware testing and debugging. Through simulation, timing errors were detected up to 12 months earlier, their causes were understood through appropriate visualization, and they were efficiently resolved.

Bibliography

[1] AMALTHEA: An Open Platform Project for Embedded Multicore Systems

[2] INCHRON Tool Suite

[3] T. Kramer, R. Münzenberger: Modeling and real-time analysis of complex causal loops in driver assistance systems, 3rd Autotest, FKFS, October 2010.