Changing Gears: Parallelizing Hardware and Software Development at Continental

What happens when you approach the development of electronic control units (ECUs) for vehicles in the same way as smartphone design? Continental is exploring this question by parallelizing hardware and software development.

The automotive industry is facing numerous challenges in building components to meet the needs of today’s customers. On the one hand, customers demand a vehicle that behaves like a smartphone on wheels with continuous updates and thousands of apps instantly available. On the other hand, the complexity of a vehicle’s internal software and hardware architecture needs to be reduced. This trend has led to the advent of software-defined vehicles (SDVs).

The internal architecture of an SDV aims to optimize the number of ECUs in a vehicle replacing single purpose ECUs (more than 100 in a modern vehicle) with multi-purpose ECUs (to a few tens). In an SDV, software plays a much bigger role, opening up new possibilities that will help change the development processes for vehicles.

Recognizing this challenge, Continental is taking a new path in creating ECUs. Instead of solely developing and testing using the target hardware, Continental is conducting software development and testing on virtualized versions of the target hardware. More specifically, Continental is running a virtualized ECU on AWS designed to help enable modern software development practices in Continental’s ECU development projects. This can deliver results faster and with higher quality.

The first step supporting the approach presented above is the availability and use of ARM-based CPUs, which are prevalent in both automotive and consumer devices like smartphones and TVs. In automotive, ARM CPUs (mostly based on Cortex-A) are widely adopted for high performance computing (HPC) e.g., infotainment systems. Most of these ARM systems share the same Arm64 base Instruction Set Architecture (ISA).

Amazon Web Services, Inc. (AWS) offers a wide range of ARM-based Amazon EC2 instances. The respective AWS Graviton Processors series has arrived at the fourth generation. AWS Graviton Processors are built using ARM’s Neoverse CPU employing the Arm64 ISA. The fact that both the target hardware and AWS Graviton share the same ISA enables environmental parity. Leading to the result that the same application-binary can run on the target hardware environment as well as on the virtualized environment on AWS, as detailed in this white paper.

A second step is the selection of the operating systems by Continental, like QNX, Linux, or Android, and automotive middleware like Adaptive Autosar or a Realtime Operating System. AWS EC2 can to run a wide selection of automotive OSs (including real-time OSs) and middleware available that help customers run automotive software.

Traditionally, Continental started the development process of a new ECU with the specification of the hardware. The hardware specification is influenced by a variety of factors such as the price of hardware components and the expected performance. After the specification phase, hardware prototypes (frequently called samples or target hardware) with increased maturity are built by Continental and sent to Continental software developers allowing them to start building and testing software.

One measure to accelerate ECU development is to shift the start of software development and testing earlier in the project (commonly referred to as “shift-left”). To achieve that, structural changes need to be applied to the software development process and related tools. Figure 1 shows the traditional approach to create a new vehicle High-Performance Computer (HPC), and an approach isolating hardware- and software development below.

Figure 1: Isolation of Hardware and Software Development (Source: Continental)

Continental’s Shift-Left Strategy

Let’s assume at Continental there are two teams working on a new ECU project. One team works on the hardware part. The other team is responsible for the software. At the beginning of the project both teams agree on fundamental properties of the new ECU. The goal of this effort is to arrive at a position where both teams can work in parallel from the beginning of the project.

This approach of agreeing on common specifications for hardware and software features gives both automotive hardware and software development teams at Continental the ability to construct ECUs in a new way. It involves providing a target environment, defined by the respective hardware specifications, and a virtualized mirror running on the AWS cloud. The goal for Continental is to provide each of its software developers with a personal virtualized development and test environment. This approach helps software developers to identify software bugs much earlier in the project lifecycle than was possible traditionally. Removing bugs later usually comes with a much higher mitigation effort. It also helps enable Continental to begin developing production-ready software even when the target hardware environment is not yet available.

The next section describes how Android Automotive can be deployed to an AWS EC2 instance which can create a virtualized development environment. This is followed by a passage describing how Continental is using Android Automotive to help build its next generation infotainment system.

Use of Android Automotive to Build the Virtualized Development Environment

Android Automotive is Google’s In-Vehicle Infotainment (IVI) product running directly on a vehicle ECU. It is an Android operating system with extensions that provide automotive-specific features. The Android operating system is a full stack offering that includes all the layers of a typical OS software stack, a Linux based kernel, Hardware Abstraction Layers (HAL), platform components, middleware, and the application layer.

Android’s HAL, which abstracts access to peripheral devices is a promising approach to achieving parity between virtual and target hardware environments. The HALs can be designed to enable transparent access to both the physical and virtual representations of a device. Having the virtual device backed by HAL implementations at the beginning of the project helps enable engineers working on the higher layers of the software stack to start and accelerate development without having to wait for the physical hardware.

Continental Case Study Smart Cockpit HPC

At June 20, 2023, Continental has introduced the Smart Cockpit HPC (High-Performance Computer) designed to deliver optimal system performance for a pre-integrated suite of cluster, infotainment, and Advanced Driver Assistance Systems visualization functions within vehicles.

The infotainment system of the Smart Cockpit HPC is powered by four ARM Cortex-A72 cores from the SoC (System on a Chip) provider, Telechips Inc. In addition, it is equipped with an array of I/O devices, including a multi-touch display, microphone, speakers, WiFi, Internet access, USB, and Bluetooth radio. Figure 2 shows a screenshot of the infotainment cluster running on AWS that is an exact mirror of what is shown on the target hardware.

Figure 2: Screenshot from the virtualized device demonstrated at the Continental booth at IAA Mobility 2023

While physical hardware testing is still a core portion of Continental’s ECU performance and reliability testing procedures, virtualizing (and therefore parallelizing) the earlier development stages has dramatically shortened end-to-end development time. Leveraging Android Automotive as the infotainment platform, which can be deployed on AWS as well as on the target hardware, Smart Cockpit HPC is able to decrease development time from 3 to 4 years down to 18 months. This is achieved by parallelizing hardware- and software development providing software developers with a virtualized environment right from the start.

The ability to integrate various peripherals using Android’s HAL concept enables developers to seamlessly create software within the virtualized environment that can run on the target hardware without modifications.

In conclusion, Continental’s Smart Cockpit HPC is not just an innovative product; it is a testament to the transformative power of parallel development.

Conclusion

Continental is striving to innovate quickly, but in a manner that preserves the company’s high bar for ECU performance and reliability. By parallelizing hardware and software development, Continental is able to conduct a significant portion of the same testing and iteration work, which is necessary to ensure the device’s performance and reliability, in a virtual environment. Continental built its solution using AWS cloud services, leveraging AWS Graviton processors, to construct a virtualized development environment for its new Smart Cockpit HPC.

Not only is the development timeline accelerated, but the elastic nature of AWS cloud services and virtualization allows many Continental teams to simultaneously perform testing and development activities on different aspects of the ECU and its functionalities.

For more details, please visit our AWS for Automotive page and Continental’s HPC page.