Develop and test automotive software at scale using AWS

The traditional hardware-centric approach of developing and testing automotive software using Hardware-in-the-loop (HiL), is slow and limited in scale. The physical Electronic Control Units (ECUs) are not readily available during the software development phase, thus limiting the development team’s ability to scale. Consumer demand and expectations highlight the need for vehicles to be more connected, autonomous, shared, and electric (CASE). For example, a McKinsey report says (1) 95% of new vehicles sold in 2030 will be connected, (2) 64% of consumers would switch from their existing automaker for better autonomous-driving capabilities, (3) EU law will require all new cars sold to have zero emissions from 2035, and (4) two out of three US customers expect their shared-mobility usage will increase over the next two years. Electrification, Advanced Driver Assistance System (ADAS), and In-Vehicle Infotainment (IVI) features continue to increase the lines of software code, and require even more complex software in the car. The number of lines of code is expected to increase from 100 million lines per vehicle to about 300 million lines by 2030. The use of the classic V-model for automotive software development lacks agility. The validation of these systems can no longer happen in isolation, or late in the development process. Testing solely utilizing physical hardware test benches and mule vehicles is late and expensive. Most of the functional problems need to be addressed earlier in the development process and in a more productive environment, which can help avoid project overruns.

Automotive software – Complexities and advancements in modern vehicle

Why is the automotive software development process so complicated? Automotive software development and testing has to follow regulated processes, and comply with certain automotive standards. For example, OEMs may need to comply with certain International Standards Organization (ISO) regulations, AUTomotive Open System Architecture (AUTOSAR) standards, or meet the Automotive Software Process Improvement Capability determination (ASPICE) requirements. This increases the complexity of automotive software development. In addition, different players providing parts of the solution for software development, complicated testing requirements for test drives (such as millions of kilometers, thousands of scenarios), testing with various HiL systems, and embedded software development adds more complexity to the automotive software development process.

Having established the limitations and challenges with the HiL based development and testing, and the complexity inherent in the development and testing of automotive software, let’s now ask the question – what is driving the advancements in the modern vehicle such as IVI and ADAS? We posit that it is due to a change in consumer expectations. Vehicle owners and passengers expect the modern vehicle to function like a smart device. Consumers increasingly demand a high degree of customization for their vehicles. Digital features are key to improving the driver experience before and after vehicle purchase. Herein, we will define the key concept called Software-Defined Vehicle (SDV). SDV is about reducing vehicle hardware architecture complexity, by enabling features via software at the start of the vehicle production. SDV is also about delivering new or enhanced features via software post production of the vehicle, and throughout the lifecycle of the vehicle. According to a McKinsey report, “the automotive software market is projected to more than double in size from $31 billion in 2019 to roughly $80 billion in 2030—a CAGR of more than 9 percent.” A SBD Automotive report highlights that “global automakers are spending well over $1 billion per year on software research and development, representing a cost between $1,000 to $3,000 for every vehicle sold.”

Recognition of this trend and its revenue potential, along with budget allocations for software and hardware development made by OEMs, are great initial steps. However, additional new and improved processes and approaches are also necessary to make progress in the SDV roadmap. In this blog post, we describe a specific solution that is expected to help OEMs and suppliers address the automotive industry challenge of limited availability of target systems, and HiL related scalability issues. The approach centers around using AWS based modernized workflows to help support globally distributed teams. The approach can help deliver important end-customer value quickly when using virtual assets. We will start with a quick review of the vehicle architecture evolution, which provides an important linkage to the approach.

Vehicle architecture evolution

Traditional vehicles have a large number of single-purpose, medium-complexity ECUs. System-on-Chips (SoC) are powerful semiconductor devices that make high performance compute (HPC) possible in modern vehicles. Significant advancements have been made in SoCs recently, and the compute capacity in a single SoC continues to improve. Additionally, the Electric and Electronic (E/E) architecture has started to become more centralized and consolidated. Figure 1 highlights the vehicle architecture evolution. It is therefore imperative that the solution to the target system availability problem accounts for both HPCs and traditional ECUs.

