A Data Pipeline for Effective Automotive OTA: Five Key Aspects of the eSync System

Technology News | January 11, 2018

By Christoph Hammerschmidt

OTA (Over-The-Air) updating is attractive to carmakers as a way to update the software in a car. The traditional auto industry mechanism of warranty recalls or service advisories are expensive for carmakers and inconvenient for car owners. OTA updates can allow a carmaker to fix software problems remotely at minimal cost and time. OTA also can be used as a mechanism for new revenues through subscription-based OTA service plans, or sale and delivery of after-market performance improvements. OTA updating can also allow carmakers to initiate the manufacturing of new models sooner, with fewer delays, as the latest software can be installed after the vehicles roll off the production line.

But to achieve these benefits, carmakers need an OTA solution that meets the particular needs of the automotive market. Automotive OTA is more complex than OTA used for other markets like computers, set-top-boxes or smartphones. It may start with a head unit that appears similar to a PC or smartphone. But within a car there are also dozens of other processors in the various ECUs (Electronic Control Units) and sensors, with different capabilities, running a variety of operating systems, on several different types of automotive networks.

To address the unique requirements of the automotive market, Excelfore has developed the eSync™ System, a unified system for vehicle-to-cloud networking. The eSync System provides a secure and robust solution for managing both OTA data push to, and diagnostic data pull from, any number of processors in a single vehicle.This article discusses five key aspects of the eSync System, and how these aspects address the needs of automotive OTA updating.

Pipeline from the Cloud to the End Devices

The eSync System uses a three-part architecture, with server software in the cloud, client software as the hub of eSync-related communications in the vehicle, and software agents at the ECUs or sensors. This server-client-agent architecture provides a coherent pipeline from the cloud all the way to the end devices in the vehicle.

Systems drawn from non-automotive markets are often based on simpler server-client architectures, and do not reach to the end devices in the car. They must rely on unrelated data management processes and pipelines within the vehicle to extend the OTA process to end devices.

The eSync architecture allows great flexibility in how the capabilities of the eSync System can be configured in any given car. The client can be resident in a head unit, a network gateway/switch, or a TCU (telematics control unit). The agents allow eSync-compliant ECUs, sensors, and actuators to be added, replaced, or removed from the vehicle system quickly, with minimal integration effort needed on the eSync system.

The eSync System architecture even allows for multiple isolated OTA or diagnostic domains within the vehicle if separation is desired by the carmaker, allowing for example separate eSync clients for safety-critical ADAS (Advanced Driver Assistance System) or motor control, each managing their own set of agents.

There are many benefits from having a coherent pipeline from the cloud all the way to the end devices. It is easier to provide bidirectional communications so that end device status is reported back to the cloud, it is easier to establish end-to-end security, and it is easier to ensure that the cloud-to-car solution is scalable to reach dozens, or even hundreds, of end devices in the car.

Bidirectional Pipeline from the Cloud to the End Devices

The eSync system creates a data pipeline that provides data flow in both directions. It can push data down to the end devices in the vehicle, for OTA updates. And it can pull data up from the end devices in the vehicle, for diagnostic and telematics services.

Agents created for each eSync-compliant end device manage both the updating process and the status gathering process. Even the OTA process makes use of diagnostic capabilities, as agents provide status and capabilities information to the client. The client assembles the information and provides a current ‘manifest’ of eSync-compliant end devices on its network to the cloud server, which then uses that information to guide the OTA processes to the vehicle.

This approach has several benefits:

Improved OTA cycle: Prior to an OTA update, the eSync system provides valid data of the state of the end device; during an OTA update the eSync system compresses and encrypts the files to be transmitted according to the reconstruction and decryption resources of the end device; after an OTA update the eSync system validates the successful completion of the update
Data-driven prognostics: data from end devices feeds into the server, providing the database for diagnostics and predictive analytics
Smart learning: the closed feedback loop of status-update-new status-new update drives enhanced efficiency and performance improvements

Bidirectional End-to-End Security

OTA systems need a strong focus on cybersecurity, and should aim for a coherent ‘end-to-end’ security structure. Attackers can intrude anywhere between the OTA server in the cloud and the end device, and should not be able to read or manipulate any of the transmitted data, nor insert any malicious data of their own. The security system should also provide defense-in-depth, so that if one element is compromised the damage cannot spread.

