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 atten-tion to the traffic.

Systems such as the traffic jam assis-tant [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

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 increas-

ingly 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

AUTHOR

Dipl.-Ing. (M.Sc.) Karsten Hoffmeister

is Senior Manager at Elektrobit in Erlangen (Germany).

DEVELOPMENT DRIVER ASSISTANCE SYSTEMS

42

while the assistance function is active. This means that they will not be availa-ble if a failure occurs. During this time, the vehicle system will be responsible for avoiding or handling dangerous situa-tions. 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 func-tionality 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 emer-gency 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 sen-sors, actuators and software calcula-tions 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

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, cal-culate control set point, control actuators).

In the future, the development team will be forced to implement more and

more solutions on the system level. Indi-vidual 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 sen-sors and actuators is also increasing, are becoming more and more rigorous. The need for high-performance proces-sors that can execute complex calcula-tions 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 com-puter architectures will be implemented in the automotive industry in a way that makes the functions hardware-independ-ent. And ideally, the developers will not need to know where and how their shares of the functions will be executed.

MODIFIED SYSTEM ARCHTICTURE

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 pro-cessors as the performance controller. The associated software supplies Elek-trobit with the EB tresos basic software, which in this case is based on the classi-cal Autosar and on a variant of this standard. The variant forms the run-time environment with a dynamic oper-ating system (in this case, Linux) on the Tegra processor in the sense of the new “Adaptive Autosar”.

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)

FIGURE 1 The var-ious stages to automated vehi-cles require a change in the system architec-ture (© EB)

DEVELOPMENT DRIVER ASSISTANCE SYSTEMS

44

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 sev-eral driver assistance functions as part of a situation-and-decision module. The assistance functions that run in the framework, such as an automated park-ing function, rely on the safety mecha-nisms that the underlying infrastructure makes available: The function manage-ment and compliance monitoring soft-ware, 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 algo-rithms with high performance require-ments (ex. “mixed criticality systems”).

On dynamic software platforms such as the EB tresos environment that Elek-trobit implemented on Drive PX, the communication paths between the indi-vidual functions are transparent and flexible. Whether applications communi-cate with their environment on the same control device via a “classical Autosar RTE” or the communication is dynami-cally 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 redun-dancy mechanisms for executing func-tions for fail-operational systems, for example, by implementing hot or cold standby functionality. This means that the functions are redundant on an addi-tional hardware environment in standby and are activated if the main function fails. For cold standbys, they are not acti-vated 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 sen-sor and actuator signals are dynamically rerouted, depending on where the func-tion is being run, FIGURE 3.

In a control device architecture that permits the described dynamic behav-iour, you can guarantee the availability

of dedicated functionality by intelligently connecting several of these control devices on the system level. Of course physical redundancies in the power sup-ply and communication channels must also be implemented. The advent of Eth-ernet 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 exe-cuted 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 environ-ment the system must be re-configured. The place where functions are executed changes and the sensor and actuator sig-nals 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 ser-vice-oriented architecture with central control and distribution mechanisms.

FIGURE 3 Dynamic control device architecture guarantees the reliability of dedicated functional ranges (© EB)

01I2016 Volume 11 45

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 vehi-cles with their environments. An online connection like this would also require a modification in the architecture that sat-isfies the stricter security requirements. Firewalls, access controls and the obser-vation of systems from within so as to be able to detect potential manipulation of safety-critical functions (intrusion detec-tion) are all additional examples for the increasing requirements for a software infrastructure platform to be imple-mented in vehicles.

INTEGRATED DEVELOPMENT

With today’s development approach, it will be difficult to implement an over-all system consisting of hardware and software. Vehicles still consist of com-municating “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 manufac-turers” and of course the major IT pro-viders 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 deci-sions and accelerate the change in vehi-cle system architectures. Car manufac-turers, Tier 1 suppliers and software developers are all faced with the chal-lenge 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 soft-ware-defined vehicle infrastructure platform.

REFERENCE[1] http://www.pcwelt.de/news/Audi-zeigt-Stau- Pilot-Autonom-bis-Tempo-60-Serienre-ife-ab-2017-9683696.html

DEVELOPMENT DRivER ASSiSTAncE SySTEMS

46

01I2016 Volume 11 47

7th International Munich Chassis Symposium

14 and 15 June 2016

Munich | Germany

chassis.techplus

PROGRAM AND REGISTRATION

www.ATZlive.comAbraham-Lincoln-Straße 4665189 Wiesbaden | Germany

Phone +49 611 7878-131Fax +49 611 7878-452ATZlive@springer.com

© A

UD

I

www.ATZlive.de

/// SCIENTIFIC DIRECTORProf. Dr. Peter E. Pfeffer

Munich University ofApplied Sciences

/// ONE FOR ALLFour congressesin one event

chassis.techplus

Simultaneous InterpretingGerman and English

MODERN CHASSISSteps towards intelligent systemsSMART CHASSISRequirements and testingASSISTANCE SYSTEMS

Increased safety and comfort

7th International Munich Chassis Symposium

14 and 15 June 2016 | Munich | Germany

chassis.techsteering.tech

brake.techtire.wheel.tech

+

++

/// KINDLY SUPPORTED BY

MODERN CHASSISSteps towards intelligent systems

SMART CHASSISRequirements and testing

ASSISTANCE SYSTEMS Increased safety and comfort

/// SCIENTIFIC DIRECTOR

Prof. Dr. Peter E. PfefferMunich University ofApplied Sciences

/// ONE FOR ALL

Four congressesin one event