In-Vehicle Networking Requirements for OTA Updates
March 12, 2020
Over-the-air (OTA) technology is becoming increasingly common in today?s cars. With a bidirectional wireless connection to a server in the cloud, it handles both updates and data gathering.
Over-the-air (OTA) technology is becoming increasingly common in today’s cars. With a bidirectional wireless connection to a server in the cloud, it handles both updates and data gathering.
But, of course, a vehicle is not just one device. In order to link them to a central server, we need end-to-end networking to define data pathways between all ECUs and sensors within the car.
The value provided by building such a data pathway is clear. Recall costs, life-cycle vehicle health management, diagnostics, predictive analytics, efficiency, or autonomous driving all improve with connectivity. Customer retention, new revenue generation through post-sale upgrades and features-on-demand are additional benefits.
The in-vehicle network (IVN) is at the core of the connected car. Stand-alone technology domains are to be confined to history – the future is a pathway of communication links to each device.
However, the exact topology and technology of the in-vehicle network is a topic of significant debate. Are we done with MOST? How much of the car will use Ethernet? Is there a place for Ethernet AVB, or do we need TSN? What is the place of Flexray? Of LIN? Does CAN expand or recede in the future? If we consider the question from the perspective of the entire industry, our answer must be “all of the above,” at least for the next several years. Across the industry, we should look for ways to integrate hybrid IVN environments with multiple network technologies into functional automotive systems.
As the choice of network technology is evolving, so is today’s market we must integrate hybrid IVN environments with multiple network standards. The challenge is to create a single OTA pipeline even though we cannot yet agree on a common network or operating system.
A Common OTA Messaging Protocol
The answer lies in an architectural approach that eliminates the unique differences of the various networks, busses, Oss, and even devices that are present in today's cars. To standardize the OTA pipeline, we must implement a common message protocol that is located above the level of the network or bus interface, whilst having the necessary components to convey the information necessary to complete transactions between the server in the cloud, and an In-Vehicle architecture with a client to master the OTA processes, and agents which abstract the ECUs, sensors, or other edge devices.
Fig. 1: The eSync OTA data pipeline standardizes the In-Vehicle Client-Agent architecture.
Automating IVN OTA Integration
This standardization bridges the heterogeneous IVN environment, creating a pathway for many cross-platform integration capabilities, such as device mapping (or topology tree) across all connected devices. It replaces the difficult and manual tree mapping process with an automated interrogation approach for all devices with a common methodology.
Adding and removing features, or even devices, becomes a direct and easily accomplished process of messaging, without significant integration engineering – during development, at deployment, and after delivery. This enables faster deployments and equipment package feature enhancements, with secure and complete asset inventory management.
Distributing the OTA Workload
Another opportunity arising from standardizing a client–agent architecture is parallel tasking. The bulk of the OTA task work can be done by the agents, distributed throughout the car, rather than in a single OTA master device. With a server possessing all the information regarding the OTA capabilities of each agent, delta files can be constructed for the reconstruction resources reported by each device. The client can push these deltas over the IVN to the agents, which perform their reconstructions and re-flashing in parallel. This shortens vehicle downtime for multi-ECU updates. The same concept having all the information on the server also allows encryption to reach the edge devices for enhanced security.
IVN integration is improved, with greater awareness of vehicle topology and asset revision management, done by a distributed client-agent architecture using common messaging protocols. All devices, networks and OSs appear to the server as a uniform set of agents.
There is growing recognition that OTA must reach all programmable devices in the car. But today, there is a bewildering proliferation of proprietary OTA approaches. It is now time for the industry to explore how a common data pipeline can be built from the cloud to the end devices in the car. This is the fundamental principle of the eSync Alliance, an open trade association formed by companies rooted in the automotive industry.
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/
Molex is a member of the eSync Alliance. www.molex.com
eSync is a trademark of the eSync Alliance. More information about the eSync Alliance is available at www.eSyncalliance.org