Simulating Automotive E/E Architectures in AWS – Part 1: Accelerating the V-Model

Over the last 15 years, the complexity of automotive Electrical/Electronic (E/E) architectures which include Electronic Control Units (ECUs), related sensors, actuators, and wiring inside vehicles has grown. Rather than continuing to add new hardware components to E/E architectures, automakers are shifting towards consolidating smaller, fixed-function ECUs into a larger High Performance Computer (HPC) while retaining a smaller number of purpose-built distributed ECUs. This brings advantages to automakers, including but not limited to, reduction in wiring and weight of the vehicle. With the compute capabilities of these HPCs, automakers are creating entire software platforms with rich new user experiences and frequent software updates. As modern E/E architectures utilize a mixture of HPCs and fixed function ECUs, the interoperation between them must be validated, which is driving an increase in automotive industry demand for virtual validation of entire subsystems.

This blog series is comprised of two parts. In part 1, we explain the trends in automotive E/E architectures and the general concepts and challenges automakers face around simulation of ECU software utilizing the cloud. In part 2, we cover how automakers can use AWS and dSPACE technology to help simulate automotive E/E architectures by utilizing dSPACE VEOS in combination with native ARM for HPC images leveraging AWS Graviton.

Modern Automotive E/E architectures

Recent automotive E/E architectures address the complexity of managing many single function modules by consolidating related functions on domain controllers. These “domain centralized architectures” contain main computational units for each major domain like ADAS (Advanced Driver Assistance Systems) and Powertrain. The domain controllers communicate with one another, through a gateway, to allow cross-domain functions like monitoring status of ADAS applications on a screen related to the infotainment domain. Sensors and actuators are connected to domain controllers through automotive buses like CAN, LIN, or automotive Ethernet.

As automakers consider ways to further reduce the number of components, “vehicle-centralized architectures” are gaining more popularity. The functionality provided within Domain controllers can now further be consolidated and replaced by single digit HPCs. Through high-speed Ethernet connections, the HPCs communicate with Zonal ECUs. A handful of them are positioned at certain geographic points throughout the vehicle and connected to all sensors and actuators around their location. This reduces the wiring inside the vehicle, as outlined in Figure 1.

Figure 1: Conceptual E/E Architecture diagram

The decreasing number of physical ECUs does not reduce testing and validation efforts for automotive software. Vehicle-centralized architectures make more complex automotive software (e.g., cross-domain) possible, enabling additional connectivity (e.g., V2X), continuous software updates, and new software features over the lifecycle of the vehicle.

Automotive Software Development Model

In modern software development, developers use DevOps, which is a combination of cultural philosophies, practices, and tools that increases an organization’s ability to deliver applications and services at high velocity. Continuous integration (CI) is required where developers regularly merge their work into a central repository where automated builds and tests can be run. The key goals of CI are to find and address bugs earlier to improve software quality and reduce the time from feature ideation to release.

However, in the automotive industry, there are design standards in place, such as ISO-26262 for functional safety and ASPICE (Automotive Software Process Improvement and Capability dEtermination, based on ISO/IEC 15504), which help address how designs are conducted for automotive software components. ISO-26262 and ASPICE are based on the V-model which is a development process, based on the traditional waterfall model. The waterfall model is a linear approach to software development in which each phase must be completed before the next can begin. It is used by automakers and suppliers and emphasizes the need for testing and verification throughout the entire development process. The V-model consists of two phases, the left side is the “design” phase, and the right-hand side is the “validation phase”. This is shown in Figure 2.

Figure 2: Automotive V-Model Development Process

During the design phase, developers define the system design, specifications, and requirements up front before validation is started in the test phase. This process can result in delayed release cycles and the late discovery of bugs and errors. It is clear that automakers need a way to use the speed and agility provided by modern DevOps while still supporting the design standards required by the industry.

“Shift-Left”

AWS and dSPACE are working to “Shift-left” the validation and verification of vehicle centralized architecture systems using simulation technologies in the cloud. These simulation techniques help enable the automotive industry to accelerate the verification process typically defined within the V-model, by running test cases in parallel. This involves moving testing activities earlier in the development cycle and enabling it at scale in the cloud, rather than waiting for the right side of the process where problems are harder and more expensive to fix. By catching defects earlier using cloud native DevOps and simulation, engineers can reduce the risk of costly errors, and can help improve overall quality of the software. Shift-left testing also help enables cost reduction and speed to market as it allows for more frequent feedback loops and earlier identification of costly problems.

While the Shift-left model increases the number of tests needed in a full software environment, it does not diminish the need for system and integration using hardware in the loop (HiL) systems. Instead, the Shift-left model simply increases focus on testing earlier in the development cycle. Automotive software development teams can use more agile development methods provided via cloud native DevOps by quickly iterating over the V-model with more cost effective SiL testing. Applying these methods within their development processes improve quality and remain true to the intent of the V-model.

Simulation Model