Figure 1: Vehicle Architecture Evolution (Source: Continental AG)

Virtual development and Software-in-the-loop testing in the cloud

The automotive industry is using the established AUTOSAR standards for ECU applications. The AUTOSAR standard has two variants, classic and adaptive. The AUTOSAR Classic Platform is designed for the implementation of the control software that typically addresses deeply embedded ECUs such as climate control and doors. The AUTOSAR Adaptive Platform addresses the development of modern automotive software systems such as automated driving, infotainment system and connectivity.

Virtualization of the AUTOSAR applications have been in practice for some time now. Software-in-the-loop (SiL) testing has been made possible on desktop PCs by SoC virtualization vendors. The virtualized SoC on desktop PCs can be used to emulate the actual SoC that is used on the physical ECU. A combination of virtualized bit-parity compatible operating system (OS), and microcontroller abstraction layers provide the core capability to complete SiL testing. Bit-parity is the concept where the code compiled in one environment provides Instruction Set Architecture (ISA) level compatibility, or parity on the target hardware. The end-result is the ability to develop applications for a target architecture in a virtualized environment, without the need for that target hardware.

Scaling via on-premises hardware is expensive, as it does not support a pay only for what you use model. The physical hardware that is purchased results in sunk cost for OEMs as it has been spent and cannot be recovered. AWS can help offer customers a solution to this automotive industry problem. For example, cloud-based automotive ECU application development can be accomplished using AWS Graviton ARM based EC2 instances. These Graviton ARM based EC2 instances have the capability to provide automotive customers with bit-parity for their software builds. AWS also supports development and testing of IVI applications at scale. Android Automotive OS can be used on AWS EC2 instances, to help OEMs develop their infotainment applications. Elektrobit (a fully owned subsidiary of Continental) has immense capability in the IVI area. Elektrobit has a reference Human-Machine Interface (HMI) for HPC cockpit solution, a productivity toolset for Continuous Integration (CI), Continuous Delivery (CD), and Continuous Testing (CT). In addition to these, Elektrobit also has an end-to-end Android Open-Source Project (AOSP) environment, an Android emulation environment, and toolsets for vehicle emulation of AOSP and Android Automotive. Elektrobit is enabling the above-mentioned IVI capabilities on AWS.

Continental Automotive Edge Framework – Development on another level

In 2021 Continental launched its Continental Automotive Edge (CAEdge™) framework. CAEdge is a modular hardware and software platform that connects the vehicle to the cloud, providing automakers and suppliers with a development environment that can help increase efficiency and accelerate software development. CAEdge™ is designed to provide users with the ability to provision virtual ECUs (vECUs) using the new vECU Creator feature. vECU Creator will allow developers to instantiate vECUs of different configurations that are part of a HPC. A virtualized HPC running on AWS, enabled by the new vECU Creator solution, can be visualized as shown in Figure 2.

We will first explain the concept of a virtual ECU (vECU). A vECU virtualizes ECU hardware. Stated another way, vECUs aim at running target ECU code in the cloud, without the need for the physical hardware. A vECU will contain the necessary software modules to simulate the functionality of the real ECU. Elektrobit, together with their strategic SoC virtualization vendor alliances, and AWS can help enable the virtualization of ECUs in the cloud. Elektrobit has a proprietary suite of comprehensive products based on classic and adaptive AUTOSAR, an open-source operating system for high-performance computing (EB corbos Linux), hypervisors, and products for secure and efficient in-vehicle network communication.

Figure 2: A virtualized HPC on AWS, enabled by vECU Creator

Virtual ECU Creator substantially speeds up development

