Future Automotive E/E Architectures for Autonomous Cars
During the last decades, a large number of software-based functions has been introduced in form of embedded systems. Many of them are characterized as safety-critical such as those found in the avionic, automotive, railway, and industry automation domains. The number of those functions as well as the complexity of involved hardware topologies will grow.
E/E architectures (electric/electronic) can be best characterized as historically grown, mostly federated but sometimes integrated architectures with often pragmatic, cost- efficient, and ad-hoc solutions. The notion of E/E encompass (i) the electrical network (e. g. high-voltage network, power electronics, generator), (ii) the reliable distributed con- trol system architecture (CSA) (e. g. sensors, actuators, electronic control units (ECU), bus systems), and (iii) less safety-critical infotainment systems (e. g. components from the consumer electronic industry). Within the context of the OSBORNE project we focus on the last two mentioned. Automotive domain separation (e. g. body, chassis, etc.) is still present. However, new ADAS and infotainment functions will break domain boundaries. Thousands of software-controlled functions are realized by a complex interplay of signals with timing requirements sent via heterogeneous bus systems with complex gateway structures connected to purpose-built ECUs with often closed proprietary designs. Over time, there was a shift from a “one function per ECU” paradigm towards a situation where several functions are deployed onto a single ECU and a function is potentially divided into several sub-functions executed on several ECUs. However, this “ECU-” or “signal-based” development approach has reached its limits of mastering complexity
In automotive software systems, only a few functions pose strongest safety requirements (i. e. ASIL D, cf. ISO 26262). However, along with highly automated or fully automated driving (SAE levels 4 and 5 of driving automation) this situation changes: we are facing a paradigm change in that the responsibility of driving a car switches from the driver to the machine. This coincides with a change of safety goals and safety measures because for level 5 there is no driver to fall back to anymore. Hence, fail-operational behavior instead of fail-silent is E/E-architectural challenge.
The main question still remains unanswered:
How does a future-proof automotive E/E architecture look like with emphasis on safety, automation, and intelligence?
The next generation of Intelligent Personal Assistant systems are capable of covering a variety of tasks from being a car advisor on different applications, and well-being coach of the occupants, to being a chauffeur for the passengers in absence of the driver for autonomous driving scenarios. The increasing amount of data in car beside the difficulties in hyperparameter tuning for training (learning rate, loss function, number of training iterations, gradient update smoothing, optimizer selection, etc.) and therefore, growing complexity in defining a good reward function in most of the cases, shows the need for scalable machine learning approaches. Ensuring the safety of the AI-based functions in E/E architecture of automotive is undoubtedly a big challenge.
An increasing number of functions in automotive E/E architectures introduces further requirements for in-vehicle communication systems such as the capability to support mixed- criticality and hard real-time requirements. Such a communication system has to offer higher bandwidth (required for e. g. demanding video data transmission > 1GB/s) and timing guarantees to fulfill safety-related requirements (e. g. deterministic minimum latency and jitter, reliability, and fail-operational). Our objective is to reduce heterogeneity and configuration complexity of in-vehicle com- munication sub-systems while supporting mixed-criticality and hard real-time. This yields advantages for the function developer, who is spared the task of network management and can focus more on function development itself.
- Chair of Software and Systems Engineering, TUM