Simulating Automotive E/E Architectures in AWS Part 2: Solution in Action

This is the second blog post in our 2-part series that provides guidance on how to simulate automotive Electrical/Electronic (E/E) architectures in AWS. In part 1, we discussed the trends in automotive E/E architectures and the general concepts and challenges facing automakers around simulation of Electronic Control Unit (ECU) software utilizing the cloud. In this part 2, we cover how automakers can use AWS and dSPACE technologies to simulate automotive E/E architectures by using AWS and dSPACE VEOS in combination with native ARM for HPC images using AWS Graviton.

dSPACE is an AWS Partner which provides tools and expertise for development, testing, and validation mainly used in the automotive industry. In its 30+ year history, dSPACE has become a global technology leader for simulation and validation solutions, especially known for its Hardware-in-the-Loop systems. dSPACE is continuously extending its portfolio for Software-in-the-Loop solutions which includes VEOS, a product that is designed to simulate complex networks of virtual ECUs and SIMPHERA for cloud-based, scalable simulations which can be used across domains including ADAS (Advanced driver-assistance system) /AD (Autonomous Driving systems).

The VEOS-Graviton solution demonstrates how development teams can test virtual ECUs using dSPACE’s VEOS, a Virtual Ethernet bus designed to emulate automotive E/E architectures. This helps allows for early validation of input and output signals under various test scenarios and communication between sub-systems on AWS.

The dSPACE and AWS E/E Simulation Solution

dSPACE has solutions to virtualize edge and Zonal ECUs and run them in VEOS on Amazon EC2 x86 based instances as well as the possibility to bring the HPC to AWS Graviton instances. There is a lot of communication between HPC and Zonal ECUs as also outlined in the Modern Automotive E/E Architectures section in part 1 of this blog series. For the simulation solution setup, communication between VEOS (virtual Zonal ECUs) and AWS Graviton (virtual HPC) needs to be established.

This set up requires the virtual Zonal ECUs to be connected to a virtual Ethernet channel in VEOS. This simulated Ethernet channel is independent of any host Ethernet devices. To enable communication, it’s also necessary to connect the AWS Graviton instance representing the HPC to the virtual Ethernet channel running VEOS. Please note that VEOS is installed on a separate instance.

dSPACE has developed a bridge component to handle communication between VEOS and the AWS Graviton instance. The bridge consists of two parts: One part runs in VEOS and communicates on the virtual Ethernet and the other part runs on the AWS Graviton instance. The bridge can capture and inject Ethernet frames on OSI Layer 2. This enables the production Ethernet communication stacks of the components in the simulation.

One common communications protocol used in the automotive industry is SOME/IP (layer 7 of the OSI model). It is a service-oriented protocol based on UDP/IP and TCP/IP (layer 3 and 4 of the OSI model). As the bridge forwards Ethernet traffic on a lower level, it is possible to use production SOME/IP stacks and investigate behavior of SOME/IP protocols using the dSPACE bridge component.

dSPACE also offers a solution to create SOME/IP Restbus models which could for example represent a virtual Zonal ECU when it is not yet available. This enables either simulating the Zonal ECUs in VEOS or having the Restbus models to communicate with the AWS Graviton instance. A diagram of how the bridge interacts with the two simulation instances is shown in Figure 1.

Figure 1: High level Architecture showing dSPACE Bridge Solution

It’s also possible to simulate edge ECUs and set up further virtual buses (CAN, LIN) in VEOS. Complex simulation systems can be created that consist of all types of ECUs and models that are needed to simulate Zonal architectures as shown in Figure 2.

Figure 2: Architecture showing all model and simulated ECU variants on AWS

In terms of synchronization between VEOS and AWS Graviton instances, the solution shown in figure 2 relies on a loosely coupled approach as of today. This approach allows the development team to easily switch between automotive components as needed.  On the AWS Graviton instance, a real-time OS is utilized, as commonly used on automotive HPCs. VEOS helps approximate real-time behavior and calls tasks of the virtual components on-time.

An architecture diagram of the proposed solution on AWS is represented in Figure 3. It describes how development teams can utilize dSPACE ControlDesk to interface with the various Amazon EC2 instances that represent logical representation of the virtualized ECUs in our architecture.

Figure 3: AWS Architecture diagram of the simulation solution

In addition to this architecture, the individual components can also be containerized to bring added scalability using the AWS cloud components, such as AWS Batch, Amazon Elastic Kubernetes Service, and AWS Step Functions.

Solution in Action

To demonstrate the VEOS-Graviton solution, AWS supported dSPACE to create a simple but vivid demo project: a simplified heater controller.

AWS and dSPACE worked with Elektrobit, an industry-leading provider of automotive software components. Elektrobit’s EB Corbos product line includes an AUTOSAR runtime for adaptive applications. Elektrobit and AWS set up an environment to execute this runtime and related adaptive applications on AWS Graviton instances. More detailed information about development and execution of adaptive applications with EB Corbos in the AWS cloud are available in this blog article.

In this demo, Elektrobit implemented the heater controller as an adaptive application utilizing EB Corbos and deployed it to an AWS Graviton instance. The heater component is representing the main HPC of a vehicle in the demo.

Instead of separate virtual components for Sensor/Actuator, Edge and Zonal ECUs, all of the functionality is put together into a Restbus model and run in VEOS. An Android instance represents the HMI, a digital cockpit UI which also runs on an AWS Graviton instance. The heater controller – or more precisely the EB Corbos communication stack – exchanges data with the Restbus model through the bridge component. It connects the Host Ethernet of the AWS Graviton with the Virtual Ethernet in VEOS.

