How Excelfore Uses the AWS Cloud to Develop and Deliver Continuous Software Updates for Software Defined Vehicles

Over the past two decades, the value of software in vehicles has risen dramatically. Software in vehicles we drive has usually been embedded into proprietary hardware. Updating and improving such software was usually done by bringing the vehicle in for service, and then updating the firmware with legacy and proprietary systems. In a software defined world, such updates now are done remotely without changing the hardware. It can also be done more frequently much like the apps on our smartphones.

A software defined vehicle (SDV) is a vehicle where the experience of owning, maintaining and driving it is increasingly defined by the software running on it. Such vehicles require a software process for configuring it both before and after the Start of Production (SOP). This includes configurations for feature updates, infotainment and comfort, and vehicle hardware parameters.

The SDV paradigm brings important architectural requirements. First, software defined vehicles need consolidated hardware to allow common software workloads to be deployed across different vehicle models. Second, such vehicles need compute resources capable of scaling up for future enhancements and software updates. Third, for running data aggregation and analytics, the entire software ecosystem needs to support a scalable data storage platform capable of collecting and storing massive amounts of data collected from vehicles.

In this post, we describe how Excelfore, an AWS partner, is using the AWS Cloud to provide a solution for delivering continuous updates of software running on software defined vehicles.

Overview of Solution – Excelfore eSync

The following diagram gives an overview of Excelfore’s eSync system on AWS’s cloud computing platform.

Figure 1: Excelfore’s eSync Platform for Building Digital Twins in the Cloud

The eSync server is deployed as a container running on Amazon Elastic Kubernetes Service (EKS). The EKS clusters run on AWS EC2 instances powered by ARM-based Graviton processors across multiple Availability Zones for high availability. These eSync instances integrate with multiple AWS offerings such as Amazon SQS, Amazon Elasticache for Redis, Amazon RDS, AWS KMS, Amazon ECR and Amazon OpenSearch. This integration enables security along with easier control and management of the over-the-air (OTA) solution.

The eSync Client in the vehicle connects to the eSync Server via the eSync Messaging Protocol to pull down updates. The eSync Agent in the vehicle orchestrates software updates. Like eSync Server in the Cloud, the eSync in-vehicle components also run as containers on ARM-based hardware.

Because the eSync cloud environment also runs containers using ARM-based processors, it provides a platform for building digital twins or virtual models of vehicles in the cloud. Software developed and tested for digital twins in the cloud under accelerated production times can be deployed with confidence onto the same compute environment running on vehicles.

New Vehicle Architectures for SDV

We now describe how the eSync Platform facilitates meeting new hardware and software architectures for SDVs.

Vehicle Architecture- Hardware

The market is now aggregating around two Electric/Electronic architectures, Domain and Zonal. There is also a hybrid architecture that combines both Domain and Zonal.

Domain architectures are comprised of physical domains located around the vehicle with the peripherals pertaining to a specific domain physically routed to it. This architecture requires cabling that adds weight.

Figure 2: Domain architecture (Source: NXP^® Semiconductors)

In the Zonal architecture the vehicle is separated into zones with a central compute domain that is usually a High-Performance Compute (HPC) ECU. The HPC is connected through a central gateway (e.g., multi-port ethernet switch) with redundant connections to each of the zones. Each zonal gateway uses Virtual Local Area Network (VLAN) technology. VLANs are used to segment domains into separate virtual networking domains running on shared physical cabling and interconnects which enables more efficient use of these cabling and interconnects.

For a SDV, the Zonal architecture presents a better solution as each zone can more readily run their own virtualized software of the ECUs running on a connected HPC platform on the vehicle. One point to note is that while all the above network architectures are Ethernet-based, CAN-bus is not totally eliminated from the architectures. Within the automotive context, Zonal and Domain architectures can still use a CAN connection to initiate a faster wake up during start up

Figure 3: Zonal architecture                                                                                 Figure 4: Hybrid (Domain/Zonal)

(Source: NXP Semiconductors)

Vehicle Architecture- Software

SDV architectures also need a special software approach for implementing control, status, configuration, software updates and data collection for all ECUs. The goal of such an approach is to use microservices with containers that breaks down the automotive software monolith.

Figure 5: Service and Signal Layer separation in Zonal architectures
(Source: Aptiv)

A microservices architecture defines APIs that software components can call to interoperate across various domains. These service interfaces use common interface standards and an architectural pattern so they can be rapidly incorporated into new applications.

