Accelerate Automotive Collaboration using Interconnected Virtual Embedded Development Targets on AWS

The development of modern vehicles requires extensive collaboration between automotive original equipment manufacturers (OEMs) and their multi-tiered supplier network. During the integration phase, an OEM and its supplier tiers verify that all components fit with one another and satisfy the OEM’s requirements. This phase is mostly performed towards the end of the vehicle development lifecycle and is marred by dependencies on hardware and software development lifecycles, late detection of defects and cost overruns. This leads to delays in OEM vehicle’s start of production (SOP).

In this blog, we showcase an architecture featuring two virtual components in the form of Amazon Machine Images (AMI) from different AWS Partners and customers which are available through the AWS Marketplace, namely Panasonic Automotive vSkipGen™ and ETAS RTA-VRTE StarterKit. The first benefit of the architecture is that issues related to software, communication and component interfaces are identified and fixed earlier in the in-vehicle software development lifecycle by the OEM when performing integration of virtual components in the cloud. This avoids costly rework later. Second, suppliers can enable continuous integration and continuous testing without revealing their respective intellectual property (IP), bringing automation in the verification and validation phases without exposing source code nor data. Third, AWS’s pay-as-you-go model helps customers reduce upfront capital expenditure on expensive hardware targets (early hardware samples), by introducing on-demand provisioning of the virtualized hardware equivalent. Ultimately, virtualization of components and their secure interconnectivity helps enable improved collaboration and accelerate vehicle (software) development.

Typical vehicle project setup

OEMs work closely with multiple Tier-1 suppliers that deliver major systems to the OEM, including powertrain, chassis, interior, infotainment, and related electrical and electronic (E/E) components. OEMs work alongside double-digit number of Tier-1 suppliers during the design process, and Tier-1 suppliers manage another double-digit number of lower tier suppliers providing sub-components. This multi-level supply chain enables OEMs to focus on vehicle integration and brand identity, and reduce costs while using specialized supplier expertise. In parallel, the suppliers are responsible for their scope of work. Therefore, close coordination between supplier tiers is imperative for a successful vehicle program.

However, OEMs and Tier-1 suppliers have in-house software expertise and manage software interfaces that are not written to standardized automotive conventions. Tier-2/3 suppliers must seamlessly integrate their software components with Tier-1 supplier’s electronic control units’ (ECUs) hardware and software. As a result, software integration poses risk of failing due to incompatibilities across suppliers.

As vehicle launch approaches, Tier-1 suppliers deliver prototypes for OEM integration testing, to identify issues that may need design changes. Any OEM requirement change cascades back down the supply chain and creates long turnaround cycle across the Tier-N suppliers to update, integrate and validate the software with expected quality criteria. This entails many failures due to late integration, miscommunication, weak requirements, incompatible solutions, and interfaces, leading to delays in OEM vehicle’s SOP.

Going software-first and shifting the development cycle left by using virtualization

Virtual embedded development targets (vEDTs) are designed to replicate the functionality of physical ECUs, cockpit domain controllers (CDCs), zonal compute units (ZCUs) and high-performance compute nodes (HPCs). Virtualization helps OEMs and suppliers decouple hardware and software development lifecycles, and start software development and integration testing earlier in the vehicle lifecycle (commonly referred to as “shift-left”), even before the physical target hardware is available.

vEDTs from OEMs and suppliers securely connect and communicate using automotive protocols on top of AWS’ network, virtualizing the in-vehicle communication between physical EDTs. This establishes a virtual electrical and electronic architecture (vEE) or a virtual vehicle (sub-) system in the cloud. Using vEDTs and vEEs, OEMs and their suppliers can integrate and test earlier to help identify and mitigate cross-supplier interface incompatibilities and software issues. vEDTs also lower the barrier for innovation in automotive software development, introducing on-demand provisioning and a pay-as-you-go model. Additionally, vEDTs based on ARM aarch64 Instruction Set Architecture (ISA) execute at bit-parity on AWS Graviton processors, in comparison to lower efficiency instruction translation approaches of simulators like QEMU.

Architecture Overview

This architecture highlights the potential of an OEM using vEDTs and AWS services to help enable more seamless collaboration between its developers and two of its suppliers – in our case, ETAS and Panasonic Automotive (PASA). This is reflected by the three AWS accounts on the architecture in figure 1.

In this case, vEDTs run on Amazon Elastic Compute Cloud (EC2) instances securely inside Amazon Virtual Private Clouds (VPCs). Multiple vEDTs running in their respective supplier’s VPC are interconnected using AWS Transit Gateway to form a virtual vehicle E/E architecture.

