WHITE PAPER

Updating Containers using eSync

Craig Conkling Aurelien Hars

Stergios Zisakis
John Crosbie
Madhav Gudimetla
Mark Singer
Eric Scott
 Updating Containers using eSync
Executive Summary
Any over-the-air (OTA) software update solution requires an application running on the cloud to deliver software
updates to remote edge devices - such as electronic control units (ECUs) inside vehicles. The eSync OTA platform
can update an individual ECU or a cluster of ECUs inside the vehicle. There are various architectures that
automotive Original Equipment Manufacturers (OEMs) pursue to organize the ECUs inside the car – for example,
using domain controllers for all ECUs within each technical domain of the vehicle or zonal controllers for all ECUs
within each zone of the vehicle – and a properly constructed eSync pipeline provides the capability to update one
or all of the ECUs that may come under a given domain or zone.

The control and design of the software update mechanism must be capable of handling several essential
requirements of the automotive industry. As an example, there might be dependent relations between multiple
ECUs. It may be necessary to treat updates in a group of ECUs as one atomic update – meaning that any updates
must be completed to the group as a whole, and partial completion updating only a subset of the ECUs in the
group is not acceptable.

OEMs are fast adopting virtualisation concepts from the personal computing world to the automotive industry,
enabling platform as a service (PaaS) or feature as a service (FaaS) in vehicles. More recent adoptions are in
containers (using popular platforms like Docker and orchestrating software like Kubernetes). An entire domain
controller can be containerised, and the container needs to be updated using an OTA update.

This white paper describes how a containerised eSync OTA software update solution seamlessly updates
containers. The white paper provides the approach and guidelines to update the containers using the eSync OTA
solution and update edge device software. The white paper discusses eSync as a Container, Dependency
Management using popular services, and securely updating containers using eSync.

eSync and Containers

eSync over-the-air (OTA) solution comprises components that reside in the cloud (eSync Server) and inside
vehicles (eSync Client and eSync Agents). The design philosophy behind eSync is the Server-Client-Agent
model. The eSync Server resides and runs from any remote cloud to securely orchestrate software updates to
ECUs. The eSync in-vehicle components are typically a single eSync Client and one or more eSync Agents that
update the vehicle’s edge devices. eSync Client runs on vehicle hardware with the highest power, memory, and
processing capabilities to download software updates from trusted sources. eSync Server and eSync Client
exchange X509 certificates, mutually authenticate each other as trusted sources and establish a secure
communication channel for software updates.

At least one or more eSync Agents run (within eSync Client space or outside it on other hardware) to report the
current software version and securely update their designated ECUs under the prescribed conditions. The in-
vehicle components (eSync Client and eSync Agents) work in conjunction with one or more Policy Services that
describe and define the update process, sequence, method, location of flash tools, and update conditions to
satisfy before updating the ECU.

PUBLISHED BY ESYNC ALLIANCE© July 6, 2022 2

 Figure – 1: Containerised eSync Architecture

The above figure shows the generic containerisation of eSync components in the cloud and inside vehicles. The
cloud orchestration manages the signed containers pushed to a trusted container registry and makes the
endpoint URL details available in metadata stored in the eSync Server database (not shown in the diagram). Many
popular cloud service providers (viz. AWS, Azure, Google Cloud) support the latest containerisation tools (such as
Docker) and orchestration services (such as Kubernetes and OpenShift from RedHat).

It must be noted that the architecture of orchestration and container management in a given cloud infrastructure
more or less remains the same across cloud service providers. On the in-vehicle side, an orchestration module
takes care of downloading the container images from the trusted container registry. The workload agent handles
updating the containers and the ECUs connected to the hardware. It must be noted that the in-vehicle
configuration can be modified to suit any in-vehicle implementation, where eSync Client and eSync Agent can run
on separate containers.

A generic architecture of containerised eSync is shown below.

PUBLISHED BY ESYNC ALLIANCE© July 6, 2022 3

 Figure – 2: Containerised eSync In-vehicle Components

Containerised eSync Server

Describing the cloud side architecture for containerising eSync Server with orchestration is beyond the scope of
this white paper. It is assumed that the eSync Server on cloud is containerised to provide high availability and
provides an interface to accept signed containers from authorised users or via some automated CI/CD workflow.
The eSync Server stores the metadata of the container and pushes the signed and encrypted container images to
a trusted registry. The trusted registry will provide the containers when designated vehicles requests them.

Containerising eSync In-vehicle Components

