Continental is redefining embedded software development

The virtualization of electronic control units (ECUs) and the applications they support has become a cornerstone of innovation in the automotive industry. Continental is redefining embedded software development by taking the development and testing of ECU software and decoupling it from the constraints of physical hardware. Virtualization opens the door to parallelizing hardware and software work for new ECUs, reducing time to market by orders of magnitude. Moreover, virtualization empowers developers worldwide to design and test applications for ECUs without the need to have physical hardware for validation.

Continental AG (Continental), an AWS Partner, is at the forefront of the virtualization movement with its Smart Cockpit High-Performance Computer (HPC), which is an ECU that serves applications with high compute requirements. Using AWS services such as HAQM Elastic Compute Cloud (HAQM EC2), secure and resizable compute capacity for virtually any workload, Continental has introduced a modular and scalable approach to HPC development. Continental’s method makes use of partitions, which are distinct and independent sections of an ECU, to discretely virtualize various kinds of automotive systems, such as infotainment or instrument clusters. The partitions empower automotive software development teams to integrate diverse software stacks while maintaining flexibility and scalability.

This article explores Continental’s pioneering work in ECU virtualization, highlighting the ability to combine partitions in an arbitrary way, which helps facilitate experimentation with future ECU setups and exploration of a given setup’s specific properties.

The shift to ECU virtualization

Continental’s journey to HPC virtualization began with the need to speed up development times for new HPCs. By utilizing ECU virtualization and implementing it on AWS cloud infrastructure, Continental has accelerated the development of new HPCs by orders of magnitude. The Continental approach not only speeds up the development process but also helps facilitate higher quality and reliability in the final product. Each of the partitions can run on ARM-based AWS Graviton instances, which provide the best price performance for cloud workloads running on HAQM EC2.

The use of Graviton provides environment parity with modern vehicle ECU hardware, empowering automotive software developers to run the same compiled binaries in both cloud simulations and the target vehicle hardware. Parity helps streamline development and testing processes of automotive software, meaning that cloud-based simulations accurately reflect on-vehicle performance and behavior.

Several factors facilitate the use of virtualized ECUs as replacements for hardware ECUs:

• Near real-time running of code: With Continental’s solution, all partitions operate in near real time. That can be achieved because there is parity between the CPUs used on many of today’s compute resources and the AWS Cloud. Many modern ECUs use ARM-based CPUs. ARM-based CPUs are also available as HAQM EC2 instance types, which makes it possible to run the same compiled binary—without changes—on both environments.
• Automotive accelerators: Autonomous driving HPCs use Graphics Processing Units (GPUs) for enhanced performance. Environmental parity between target ECUs and AWS services can also be achieved by matching GPUs. AWS provides HAQM EC2 compute instances that run on Nvidia GPUs as well as Qualcomm GPUs.
• Inter-partition communication (IPC): Virtualizing communication is as important as having the same type of CPU available in both environments. Virtualized IPC mirrors the real hardware environment, facilitating near real-time execution and maintaining binary identity across partitions.
• Peripheral integration: A virtualized ECU should work and behave exactly as the hardware version does. Peripherals such as those running on a CAN bus, the SOME/IP protocol, Bluetooth, cameras, and audio or video interfaces are fully supported in the virtual environment, facilitating comprehensive testing and validation.

Toward software-first ECU development

Traditionally, automakers have taken a hardware-centric approach to developing new ECUs. The hardware specification is the first component to be created. Samples of that target hardware are then delivered to software development teams. A downside of the traditional approach is that software development teams must adjust for and cope with the constrained resources of the respective target hardware.

Virtualizing ECUs, combined with the concept of an ECU partition, empowers automotive software developers to create ECU configurations. They can react to the trend of integrating more partitions on a single HPC, such as an ADAS partition and an infotainment partition. In a cloud environment, development teams can create arbitrary configurations and tailor memory and CPU resources to help meet specific automotive requirements. This allows them to innovatively combine existing partitions. Using this technology, development teams can develop software and test its behavior on multiple virtualized ECU configurations.

