The Next Step in Mixed-Criticality Processing

The Next Step in Mixed-Criticality Processing

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. 

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. 

How helpful was this article?
i

 

×

Please let us know how helpful this article was, so we can provide you with the best content possible. If you have more feedback to share, please feel free to contact us.
Thank you!

Careers


Shape the future of mobility. Join our team to help create vehicles that are safer, greener and more connected.

View Related Jobs

Subscribe