EDAG Worldwide

    Vehicle Engineering
    br
    Brazil
    cn
    China
    gb
    Great Britain
    it
    Italy
    jp
    Japan
    my
    Malaysia
    mx
    Mexico
    nl
    Netherlands
    se
    Sweden
    pl
    Poland
    ch
    Switzerland
    es
    Spain
    cz
    Czech Republic
    hu
    Hungary
    us
    USA
    Production Solutions
    br
    Brazil
    cn
    China
    in
    India
    mx
    Mexico
    se
    Sweden
    cz
    Czech Republic
    hu
    Hungary
    us
    USA

    tech insights

    Vehicle IT without latency problems

    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. textbild-1-latenzen-im-sdv

    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

    textbild-2-latenzen-im-sdv-enThe 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 talk to our experts from EDAG Engineering, Mario Maul, expert in Architecture & Networks, and INCHRON, Florian Mayer, timing expert for automotive embedded software, about how the jointly developed effect chain-centered architecture design and the associated toolchain, as well as the practical know-how of the two partners, can make your development processes in the field of SDV more efficient. 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. Whitepaper Latenzen im SDV EN

    Download white paper now
    Schedule  an Expert  Call >>

    Related Post

    A parking assistance system really comes into its own when parking spaces are cramped and awkward. To ensure that the assistant will not simply shut down or drive back and forth dozens of times, the systems need to be validated and optimized in extensive test series. This takes time and money. EDAG has now come up with an alternative: the...

    >> Read more
    As cars and commercial vehicles become increasingly connected, cybersecurity risks increase as well. As a result, from July 2024, new vehicles will only be registered in the EU if their manufacturers can guarantee secure operation with appropriate solutions to ward off attacks and to detect and eradicate vulnerabilities. The importance of...

    >> Read more
    Purchasers of electric cars have accepted that "refueling" takes longer than for a vehicle with a combustion engine. What is especially annoying, however, is when problems arise at the charging station, wasting even more time before the charging process even starts. Plug & Charge can help to remedy this situation. Interoperability requirements,...

    >> Read more
    EDAG Logo

    EDAG

    Kreuzberger Ring 40, 65205 Wiesbaden
    p +49 661 6000-0 f +49 661 6000-223