Rolland Dudemaine, VP Engineering, eSOL Europe
The priorities driving the development of EV electrical architecture differ significantly from those that govern conventional internal combustion engine (ICE) vehicles, and will be met through fundamental changes to hardware and software
Consumer adoption of electric vehicles (EVs) is expected to grow, driven by factors such as increasing concern over climate change, new and improved models entering the market, and proposed legislation to ban sales of new ICE vehicles in the future.
The arrival of the EV introduces a step in the otherwise curved trend of electrification sweeping through established function categories: body/chassis, comfort, safety, powertrain and infotainment. With no combustion engine on board to power subsystems such as cabin heating, or drive an alternator, the EV’s electrical infrastructure differs significantly from that of conventional vehicles.
Changing Priorities of the Electrical Infrastructure
New priorities are taking precedence in EV electrical infrastructures, including safe battery management and efficient use of electrical energy everywhere to extend driving range. Where the battery is concerned, greater care must be given to monitoring the battery condition and stabilizing aspects such as internal temperature and cell balancing to maximize performance and longevity. Meanwhile, EV battery voltages are generally higher than the 12V lead-acid battery in a conventional vehicle, meaning extra safety precautionsare required.
Drivetrain electrification, in combination with other trends such as the infusion of V2X (vehicle to everything) connectivity and higher-level autonomous driving capabilities, is a catalyst for more centralized vehicle electrical infrastructures. Aggregation and integration of multiple domains, currently handled by large numbers of individual ECUs distributed throughout the vehicle, enable vehicles to become software-defined and help to enhance overall quality, cost, and performance. Importantly for EVs in particular, aggregation also helps to reduce wiring weight and complexity, as well as saving precious battery energy – all of which contribute to increased driving range.
The trend to centralize control of demanding vehicle functionalities is driving demand for high-performance computing with a minimal power requirement, leading to the development of highly efficient, heterogeneous, manycore processors to handle these diverse workloads.
At the same time, there is a clear requirement for flexibility and scalability within the electrical infrastructure. OEMs need this to create differentiated product ranges cost-effectively by implementing different applications and features on different models, utilize different hardware platforms of varying cost and complexity throughout their product ranges, and deliver new models within tough time-to-market targets. They also need to deploy and enable new functionality after physical delivery, Over-The-Air (OTA).
Meanwhile, new concerns surrounding safety and cyber-security are appearing. With increasingly pervasive connectivity and higher levels of autonomy, there is clear potential for malicious hacking to threaten individual safety and even national security. As far as functional safety is concerned, established standards like ISO 26262 arguably may not be sufficient for emerging use cases like autonomous driving. Newer standards such as SOTIF (Safety of the Intended Functionality) and UL4600 are being developed to cater for these applications. OEMs and Tier 1s need hardware and software architectures they can rely on as part of the solution to these challenges.
Changing Faces of Hardware and Software
To give the best chance of success, it makes sense to consider the software platform as well as the hardware and, in particular, the architecture of the operating system (OS) which brings together these rapidly developing computing elements.
Figure 1. The software platform of the future must support safety, scalability, and real-time determinism.
Figure 1 depicts an automotive software platform which incorporates the AUTOSAR Adaptive Platform (AUTOSAR AP). This addresses the demands of future vehicles and is intended for use in systems certified up to ISO 26262 ASIL-D. AUTOSAR AP standardizes foundation-layer software and allows for planned dynamics, which permits adaptability without compromising the handling of safety-critical processes. Planned dynamics is achieved through several measures, such as making sure all processes are registered during system integration, and restricting privileges for starting processes. In addition, AUTOSAR AP manages communication between application processes and external entities according to strict policies established during system integration.
The platform shown is based on a Service-Oriented Architecture (SOA), which is well suited to future centralized and zone-based vehicle electrical architectures and provides flexibility as well as transparency in terms of implementation and mapping: the location of the server providing the service is independent of its use, which is critical for distributed computing. Moreover, transparency provides a good foundation for Freedom From Interference (FFI), which is one of the central concepts in functional safety. On the other hand, a physical mechanism like the memory management unit (MMU) of the processor is needed to provide assurance of FFI. The OS virtualizes this mechanism in the form of ‘OS processes’, which are the physical instances of the services and applications.
In the architecture illustrated in Figure 1, many components run as processes. Frequent interaction between processes is necessary, for example if an application process needs to use a service that is run as another process. Historically, functional safety has been predicated on protecting processes from one another. AUTOSAR AP now introduces a reliance on Inter-Process Communication as an OS feature, which can be much more costly performance-wise than intra-process communication; it can also evolve into a significant system performance issue when all the software is integrated.
OS for Manycore Processing
With demands for unimpeded inter-process communication in software, as well as large numbers of intercommunicating processor cores in the manycore CPUs at the heart of the emerging centralized hardware architecture, traditional OSes are increasingly likely to fall short in their ability to service all parts of the system adequately to maintain performance.
In contrast, a distributed microkernel OS is inherently suited to servicing large numbers of interlinked cores and processes. It enables fast and deterministic response, which is particularly important to ensure proper handling of real-time control applications in domains such as powertrain. A distributed microkernel OS is unlike typical microkernel OSes. With no need for cross-core kernel locks to prevent concurrent accesses, which can impair performance, the architecture ensures parallelism is preserved.
eSOL has developed such a distributed microkernel OS, eMCOS, to meet the future needs of the automotive sector including the requirements for scalability, safety and real-time determinism. eMCOS can scale in multiple ways to handle either small or large sets of functions. Applications can be connected between the microkernels and users can customize the adaptation layer to suit their intended purpose. Ideally suited to state-of-the-art manycore processors, eMCOS supports inter-cluster message passing and so allows dynamic AUTOSAR AP and static AUTOSAR CP (Classic Platform) to run on the same chip. A layered scheduling mechanism enables hard real-time determinism and permits high-throughput computing combined with load balancing. Standard support is available for multi-process POSIX and AUTOSAR programming interfaces, and there are special-purpose APIs for functions such as Distributed Shared Memory (DSM), fast messaging, NUMA memory management, thread-pool, and others.
The demands placed on vehicle electrical infrastructures continue to intensify and are being further compounded by the transition to full-electric powertrain. Centralization and aggregation of functions formerly handled by individual ECUs is driving moves to adopt manycore CPUs to achieve a suitable combination of computer performance, energy efficiency and low power consumption. These, however, are not best served by conventional OSes. Designers therefore need to understand the effects of OS selection and, in particular, consider a distributed microkernel OS to maximize the advantages gained by adopting manycore to meet the needs of tomorrow’s vehicles.