EN 
DE Authors: Olaf Schmidt, Dr. Ralf Münzenberger, Philip Rehkop, INCHRON GmbH; Armin Stingl, iSYSTEM GmbH; Michael Reiß, Elektrobit GmbH
Contribution – Embedded Software Engineering Congress 2018
Highly automated and autonomous driving requires significant computing power, necessitating the integration of high-performance controllers based on the AUTOSAR Adaptive Platform with electronic control units (ECUs) based on the AUTOSAR Classic Platform. From the outset, it is crucial to design and test end-to-end functional chains spanning all ECUs within the project. This paper comprehensively demonstrates the synergy between AUTOSAR Classic and Adaptive Platforms, static and dynamic architectures, and simulation and measurement on the target system. It is a collaborative effort between Elektrobit, iSYSTEM, and INCHRON.
motivation
The requirements for the electrical/electronic (E/E) architecture in vehicles have changed due to current trends such as automated driving and electromobility. Automated driving, in particular, demands increasingly powerful electronic control units (ECUs) that use information from various input sources to calculate automated driving responses, for example. The calculated environmental model of the vehicle should also be usable by other driving functions.
The aforementioned requirements are difficult to implement in a classic E/E domain architecture. Instead, a centralized E/E architecture is used, in which the various smart sensors, actuators, and other ECUs in the vehicle are connected to only a few, but very powerful, high-performance controllers. This ensures high flexibility and allows vehicle functions to be dynamically distributed across these high-performance controllers.
See Figure 1: Domain Architecture and Figure 2: Centralized Architecture (PDF)
In a centralized E/E architecture in the vehicle, there will be a large number of interaction chains between high-performance controllers and the "classic" control units. The overall functionality results from the interaction of both platforms. This requires considering the real-time requirements of the overall system and the interaction chains along the data flows from sensor to actuator, including service-oriented aspects. Communication.
Simulation is used to verify the timing behavior of components along the causal chains. Data flow causal chains represent data that is considered along a process chain. Besides the content, these often have temporal requirements such as latency, process sequence, and data age.
During implementation, traces are recorded from the running control unit. The timing requirements are checked in the simulation and the traces (implementation). This allows requirements to be designed and tested early on, and the implementation to be verified later.
This paper describes the process using an example where a sensor is implemented on an ECU with a Classic platform and connected via Ethernet to an ECU with an Adaptive platform. The functional chains are designed, simulated, and tested in advance, and then the requirements are tested again with the implementation. This interaction requires new tools and integrations on the ECU software side, as well as tracing tools and simulation & analysis capabilities. Through the collaboration of Elektrobit, iSYSTEM, and INCHRON, an integrated solution has been developed for customers that spans both the Classic and Adaptive platforms.
AUTOSAR Classic vs. Adaptive Platform
The ECU architecture was previously based primarily on the AUTOSAR Classic platform. The AUTOSAR Classic platform uses a static operating system based on the OSEK operating system (Open Systems and their Interfaces for Electronics in Motor Vehicles), which AUTOSAR has extended with several functionalities. While such a static approach is very helpful for developing safety-critical functionalities and sufficient for smart sensor/actuator ECUs, it doesn't provide the desired flexibility. Therefore, the AUTOSAR Classic platform was supplemented with the AUTOSAR Adaptive platform. Unlike the Classic platform, AUTOSAR does not specify its own operating system for the Adaptive platform. Instead, it requires the use of a POSIX operating system (POSIX Profile PSE51). This means that Linux, which is already used in the automotive sector, for example in infotainment systems, is also available as an operating system for the Adaptive platform.
In summary, the various requirements suggest that both AUTOSAR platforms will be used in a centralized E/E architecture. This naturally raises the question of how data can be exchanged between the Classic and Adaptive platforms. Both the Classic and Adaptive platforms support the principle of service-oriented communication. Communication takes place via Ethernet, replacing the previous signal-based communication used on the automotive communication buses CAN, LIN, and FlexRay. Data is only exchanged between electronic control units (ECUs) when services offered by one ECU are required and consumed by other ECUs. The protocol used is SOME/IP (Scalable Service-Oriented Middleware over IP).
Demonstration project
The demonstration project set up by Elektrobit, INCHRON and iSYSTEM is intended to take these aspects into account.
See Figure 3: Demonstration project (PDF)
A sensor-based ECU, running Elektrobit's Classic Platform software (EB tresos), reads a button press and derives a speed signal from it. The "speed signal" service is offered to other control units via "Service Discovery." An Infineon AURIX TC39x serves as the hardware platform.
A second ECU – the high-performance controller – subscribes to the "speed signal" service and then receives this signal. The SOME/IP protocol is used for transmission. The current speed is displayed on a speedometer. The high-performance controller software is based on the Adaptive Platform solution and the Linux distribution from Elektrobit (EB corbos). A Renesas R-Car H3 serves as the hardware platform.
Chains of effects and architectural levels
Data flow chains should be considered consistently across all architecture levels throughout the entire vehicle and control unit development cycle.
Initially, sensors and actuators for the customer function are connected at the customer function level, and the latency times are defined.
At the functional level, customer functions are broken down into blocks that process sub-functions sequentially or in parallel. Each of these functions is allocated a time budget along the chain of effects and can be tested in the simulation.
The functions are distributed across various control units at the OEM system level. These control units are interconnected via different buses. The time budgets must be allocated accordingly along the functional chains to the control units and communication times.
Within the ECU system, the focus shifts to a single control unit and its functions and interaction chains. This involves examining various CPUs, SoCs, cores, and ECU-internal buses.
At the software architecture level, it is defined how the functions/runnables are distributed across tasks and ISRs, and the parameters (core allocation, priority, etc.) of these elements are set. Since scheduling is taken into account in the simulation, net execution times must be derived from the previously defined time budgets.
At every level, simulation and testing can be used to examine the causal chains and requirements of the overall system. Virtual verification allows test cases to be derived during the implementation and testing phases that would not be feasible on a physical control unit.
In the demonstration project, causal chains on OEM system, ECU system and software were combined and simulated in a chronSIM model:
See Figure 4: Simulation of the causal chain with INCHRON chronSIM (PDF)
Synchronous measurement of parallel running processors (iSYSTEM)
Measurement setup
The temporal behavior of the chain of effects is examined in both processors using on-chip trace logic.
The Infineon TC39x uses the Multi-Core Debug System (MCDS) for this purpose. The DAP interface is chosen as the interface between the processor and the trace tool.
The Renesas R-Car H3 processor implements ARM's CoreSight components. Each core features an embedded trace macrocell (ETM), although the ETM of the A5x cores only supports instruction tracing and not data tracing. The R-Car also includes a system trace module (STM). The ARM High-Speed Serial Trace Port (HSSTP) serves as the trace interface.
To achieve time-synchronized tracing of both processors, the iSYSTEM iC5700's internal timestamps are synchronized with each other. An optional sync port allows two iC5700s to be connected.
See Figure 5: Measurement setup consisting of two time-synchronized iSYSTEM iC5700 on-chip analyzers (PDF)
Efficient tracing using code instrumentation
On both processors, the available trace bandwidth plays a crucial role. The most obvious trace method for event chain analysis seems to be function profiling based on instruction tracing. A more efficient alternative is to signal only the truly relevant events. This means the trace only generates data to temporally mark relevant events, such as the entry and exit of relevant functions within the event chain or OS context switches.
On the Classic Platform ECU, instrumentation-based OS tasks and ISR2 tracing are quite easy to implement, as the OS already implements the corresponding trace hooks. These hook macros only need to be replaced with trace-tool-specific code. For instrumentation-based tracing of runnables, the Virtual Functional Bus (VFB) tracing hooks of the RTE are used.
On the Adaptive Platform ECU, instrumentation-based tracing of OS kernel events, adaptive components such as ARA:COM, and the application is achieved by allowing direct write access to the STM stimulus port. This is accomplished through minimally invasive code instrumentation of the Linux kernel. Both OS process/thread states and the execution of functions within the chain of effects are signaled via dedicated STM channels.
Configuration of the measuring tools
Trace configuration
In the TC39x of the Classic Platform ECU, the trace instrumentation code writes the relevant information, i.e., Task IDs, ISR2 IDs and Runnable IDs, into three specially allocated global variables, which are observed by the Data Trace Unit of the MCDS and communicated to the trace tool via the DAP interface.
The R-Car uses the System Trace Macrocell (STM). Data, such as OS Process/Thread Handles or Function IDs, is written to a so-called Stimulus Port of the STM. Such a write access initiates an STM Trace Message, which consists of the STM Channel ID, Data Payload, and Timestamp. The STM Trace Messages are sent to the trace tool via HSSTP. The STM's Stimulus Port is divided into channels. The Channel ID can be used to signal different types of events to the trace tool. For example, Function IDs can be signaled via Channel 2, while OS Thread ID signaling uses Channel 1.
Profiler configuration
Profiling involves interpreting the recorded trace data. The critical aspect here is defining the interpretation rules. In the case of the iSYSTEM profiler, this can be done using an XML description. Profiler objects can be defined, for example, to inform the profiler that the ID of the executed function is signaled via STM Channel 1.
Figure 6 (see (PDF) shows an iSYSTEM Profiler timeline representation of the chain of effects within the AUTOSAR Adaptive ECU, including relevant OS threads and functions.
The results of the trace/profiler analysis can be exported, for example, in the so-called Best Trace format (BTF). This BTF format can be read by many timing analysis/modeling tools, such as the INCHRON Toolsuite.
Testing of the action chains
INCHRON chronVIEW tests the traces based on time requirements. Furthermore, simulation enables virtual testing by creating scenarios using stochastic or what-if analyses that would be impractical to test on the real target. This results in increased test depth.
Summary
The interplay between AUTOSAR Classic and Adaptive Platforms will determine the architecture of future vehicles.
Firstly, it is important that the software components and tools used are optimally coordinated. This includes the areas of architecture/design, ECU basic software, and measurement tools.
On the other hand, focusing on the design of causal chains in the early stages of development guarantees the avoidance of timing problems.
Bibliography
[1] Thomas Bock, Dr. Henning Kleinwechter (Volkswagen), Dr. Ralph Sasse (OpenSynergy), Armin Stingl (iSystem), Dr. Ralf Münzenberger, Philip Rehkop, Olaf Schmidt (INCHRON): Use of virtualization for secure software architectures, ESE Congress 2017
authors
- Olaf Schmidt, INCHRON GmbH, Business Development, olaf.schmidt@inchron.com
- Philip Rehkop, INCHRON GmbH, Professional Services Engineer, philip.rehkop@inchron.com
- Dr. Ralf Münzenberger, INCHRON GmbH, CEO and Co-founder, ralf.muenzenberger@inchron.com
- Armin Stingl, iSYSTEM AG, Systems Engineer, armin.stingl@isystem.com
- Michael Reiß, Elektrobit Automotive GmbH, michael.reiss@elektrobit.com
Automotive – our training & coaching
Do you want to bring yourself up to date with the latest technology?
Then find out more here MircoConsult offers training courses/seminars/workshops and individual coaching on the topic of automotive/embedded and real-time software development.
Training & coaching on the other topics in our portfolio can be found here. here.
Automotive – Expertise
Valuable expertise in automotive/embedded and real-time software development is available. here Available for you to download free of charge.
You can find expertise on other topics in our portfolio here. here.
