Virtualization in the Automotive industry-The Missing Benefit!

A Bit of History

Virtualization technologies have a long history since 1967 since IBM[1] trials of running multiple operating systems on the same hardware machine of what is called control program CP-40.

The initial motivation for the control program CP-40 (an early name for the hypervisor) was to allow multiple operating systems to run on the same hardware, aimed to increase the efficiency and cost-effectiveness of computing resources.

We can appreciate the sophistication of this achievement, especially considering that the MMU (Memory Management Unit) had not yet been introduced to processors at that time. IBM's initiative to propose and develop this idea was truly visionary and forward-thinking.

While IBM pioneered the virtualization technology with a series VMMs leveraging the enhanced processor architecture, it was all for IBM processor architectures.

The first commercial hypervisor for x86 architecture was vmware in 1999.

Vmware business use case was for workstations as well as desktops that allow running multiple OS on the same desktop machine. The convenience of using Hypervisor on a desktop with various use cases introduces reliability and easy restoration as well as running cross-platform applications on the same machine was magnificent.

The virtualization technology has been used earlier was either a full-virtualization using a binary translation virtualization layer or a para-virtualization by OS-assistant virtualization or OS-assistant virtualization.

As processors have added hardware extensions to support OS, the same has been done for hypervisors, and in 2005 Intel and AMD introduced the first hardware virtualization extension with the name Intel VT or Vanderpool, the new technology eased the virtualization of the CPU by adding a new MMU stage, introducing fine-granule trapping mechanism to ease the emulation instead of binary translation and a new mode of operation for the hypervisor.

The new technology was a middle way, to what is called hardware-assistant virtualization, as much performance has been improved but yet, devices need a para-virtualization technology to be virtualized.

The hardware-assistant virtualization technology was sufficient for the hypervisor use cases on the cloud since barely computational tasks were primarily handled, allowing for efficient resource management and optimized performance without significant overhead. This technology enabled more secure, isolated virtual environments, crucial for cloud infrastructure where multiple tenants and diverse applications concurrently operate. Additionally, it facilitated rapid scalability and flexibility in deploying and managing virtual instances, thus meeting the dynamic demands of cloud computing platforms effectively.

The real breakthrough for hypervisor for embedded was when Arm introduced a hardware virtualization extension on ARMv7A in 2011 which was followed by Xen hypervisor has introduced a support based on ARMv7A in 2012.

Indeed hardware-assistant virtualization has made it easier for embedded leveraging from hardware-level spatial isolation which allows mixed-safety critical applications can be deployed aside on the same processor.

Yet, a non-pleasant fact still puts a burden on embedded virtualization use cases!

While hardware-assistant virtualization only focuses on CPU virtualization and its associated hardware elements, device virtualization on the other hand does still need para-virtualization.

This is when Xen came up with the simple and brilliant idea of Domain0 VM, Domain0 VM, or in short Dom0 which is sometimes misleadingly named by the host OS, it can have actual access to all the hardware devices and passes this right to the VM based on configuration using a backend-frontend architecture.

As the idea was appealing, it seemed either a coincidence or a domino effect Oasis open community adopted standardization of the Virtio in 2014.

Virtualization in Automotive use cases

I couldn’t find personally when the virtualization started to be adopted in automotive ECUs since I have found multiple claims about the pattern from different OEMs, I would say, the hypervisor usage pattern has appeared in sync with multiple car lines and became a defacto software architecture patterns in all automotive ECU use-cases nowadays.

Different from the usage of hypervisor in the cloud, the purpose of using hypervisor in automotive has added new aspects to the virtualization technology, which is mixed-critical safety applications.

As the automotive ECU is a powerful processing hardware platform that hosts multiple functionalities with various safety-criticality levels, the hypervisor facilitates gathering these applications on one powerful hardware platform improving power, performance, and cost efficiency.

Automotive OEM and Software factories

Before going to the core of the problem, it is worth mentioning that, the transformation of a car which the majority of its construction was mechanical into the software-defined vehicle, emerges OEM to establishing an internal software factory.

While the OEM software factories are more focused on the development of automotive applications and, integration with the other service software elements such as Autosar stack, Operating systems, and hypervisor, the service software elements are provided by Tier-1 vendors.

Automotive OEM and Abstraction

A successful story of the OEM and Tier-1 to provide a cross-domain platform's development by establishing the Autosar in 2003 by a lead OEMs partnership BMW, mercedes-benz, Volkswagen, Ford, GM, Stellantis and Toyota plus leads of Tier-1 BOSCH, Continental. The front-end motivations were scalability and, re-usability, and the back-end motivations were to offload the common software services to tier-1, get locked off of the hardware vendor, and focus on the growth of the functionality of the SdV.

Autosar has been extended to Adaptive Autosar to cover the new urge of the high computational power CPUs leveraging from the same goals for the Autosar classic.

OEM has succeeded in intervening and reshaping the industry in a way that helped the growth of the business and to go forward into the ambitious road map of the SdV.

OEM and its responsibility to tune the market

As OEM outsources many service software elements to Tier-1 companies, it carries out an implicit role in maintaining the market of the providers of those software elements.

Maintaining the market is a far-sighted and well-known pattern strategy that is aligned with the business goal to maintain both prices and quality of those service software elements.

While this strategy works well with software companies, the matter is different when it comes to the SoC vendors.

SoC vendors and the hypervisor

Since the hardware platform is still the most expensive part of the SdV, OEM doesn’t like to be locked to a specific hardware vendor.

As hypervisor came into the picture, with all the benefits it introduces, one benefit is still not yet unrevealed.

The hypervisor and its virtualization environment compose an abstraction layer to the hardware platform. The only obstacle to doing this is the complexity and volatility of the incorporated devices to the SoC which makes migration from one hardware platform to another is still effortful.

As hypervisor vendors are devoted to following the changes in the SoC and introducing an up-to-date SDK to the latest BSPs released from the SoC vendor, two important idle conditions have been assumed:

1. if the silicon vendor will cooperate fully and equally with all the hypervisor vendors.

2. if the hypervisor vendor will become neutral to all SoC vendors.

It seems both conditions didn’t quite fit into the industry, and with the appearance of the hypervisor as a defacto element in most ECUs in the car platform, a different reaction from the SoC vendor has been emitted:

1- Either an SoC vendor makes a strong and unique in a manner partnership with a hypervisor vendor which grantees a win-to-win relationship as in the case of QCOM and QNX (a few months ago QCOM acquired OpenSynergy GmbH Automotive Hypervisor division!).

2- or SoC vendor to acquire a hypervisor vendor as in the case of Samsung Exynos and Harman

3- or SoC vendor to create its hypervisor, as in the case of NVIDIA

or

4- SoC vendor to try a very enthusiastic action- to push a hardware solution to grantees spatial isolation via hardware partitioning as in the case of NXP.

The four strategies were indeed a normal initial reaction since SoC vendors might feel threatened by the upcoming virtualization solutions.

However, these strategies don’t help the business goal of the OEM since it doesn’t make them leverage the missing benefit of the virtualization environment which to get unleashed from the SoC vendor allows their complete software to be used among different variants with different hardware platforms (at least for a specific-domain SoC as IVI).

As Android Automotive Open Source or AAOS has adopted Virtio as a front-end driver for its first AAOS cuttlefish and followed by the Trout reference platform, OEM leverages the use of AAOS out-of-box with minimal changes in infotainment use-cases. But still, Automotive OEM are missing the correct strategy.

To Be Continued ...