We show that by replicating physical targets as vEDTs in isolated environments, a cockpit application developer and an AUTOSAR Adaptive application developer can develop, integrate, and test software without sharing their respective source code and data. Different parts of the architecture are numbered from [1] to [8] and will be referenced this way in the upcoming paragraphs.

Figure 1: Technical Architecture Overview

OEM Environment

The OEM account has 2 virtual development environments. The first one [1] features ETAS ISOLAR-VRTE, a design tool for AUTOSAR Adaptive Applications and configuration of AUTOSAR manifest. It also comes with an XRDP server, an open-source implementation of Microsoft’s Remote Desktop Protocol (RDP), allowing an AUTOSAR Adaptive developer persona to graphically connect to the environment. This stack is available as an AMI on the AWS Marketplace, offering a 1-click deployment on supported Amazon EC2 instances. The second one [2] features Kanzi Studio, provided by Rightware, to design user interfaces for instrument clusters, head-up displays, and infotainment systems. The AMI also brings in NICE DCV, a high-performance remote display protocol designed to provide a secure way to deliver a remote desktop experience from the Amazon EC2 instance, with a desktop client or directly in the browser.

Once satisfied with their latest modifications, each developer persona can immediately build, push and test their code (via SSH) on their respective vEDT:

• For the AUTOSAR Adaptive developer, a t4g EC2 instance [3] (AWS Graviton 2 processors, ARM v8).
• For the HMI developer, a g5g.metal Amazon EC2 instance [4] (NVIDIA T4G Tensor Core GPUs and AWS Graviton 2 processors), featuring the Panasonic Automotive vSkipGen™ AMI, available on the AWS Marketplace.
  Collaboration between OEM and its suppliers

As shown on the architecture (Figure 1), both vEDTs run in separate AWS accounts, owned respectively by ETAS and Panasonic Automotive (PASA). The secure communication between AWS accounts is made possible with AWS Transit Gateway (TGW) and AWS Resource Access Manager (RAM). But this setup brings another advantage: not only does it allow cross-account communication, but also cross-region. This means that from an OEM point of view, they could have. their development team in the US collaborating with ETAS in Germany and with PASA in Japan. Below are examples of the steps to enable such a setup between the OEM AWS account and one of the supplier’s accounts (e.g. ETAS AWS account):

1. VPCs should have non-overlapping CIDRs.

2. In OEM account, create a TGW [5] with multicast support enabled (it will be used in later steps). All other parameters can be left as default.

3. In OEM account, create a TGW attachment [6] from the shared TGW to the VPC in which the virtual development environments are running.

4. As part of the TGW attachment creation process, choose a subnet that sits in the same Availability Zone as the subnet containing the virtual development environments. It can be the subnet containing the virtual development environments.

5. In OEM account, use RAM to share the TGW with ETAS account.

6. In ETAS account, use RAM to accept the TGW sharing.

7. In ETAS account, create a TGW attachment [7] from the shared TGW to the VPC in which the vEDT is running.

8. As part of the creation process, choose a subnet in which to create the transit gateway VPC attachment that sits in the same Availability Zone as the subnet containing the vEDT.

9. In OEM account, navigate to Transit gateway attachments to accept the TGW attachment.

10. In OEM account, update the route table associated with the private subnet containing the virtual Development Environments with a route such as: Destination = [ETAS account VPC CIDR] and Target = [TGW Attachment].

11. In ETAS account, update the route table associated with the private subnet containing the vEDT with a route such as: Destination = [OEM account VPC CIDR] and Target = [TGW Attachment].

12. In ETAS account, update the Security Group of the vEDT with an inbound rule allowing SSH traffic from Source = [OEM account VPC CIDR].

To achieve the triparty setup shown on the architecture, replay steps 4.-11, replacing ETAS AWS account details with the details of the 2nd supplier (PASA account).

Cross-Supplier Collaboration

The combination of AWS Transit Gateway and AWS Resource Access Manager also enables communication between the two suppliers’ accounts, while remaining managed and enabled by the OEM. In this architecture, the vEDTs need to communicate via SOME/IP, a communication protocol that the physical embedded targets use in the vehicle. As SOME/IP relies on multicast for service discovery, rely on the already-available TGW to natively enable cross-account (and cross-region) multicast and Internet Group Management Protocol (IGMP) support. Following are detailed steps to enable such a setup between the three accounts (using the same naming convention as in the previous section):

1. In OEM account, create a TGW multicast domain:

