Modern vehicles are rapidly developing into rolling computers – more and more features are based on software. The more complex such "software-defined vehicles" (SDV) become, the more difficult it is to keep the timing under control and avoid excessive latencies ("dead times"). The toolchain developed by EDAG and INCHRON allows the calculation of expected latencies and the identification of potential problem areas early on in the development phase.
In recent years, each new feature in a vehicle has been realized using its own decentralized control unit (ECU: electronic control unit). But this concept is now reaching its limits in several respects. At 120 or more ECUs per vehicle, the electrical and electronic (E/E) architecture reaches a complexity that is almost impossible to manage. Another disadvantage: adding new features requires a significant amount of effort and is only possible when the model is changed.
The end customer, however, expects the same flexibility that they are used to from their smartphone. This is why hardware and software must be separated. The solution is to replace the plethora of ECUs with just a few central high-performance computers (central HPC) that host all the important software components as apps. This also makes it possible for vehicles to acquire new features over their entire lifetime or to rent them in a subscription model, which means that the vehicle always remains "up to date". Zonal microcontrollers (zone µC) are responsible for the separation of hardware and software, transforming the electrical signals from the sensors and actuators into hardware-independent Ethernet signals.
Longer distances create timing problems
The use of centralized control centers in the SDV, however, also has a disadvantage that should not be underestimated, as the event chains, i.e. the series of consecutive processes that occur within a system and lead to a certain result, are becoming more complex themselves: both the number and the length are increasing.
This becomes particularly problematic if it causes the latencies of safety-relevant functions to increase, i.e. delays that arise due to additional time elements such as the zone µCs and transmission to the central HPC. But even with non-critical and comfort functions, such as the infotainment system, latencies are only acceptable to customers up to a certain degree. Lethargic vehicle functions and user interfaces are poison to customer satisfaction.
One challenge is to calculate possible latencies and detect problems as early as during the development process. This is where an important aspect comes into play: signal acquisition, transmission and processing seem to be continuous, when in fact they are not. The sensors, for example, are queried periodically, the data is processed on the CPU in fixed cycles, and the data in the networks is also transmitted in cycles. 
For this reason, it is possible in the event chains that a signal arrives just slightly too late at some point, so that the forwarding or processing does not take place until the next period – under certain circumstances, this effect may even occur several times within an event chain, so that the resulting waiting times add up to an unacceptable end-to-end latency (E2E latency).
Early control of latencies
A system design the keeps to specified latency times requires a consistent and closed chain starting from requirements management through to release. INCHRON and EDAG have developed an architecture design centered on the event chain, to record the required real-time behavior – E2E latency – along the actual causal dependencies early on in the development process. Real-time requirements can always be viewed, analyzed and tested in the context of the required target behavior. This ensures compliance throughout the entire development process.
Several steps have to interlock to achieve this. EDAG's architecture design defines a vehicle based on features, and models its static behavior using logical and physical event chains. Via an ARXML file, the EDAG model is transferred from PREEvision to the chronSuite tool developed by INCHRON. The timing behavior is simulated and checked there to see whether the specifications regarding the E2E latency can be met by the static model or not. Interactions are also taken into account, so that it becomes noticeable if the features, when considered in isolation, fulfill the requirements but hinder each other and thus cause timing problems.
Tough timing requirements for E2E latency, for example due to legal requirements, standards or safety-critical features, but also due to customer acceptance, can be analyzed and optimized before the first prototype vehicle is built. Initial event chain analyses and expected latencies can be carried out very early on in the project.
Case study: BBW and ABS
The information gained this way provides then the basis for the architectural design of a SDV. An example is shown in the event chains, brake-by-wire (yellow) and ABS (red), within the system boundaries of the BBW ECU (solid lines). The dashed lines indicate that the event chains outside this system must pass through further stations, usually physical ones. This includes the detection by the sensor, which does not happen at the same time as the start event during cyclic scanning, but also the actual implementation in the actuator.
The ABS processing step is not relevant for the BBW functionality, but it is the other way around, because the decision whether a braking command from the driver can be processed or whether a higher-prioritized request from a blocking wheel must be processed first can only be made here. The benefits of this separation are evident in the design decision on where to locate the ABS and BBW: due to the fast response time of ABS, only BBW can be moved to the central HPC. ABS must be split into four independent control loops, each with a zone µC.
Efficiency through an integrated tool chain
This example shows: the earlier latency risks are identified, the easier and cheaper it is to find a solution. For a software-defined vehicle comprising between 250 and 450 features, the toolchain developed by EDAG and now INCHRON can be used to define between 700 and 1400 event chains and to assign an E2E latency as a timing requirement.
Using this toolchain, it is possible to exchange event chains, including timing budgets, between PREEvision and chronSUITE in both directions via acollaboratively developed interface. As a result, scheduling analyses can be carried out by chronSIM in the early phases, while traces can be evaluated by chronVIEW in later phases.
As a result, necessary design decisions for SDV can be made early in the development process so that latency requirements are reliably met – whether for the realization of centralized, hardware-independent or even cloud-based features. In other words, security-related aspects and customer satisfaction are both covered.
Are you also faced with the task of meeting critical latencies in your development projects? Then contact Dipl.-Ing (FH) Mario Maul, expert in architecture and networks at EDAG Engineering, to find out how the architecture design centered on the event chain developed by EDAG and INCHRON, the associated tool chain, and the practical expertise of the two partners can be used to improve the efficiency of your development processes in the field of SDV. Or download our white paper "To keep YOU in control of the latencies in the SDV (and not the other way around)" right here. It reveals further details on the functionality and added value this solution offers. 