eSync Client and eSync Agents can run in containers inside the vehicle. It must be noted that in-vehicle
containerisation is independent of the in-vehicle architecture, viz. gateway, domain controller, and zonal
architectures. A container bridge is automatically set up when a container engine is installed on the hardware
where containerised vehicle components run. In-vehicle containers communicate over this container network.

eSync Client comprises Policy Service, Broker, and HMI Service. Depending on the design and requirement, the
eSync Client (and its associated services) and an eSync Agent can run inside a container. The eSync Client checks
for new updates with the eSync Server and receives a metadata configuration file in the Figure - 2. The purpose
of eSync Agent is to update the software of ethernet enabled ECUs. A “Workload Agent” is proposed in this
architecture, responsible for updating the eSync Client container and any other CAN-based ECUs connected to
the domain controller. The figure also shows the HMI service running on separate hardware connected to the
domain controller via the physical layer. The HMI container has been separated from the eSync Client container
to ensure software update status can be handled separately and displayed on HMI. The Workload Agent can also
update the HMI container and other services running in containers on the domain controller.

PUBLISHED BY ESYNC ALLIANCE© July 6, 2022 4

Update Process of Containers using eSync
Verified, tested, signed and authorised users to upload type-approved containers to the eSync Server via an
upload user interface. The eSync Server verifies the user signature, parses and separates the metadata and
container binary, and applies its signature to the container before pushing it to the trusted container registry. The
eSync Server signed metadata is stored in the metadata database inside the eSync Server.

Authorised users can create a new software update campaign using the eSync Server campaign manager user
interface for vehicles to download the new containers. A vehicle running eSync Client establishes secure
communication with eSync Server and checks for updates. eSync Client downloads the metadata from eSync
Server, which has the required information about the new container image, such as its file size, name,
description, version, and trusted container registry endpoint URL. eSync Client checks with its policy service
(about available onboard memory, network, and user consent via HMI interaction) and accordingly coordinates
with the orchestration service to download the update from the trusted container registry. Once the orchestrator
downloads the container, the eSync Client verifies the signature. Accordingly, it sends the payload to the Work
Agent or the eSync Agent to update the container or the ECUs of the domain controller. The HMI Agent reads the
update messages from the virtual network and displays the status of the update (download, install,
success/failure) on HMI.

Container Update Sequence Diagram

Figure – 3: Container Update Process

The concepts of eSync OTA offline updates (garage updates, installing updates from sources like OBDII ports) can
be applied to update containers offline. After trust, the signed containers are transferred to the vehicle via USB
OTG or Bluetooth, and a secure connection is established. Once the container is uploaded, the process remains
as in OTA software updates. At the end of the offline update process, the vehicle technician disconnects the OBD
II connector. When the vehicle comes online, the eSync Client synchronises with the eSync Server about the
current/existing version of container software.

PUBLISHED BY ESYNC ALLIANCE© July 6, 2022 5

A note on eSync and SOAFEE
The Scalable Open Architecture for Embedded Edge (SOAFEE) project is an industry-led collaboration defined by
semiconductor suppliers. SOAFEE allows OEM and Tier-1 developers to write, build and test their native
applications on the cloud, which can then be bundled into containers through the CI/CD process for further
testing and deployment. Using the eSync OTA software update solution, tested and verified containers could be
uploaded and stored in a trusted container registry for vehicles to pull the container images from trusted sources.

Figure – 4: eSync in SOAFEE Architecture

The image on the left of Figure - 4 is the SOAFEE architecture. A modified SOAFEE architecture using eSync is
shown on the right of Figure - 4. eSync Server works with a “mixed criticality aware orchestrator” to deliver
metadata and containers to edge devices seeking new software updates. The eSync Client engages with the
eSync Server using its standard operating process and receives updates to update the in-vehicle components as
described in this white paper.

Conclusion
The white paper presented the container-based architecture of eSync. The software updates are uploaded to the
eSync Server. Metadata is stored in the eSync Server, and the actual encrypted container is stored in a trusted
registry. The document proposed a typical way to update containers inside vehicles with an eSync Client (and its
associated services) and an eSync Agent inside the container. A Worker Agent is responsible for updating the
container and some of the CAN-based ECUs connected to the domain controller. A SOFAEE based architecture
approach has been taken to demonstrate how eSync fits into the upcoming and popular in-vehicle container-
based architecture from ARM.

References
[1] https://soafee.io/

PUBLISHED BY ESYNC ALLIANCE© July 6, 2022 6