a. Specify the TGW from OEM account.
b. Enable IGMPv2 support. IGMPv2 support enables dynamic membership management for a multicast domain. Hosts in associated subnets in VPCs can join and leave multicast groups on demand using IGMPv2 protocol messages.

2. In OEM account, use RAM to share the TGW multicast domain with ETAS and PASA accounts.

3. In ETAS and PASA accounts, use RAM to accept the TGW multicast domain sharing.

4. In ETAS and PASA accounts, navigate to TGW multicast domains, select the shared multicast domain, and create an association [8] between:

a. The TGW Attachment created in step 6. of the previous section.
b. The subnet in which the vEDT is running.

5. In OEM account, navigate to TGW multicast domains, select the multicast domain, and Accept the associations with the attachments from ETAS and PASA accounts.

6. In ETAS and PASA accounts, navigate to TGW multicast domains, select the multicast domain, and go the Groups tab. Click on Create group, input a Group IP address within the 224.0.0.0/4 CIDR range (we will use 224.0.0.16 as an example) and select the Elastic Network Interface (ENI) of the vEDT. Finalise by clicking Add group members.

7. In ETAS and PASA accounts, update the Security Group of the respective vEDTs, with an Inbound rule allowing a Custom Protocol of Type 2 (which corresponds to IGMP) from Source = 0.0.0.0/32. This allows the IGMP query. Additionally:

a. In ETAS account, update the Security Group of the vEDT with an Inbound rule allowing All UDP Traffic from Source = [PASA C VPC CIDR].
b. In account C, update the Security Group of the vEDT with an Inbound rule allowing All UDP Traffic from Source = [ETAS account VPC CIDR].
c. If specific restrictions for outbound traffic are needed, have a look at the minimum required rules here, and for Network Access Control Lists (ACLs) here.

With this cross-supplier setup, an OEM and one of its suppliers can evaluate their code modification on both a given target and on the whole system without exposing any of their respective source code.

Additional notes

The use of AWS Resource Access Manager helps empower the OEM to control exposed resources and the communication between the three accounts. However, note that in step 1. of the Collaboration between OEM and suppliers section, the OEM could enable auto accept shared attachments. This would automatically accept cross-account attachments that are attached to this transit gateway, hence removing steps 5. and 8. In the Collaboration cross-supplier section, the OEM could also enable auto accept shared associations. This would automatically accept cross-account subnet associations that are associated to this TGW multicast domain, hence removing step 5.

AWS Transit Gateway currently supports IGMPv2. Depending on the underlying hardware and OS configuration of the Amazon EC2 instance, IGMPv3 might be enabled by default on the required ENI. On Ubuntu, IGMPv2 can be enforced with:

sudo sysctl -w net.ipv4.conf.[NETWORK INTERFACE].force_igmp_version=2

or:

sudo su

echo “2” > /proc/sys/net/ipv4/conf/[NETWORK INTERFACE]/force_igmp_version

To test the multicast setup, we downloaded iperf on the EC2 instances under test. A detailed walkthrough can be found here. Run the server (receiver):

iperf -s -u -B [MULTICAST GROUP IP ADDRESS] -i 1

And run on the client (sender):

iperf -c [MULTICAST GROUP IP ADDRESS] -u -T 3 -t 20 -i 1 -b 200M

Outlook

vEDTs help lower barriers to experimentation and democratize access to powerful capabilities, creating a more collaborative environment that can help support the automotive industry’s shift towards software defined vehicles (SDV). AWS Transit Gateway is designed to securely interconnect these vEDTs to create a virtual vehicle E/E architecture, using in-vehicle services discovery mechanisms like multicast across VPC boundaries.

In the future, even local Hardware-in-the-Loop (HiL) benches can be integrated into this setup using AWS services such as Amazon Direct Connect, to help provide more uniform access to Software-in-the-Loop (SiL) and OEMs’ HiL environments.

Conclusion

Virtualization and cross-supplier collaboration help deliver substantial benefits to OEMs, such as being able to identify and fix software and integration issues earlier, and avoid costly late-stage rework. The degree of automation in continuous integration and testing pipelines is increased. Code changes can propagate without the need for hardware shipments, flashing units and other maintenance tasks that consume development and testing time for automotive software today. Innovations like Panasonic Automotive vSkipGen™ and ETAS RTA-VRTE StarterKit, together with AWS services and capabilities, will help reshape traditional processes and unlock unprecedented potential through more secure collaboration across the automotive supply chain.

Learn more about AWS offerings at the AWS for automotive page, or contact your AWS team today.