Automated driving - The infrastructure shift
June 20, 2016
Current driver assistance functions such as automated parking or traffic jam assist and lane departure warning systems for the highway are the first s...
Current driver assistance functions such as automated parking or traffic jam assist 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.
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 (for example, a sensor fails), they must be able to regain control immediately.
Driver assistance functions of the future will give drivers new freedom, as vehicle operators will be able to divert their attention from traffic and tend to other activities. They will be permitted to release the steering wheel, activate their assistance function, and also make video calls during traffic jams instead of paying full attention to traffic.
Systems such as the traffic jam assistant Audi has announced for its 2017 models will give drivers more time to take control, as initially drivers will have up to 10 seconds to re-commandeer their vehicles. However, this also implies that drivers will be able to pay attention to other things while the assistance function is active, meaning they will not be available if a system failure occurs. During this time, the vehicle will be responsible for avoiding or handling dangerous situations, as it will not be able to simply shut down in case of error until full control has been returned to the driver. Instead, they must maintain a minimum level of functionality to guarantee the safety of the vehicle and the people in it, so, in fact, this short period of 10 seconds will require profound changes in design architecture as systems must evolve from “fail silent” to “fail degraded” or even “fail operational.”
[Figure 1 | The various stages to reach autonomous vehicles requires a change in system architecture.]
The shift begins in development
While the vehicle infrastructure, hardware, and software must all be engineered to remain capable of working even in the event of a system error, in the initial transition towards autonomous driving 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 area 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 associated sensors, actuators, and software calculations must be involved. To be able to implement functions with the availability and reliability required by autonomous driving, a modified system architecture is necessary.
Control devices will still be classically developed for the time being, as 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, however, development teams will be forced to implement more and more solutions at the system level. Individual control devices will leave center stage and the entire system will take the spotlight as communication paths must be able to change and software functions must be executed by other hardware in real time if the original executing hardware fails.
The requirements for implementing the actual system-level 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 growing, and software elements must also meet strict safety requirements up to automotive safety integrity level D (ASIL D), automotive’s highest software safety rating.
In the optimal case, computer architectures leveraged by the automotive industry will be implemented in a way that makes functions hardware independent so safety-critical software does not have to be specially tuned to run on the heterogeneous controller architectures that will act as execution platforms for driver assistance systems of the future. Ideally, developers will not need to know where and how their share of functions will be executed.
Modified system architecture
An example of such a platform is the NVIDIA DRIVE PX, which consists of two Tegra K1 processors as the performance controllers, an Infineon Aurix processor as the safety controller, and supports Elektrobit’s EB tresos software environment. EB tresos is based on a variant of the Automotive Open System Architecture (AUTOSAR) standard called the AUTOSAR Adaptive Platform, and forms the runtime environment for a dynamic operating system (in this case, Linux) on the Tegra processors.
A framework for driver assistance applications developed by Elektrobit is the application that runs on this system. This framework implements modules for fusing sensor data, trajectory planning and control, and standard mechanisms for synchronizing 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 EB tresos infrastructure makes available, so function management and compliance monitoring software, as well as error handling, run with freedom from interference on the safety controller itself. This guarantees reliable operation, and also makes it possible to run software with a high ASIL rating on a control device at the same time as high-performance, non-safety-critical algorithms to create mixed-criticality systems.
[Figure 2 | Software layers in combination with high-performance hardware platforms, such as NVIDIA DRIVE PX, are the basis of an integrated system approach.]
With dynamic software platforms such as the EB tresos environment on DRIVE PX, communication paths between the individual functions are transparent and flexible. Whether applications communicate with the environment on a control device using a classic AUTOSAR runtime or communication with random transmitters and recipients is dynamically established and disestablished via suitable software layers will be irrelevant for applications in the future. This communication flexibility enables redundancy mechanisms needed for “fail operational” systems, for example, by implementing hot standby functionality. A hot standby means that functions can be made redundant in additional hardware environments that are placed on standby and activated only if a function fails in the primary environment. These additional hardware environments dedicate resources such as CPU time and memory for the specific function, and therefore run in parallel. This results in rapid switching capability whereby sensor and actuator signals are dynamically rerouted based on where the function is being run.
[Figure 3 | A dynamic control device architecture guarantees the reliability of dedicated functional ranges.]
Integrated development and a “total vehicle OS”
In a control device architecture that permits the described dynamic behavior, you can guarantee the availability of dedicated resources by intelligently connecting several of these control devices at the system level so that functions reliably execute independently of what errors occur or which hardware fails. The challenge with this, however, is that it also demands a system-wide approach to software infrastructure in order to dynamically manage the entire system in real time. In such an implementation, information about the individual control devices, such as hardware status and runtime integrity, must be centralized to enable decisions on how to best reconfigure the system.
The need here becomes even more obvious if new technologies are added to the fail operational requirements, such as permanent, persistent connectivity between vehicles and their surrounding environments. An online connection like this would demand modification of the architecture to satisfy strict security requirements, as well as the provisioning of firewalls, access controls, and intrusion detection tools so that potential threats to safety-critical systems can be monitored and prevented.
Many of these requirements can be fulfilled through a service-oriented architecture (SOA) with central control and distribution mechanisms, but a new software infrastructure, a “total vehicle operating system,” will be needed to integrate all the dimensions of autonomous vehicles in the years to come. Implementing the hardware and software required by automated drive systems will be difficult using today’s development approach, since vehicles currently consist of “lone warrior” control devices that only communicate their local functions. Some of these devices are defined independently of each other, specified by different departments at car manufacturers, and developed by different suppliers. The software for these devices is based partially on standards such as AUTOSAR, but a universal platform is a solution of the future.
The shift into software-defined vehicles
New players and various electric vehicle startups who view themselves as non-traditional vehicle manufacturers, as well as major IT providers have the advantage of launching new structural development processes for emerging system areas such as driver assistance. As a result, they will be in the position to accelerate change in vehicle system architectures, prompting car manufacturers, Tier 1 suppliers, and software developers to change practices over time. This is the only way to design completely new system architecture that paves the way for software-defined vehicle infrastructure platforms of the future.
Elektrobit Automotive
LinkedIn: www.linkedin.com/company/elektrobit-eb-automotive
Facebook: www.facebook.com/EBAutomotiveSoftware