Before combining fully virtual simulation systems, conducting experiments, and automating tests, all components of the E/E architecture have to be suitable for a virtual environment. For vehicle-centralized architectures, these components include Edge, Zonal ECUs and HPCs. In the case where it is not possible to obtain a virtual ECU, a simulation model can be created to emulate the characteristics of actual sensors and actuators. There are several types of simulation models available and they can be categorized as plant, environment or restbus models. In order to establish communication between all virtual components, it is important to also set up virtual I/O connections and buses where needed. Figure 3 shows a representative block diagram of our target simulation system.

Figure 3: Simulation System I/O and Model Representation

Virtualizing all the control units is key to creating virtual simulation systems. To explain the general approach, we consider the following high-level sketch of four major layers of ECUs and HPCs in Figure 4.

Figure 4: ECU layers block diagram

Instead of depending on the target hardware with specific peripherals and connections, the components need to be enabled to run within development environments decoupled from the target hardware.

To further illustrate, it is helpful to distinguish between two types of operating systems relevant in zonal architectures: OSEK OS-like and POSIX. These operating systems are important in the abstraction of software from hardware dependencies because they abide by standards that allow for compatibility across different embedded platforms.

Edge and Zonal ECUs are commonly built atop an OSEK-like OS. They run on microcontrollers and are very suitable for embedded programming because of their small footprint and optimization for real-time applications. The AUTOSAR Classic Platform is one example of an OSEK-like stack. One key feature of dSPACE VEOS is the simulation of these kind of components.

dSPACE VEOS Cloud Based Simulation

dSPACE VEOS is a simulation platform for ECU software validation. It supports a wide range of different models, such as function models, Functional Mock-up Units (FMUs), virtual ECUs (V-ECUs), and vehicle models, independent of any specific simulation hardware.

VEOS also covers bus simulation needs related to virtual ECU networks as it can simulate automotive Ethernet, CAN, and LIN bus communication, including all bus-specific effects, without additional hardware.

With its open interfaces to connect and use existing tools, VEOS also supports co-simulation setups, where different subsystems can be modeled and simulated in a distributed manner. Co-simulation allows for time synchronization and interactions across different tools.

VEOS runs on standard PCs (Windows and Linux) and is easy to integrate into cloud-based solutions, which gives function developers, software architects, and ECU testers a variety of valuable options for SiL testing.

To simulate Edge and Zonal ECUs, VEOS provides an adjusted OS that allows us to execute the application layer and further parts of the basic software in VEOS and thus in x86 environments.

VEOS provides several modules to abstract I/O and bus drivers. So, we can run OSEK-based components and connect them on I/O and bus level.

Figure 5: Edge/Zonal ECU simulation on AWS

By adjusting the “OS / Kernel / Drivers” layer, it is also possible to avoid chip simulation and achieve reasonable performance of simulations. Of course, the adjustments must not have heavy impact on the behavior to produce meaningful simulation results.

The other category, POSIX, are commonly related to the High-Performance Computers (HPCs) in a zonal architecture. HPCs are closer to IT servers in terms of performance, architecture and provide capabilities to execute demanding algorithms while needing to remain highly reliable.

While being performant they need to be energy efficient and the automakers have adopted Arm-based processors as the computational core of such HPCs in combination with HW accelerators. They are already preferred choice in several domains like in-vehicle infotainment and ADAS and they are expected to become the computational enabler of the SDV (Software-defined vehicle).

AWS Graviton for HPC Simulation

AWS provides custom-built 64-bit Arm-based processors called AWS Graviton, which are designed to deliver up to 40% optimal price performance improvements for cloud workloads. By having these processor options on an increasing number of instance types including with HW accelerator, automotive developers can develop and run POSIX based HPC applications and toolchains using the same Arm intellectual property (IP) and tools that are also used in embedded automotive platforms. This allows for direct execution of the Arm Instruction Set Architecture without the need to cross-compile.

Figure 6: HPC simulation on AWS

However, it is important to note that AWS Graviton based systems are not 100% identical to SoCs and ECUs utilized in the vehicle. For example, there is no physical CAN bus on these cloud systems. AWS and dSPACE are helping to deliver value by unlocking and enhancing SIL capabilities much earlier in the development cycle. Therefore it also follows that HiL validation will remain a requirement. Aspects such as CPU parity can be considered directly and differences in input and output can be further simulated using replayed messaging. Automotive engineers can also simulate or emulate the hardware peripherals that are not present in the system.

For this approach to be successful, we also have to ensure that we have the software vendors developing hypervisors and operating systems utilized in the automotive space are also running on AWS Graviton. Today, we have several Amazon Machine Images (AMIs) that are used in automotive already ported to work natively on AWS Graviton, such as Blackberry QNX and embedded Linux.

Conclusion

Join us for Part 2 in our blog series, in which we teach you how dSPACE and AWS are helping to enable the simulation of automotive E/E architectures on AWS. This blog will go into the technical details of the solution and our approach to achieve scale.

For more details regarding this solution, Please contact dSPACE or AWS to schedule an introductory meeting.