A representative diagram of the demo setup is shown in Figure 4.

Figure 4: High level architecture of the E/E Simulation Demonstration

When the simulation starts, the developer can set a target temperature through the digital cockpit UI based on Android. The controller application takes the target temperature and also receives the current temperature from the Restbus model running in VEOS. It computes heater power and transmits it to the Restbus model. The controller application on AWS Graviton and the Restbus model in VEOS represent a closed-loop scenario.

The Restbus models offers an “Interior Temperature Service”, the controller application a “Heater Controller Service” and the digital cockpit UI a “Target Temperature Service”. During the initial phase of the simulation, it’s possible for the developer to monitor related SOME/IP Ethernet communication and see service discovery as well as event subscription messages. Users can also use software from dSPACE to monitor messages being exchanged between components. For example, dSPACE ControlDesk is another product from dSPACE for monitoring, experimentation and measurement. ControlDesk enables connecting to VEOS and interacting with the simulation system. Traffic on the virtual Ethernet channel can be analyzed as shown in Figure 5.

Figure 5: ControlDesk Ethernet Traffic View

When the SOME/IP communication is working and all event subscriptions were successful, the target temperature can be changed using the Android digital cockpit UI. In this case, it is possible to step through a range of 16 to 28 degrees Celsius with a step size of 0.5 degrees using two buttons as highlighted in Figure 6.

Figure 6: Android Automotive HMI Screenshot

ControlDesk also allows measurement of the current temperature. It is a signal that is read from the Restbus model and plotted during simulation in a ControlDesk view. Whenever the target temperature is changed through the UI, the controller application adjusts the heater power to have a matching current temperature. This is shown in the ControlDesk plotter in Figure 7.

Figure 7: ControlDesk graph view of vehicle cabin thermal model output

With the connection of VEOS and AWS Graviton, users of the solution such as developers can create simulation systems that represent automotive E/E architectures including multiple HPCs running native application code.

At first, users can conduct test runs to check if the simulation is starting or if there are unexpected crashes, errors, or warnings. Issues can be identified in individual components (like in a Virtual ECU or HPCs) and related initial input signals or bus frames that may be causing unexpected behavior. In either case, it is possible to debug and resolve the issue using the virtual environment.

Through interface tests conducted by validation teams, it is possible to check if all components can communicate with one another correctly. One example on the network level is investigating service-oriented communication between HPCs and their counterparts. If there is a mismatch in the SOME/IP configuration of an HPC and a Zonal ECU, it will become obvious in the simulation system. By investigating the Ethernet traffic developers and testers can understand the root cause and fix the configuration. Similarly, the behavior of further protocols (like DDS or MQTT) can be investigated to identify and fix potential issues with the configuration.

Fault-injection tests can be used to check robustness of systems when data is corrupted or distorted. There are different options for components running in VEOS to manipulate the data exchanged with further components, like adding offsets to signals or dropping Ethernet frames. This way, it is also possible to inject errors into HPCs running on AWS Graviton, analyze their behavior, and consider a more robust behavior.

Interactive or Automated

There are two primary approaches to conduct different tests:

1. Manually, through experiments or interactive access.
2. By using test automation.

For experiments, development teams can interact with VEOS using well-established interfaces (XIL API) or tools (like ControlDesk). This grants access to signal and bus levels where measurements can be taken to help understand the behavior of the system. When users connect an AWS Graviton instance to VEOS, they can choose to implicitly interact with the HPC, like measuring and stimulating the model in VEOS that is part of a closed-loop setup with the HPC software stack on AWS Graviton. Different layouts created while conducting experiments, can be reused for HIL environments later.

To run different tests frequently, automotive developers can utilize test automation tools like dSPACE AutomationDesk. By creating different test routines (like setting input signals to certain levels, comparing resulting output signals against reference values), developrs can create different test cases which can become part of pipelines for CI or CT (Continuous Testing).

AWS allows development teams to scale test executions by running tests in parallel on different instances. dSPACE tools like VEOS and AutomationDesk are suitable to run in cloud environments at high scale.

With SIMPHERA, dSPACE provides a cloud-based solution to create, run, and evaluate validation test suites for various vehicle functions. It also handles the creation and parameterization of simulation systems and orchestrates them to execute a number of test cases efficiently on a custom number of execution nodes. SIMPHERA’s primary focus is scenario-based tests that provide an understanding of the behavior of ADAS and AD software.

Figure 8: AWS Reference architecture for dSPACE SIMPHERA

Conclusion

In this blog, we introduced a new concept to connect dSPACE VEOS with AWS Graviton instances to simulate state-of-the-art automotive E/E architectures in a cloud environment. We outlined how the concept works by describing a demo that dSPACE, AWS, and Elektrobit put into operation. Lastly, we explained how automotive software developers and testers can benefit from this approach to conduct different tests in a fully virtual and scalable environment.

AWS and dSPACE plan to improve implementation details and will investigate further use cases such as AV/ADAS domain in order to provide additional quick reference guides for customers. If you develop or need to test automotive software including HPCs, the VEOS-Graviton connection can deliver immediate value in creating a virtual environment for integration and testing while using native application code. This can provide opportunities to help reduce costs and time-to-market in an overall development process or validation strategy.

Please contact dSPACE or AWS to schedule a live demonstration of the VEOS-Graviton E/E simulation solution.