Continental is launching an industry-leading cloud-based virtual application development and testing solution suite, using AWS services.  Continental and Elektrobit, with the support of AWS, are making this innovative solution available to automotive OEMs and their suppliers. vECU Creator is designed to offer developers a range of virtualized hardware and software selection, for base tooling and simulation. After selecting the target chipset (e.g., Qualcomm, NXP) and middleware (e.g., vClassic AUTOSAR, Adaptive AUTOSAR, Android), the vECU is setup on the developer’s AWS CAEdge account with the necessary tools and software components. This allows developers to begin coding in minutes, without having to wait for the physical hardware. vECU Creator will support development of applications across QNX, many Linux distributions, and Android based IVI applications. The Linux distribution support includes Elektrobit EB corbos, Canonical, and more will be supported in the future. Continental is working with market-leading SoC virtualization vendors, enabling vECU Creator to offer a range of virtualized SoC selection. With these combined, the cloud-based vECU Creator will offer a comprehensive solution to develop and test automotive ECU and HPC based applications at scale.

In addition to allowing developers to build automotive applications in the cloud, vECU Creator also has a fully automated test pipeline that is integrated with popular Continuous Integration (CI) systems, such as Jenkins. When triggered by the CI process or when run manually by testers, vECU Creator builds vECUs, and provisions the required test vECU instances automatically to run tests on AWS. Figure 3 illustrates the vECU Creator test pipeline.

Figure 3: vECU Creator – Automated Test Pipeline

vECU Creator’s Key Benefits

vECU Creator will differ from other vECU solutions on several dimensions:

• Value: Unlike other vECU solutions, pricing is simple: tiered, based on use – particularly for existing solutions with a middleware component. The solution can be purchased from Continental via AWS Marketplace when available. The ability to simulate hardware in the cloud (without investing in that hardware to support early testing) also creates cost savings for customers. A unique benefit is the ability to configure vehicle subsystems as shown in Figure 2, not just ECUs, resulting in a much higher parity to the target system. This enables evaluation and comparison of the target architectures.
• Convenience: Users can instantly provision and deploy virtual hardware via CAEdge, and use the vECU Creator simulation module in CAEdge to evaluate and compare different simulation technologies using the same test scenarios. Simulation is included in a seamless and automated workflow as shown in Figure 4.

Figure 4: Simulation workflow

• Expertise: Customers using vECU Creator will benefit from Continental’s / Elektrobit’s automotive expertise, in addition to its other engineering and validation services already available to customers today.
• Selection: Users can access the latest and greatest virtualized, configurable vehicle architecture provided by vECU Creator, mirroring the target hardware. Users are also able to configure vehicle subsystems (and select from pre-existing templates), not just ECUs. This helps enable a customer’s evaluation and comparison of target architectures. Potential use-case for this would be to run different simulation technologies (chip-level, application-level) with the same test scenarios, by just selecting a different vECU target.
• Pre-integrated, one-stop-shop that offers the complete stack required to build a vECU.

Conclusion

Continental continues to extend its collaboration with AWS via new, innovative cloud-based additions to its CAEdge platform, such as vECU Creator. Continental and AWS have announced a Strategic Collaboration Agreement related to vECU. Prior to the launch of vECU Creator, automotive software developers and testers had long wait times for the physical hardware to become available for testing and validation of software. This impacted project delivery timelines. With vECU Creator, developers and testers can provision virtualized hardware on AWS, and pull forward their development and testing activity in the software development cycle. Continental expects that vECU Creator may save anywhere from 6 to 12 months of project delivery time. vECU Creator may also reduce the number of software bugs that are typically discovered by OEMs closer to the vehicle launch. Finding bugs earlier in the development cycle can help automakers ensure their projects stay on schedule, and reduce project costs. Continental, being one of the leading automotive suppliers, has already started using vECU Creator for its projects. It is time for OEMs and other suppliers to realize the benefits of vECU Creator, too.

We invite you to read more about CAEdge here. To learn about how AWS may help lower the cost of software infrastructure, we invite you to experience a hands-on workshop here.