To make the ‘connected car’ a reality, the automotive industry needs to create a secure pipeline that connects to all the devices in the car and enables over-the-air (OTA) updates. Today, automakers offer many car models with a huge variety of options and equipment packages which may need to be replaced or upgraded. What are the implications for the server handling these OTA updates for vehicles in the field?
In order to send out the correct updates, the server must accurately know the current details about all devices in each car. A variety of options and packages of equipment may be available for each model or sub-model. Some of these options or packages may be selected late in the production process, or even post-production in regional distribution or dealer inventories. Even after sale, devices may be replaced or upgraded, sometimes through dealer networks and sometimes through the parts supply channels (whether by independent mechanics or home mechanics).
All of this adds complexity to the automotive OTA environment. Consider a car brand with three different models of cars. If each of these models has five different sub-models, and each of these has ten different trim packages, we are suddenly confronted by 150 different possible combinations of end devices.
In an industry exhibiting this level of complexity, the best approach is a bi-directional data pipeline which standardizes protocols and OTA-related behaviors for each individual device. If each device can report its presence, what software it is running, its status and its OTA-related capabilities, then the server can automate tracking and distinguishing between various vehicle configurations.
Fig. 1: The eSync Alliance proposes a standard OTA data pipeline
The eSync specification for data pipelines provides this capability. Within the eSync architecture, an Agent is written for each device. These Agents take into account the characteristics of all the different devices, while implementing a standard set of behaviors and protocols for the data pipeline. Any two devices may have different resources. For example, an ADAS high-performance computing platform will have more processing, more memory, and a more sophisticated OS than a seatbelt tensioner. Using standard protocols, the agents for these two devices can report their different capabilities, enabling the server to use different techniques to prepare updates for these two devices.
Similarly, the client in each vehicle corresponds with the server in the cloud using a standard set of behaviors and protocols. One of the standard client (vehicle) behaviors is to report its complete ‘tree’ of all agents to the server and to update the information on the server when there is a change.
This process fully automates the maintenance of an up-to-date vehicle database. At every moment in time, the server has current information on each device in every car in its fleet. There is no administrative burden for maintaining the database – each client updates the database on its own if there are changes in its configuration or device tree.
Various devices of an automotive sub-system are normally sourced from multiple suppliers and must work together. Standardization helps ensure the devices all implement the same OTA approach so they can be reached, updated, or rolled-back smoothly and efficiently. Standarization allows certification organizations a level of transparency to help governments bring order to the safety of OTA mechanisms implemented by multiple automotive suppliers. If each vendor pursues their own proprietary OTA method, verification becomes a very difficult proposition.
Any eSync-compliant Server will conform to the standard functional behaviors and messaging protocols. Providing standardization at this level allows portability across public and private clouds, and facilitates consistent capabilities in multiple geographical markets. eSync servers have been implemented on Amazon AWS, Baidu, Microsoft Azure, and Tencent public clouds, as well as OEM-proprietary servers. A car that is marketed in multiple geographic areas can be updated by servers in the local area, according to local policies, even if the server software is hosted on a different cloud or comes from a different vendor … so long as it is eSync compliant.
The eSync standard provides for a distributed policy mechanism. There can be policies set in the eSync Server for each OTA campaign, policy set within each package of software components to identify dependent relationships in versions of software to multiple devices, vehicle policy in the eSync Client and a policy for each edge ECU residing in the eSync Agent for that device. This distributed policy helps OEMs to refine and tailor their OTA mechanisms for different geographies and government mandates. It even can elegantly avoid embarrassing situation for OEMs, when the Server drives an OTA update campaign that is in conflict with an update provided in the repair garage through a diagnostic tester. If an update is provided in a garage that is done for a specific fix that did not make it to the OTA Campaign, the device policy can reject the OTA update campaign until the expiry date is reached for the shop-updated software in the ECU.
OTA Considerations: A blog post series by members of the eSync Alliance, an open industry consortium dedicated to automotive OTA software standards. www.eSyncAlliance.org
About the eSync™ Alliance
The eSync™ Alliance is an industry initiative to drive a multi-company solution for over-the-air (OTA) updates and diagnostics data in the automotive electronics space, potentially saving billions of dollars per year for automakers. By working together in the Alliance, companies will benefit from a simplified development environment made possible by a standardized yet customizable open platform. The Alliance released version 1.0 of the eSync specification in April 2019. A synopsis is available at https://www.esyncalliance.org/downloads/
Excelfore is a member of the eSync Alliance. www.excelfore.com