Managing real-time platforms for ADAS and automated driving
March 17, 2016 by John Day
By Dr. Kai Richter, Maurice Sebastian, Sean Whitty and Jonas Diemer of Symtavision (now part of Luxoft)
The move towards ADAS and automated driving marks a milestone in the history of the automotive industry, which possibly (some say most likely) will revolutionize passenger traffic worldwide. From a technical perspective, we are also seeing significant changes being caused by the arrival of new components and by totally new system and software architectures. As a consequence, new business models and new providers are beginning to emerge particularly in the areas of hardware/software and system integration.
In terms of in-vehicle communications, Ethernet is fast becoming the preferred standard for future E/E architectures in the age of ADAS and automated driving. However, high bandwidth alone does not guarantee reliability and cost optimization. These goals can only be achieved through the optimal use of Ethernet’s capabilities while also carefully considering system and software requirements during design and implementation.
Automated driving, however, is not something that can be achieved in a single step. Worldwide, the process is divided into five classes: In class 1 and 2 (assisted and partial automated driving), the driver is ultimately responsible for a safe ride and must at least control the vehicle. In the higher classes 3 to 5, the vehicle itself assumes overall control and is able to regulate some or even all driving situations.
From a component perspective, there are a lot of new sensor types, such as laser scanners, used in today’s vehicles as well as new, complex software for object recognition, lane detection and communication. Some of this information is displayed in HUD-format on the inner windshield as “augmented reality”. This is the same data that is used during automated driving procedures in order to analyze and predict the current traffic situation and to make driving decisions, which influence the basic functions of the car like accelerating, breaking, steering, or (new!) waking up the driver to assume control.
These innovations can only be delivered by increasing software content and a massive growth of computing power. In the area of simple assistance functions as well as in automated driving, totally new hardware platforms are emerging with levels of computing power far exceeding that currently available in vehicles by at least one dimension. One such example is NVidia’s Drive PX Platform (http://www.nvidia.com/object/drive-px.html), which establishes the company as new player in the area of vehicle control systems. Such platforms integrate a variety of AUTOSAR and non-AUTOSAR components with further co-processors for video- and object-processing as well as machine learning and communication. Different operating systems and software architecture concepts are used in this context in parallel and previously independent domains, like chassis, powertrain, instrument cluster, etc., increasingly growing together. This results (partly like in the five steps described above) significant changes for the E/E topologies (finally!): the increasing numbers of decentralized ECUs being replaced by a few central high-performance computers connected to hundreds of sensors and actuators in the entire vehicle.
Figure 1: Future E/E architectures will consist of fewer, but very powerful ECUs.
Cleary, architecture is the hot topic: In the near future, Ethernet will dominate vehicle communication in the whole car as well as within the central ECUs and for the all data such as sensor signals, video, object data, multimedia, and control signals for actuators, which run on CAN, LIN, or FlexRay today. Also, the software architectures will change. Topics like virtualization and hypervisor have become very popular in order to make the porting and integrating of software easier and to ensure safety requirements, such as freedom of interference and partitioned scheduling.
Complexity and System Integration
One of the greatest challenges is the large number of dependencies within a system. In particular, the high level of integration of many software components onto few hardware components (CPUs and network connections) leads to resource conflicts and mutual influences, which must be well understood and reliably managed in order to optimize the use of the described technologies and components. More software always means more communication and coordination between the – usually networked – software parts.
In this context, co-ordination means:
• Executing software at exactly the right time;
• Making the executable components and necessary data (CPU load and bus load) available at exactly the same time;
• Executing communication software components in the right order and fast enough (schedule and event chains); and
• Ensuring that software components do not disturb each other (safety and security) etc.
For traditional architectures with OSEK and AUTOSAR software, as well as CAN, LIN, or FlexRay busses, the questions concerning architecture and real-time aspects are now well understood. System developers are able to predict the real-time behavior of single ECUs or the communication within a combination of ECUs using appropriate timing models, as well as monitor this behavior continuously during software development and integration by time measurement and hence are able to make corrections, if necessary. In the Ethernet domain, however, all OEMs and Tier-1s are still in the learning phase.
Ethernet is used as a communication backbone for object data and control signals in almost all established reference platforms for driver assistance and automation, and will also soon be used for the communication between the few remaining ECUs (see Figure 2 – level 5). Thus, many control signals that are exchanged via CAN and FlexRay today will be migrated to Ethernet. While the busload bottlenecks known in the CAN world will no longer exist (the entire communication over a CAN bus at 100% load requires only 2% of the available bandwidth in an Ethernet architecture), at least two further questions concerning the real-time behavior – communication latencies and software overhead – will remain, or even get worse.
Figure 2: AUTOSAR socket adapter
The signal runtimes, which describe the delay between sending a signal and receiving it at a different position, are only partly dependent on the bus speed and also influenced by the chosen packaging and trigger mechanisms. In contrast to the relatively simple PDU concept in the CAN world, Ethernet offers a much greater variety of configuration options.
Packaging in this context means combining several signals into a larger unit. So far (AUTOSAR and CAN), fixed (static) mappings from signals to PDUs and from PDUs to CAN frames have been used. Ethernet allows (for instance via the AUTOSAR Socket Adapter, see Figure 2) the dynamic packaging of PDUs or signals into Ethernet frames (see Figure 3), in order to transmit only the PDUs where the input data has changed.
Figure 3: Visualization of static (above) and dynamic (below) packaging for signal-based (left) and PDU-based (right) configuration. The latter usually delivers the best results, but has to be optimized in detail.
Whereas packaging describes how signals are combined, triggering means the activation of the actual transfer of the Ethernet frame. Besides the three usual triggers for CAN frames – cyclic, event-driven (direct in AUTOSAR) and mixed – Ethernet, with its dynamic packaging options, effectively delivers a number of further hybrid trigger options, for example by time-outs of the updated PDUs, potentially also combined with reaching specified maximum buffer capacities. The frequently mentioned classification of the Ethernet world into time- and event-triggered does not really reflect this variety of options.
Currently, OEMs are experimenting with several strategies using appropriate timing models and timing analysis tools, as in the established AUTOSAR world with CAN and FlexRay communication. Hence, different network configurations can be analyzed concerning their real-time capability in advance, and consequently optimized in respect of specific requirements. The following criteria are particularly important from a timing point of view:
• CPU load of the sending ECUs;
• CPU load of the receiving ECUs; and
• End-to-end delays of signals.
Figure 4: Comparison of different packaging and trigger strategies concerning CPU load: Grouping by cycle times (CYL), grouping by receivers (RX – unicast), grouping by receiver groups (RXGROUP – multicast).
Results from experimental studies (for example by Audi Electronics Venture GmbH, Paper: “Finding Good Ethernet PDU Packaging Strategies to Minimize ECU Performance Requirements – A Case Study” presented at the Automotive Ethernet Congress 2016 in Munich, Germany) show three aspects in particular. Firstly, the dynamic packaging of signals (accurately configured) leads to fewer frames on the whole and therefore to a basic CPU load reduction of the involved ECUs and to a lower network load. Secondly, there are, nevertheless, no universal optimal dynamic packaging and trigger strategies that can be recommended in any case. In fact, the evaluated strategies all have advantages as well as disadvantages:
• In particular, the dynamic packaging using grouping by cycle times (named DYN-CYL-GR in figure 5 and 6) leads to especially short signal delays, but can increase the CPU load significantly depending on the concrete specification.
• Packaging with fixed cycle times (DYN-CYL) reduces the CPU load significantly on one hand, but leads to much higher signal delays on the other hand.
• Packaging by receivers (DYN-RX) delivers short delays as well as low CPU load, but requires a completely new configuration of all ECUs if only one receiver is added or removed, and thereby violates established platform design rules.
Finally, it must be considered that dynamic packaging increases complexity and decreases predictability in general. Therefore, a static and cyclic variant can also make sense for safety-critical communication, as it is easier to qualify and verify.
Figure 5: Comparison of end-to-end delays of different signal paths in the evaluated system.
Figure 6: Comparison of the ECU CPU loads of the evaluated system.
Clearly, if dynamic packaging is used, the complexity of the system architecture and the real-time behavior grows with the number of options for the specification of communication strategies. While this makes it possible to take good advantage of resources, it is at the expense of understandability and hence also safety of the whole system. Therefore, related design decisions, or even the definition of design rules for Ethernet-based signal communication, has to be planned and evaluated extremely carefully. As unfortunately there is no common “best practice”, this planning definitely has to take into account the related constraints such as latency requirement of functions, platform concept, existing design rules, and the current use case. The different strategies can be efficiently compared by real-time analysis using timing models in order to finally select the optimal complete configuration for an existing car model or platform architecture.
Managing the Challenge
Besides networks, the software domain is also changing for ADAS ECUs. Software components from previously strictly separated domains (chassis, power train, driver assistance, automation) will be integrated into one ECU with a heterogeneous mix of software concepts and operating systems. In contrast to the past, these will no longer run on different ECUs, but will share a small number of high-performance CPUs within one ECU. Also in this context, appropriate static and dynamic concepts for partitioning, integration and scheduling will be necessary; key words are virtualization and hypervisor. Again, there is not much experience in these areas yet. Also, related timing models and analysis tools provide the basis for the optimal resource usage and reliable integration.
In addition to new software functions, new technologies, system architectures and integration options must be properly managed, using appropriate timing modeling to capture requirements and to analyze real-time capabilities at the system level. This will be the only way to eventually bring innovative driver assistance and automated driving functions, which are already or will be available in the near future for premium vehicles, cost-effectively and reliably into the volume model market.
# # #
Symtavision®, now part of Luxoft Inc, provides market-leading tools and associated consulting/engineering services for system-level timing design and timing verification – from early-phase estimation to final verification. Symtavision’s tools are used extensively in automotive electronics with support provided for all industry standards as well as a variety of other industry sectors including the aerospace, automation, multimedia, telecommunications and transportation markets. Symtavision is headquartered in Braunschweig (Germany) with subsidiary offices in Munich (Germany), Cologne (Germany) and Troy (Michigan, USA), and is supported by a global network of distributors. Symtavision is an AUTOSAR development member and also a founding member of the Real-Time Experts Alliance. For more information, visit: http://www.symtavision.com.
About the Authors:
Dr. Kai Richter is the CTO at Symtavision (now part of Luxoft).
Maurice Sebastian is an Applications Engineer at Symtavision (now part of Luxoft).
Sean Whitty is an Applications Engineer at Symtavision (now part of Luxoft).
Jonas Diemer is a Solutions Architect at Symtavision (now part of Luxoft).