Safety domains, both active and passive, are undergoing faster development than almost any other area in the automotive industry, with strong growth of advanced driver assistance systems (ADAS) and substantial investments into autonomous driving from all major OEMs.

These new functionalities share a few common characteristics:

 - They use multiple sensors utilizing various technologies to recognize the world around the car

 - They take control of the vehicle for the driver (including braking, steering and accelerating)

 - They use complex algorithms to capture what has been learned in real life

This makes them ideal for updating via over-the-air (OTA) updates, however, today the safety domain is usually not OTA-updatable.

Managing Multiple Device Updates

ADAS functionalities usually require complex systems combining sensors with central engine control units (ECUs) to analyze data and make decisions, and intelligent mechatronics to convert these into actions.

This complex setup puts a focus on configuration management. OEMs typically spend a lot of time and resources on quality assurance and testing to ensure that a given configuration of multiple devices will perform correctly.

When an OTA update is required, it is necessary to maintain full coherency of the system configuration. This means it is necessary to move from one known, tested, and fully verified state, to the next. It is not acceptable to end up with a mixed configuration with various devices in alternative states, as this would never pass the test.

Consider an example with two cameras and one radar (Fig. 1). If the camera updates go well but the radar update fails then the complete ADAS sub-system must be reverted to the last known, tested and verified state.

Fig. 1: The integrity of dependent relationships among multiple devices must be ensured before an OTA pipeline can be used to update the ADAS or safety system domains.

This is a key requirement for updating the ADAS domain. There must be mechanisms to group together updates of multiple devices and sub-systems, and to treat grouped updates as a single transaction, i.e. to succeed, or revert to the previous state if unsuccessful, together.

Update Policy Control

Updating safety devices requires extra attention. For example, while a map can be updated while a vehicle is in motion, updating a braking ECU while a vehicle is in motion is unacceptable. In the case of the braking ECU, we would install updates only when the vehicle is in a state with a speed of 0, engine OFF and the parking brake or transmission lock ON. This means OEMs need to define policies that set the conditions for starting updates…for the entire vehicle or for individual devices.

The policy creation can be manual, but when lives are at stake, we also need a mechanism built into the device to establish a policy for updating critical ECUs, so that the ECU ensures that an absolute minimum number of preconditions are met prior to beginning the update.

This is a clear and compelling case for using the concept of an agent, whereby safety-related policies are installed in the ECU and consistently followed for updates to that ECU…regardless of vehicle model or the levels of training or attention of the OTA administrators.

Finally, individual ECUs in the safety domain are probably not aware of the interaction of the driver with the user interface in the cockpit. For example, has the driver given permission for the update to start? Has the driver been notified that the brakes are in mid-update, and that the driver must not start the car and drive at this moment? Standardization helps here by providing consistent APIs that can be the used by the vehicle's HMI.

Overall, industry-wide standardization will help ensure that OTA updates of safety-critical devices are handled efficiently and securely, with a bi-directional pipeline such as eSync providing the data transport mechanism required.

__________________________________________________________________________________________________________

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

• https://www.embedded-computing.com/home-page/ota-updates-requirements-for-the-server-in-the-cloud
• https://www.embedded-computing.com/home-page/in-vehicle-networking-requirements-for-ota-updates
• https://www.embedded-computing.com/home-page/how-automotive-infotainment-can-benefit-from-ota-updates
• https://www.embedded-computing.com/home-page/keeping-cars-safe-with-ota-updates
• https://www.embedded-computing.com/home-page/managing-the-complexity-of-updates-for-multiple-automotive-systems
•  https://www.embedded-computing.com/home-page/keeping-connected-cars-safe-and-secure

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/

ZF Friedrichshafen AG is a member of the eSync Alliance. www.zf.com

eSync is a trademark of the eSync Alliance. More information about the eSync Alliance is available at www.eSyncalliance.org