Containers are units of software packaged with code and its dependencies that can easily be run in different computing environments. They provide an ideal solution for meeting the requirements of software-defined vehicles. Just as container packages in the data center can be developed once and then deployed repeatedly on heterogeneous servers, container packages can now also be developed in the cloud and then repeatedly deployed across a heterogeneous fleet of automobiles, provided that they all run a common virtualization platform.

In our microservices architecture using containers, the central compute platform has ECU software running in a container on an HPC instantiated for different domains providing connectivity to the cloud service. Examples of such ECU workloads include infotainment and instrumentation. The majority of ECUs will run as containers on common hardware resources, orchestrated by lightweight Kubernetes K3s, leading to fewer ECU devices in new vehicle designs. This comprises the service layer activities. All ECUs that are connected below the Zonal controllers (e.g., doors, speakers, Lidars, Radars) communicate through and are controlled by physically wired connections.

To ensure compatibility with common platforms with a microservices architecture, SDVs should be equipped with standardized abstractions that other software can easily interface with. This will provide market incentives to innovate for a large market of vehicles across automotive OEMs.

OTA Update using Containers for SDVs on SOAFEE EWAOL

In close collaboration with ARM, Excelfore has built its eSync server, client and agent as containers on top of a SOAFEE EWAOL architecture. SOAFEE is an industry led collaboration of automakers and suppliers whose mission is to define standards for SDVs. EWAOL is a reference implementation of SOAFEE.

In the SOAFEE containerized environment the delivery of software updates in eSync is orchestrated through workload agents. Workload agents are themselves containers that eSync clients pull from the eSync server in the cloud down to the vehicle. The eSync client also resides in a container. The working model is a container that pulls down a container to update other containers. The eSync client and workload agents work on top of the EWAOL layer as shown in Figure 6.

Figure 6: eSync as Containers on SOAFEE EWAOL Layer

Figure 6 references the OpenADKit, distributed by the Autoware Foundation, an automotive trade association dedicated to the creation of open-source autonomous driving stacks. A working implementation of eSync OTA within the SOAFEE EWAOL containerized environment was presented an example workload which was presented as a master class in the ARM DevSummit 2022. [session #1115]

Update to SOAFEE EWAOL to the Edge and a Digital Twin

To optimize the cycle of developing and updating software on containers, a digital twin in the cloud can achieve system parity with the hardware on the edge by running the same container workloads, but on top of the ARM based AWS Graviton processor as shown in Figure 7. Designed by AWS, the ARM-based Graviton processors deliver the best price performance for your cloud workloads running in Amazon EC2. Because automotive edges commonly run ARM processors, AWS Graviton processors offer the ideal platform for SDV development and building digital twins in the cloud.

A digital twin of the vehicle is also available in the cloud, providing a replica of the actual vehicle. Deploying a digital twin provides a major operational advantage to OEMs and Tier-1s for running workloads such as perception, planning, and control.

• The perception workload can take simulated sensor data and produce a set of results
• The planning workload provides the required plan to react to the result sets
• The control workload actually performs the operations of a real vehicle

Once these workloads are tested in the cloud, they can be deployed as campaigns using eSync OTA updates to a set of test vehicles to gather information on the update process. This digital twin provides detailed insights to OEMs and Tier-1s before actually deploying the jobs on a large fleet of vehicles.

Figure 7: Digital Twin

The advantage of creating a digital twin is that an automotive OEM or Tier-1 no longer needs to complete development of the hardware target platform before beginning development and testing of the associated in-vehicle software. And even when the hardware becomes available, the digital twin in the cloud still provides availability, scalability and elasticity for developers – characteristics that are not as easily available in real hardware evaluation kits. These advancements are akin to VLSI design modeling that are so integral to chip designs today.

With these advancements OEMs can achieve the following benefits:

• Cost Savings: By reusing the same eSync software across model platforms, OEMs can achieve 40-80% savings on OTA integration costs. One early OEM, FAW of China, realized savings of 60% for its second model program enabled by the reuse of eSync Agents for ECUs from the first program.
• Improved Performance: By adaptively compressing OTA data by 90% and higher, eSync accelerates software updates while reducing data transmission costs.
• Streamlined Operations: Through the integration of OTA-ready components from eSync Alliance members OEMs can choose from a marketplace of solutions that conform to an industry standard.

Conclusion

Through digital twins running on SOAFEE’S EWAOL architecture, Excelfore’s eSync platform enables developers from across the automotive ecosystem to define and deliver the SDV experience through a standard architecture and platform.

To begin developing and updating software for SDVs, developers can use the eSync software development kit available on the AWS Marketplace.

For container updates, eSync container workload agents are available from GitHub.

SDVs are now both the present and future of the automotive experience. There is no better time than today to begin developing.