To meet these requirements, a system must include cryptographic protocols tailored to the resource constraints of embedded systems. Sufficient protection exists only if the validation used for the cryptographic measures are appropriately distributed.

The eSync System provides layered bidirectional validation and distribution of cryptographic keys. All clients in the fleet must be validated by the server, and the server must be validated by all clients in the fleet. An additional layer of cybersecurity is created within the car, where all agents in the car must be validated by the client, and the client must be validated by all the agents in the car.

All communications can be encrypted in the eSync System. Communications over the air are typically encrypted using AES-256, a security protocol rating by the US Government as sufficient even for highly-classified material. Communications from the client to agents within the vehicle may use this same high level of encryption, or less complex encryption schemes, depending on the decryption resources available in the various end devices. The system also uses SHA-256 (Secure Hash) to create a secure digital ‘fingerprint’ of the original data file in the server, so that the update agent at the end device is able to verify after the many steps in the process — compression, encryption, transmission over the air, transfer over the in-vehicle network, decryption and decompression — that the resulting file has not been forged, spoofed, or in any way corrupted, and is in fact an exact duplicate of the original authorized file on the server.

End-to-End Compression

In the eSync System, data can be compressed from end-to-end. Files are compressed using mechanisms that are appropriate to each of the specific end devices being updated. This optimizes not only the bandwidth from the cloud to the vehicle, but also the bandwidth and reconstruction time inside the vehicle. The process relies on the bidirectional nature of the eSync data pipeline, making use of current information on the resources of the end device available to the server in the cloud.

Multiple Integration Points with APIs

The eSync System is built from many middleware components that work together to create the bidirectional data pipeline, and each component has well-defined APIs (Application Programming Interfaces). The interface between the agent and the client is built on APIs. The client-to-cloud interface is built on APIs. Similarly, the eSync cloud servers have APIs to interface with carmakers’ or third-party databases. They also have APIs for the cloud-based application front-end, which provides the user interface for creating OTA campaigns or examining diagnostic data. These provide clear and well-defined integration points.

By providing multiple integration points with well-defined APIs, Excelfore has created an environment for many companies to participate in the eSync ecosystem. Carmakers can combine head units, ECUs, sensors, and actuators, from multiple sources, into a vehicle system with a single coherent data pipeline from the cloud all the way to the end devices, and can have high confidence in the integration effort and schedule.

Bringing it all Together

Let’s look at an example of how the eSync System works in practice.

On power-up, the update agent for a particular ECU provides its status to the eSync client, including its resources, the version of software it is running, and any diagnostic or error codes from the ECU self-test. The various ECUs in the car, and the head unit, do not necessarily come from the same vendor, but instead can come from any number of vendors offering eSync-compliant devices.
The eSync client brings together all agent information into an up-to-date manifest of every eSync-compliant device in its network. It then reports the manifest to the eSync server in the cloud.
The server has a record of every eSync-compliant end device in every eSync-compliant vehicle in its fleet. The record is never more than one power cycle old, and can be updated at any time through an interrogatory to the vehicle.
When the time comes for an OTA update, for example updating software in a given ECU to version 3, the eSync server has a record of which vehicles have that ECU installed and operational, which ECUs currently have version 2, which are still on version 1, and even if any of the vehicles already have version 3. The eSync server also has information on the processing resources available for that particular ECU in the different sub-models in the fleet, which may have different in-vehicle network configurations. Using Excelfore’s adaptive delta compression engine, the eSync server can create as many different delta files as required to bring the whole fleet up to version 3, minimizing bandwidth, transmission costs, and vehicle downtime.
Using the bi-directional pipeline, the eSync OTA update process ends with each agent reporting its new status. This confirms that there has been no failure in the OTA process, and verifies that the correct version of the software is now installed and that each agent’s ECU reports no errors.

Conclusion

While automotive OTA updates may at first glance appear similar to OTA in smartphones or computers, it is clear there are many challenges to address in order to provide a secure, efficient system that can handle multiple devices in each vehicle, over the many vehicles in a fleet.

The eSync System provides a coherent pipeline from the cloud all the way to the end devices in the vehicle, giving carmakers confidence that their OTA updates can be managed effectively.

About the author:

Shrikant Acharya is Chief Technology Officer of Excelfore Corp. He holds 11 patents in the areas of mobile devices, apps & services, and connectivity. Acharya holds a bachelor’s degree from Birla Institute of Technology and Science (BITS), Pilani, India, and an MSEE from the University of Texas at Arlington.