Continental has turned the vision of software-first ECU development into reality, in part by discovering a way to combine arbitrary partitions into virtualized high-performance computers (HPCs). The figure below shows all partition types available today: Android Automotive OS, Linux, AUTOSAR Classic Platform, QNX, and AUTOSAR Adaptive Platform.

Consider the ADAS-Cockpit HPC (AC HPC), which runs two partitions on a single hardware unit. Starting with an application and middleware catalog, Continental defines the required capabilities and places them in the respective partitions. An AC HPC might include multiple AUTOSAR Classic partitions, an ADAS partition (for instance, QNX), an AUTOSAR Adaptive partition, and an Android Automotive OS partition. The independent partitions empower Continental to create virtualized versions of the respective target hardware. They support a variety of automotive operating environments and future use cases. Each partition is built according to specific system requirements, helping to facilitate the development and testing of different ECU functionalities. In addition, those five partitions can be combined using the same protocols as in a vehicle. This provides the ability to support a new generation of HPCs that integrate features from different business domains on a single hardware platform.

The virtual partitions are integrated to form a virtual HPC (vHPC) or virtual ECU subsystem that is complete with all necessary virtual peripherals. The vHPC can then be tested, using the same testing tools on both the target hardware and the virtualized ECU. By evaluating the hardware resource requirements, Continental can propose and select the most suitable system on a chip (SoC, e.g. NXP or Qualcomm) for the targeted hardware and workload with respect to a new HPC project, facilitating optimal performance, efficiency, and end-customer functionality.

Figure 1, below, shows several different partition types, each of which is designed to run automotive applications in a cloud setting. Imagine these as different software stacks, each representing a different operating system and software framework. Underneath each of them are shared layers for communication and hardware connections.

Figure 1. Today there are Android, Linux, Autosar, QNX, and Adaptive Autosar partitions available

The different partition options, from left to right in Figure 1 above, are the following:

• Android Automotive OS: Based on Android, just like the operating system on many smartphones and tablets. Ideal for user-friendly use of car features like music, navigation, and hands-free calling. It runs on top of Linux and uses a package manager for installing and updating apps.
• Linux: A flexible, widely used operating system. It’s suitable for general automotive tasks that don’t require strict near real-time performance, and it offers a package manager to easily add or update software.
• AUTOSAR Classic Platform: A traditional automotive software standard focusing on reliable, near real-time operations. It’s perfect for running core vehicle functions that must respond quickly and predictably, and it uses model-based simulation (Synopsys Silver) to test its runnables (basic software units).
• QNX: Known for its secure, stable, and near real-time microkernel architecture. It’s commonly used in safety-critical and infotainment systems where reliability is key, and it includes a package manager for straightforward software management.
• AUTOSAR Adaptive Platform: A newer standard designed for modern, connected vehicle technologies. It supports advanced features like V2X (vehicle-to-vehicle and vehicle-to-infrastructure) communication, and it includes a package manager to simplify app and service deployment.

Below all stacks are the following layers:

• Communication: Handles data sharing and messaging between different parts of the system.
• Peripherals: Manages hardware connections such as for sensors, cameras, or other devices used by the car.

Conclusion

Using AWS cloud infrastructure, Continental provides a modular, scalable solution speeding up software development for vehicle HPCs. Through the creation of virtual partitions and integration of multiple automotive domains within a single high-performance computing platform, Continental’s approach to HPC virtualization is a step forward in automotive software development. This setup supports software development teams in testing and validating automotive applications, aligning with the trend of consolidating diverse vehicle functions within centralized computing environments.

Continental’s work in ECU virtualization supports the future of connected and intelligent automotive systems, delivering ever more adaptive, reliable, and user-focused solutions. Join us in shaping the next generation of software-defined vehicles—connect with our experts today to explore how AWS can help accelerate your development.