With consumers increasingly expecting vehicles to have advanced features, OEMs are looking for new ways to meet demands while optimizing compute resources and costs. Fusing ADAS and the cockpit domain on a single high-performance compute platform through mixed-criticality processing can help OEMs achieve that goal by improving efficiency and simplifying vehicle architecture — allowing OEMs to optimize costs while enabling a feature-rich system.
However, such fusion comes with unique challenges beyond current mixed-criticality processing.
Mixed-criticality processing today
To understand mixed-criticality processing, it is essential to first understand the automotive safety classification system. ISO 26262, the automotive functional safety standard, outlines a classification system known as the Automotive Safety Integrity Level (ASIL), which includes four risk levels: ASIL-A, the lowest level, through ASIL-D, the highest level, which is the rating given to advanced safety applications. A fifth level, Quality Management, or QM, is assigned to features for which no risk reduction is required because standard quality management practices are deemed sufficient. In mixed-criticality processing, a single compute platform is used to support applications with different safety levels.
Automotive OEMs currently employ mixed-criticality systems — using virtual machines to provide dedicated resources — in scenarios where the underlying hardware requirements of the features are the same. Take, for example, the integrated cockpit controller (variants of which have been on the market since 2018): The instrument cluster applications are classified as ASIL-B, while the Android infotainment system has a QM designation. Both require a graphic processing unit (GPU) to display information, so they are able to run on a single chip and share that resource — helping to reduce the system cost by 20 percent.
However, ADAS and the cockpit domain have very different underlying hardware and software needs, with the ADAS feature set requiring a fail-safe design and access to more accelerators, such as a neural network processing unit. These differences can make fusing those functional areas in a mixed-criticality scenario more complicated.
The building blocks for fusing ADAS and the cockpit domain
Several building blocks are essential to successfully fusing ADAS and the cockpit domain onto a single high-performance compute platform: a hypervisor, a real-time operating system (RTOS), containers and middleware.
Hypervisor
A hypervisor is software that uses virtualization technology to create, run and manage virtual machines. A key benefit of hypervisors is that multiple operating systems with very different characteristics can run at the same time, sharing the same virtualized hardware resources without interfering with each other. Without this capability, only one operating system could run on a hardware system.
Embedded systems, such as those in automotive applications, have strict resource usage limits that the hypervisor must operate within while communicating rapidly and with low latency. An RTOS is essential for enabling this fast communication.
RTOS
An RTOS is a specialized operating system that processes data and performs operations within specifically defined time constraints. RTOSes have two key features: predictability and determinism. In an RTOS, repeated tasks are performed within a tight time boundary — meaning each task must take the exact same amount of time to execute every time and must always produce the same result.
Containers
Software containers are essential to enable RTOSes to perform targeted updates. This is especially critical when you consider that systems rated ASIL-D require retesting every time an update is deployed. Without software containers, any update to the cockpit domain would necessitate retesting the entire system. Containerized microservices also help break down complex software systems into small, independent services, which reduces the size of updates.
Middleware
In a true software-defined vehicle architecture, middleware is the glue between the hardware, operating system and application software — providing common services across vehicle domains and allowing domain-specific developers to build on those capabilities. The middleware also allows the application to be hardware agnostic through a modular, service-oriented approach.
A system-level approach maximizes benefits
Fusion provides the ideal trade-off between price and performance while facilitating the scalability and modularity of ADAS and the cockpit domain. However, many of the benefits of fusion, such as reduced costs and faster development times, are achieved only by sourcing an all-in-one solution. If OEMs source the hardware separately from the software, there is a greater burden on the development team to integrate the solutions. By bringing together an RTOS, middleware and a hypervisor in a single, scalable, integrated solution, OEMs can focus more on developing brand-differentiating features.
As a system integrator, Aptiv is well suited to help OEMs get the most benefit from fusing ADAS and the cockpit domain. In 2022, we acquired Wind River, a global leader in delivering software for mission-critical intelligent systems. Wind River’s Helix hypervisor platform simplifies, secures and future-proofs designs by consolidating multiple operating systems and mixed-criticality applications onto a shared system. Wind River’s VxWorks® is the industry’s only RTOS to support application deployment through containers that are compliant with Open Container Initiative standards, ensuring compatibility and ease of use across different platforms and environments. Together, Aptiv and Wind River can help OEMs develop an all-in-one solution that reduces costs, improves development times and meets their unique needs.