Cloud Architecture

A Cloud-Native Environment for Distributed Automotive Software Development


Car drivers have become users that expect new and updatable features and a digital user experience in addition to driving comfort and safety. OEMs are thus committed to lay the foundations for faster innovation through a concept called Software-Defined Vehicle (SDV). This blog post demonstrates an example of how ETAS and AWS collaborate on cloud-native environments for distributed automotive software development, which we see as an important step towards enabling SDVs.

Current in-vehicle software is tightly coupled with the underlying hardware and this slows down the pace of the software evolution. Future electronic and electric vehicle architectures will also provide centralized High-Performance Compute (HPC) units where software innovators will be able to develop vehicle functions abstracting the specific vehicle hardware. The software will be a collection of loosely coupled modules that adopt a service-oriented architecture. This change is not without challenges and together with additional supply chain constraints in place, it takes smart solutions to pave the way towards customer centricity.

To lead the way in the SDV transformation, ETAS and AWS are combining automotive and cloud knowledge. Starting with in-car security and scalability of testing, ETAS and AWS presented a cloud-based co-simulation environment for in-vehicle distributed function development at the ETAS Connections 2023 event. In this blog, we describe the vision behind the project, show a demo walkthrough, and provide technical details on how we have built it.

Vision

In an industry where hardware perfection has been the primary focus for decades, software is now taking over and introduces unprecedented new possibilities as well as new challenges to bring exciting features into series production vehicles. ETAS, a leader in the automotive software business, has acted on this transformation with a major company relaunch in 2022, targeting a leadership role in the race towards software-defined vehicles – with offerings for operating systems, development, cloud, data, security, and end-to-end solutions.

The growing importance of software in mobility systems will come with new challenges of designing and running applications in a distributed vehicle infrastructure, including short-term updateability, and shortest-possible development cycles. Cloud solutions will be driving factors to solve these challenges, and early collaborative software development environments will be essential to achieve a reliable system behavior and short time-to-market cycles. One topic which is addressed by AWS and ETAS is cloud-based micro-processor technology with heterogeneous software stacks for Advanced Driver Assistance Systems and Automated Driving (ADAS/AD), which are on their way to extend the existing micro-controller architectures.

With AWS Graviton processors, and the recently announced Qualcomm Co-Innovation, AWS is enabling environmental parity between in-vehicle and cloud. AWS services for DevOps, software development and AI/ML open up new opportunities for automotive leaders like ETAS to rehost to the cloud an increasing number of development stages that so far have been heavily dependent on physical assets, such has prototypes and HILs, accelerating a shift-left movement.

Overview of the Solution

The cloud gives automotive software developers the possibility to create a personal virtual hardware and software environment within minutes that can be shared with collaborators and connected to a CI/CD pipeline. ETAS and AWS have built a proof-of-concept for a virtual environment that can be used to develop and test a demo application controlling a step motor position. This application runs on an Eclipse SDV Leda distribution and communicates to a SOME/IP service which represents an ETAS AUTOSAR Adaptive stack application. The latter communicates via CAN messages to a virtual Electronic Control Unit (vECU).

The prototype combines AWS Graviton and x86 Amazon EC2 instance types, AWS Cloud Development Kit (AWS CDK) to model the cloud virtual environment, ready-to-deploy Amazon Machine Images (AMIs) with ETAS’ ETAS RTA-VRTE middleware, and the open-source project Eclipse SDV Leda. Together with additional managing, networking, and access services, this gives us the possibility to define a scalable, heterogeneous, and distributed compute infrastructure with automotive software stacks. It also lets you easily login and control the virtual system via a web browser and SSH.

Architecture

Figure 1 below shows an overview of the architecture of this prototype. The user journey is numbered from [1] to [5] and will be referenced this way in the upcoming paragraphs. It starts with a project administrator, who connects to a management user interface (UI) [1] which acts as the single point of entry to the service. There, the project administrator can choose a number of parameters to customize the virtual environment to suit the developers’ needs. The chosen parameters are fed into the AWS CDK application [2] that finally deploys an AWS CloudFormation stack.

Figure 1 Technical Architecture Overview

Figure 1: Technical Architecture Overview

The CloudFormation stack takes only few minutes to deploy the required resources and the software developer can then securely connect to an Apache Guacamole server, a clientless remote desktop gateway within their browser [3]. From there, they can interact via SSH with their target compute resources hosted in an Amazon VPC Private Subnet [4].

