DEVELOPMENT DRIVER ASSISTANCE SYSTEMS Automated Driving Necessary Infrastructure Shift The current driver assistance functions such as automated parking or traffic jam assistants and lane departure warning systems for the highway are the first steps on the way to automated driving. But today s system architectures are already reaching their limits in terms of the driving functions expected in the coming years. The growing interconnectivity of control devices and their increasingly complex functions require an integrated system approach with regards to development and a cross-functional, cross-vehicle software platform. Elektrobit provides proposals for future approaches. EB 42 AUTHOR Dipl.-Ing. (M.Sc.) Karsten Hoffmeister is Senior Manager at Elektrobit in Erlangen (Germany). TRADITIONAL DEVELOPMENT DOES NOT WORK ANYMORE Many driver assistance functions are already available today. But according to the law, drivers are still not permitted to rely on this system completely. If an error occurs (e.g. a sensor fails), they must be able to regain control immediately. The driver assistance functions of the future will give drivers new freedom. They will be able to divert their attention from traffic and attend to other activities. They will be permitted to release the steering wheel, activate their assistance function and also make a video call in a traffic jam instead of paying full attention to the traffic. Systems such as the traffic jam assistant [1] that Audi has announced for 2017 will give drivers more time to take control. Initially, drivers will have up to 10 s to take control of their vehicles again. However, drivers will be explicitly allowed to pay attention to other things
while the assistance function is active. This means that they will not be available if a failure occurs. During this time, the vehicle system will be responsible for avoiding or handling dangerous situations. This apparently short period of 10 s will require profound changes in the system architecture. The systems must change from fail silent to fail degraded or even fail operational. They will not be able to simply shut down in case of error until they have given control to the driver. Instead, they must maintain a minimum level of functionality to guarantee the safety of the vehicle and the people in it, FIGURE 1. The vehicle infrastructure, hardware and software must all be engineered to remain capable of working even in case of error. For the first functions, the emergency functions can have a rudimentary scope, for example, coming to a safe, slow stop with warning signal flashers. This safe state is adequate in traffic jams but in normal traffic, the system would have to safely drive to the nearest emergency rest stop or take the next exit and come to a safe stop. Depending on the range of functions required in case of an error, many sub-functions and the associated sensors, actuators and software calculations must be involved. To be able to implement functions with the availability and reliability required by automated driving, a modified system 01I2016 Volume 11 43
DEVELOPMENT DRIVER ASSISTANCE SYSTEMS FIGURE 1 The various stages to automated vehicles require a change in the system architecture ( EB) architecture is necessary. However, one control device will still be classically developed: The implementation of driver assistance functions is static and follows a specified pattern (import sensor data, calculate control set point, control actuators). In the future, the development team will be forced to implement more and more solutions on the system level. Individual control devices will leave center stage and the entire system will take the spotlight: Communication paths must be able to change and software functions must be executed by other hardware in real time if the originally executing hardware fails. The requirements for implementing the actual assistance functions, whose complexity in the network with the sensors and actuators is also increasing, are becoming more and more rigorous. The need for high-performance processors that can execute complex calculations in real time is increasing. Parts of the software must also meet strict safety requirements, some at the top safety level: ASIL D (automotive safety integrity level D). But they cannot be implemented on high-performance processors like these without prior changes. A mixture of different controller architectures as execution platforms for future driver assistance functions is necessary. In the optimal case, these heterogeneous computer architectures will be implemented in the automotive industry in a way that makes the functions hardware-independent. And ideally, the developers will not need to know where and how their shares of the functions will be executed. MODIFIED SYSTEM ARCHTICTURE FIGURE 2 Software layers in combination with high-performance hardware platforms (e.g. Drive PX from Nvidia) are the basis of an integrated system approach ( EB) 44 An example of such a hardware platform is Drive PX from Nividia. It consists of an Infineon Aurix processor as the safety controller and two Tegra K1 processors as the performance controller. The associated software supplies Elektrobit with the EB tresos basic software, which in this case is based on the classical Autosar and on a variant of this standard. The variant forms the runtime environment with a dynamic operating system (in this case, Linux) on the Tegra processor in the sense of the new Adaptive Autosar.
A framework for driver assistance applications developed by EB is the application that runs on this system. The framework implements modules for fusing sensor data, trajectory planning and control and standard mechanisms for synchronising and coordinating several driver assistance functions as part of a situation-and-decision module. The assistance functions that run in the framework, such as an automated parking function, rely on the safety mechanisms that the underlying infrastructure makes available: The function management and compliance monitoring software, as well as the error handling, run with freedome from interference on the safety controller, FIGURE 2. This guarantees reliable operation. It is also possible to run software with a high ASIL safety level on a control device at the same time as non-safety critical algorithms with high performance requirements (ex. mixed criticality systems ). On dynamic software platforms such as the EB tresos environment that Elektrobit implemented on Drive PX, the communication paths between the individual functions are transparent and flexible. Whether applications communicate with their environment on the same control device via a classical Autosar RTE or the communication is dynamically established and disestablished via suitable software layers and channels to random transmitters and recipients will be irrelevant for applications in the future. This flexibility in communication enables the implementation of redundancy mechanisms for executing functions for fail-operational systems, for example, by implementing hot or cold standby functionality. This means that the functions are redundant on an additional hardware environment in standby and are activated if the main function fails. For cold standbys, they are not activated until the main function fails and displaces less important applications on the control device as required. For hot standbys, they run parallel to the main function. This results in rapid switching capability, but binds resources like CPU time and memory permanently. The sensor and actuator signals are dynamically rerouted, depending on where the function is being run, FIGURE 3. In a control device architecture that permits the described dynamic behaviour, you can guarantee the availability FIGURE 3 Dynamic control device architecture guarantees the reliability of dedicated functional ranges ( EB) of dedicated functionality by intelligently connecting several of these control devices on the system level. Of course physical redundancies in the power supply and communication channels must also be implemented. The advent of Ethernet and several batteries, for example in an electric vehicle, are the basis that will enable a software infrastructure platform for future highly automated driving functions. The challenge for the implementation is that it will require a system-wide approach for implementing a software infrastructure. The functions will be executed on several control devices and the logic for changing the distribution must take system-wide, dynamic aspects into consideration. The information on the functioning of the individual control devices must be acquired centrally. Decisions can be derived from these data: Depending on the status of the hardware and the integrity of the run-time environment the system must be re-configured. The place where functions are executed changes and the sensor and actuator signals are rerouted. The goal is to be able to reliably execute dedicated functions independently of which errors occur in the system or of which hardware fails. This can be achieved through a service-oriented architecture with central control and distribution mechanisms. 01I2016 Volume 11 45
DEVELOPMENT Driver AssiSTAnce SySTEMS A single platform must be created, a sort of total vehicle operating system. The need here becomes even more obvious if new technologies are added to the fail-operational requirement, such as the permanent connectivity of vehicles with their environments. An online connection like this would also require a modification in the architecture that satisfies the stricter security requirements. Firewalls, access controls and the observation of systems from within so as to be able to detect potential manipulation of safety-critical functions (intrusion detection) are all additional examples for the increasing requirements for a software infrastructure platform to be implemented in vehicles. INTEGRATED DEVELOPMENT With today s development approach, it will be difficult to implement an overall system consisting of hardware and software. Vehicles still consist of communicating lone warriors : the control devices with their local functions. Some of them have been defined independently of each other, specified by different departments at car manufacturers and developed by different suppliers. The software is based partially on standards such as Autosar, but a universal platform is a solution of the future. New players and various start-ups for electric vehicles whose self-images are that of non-traditional vehicle manufacturers and of course the major IT providers have the advantage that they can launch and structure the development process in the new system areas such as driver assistance functions from the ground up. As a result, they will make very different architecture related decisions and accelerate the change in vehicle system architectures. Car manufacturers, Tier 1 suppliers and software developers are all faced with the challenge of adapting their development and supplier structures both a result of growth over time. This is the only way to design completely new system architecture and pave the way to a software-defined vehicle infrastructure platform. REFERENCE [1] http://www.pcwelt.de/news/audi-zeigt-stau- Pilot-Autonom-bis-Tempo-60-Serienreife-ab-2017-9683696.html 46
chassis.tech plus 7th International Munich Chassis Symposium 14 and 15 June 2016 Munich Germany www.atzlive.de MODERN CHASSIS MODERN CHASSIS Steps towards intelligent systems Steps towards intelligent systems SMART CHASSIS Requirements and testing ASSISTANCE SYSTEMS Increased safety and comfort SMART CHASSIS Requirements and testing /// SCIENTIFIC DIRECTOR ASSISTANCE SYSTEMS Increased safety and comfort Prof. Dr. Peter E. Pfeffer Munich University of Applied Sciences /// ONE FOR ALL Four congresses in one event + + + chassis.tech plus Simultaneous Interpreting German and English chassis.tech steering.tech brake.tech tire.wheel.tech AUDI 7th International Munich Chassis Symposium 14 and 15 June 2016 Munich Germany /// SCIENTIFIC DIRECTOR Prof. Dr. Peter E. Pfeffer Munich University of Applied Sciences /// ONE FOR ALL Four congresses in one event /// KINDLY SUPPORTED BY PROGRAM AND REGISTRATION Phone +49 611 7878-131 Abraham-Lincoln-Straße 46 Fax +49 611 7878-452 65189 Wiesbaden Germany ATZlive@springer.com 01I2016 Volume 11 47 www.atzlive.com