- Shaarmila B and Adithyu Asok
- May 8, 2024
Navigating Over-the-Air Updates on Android Automotive OS
From in-vehicle infotainment systems to advanced driver assistance systems (ADAS), OTA updates play a crucial role in keeping automotive software up-to-date and ensuring optimal performance.
OTA updates in automotive systems refer to remotely updating the software or firmware of vehicle components without physical intervention. They are delivered seamlessly over the air, ensuring that vehicles remain equipped with the latest features, performance enhancements, and security updates. OTA updates play a crucial role in maintaining the optimal functioning of automotive systems without requiring manual installation or user intervention.
Infotainment and driving control are the two main areas where OTA updates for automobiles are extensively being used. Infotainment updates include new features, software updates, streaming services, interface updates, updates to maps and audio enhancements.
Different Categories of OTA
There are two categories based on which the OTA updates can be classified. They are:
- Based on the type of update they deliver and the purpose they serve in the system, the OTA updates can be classified as Software Over-the-Air (SOTA), Firmware-over-the-air (FOTA), Over-the-air service provisioning (OTASP), Over-the-air provisioning (OTAP), and Over-the-air parameter administration (OTAPA).
- Based on the approach used for system updates and how they handle system partitions, the OTA updates can be classified as Non-A/B system updates and A/B (seamless) system updates.
Software Over-the-Air (SOTA) Update:
SOTA updates focus on updating software applications within the vehicle, such as the infotainment system, navigation software, and driver assistance features. These updates offer hassle-free improvements for users, enhancing security and providing access to new features.
One important element of SOTA is the `UpdateManager` class, a utility designed to facilitate the management of app updates via OTA (Over-The-Air) mechanism. It provides functionality to check for updates, prompt users for updates, and handle the download and installation process seamlessly. The updating mechanism includes:
1. Hosting a new version of application and json file (which contains the metadata associated with the application) in cloud.
2. The application running on the device should parse json file to determine whether an update is available.
3. Once the user approves update, the application uses DownloadManager to download the application from cloud.
4. BroadcastReceiver is used to get notified on completion of download.
5. Upon getting download completion notification, we use intent to start the installation activity.
6. This will internally trigger update prompt to the user
7. When the user starts update, the new apk will get installed, version of application has been updated from 1.0.0 to 1.0.1
Firmware Over-the-Air (FOTA) Updates:
While SOTA updates have quickly become common, updates for FOTA are not as easily accomplished. FOTA updates target the firmware of vehicle components, including electronic control units (ECUs), sensors, and actuators. These updates optimize device performance, ensure compatibility with other vehicle systems, and enhance security by fixing vulnerabilities. Nevertheless, FOTA updates carry the risk of bricking devices if the update process fails, requiring careful testing and timely releases from manufacturers. The FOTA gateway, download engine, and update engine collectively form the backbone of the FOTA update infrastructure, enabling manufacturers to securely deliver firmware updates to the vehicles.
Over-the-Air Service Provisioning (OTASP):
OTASP enables seamless activation of new services and updates in vehicles without requiring physical SIM card replacements. While OTASP simplifies service enrolment and management, it may lead to potential service disruptions if not properly managed.
Over-the-Air Provisioning (OTAP):
OTAP streamlines device deployment and management in vehicles, allowing for remote configuration of vehicle settings and features. However, OTAP may pose security risks and require reliable network connectivity for successful implementation.
Over-the-Air Parameter Administration (OTAPA):
OTAPA facilitates dynamic administration of network parameters and configurations in vehicles, optimizing performance under various conditions. Nevertheless, OTAPA requires careful management to prevent misconfigurations that could lead to malfunctions or security vulnerabilities.
Feature | Processes | Advantages | Disadvantages |
Software over-the-air (SOTA) |
|
|
|
Firmware over-the-air (FOTA) |
|
|
|
Over-the-air service provisioning (OTASP) |
|
|
|
Over-the-air provisioning (OTAP) |
|
|
|
Over-the-air parameter administration (OTAPA) |
|
|
|
A/B (Seamless) System Updates
Modern automotive systems, like Android-based infotainment systems, might utilize A/B partitioning for seamless system updates. A/B system updates involve maintaining two separate system partitions on the vehicle’s storage, allowing updates to be applied to the inactive partition while the system is running. This approach ensures minimal downtime during updates and seamless switching between partitions for uninterrupted vehicle operation.
For seamless system updates, there are mainly 3 steps involved. They are:
1. Create OTA Image:
a. OTA image can be created by the default “make” tool provided by the AOSP. OTA image of complete build can be created using the following commands
• “source build/envsetup.sh”
• “lunch aosp_panther”
• “make dist DIST_DIR= dist_output” or
• “ota_from_target_files dist_output/panther-target_files.zip ota_update.zip”
b. It is not always necessary to create full OTA image, we can also create incremental OTA image to include the recent changes. Incremental updates contain only binary patches for files that have changed since the previous version, making them smaller in size. These updates are efficient because they encode only the differences between the old and new versions of files, rather than including unchanged files.
c. To build an incremental update, we need the target_files.zip files from both the previous and new builds. The build process generates an incremental update package, which is significantly smaller compared to a full update package.
• “ota_from_target_files -i PREVIOUS-panther-target_files.zip dist_output/panther-target_files.zip incremental_ota_update.zip”
2. Host OTA image in server
• The new generated OTA image can be distributed by hosting on a file server. The url field in the config Json file should be pointing to the file location.
• “url”: https://files.server/ota-1.zip
• If we want to provide a local file instead of downloading from server, we can modify the url field like
• “url”: file://path_to_ota_file.zip
• The update payload will have metadata and the data. Metadata contains the instructions to update to the new version, instruction such as writing to certain partition, hash information to verify the updating process etc. The data, contains the compressed blob or the binary.
3. Update Application
• SystemUpdaterSample (sample application by AOSP) application is a base sample application by Google, every vendor should take this as reference and implement their own OTA application with add on features.
• SystemUpdaterSample will show list of available updates on the UI.
• User is allowed to select an update and apply it to the device.
• The app will show the installation progress. Resetting the update requests update engine to cancel any ongoing update and revert if the update has been applied. Stopping does not revert the applied update.
.• Once the update is completed, on reboot new changes come into effect.
• To integrate the SystemUpdaterSample into the device, several steps need to be followed.
- The application needs to be added to the device’s configuration by including “PRODUCT_PACKAGES += SystemUpdaterSample” to the required .mk file. Additionally, permissions need to be granted by modifying the required xml file.
- Further configuration involves setting “privileged: true” to Android.bp file to ensure proper functionality.
- Following these configurations, the sample app needs to be built and flashed onto the device.
- Download the OTA packages and push to the device’s directory.
- Configuration files, like “sample.json,” must be modified accordingly and pushed to the device as well.
- Finally, the sample application can be executed on the device.
• If a new build needs to be released, the URL in the config can be modified such that it can download the latest.
• Once the installed, the update manager reads the hashes of whole partition and is compared to the expected hashes received in metadata. If the computed hashes match the expected values, it indicates a successful update with integrity and correctness.
Non-A/B System Updates in Automotive Systems
Non-A/B system updates are traditional methods used by automotive systems without A/B partitions, typically consisting of partitions named boot, system, vendor, user data, cache, recovery, misc. The life cycle of a non-A/B system update involves several steps, including checking for updates, downloading updates, verifying integrity, and installing updates. During the update process, vehicles may prompt users to confirm update installations, ensuring user consent before making changes to the system. Non-A/B system updates may involve some downtime during the update process, but they are essential for maintaining the security and functionality of automotive systems.
The main difference between non-A/B and A/B seamless updates lies in how they handle system updates and partitions:
- System Update Process: Non-A/B updates follow a traditional process where updates are applied directly to existing partitions, while A/B seamless updates involve transferring updates to a separate partition before switching over seamlessly.
- Downtime: Non-A/B updates may involve some downtime during the update process, whereas A/B seamless updates minimize downtime by ensuring the device remains bootable throughout the update process.
- Recovery Partition Handling: In non-A/B updates, the recovery partition may need to be re-flashed with the desired contents from the system partition after updating, while A/B seamless updates handle recovery partition updates seamlessly during the boot process.
Conclusion
OTA updates have revolutionized the automotive industry by offering a convenient and efficient way to keep vehicle software up to date. By understanding the working process, categories, and types of OTA updates ensure the reliability, safety, and compliance of vehicles in an ever-evolving technological landscape. They are not just updates; they are critical component of automotive innovation, enhancing the driving experience and paving the way for the future of mobility.