The management UI allows to monitor the state and properties of the deployed compute resources including metrics like, e.g., CPU utilization or use-case specific signals [5], which are useful for project administrators and software developers.

Target infrastructure

The virtual environment has three distinct Amazon EC2 instances ([A], [B] and [C] on Figure 1):

A. StepMotor vECU
This instance executes a Functional Mock-Up Unit (FMU) model for the step motor ECU and communicates with the step motor service via CAN frames over an IP protocol. Based on an x86 Amazon EC2, the instance runs a Linux OS distribution.

B. StepMotor Service

This instance provides a SOME/IP service to control the step motor and communicates with the StepMotor vECU above via CAN frames. The service represents an ETAS AUTOSAR Adaptive application and is powered by an Amazon EC2 Graviton instance.

C. StepMotor Application
This instance runs the vehicle application that ultimately controls the step motor position. The vehicle signals are abstracted via the standard-based Vehicle Signal Specification (VSS). The underlying distribution is Eclipse SDV Leda that runs on an Amazon EC2 Graviton instance.

The AWS Graviton family of processors, based on Arm64, offers a similar CPU architecture found in many embedded automotive platforms. This enables a cloud-native development approach. Tools can produce binary artifacts that can be executed unmodified both in-vehicle and in the cloud.

To speed up the deployment of each virtual environment, the different Amazon EC2 instances are created from custom AMIs. These AMIs include the operating system, middleware, frameworks, and the related configurations. In order to spin up Amazon EC2 instances at deployment time where use-case-specific application and configurations are required, we have used cloud-init directives passed via EC2 user data. The EC2 user data can be generated dynamically using AWS CDK and depends on the parameters chosen by the project administrator.

Communication

Communication between the instances within the Private Subnet relies on 2 protocols:

  • CAN is a vehicle bus and a message-based protocol used in the automotive industry.
  • SOME/IP is an automotive/embedded communication protocol which provides service-oriented communication over an IP-based network.

As SOME/IP relies on multicast for service discovery, we decided to add an AWS Transit Gateway to the deployed infrastructure. Transit Gateway natively supports multicast and Internet Group Management Protocol (IGMP), and serves as a managed multicast router, facilitating one-to-many communication in an Amazon VPC.

By adding the private subnet of the attached VPC to a Transit Gateway IGMP Multicast Domain, clients can dynamically join and leave a Multicast Group by sending IGMP messages. In addition, when IGMPv2 is enabled, any AWS Nitro instance can both send and receive traffic. Thus, every time a new Nitro instance is added to the private subnet, it can automatically start communicating with the other existing ones. This removes the need to manually setup a new network configuration which accelerates the developer experience.

Demo Walkthrough

The demo shows three use cases all provided via a WebUI (Virtual Mobility Platform Manager) using the Virtual Mobility Platform API (see Figure 1):

Define, configure and deploy the Step Motor demo [1 and 2]

Figure 2 Define, configure and deploy the Step Motor demo

Figure 2: Define, configure and deploy the Step Motor demo

Directly access your Amazon EC2 instances [3 and 4].

Figure 3 Directly access your Amazon EC2 instances

Figure 3: Directly access your Amazon EC2 instances

Modify simulation properties and monitor the signal of the step motor position [5]

Figure 4 Modify simulation properties and monitor the signal of the step motor position

Figure 4: Modify simulation properties and monitor the signal of the step motor position

Signals like the motor position are exported to Amazon CloudWatch as custom metrics, added to a CloudWatch Dashboard and embedded in the WebUI.

Conclusion

Combining the broad range of AWS services and solutions, such as AWS Graviton and CDK, together with ETAS RTA-VRTE middleware, and the Eclipse SDV Leda open-source project, it is possible to create a cloud-based environment for in-vehicle distributed function development. AWS gives you the possibility to create with a personal virtual hardware and software environment within minutes and to access it with a web browser. To share this environment across project collaborators and connect it with a CI/CD pipeline are the logical next steps.

A variety of imaginable paths lays in front of us, and we would like to take your feedback into considerations when we move forward. Feel free to contact ETAS or AWS for a discussion and demo of the solution, and share your pain points and most relevant use cases.



Source

Related Articles

Back to top button