Overview
OTA (Over-The-Air) technology was first used in the PC and mobile phone industries and has more recently been widely applied in the automotive sector. However, the complexity of in-vehicle communication networks and fragmentation of automotive electronic systems have constrained full-vehicle adoption of OTA. This article examines OTA definitions and use cases, the OTA implementation process, and key "cloud-gateway-vehicle" technologies to provide a reference for engineers involved in OTA design, verification, and production.
1. Automotive OTA: Definition and Use Cases
1.1 OTA definition and categories
OTA stands for Over-The-Air and generally refers to remote wireless update methods. Unless otherwise specified, OTA in this article refers to all forms of remote automotive updates. The prerequisite for OTA is that vehicles have remote network connectivity, and the rapid penetration of connected vehicles has driven OTA adoption.
OTA enables software updates without requiring vehicles to visit after-sales service centers; instead, OEMs can remotely connect to target vehicles and push software updates.
As OTA usage has expanded, several related concepts have emerged according to the update target. Some OTA solutions abstract all updateable software objects into software clusters that range from configuration parameters to entire operating system firmware. The GB standard "General Technical Requirements for Automotive Software Update" covers the OTA concepts below (excluding remote diagnostics).
1.1.1 Software Over-The-Air (SOTA)
SOTA refers to remote software updates at the application level. SOTA downloads and installs application update packages to implement incremental updates of controller functions. It is typically used for infotainment and driver assistance systems. SOTA usually involves small-scope application updates that do not affect core vehicle systems, so prerequisites for upgrades are lower. Incremental update strategies significantly reduce package size, saving network bandwidth and storage.
1.1.2 Firmware Over-The-Air (FOTA)
FOTA covers updates from low-level algorithms to top-level applications without changing hardware parts. Updates are applied by remotely downloading and writing new firmware. FOTA includes updates for drivers, system software, functions, and applications, and is unrelated to hardware replacement.
FOTA affects core vehicle systems, including but not limited to powertrain control, chassis electronics, automated driving, and body control systems. It can change behaviors related to charging/discharging, regenerative braking, acceleration characteristics, and driver assistance logic. In principle, any ECU supporting firmware updates can be covered by FOTA.
1.1.3 Configuration Over-The-Air (COTA)
COTA refers to remote modification of configuration words to change software behavior. Configuration words are data stored on ECUs (identified by DIDs) that can be read and modified via diagnostic commands. They map to vehicle function codes and allow software to enable corresponding features. Common COTA use cases include remotely toggling features, such as software subscription-based capabilities.
1.1.4 Data Over-The-Air / Diagnostic Over-The-Air (DOTA)
DOTA has two common meanings:
- Data Over-The-Air: remote updates of data packages independent of executable software, e.g., map data, voice data, and machine learning models. These updates are often large (multiple GBs to tens of GBs) and proceed independently from software updates.
- Diagnostic Over-The-Air: cloud-based data collection and monitoring that proactively detects vehicle system anomalies to support remote or manual repairs. Triggers can be reactive (user reports) or proactive (periodic collection of network, application, hardware performance, and system state data for analysis).
1.1.5 Everything Over-The-Air (XOTA)
With increasing vehicle intelligence, OTA may extend to external smart devices associated with the vehicle, such as smart keys and AR devices. Some organizations use XOTA to denote all vehicle-related software updates ("Everything Over-The-Air").
1.2 OTA application scenarios
1.2.1 Vehicle lifecycle dimension
From the developer compiling a target version to updating the software on target hardware, software updates span multiple lifecycle stages. Different stages impose constraints on update goals and methods. Many OEMs currently focus OTA on after-sales updates, but OTA offers efficiency and cost advantages across other stages. Typical lifecycle update scenarios include supplier component stage, final assembly, transportation, pre-sale inventory, and after-sales, as described below.
| Vehicle lifecycle | Update purposes and methods |
|---|---|
| Component stage | ECU suppliers' production lines are the earliest nodes to switch to the latest software versions, preventing old software from flowing downstream. At this stage, parts are updated using chip programming tools or supplier-specific tools; OTA is not applicable. |
| Final assembly | Some software can be written at EOL (end of line) test stations, but EOL programming affects line takt time, so OEMs avoid heavy on-line programming. If the vehicle already supports remote connectivity, OTA-based programming at assembly can enable parallel multi-vehicle updates without affecting line stations, improving efficiency. A few manufacturers have implemented OTA at final assembly. |
| Transportation | Vehicles transported from assembly to dealer stock pass through a logistics window. Large update packages that would slow the assembly line can be updated during transport using OTA; however, power supply management and vehicle safety during transport require further consideration. |
| Pre-sale inventory | Dealers often hold inventory requiring software updates before delivery. OTA can automatically sync inventory vehicles to the latest software, reducing delivery delays. |
| After-sales | Historically, users had to visit service centers for software updates. OTA enables users to update anytime via simple operations, keeping vehicles up to date. OTA has become an important tool for improving user retention, addressing software after-sales issues, and enabling service ecosystems. |
1.2.2 Software operations and management dimension
From a software operations perspective, typical OTA use cases include software recall, bug fixes, performance optimization, feature customization, new feature delivery, and paid feature subscriptions.
| Typical application | Description |
|---|---|
| Software recall | When software causes major functional defects (e.g., safety, cybersecurity, regulatory issues), OTA can recall and fix problematic software at scale quickly, reducing impact and cost compared with physical recalls. |
| Bug fixes | Non-critical bugs can be fixed by periodically pushing software updates via OTA. |
| Performance optimization | OTA's convenience makes it feasible to push performance optimizations routinely; this is now a common OTA scenario. |
| Software personalization | Typical COTA use cases where users update parameters (e.g., idle settings, start/stop behavior) remotely to customize vehicle behavior. |
| New feature delivery | OTA enables continuous post-sale feature iteration. The number and frequency of new features delivered via OTA have become important OEM metrics. |
| Paid feature subscription | Derived from new feature delivery, OEMs may offer certain features as paid upgrades post-sale. This creates new revenue opportunities beyond vehicle sales. |
2. Automotive OTA Technical System
2.1 OTA implementation process
Automotive software update essentially replaces the software or data in vehicle ECUs with a new version compiled by suppliers or OEM development teams to achieve intended functionality. The core work is establishing a remote transmission link and enabling the OEM cloud system to remotely update ECU software. To perform accurate, secure, and reliable ECU updates, the OTA system requires a cloud management system to manage software and update targets; the vehicle system must receive and distribute software data and guarantee safe upgrades without specialized technicians.
Figure 2-1: Typical OTA implementation flow (source: AUTOSAR)
A typical OTA framework contains three elements: the cloud OTA platform, the vehicle-side OTA controller, and OTA update targets (ECUs). The cloud platform manages upgrade packages, vehicles, and OTA publication; the vehicle OTA controller downloads packages and writes them to target ECUs; the OTA target receives software and performs self-updates. The basic OTA steps are summarized below.
| Step | Content |
|---|---|
| 1. Package creation | ECU suppliers or OEM development teams compile new software versions and prepare upgrade packages according to agreed formats. |
| 2. Upload | After verification, supplier or OEM software is transferred via product lifecycle management (PLM) or similar systems to the OTA cloud platform for deployment. |
| 3. OTA task publishing | Operators select software and target vehicles and publish OTA tasks. Published software undergoes security processing and is delivered to file servers for vehicle download. |
| 4. Download | The cloud notifies the vehicle OTA controller to perform updates. The OTA controller fetches update information and downloads packages from designated file servers. In some systems, the controller instructs the target ECU to download its required package. |
| 5. Install | The OTA controller writes the update to the target ECU storage according to the agreed protocol. The installation process varies with ECU hardware and communication methods. |
| 6. Verification | Integrity and authenticity checks are conducted before and after installation to ensure data has not been tampered with and the software is not counterfeit. |
| 7. Activation | Depending on ECU structure, activation may include partition switching for dual-partition ECUs. The OTA controller also manages vehicle status to guarantee safe upgrades. |
| 8. Rollback | In case of abnormal updates, the system restores the previous version to keep ECU functionality available. |
| 9. Status reporting | The OTA controller reports update status to the cloud so the platform can orchestrate tasks based on up-to-date vehicle states. Reporting during each update phase enables finer control. |
2.2 OTA cloud platform architecture and key technologies
The OTA cloud platform comprises cloud systems supporting OTA operations, including the OTA server, enterprise IT systems, security services, a web console, and file servers. The platform covers lifecycle management, process integration, remote software distribution, and related functions, forming a software update management system (SUMS).
2.2.1 Cloud platform architecture
Industry designs commonly use a four-layer architecture to achieve loose coupling and high cohesion: front-end presentation, routing/gateway, business services, and data storage. The front-end provides web user interfaces; the gateway and routing layer handle communication between cloud and vehicle; the business layer implements OTA logic such as vehicle and package management, policy and task management; and the data layer stores databases, caches, and large files.
Figure 2-2: OTA cloud service framework
(1) Front-end presentation layer
Following a front-end/back-end separation, the front-end focuses on user interaction and calls back-end interfaces. For the OTA platform, the front-end is the user interaction interface to business services.
(2) Command/control layer
This layer mediates between business systems and the gateway access layer. It receives commands from business systems and places them into gateway-accessible caches, and receives gateway feedback into message queues accessible by business systems.
(3) Gateway access layer
The gateway access layer receives and unpacks data transmitted from in-vehicle terminals and forwards it to caches, queues, and other middleware according to upstream requirements.
(4) Business service layer
The business service layer implements OTA business logic and process management. Core functions include vehicle management, package management, version service, policy management, and task management. It also supports approval workflows, data integration, security services, testing, analytics, and logging. Common services are listed below.
| Common service | Function |
|---|---|
| Vehicle management | Maintain information for all updatable vehicles, including brand, model, configuration, and ECU inventory for each vehicle. |
| Package service | Online management of controller packages and differential package creation. Acts as OTA repository, maintaining software entities for all ECUs across models, including package signing and version relationships. |
| Version service | Baseline version management, HW/SW version control, version dependency management, and mapping of versions to applicable brands, models, and configurations. |
| Policy management | Flexible device group management and delivery condition configuration to support varied upgrade strategies. |
| Task management | Manage upgrade push tasks. Includes task condition setup (target models, upgrade mode, strategy, timing), selecting target vehicles (whitelists/blacklists, VIN import, tag matching), and basic operations (create, pause, cancel). |
| Approval service | Online approval workflows to replace offline software release approvals and improve efficiency. |
| Data integration | Integration with PLM, MES, EOL, DMS, ADS and other systems for version info, vehicle initialization, user and service data synchronization. |
| Information security service | Ensure OTA security by integrating with PKI for package signing/encryption, device identity authentication, and secure communications. |
| Secure access control | Manage session and access control algorithms to prevent unauthorized systems or devices from updating vehicle ECUs, enabling per-ECU access schemes. |
| Testing service | Support OTA testing, covering upgrade strategies, configuration, and tasks to verify expected outcomes. |
| Analytics | Visualize OTA upgrade status and progress, and dynamically adjust push volume to optimize system and after-sales resources. |
| Log query | Provide access to cloud logs, vehicle-cloud interaction logs, and remote vehicle logs. |
| Basic information service | Manage OTA platform accounts, permissions, and platform metadata. |
(5) PKI system
Public Key Infrastructure (PKI) manages digital certificates for issuance, revocation, and validation. In an OTA system, PKI issues certificates for vehicles, devices, and suppliers; supports mutual authentication between cloud and vehicle; and enables package signing and verification to ensure source authenticity and integrity.
(6) External data systems
External systems may include vehicle lifecycle configuration (VLCS), remote diagnostics, software sales systems, and other support systems. OEM R&D determines model-specific software and hardware configurations. When a software update is required, the VLCS identifies affected models and functions, and BOM systems provide software material numbers for version control. Supplier releases flow through PLM for verification and then to the OTA server. New production vehicles can be registered to the OTA platform by integrating MES. Dealer management systems (DMS) may supply dealer and service station information. Remote diagnostic systems provide ECU configuration and status before updates and can trigger OTA patches when issues are detected. Combined with software sales systems, OTA can support paid upgrades and feature monetization.
(7) Data storage layer
Storage includes database clusters, caches, and file storage nodes. Databases store relational data (vehicle and version info), caches improve performance and reduce direct DB access, and distributed storage nodes host large update packages and configuration files for vehicle download.
2.2.2 Key technologies
(1) Security technologies
OTA servers and related enterprise systems face typical cloud threats. Common security techniques used in OTA systems include:
| Name | Key points |
|---|---|
| PKI signing and verification | Upgrade packages and scripts are digitally signed. The vehicle verifies signatures before applying updates. |
| Secure access control | Cloud-side access control services and gateway/endpoint security functions ensure only fully authenticated requests allow ECU updates. |
| Digital certificate authentication | PKI certificates manage vehicle identities and mutual authentication between cloud and vehicle, supporting encryption, signing, and verification of messages. |
| Data security | Establish data security management and lifecycle protection to safeguard platform data. |
(2) OTA technologies
Common OTA functional technologies include package management, script management, upgrade policy management, and upgrade efficiency management.
| OTA technology | Key points |
|---|---|
| Package management | Online control of controller packages and creation/management of differential packages. |
| Script management | Online management of controller upgrade execution scripts. |
| Upgrade policy management | Online management of execution conditions and dependencies (target vehicle/version, vehicle and controller state, timing, signals). |
| Upgrade efficiency management | Policies to improve efficiency and reduce failures, supported by log analysis and iterative development. |
2.3 Vehicle-side OTA architecture and key technologies
2.3.1 Vehicle-side architecture
The vehicle-side OTA includes two main parts: the OTA controller (master) and OTA targets (ECUs). The OTA controller is the vehicle OTA core, implementing reporting, downloading, installation, vehicle state management, and HMI interactions.
Figure 2-3: Vehicle-side functional modules (referencing AUTOSAR UCM)
The OTA controller modules include: OTA manager, OTA client, download manager, installer modules, vehicle state manager, and HMI interface, described below.
| Module | Description |
|---|---|
| OTA Manager | The OTA core managing updates for all ECUs, distributing firmware and instructing ECUs when to update. It verifies vehicle conditions and aborts tasks that do not meet prerequisites, reporting results to the cloud. For vehicle-specific customization, the manager must flexibly define update scope, timing, content, user prompts, and failure handling. |
| OTA Client | Handles communication with the OTA cloud: receives OTA control commands, reports execution results, initiates update checks, and synchronizes update state. |
| Download manager | Downloads required packages and files from file servers, supports breakpoint resume to avoid redundant downloads and reduce bandwidth usage. |
| Installer modules | Write packages to target ECUs. Different ECUs require different installers: FBL installers for bootloader-only upgrades, AB installers for dual-partition AB swap ECUs, and proprietary installers for intelligent ECUs using vendor-specific protocols. |
| Vehicle state management | Ensures upgrades occur in safe states: 1) state detection (battery level, vehicle non-driving state) via monitored signals; 2) state control to restrict non-essential functions and maintain a safe state during upgrade. |
| HMI interface | The OTA controller presents update information and controls via the infotainment display or mobile app. |
(2) OTA controller deployment options
Deployment varies by vehicle E/E architecture and controller upgrade method. In traditional distributed gateway architectures, OTA master placement can be in the telematics unit (TCU/T-Box), the infotainment system (IVI), or the gateway (GW). When TCU/IVI perform ECU flashing, the GW acts as a router and the flashing chain is long. If the GW performs flashing, it shortens the flashing chain but requires additional networking and security arrangements because GW usually does not have direct external connectivity.
Figure 2-4: Traditional OTA master deployment options
To meet high compute and bandwidth demands and the "software-defined vehicle" concept, OEMs are moving to centralized E/E architectures with central compute platforms and domain controllers, flattening the E/E stack to facilitate vehicle-level OTA. Central and domain controllers typically use Ethernet for enhanced data transport and SOA for flexible inter-domain interactions. Regional controller-based OTA deployment can use a central computing unit (CCU) as the master, with two approaches: 1) the regional controller acts as a router for UDS messages while the master upgrades the region and connected sensors/actuators; 2) the regional controller acts as a subordinate master that receives all update files for the region and performs local updates for itself and connected devices.
Figure 2-5: Regional controller scheme
(3) ECU-side architecture options
As OTA targets, ECUs must receive target version data from the OTA master, write it into designated storage, and boot the new version. ECUs fall into "conventional ECUs" and "intelligent ECUs." Each may use single-partition or dual-partition layouts, leading to four main upgrade schemes discussed below.
1. Conventional ECU single-partition (bootloader) upgrade
Conventional ECUs with limited storage often use streaming flash programming: erase the target region and write received data directly to storage without storing the full package locally. Bootloader-based UDS programming is a typical streaming method.
Figure 2-6: Bootloader upgrade scheme
Single-partition schemes require the application partition to be erased before writing new data, leaving ECU functions unavailable during update. Interrupted or failed updates can render functionality unusable. Such updates typically require the vehicle to be stationary and pose challenges for battery-powered upgrades. Despite drawbacks, this scheme remains common for conventional ECUs due to low memory requirements and simplicity.
2. Conventional ECU dual-partition (AB) upgrade
AB partitioning assigns separate storage regions for the running version and the target version. A and B act as mutual rollbacks: while A runs, B is updated. After verification, the ECU boots B; if errors occur, it remains on A. AB can be implemented in three ways: 1) hardware-assisted address remapping (requires sufficient memory and remapping support); 2) software-based activation without address remapping (activation may change entry/exit addresses); 3) external memory-based AB where external storage holds backups during switching.
Figure 2-7: AB upgrade scheme
3. Intelligent ECU single-partition upgrade
Intelligent ECUs use high-performance processors and run modern OSes (Linux, QNX, Android) with file systems and generally have ample storage. They typically store update packages locally and use an update agent and installer. Single-partition schemes include a main system partition and a minimal updater partition plus a cache for packages. Update flow: receive and cache package, decrypt and verify signature, switch to updater partition, install package to main partition, then reboot to the updated main partition.
Figure 2-8: Intelligent ECU upgrade schemes
4. Intelligent ECU dual-partition upgrade
Dual-partition intelligent ECUs have two identical partitions with their own update agents and installers. The system runs on partition A; updates are installed into B without affecting normal operation. After installation and activation, the boot flag switches to B and the system restarts on the new software.
2.3.2 Vehicle-side key technologies
(1) OTA controller
1. Power management
Because vehicle updates can be lengthy and must preserve safety, the system must manage power consumption of controllers and peripherals. When upgrading while the vehicle is off, the existing battery level must be checked and power management strategies applied to differentiate between updating and non-updating controllers and reduce energy draw. If an ECU update fails, it should enter a low-power mode to minimize vehicle energy consumption.
2. Vehicle control
For updates that affect vehicle safety, the update process must maintain a safe state. The OTA controller must be able to control vehicle functions according to update type.
3. Exception handling
The vehicle-side must support rollback, breakpoint resume, and retransmission to handle transmission errors or interruptions.
(2) OTA-related protocols
1. Standard protocols
Standardized processes for flashing and updating simplify development, testing, and integration, e.g., UDS for conventional ECUs and AUTOSAR Adaptive Platform UCM.
UDS (Unified Diagnostic Services) allows external diagnostic tools to connect to in-vehicle buses and transfer data or request controller information. The FBL (Flash Bootloader) specification defines the software architecture and UDS services required for flashing. Traditional ECUs largely use UDS-based flashing.
AUTOSAR Adaptive Platform provides a Software Update and Configuration Management (UCM) service for handling update requests on AP. UCM coordinates package distribution across vehicles to ensure safe and reliable updates.
2. Proprietary protocols
Intelligent ECUs often use vendor-specific protocols: the update agent on the ECU receives the package and control commands from the OTA master or cloud and uses a local installer to perform updates. There is no single standard for these flows and vendor implementations vary.
(3) ECU upgrade techniques
1. Differential updates
Compared with full-package updates, differential updates save MCU resources, download bandwidth, and power. Differential update flow involves extracting the original version, generating a diff between original and new versions, transmitting the diff to the target ECU, merging the diff into the original to reconstruct the new version, and validating the new software before activation.
| Step | Content |
|---|---|
| Original version extraction | Extract the current installed software from the target ECU for comparison. |
| Generate diff package | Compare new and current versions, identify changes, and create a diff package using compression and diff algorithms. |
| Diff transfer | Transmit the diff package to the target ECU; smaller size reduces transfer time and bandwidth needs. |
| Diff merging | The target ECU applies the diff to the current software using a reconstruction algorithm to obtain the new version. |
| Validation and activation | Validate the reconstructed software on the ECU and activate it if checks pass. |
Diffs can be based on text (logical) or binary (physical) differences. Corresponding reconstruction tools on the ECU restore the full package for installation.
Figure 2-9: Differential computation
Figure 2-10: Differential reconstruction
2. Secure boot
Secure Boot ensures that only trusted firmware is executed during boot by verifying each step with digital signatures. Root keys stored in immutable hardware form a trust chain for boot-time verification.
3. Security verification
ECUs must verify integrity and authenticity of installed packages, requiring signature verification capabilities. Traditional ECU flashing often relied on CRC checks for integrity but lacked authenticity verification, leaving risk of unauthorized firmware writes.
2.4 Human-Machine Interaction (HMI)
2.4.1 HMI elements
HMI for OTA is typically delivered via the infotainment system and covers the entire update process: notifications, user confirmation, and key status displays. HMI design must balance regulatory compliance and usability.
| HMI category | Requirements |
|---|---|
| Regulatory compliance | Conform to the GB standard "General Technical Requirements for Automotive Software Update" (GB). |
| Usability | Version information should be visible to users. |
| Upgrade options should be configurable. | |
| Provide clear upgrade notifications. | |
| Before upgrade, users should be able to choose upgrade mode, view download progress, and cancel downloads. After download, users confirm whether to install. | |
| During upgrade, show condition checks and real-time progress; provide clear messages if conditions are not met. If rollback occurs, display rollback status and progress. | |
| After upgrade, indicate success or failure. |
2.4.2 HMI interaction modes
OEMs implement diverse HMI strategies. Six common upgrade modes are summarized below and analyzed for commercial fleet (operated vehicles) and private (non-operated) vehicles.
| Upgrade mode | Commercial fleet | Private vehicle |
|---|---|---|
| Leave-vehicle upgrade | Fleet management platforms can remotely manage upgrades once the vehicle is confirmed unmanned and conditions are met. | Yes |
| Seamless (no-wait) upgrade | No impact if properly implemented; typically achieved with AB partitioning. | Yes |
| Immediate upgrade | Vehicles return to depot and upgrades are centrally scheduled. | Yes |
| Scheduled upgrade | Fleet platforms can authorize and set scheduled upgrade times. | Yes |
| Delayed upgrade | Fleet platforms authorize and schedule upgrades at OEM-designated times (e.g., overnight). | Yes |
| Remote mobile app upgrade | Fleet manager sends notifications; owners use mobile apps to initiate or cancel downloads and view status. | Yes |
References and Source
Excerpted from "Development Status and Recommendations for Remote Updates (OTA) in Intelligent Connected Vehicles".
About the referenced publication
The book was led by several national and industry organizations in China, including the National Intelligent Connected Vehicle Innovation Center, the Defective Product Management Center of the State Administration for Market Regulation, Huawei Technologies Co., Ltd., Shanghai NIO Co., Ltd., China Software Evaluation Center, Xiangyang Daan Automotive Testing Center, the National Industrial Information Security Development Research Center, and the China Academy of Information and Communications Technology, with over 30 organizations participating.
The book examines OTA definitions and technical systems, policies and standards, industry ecosystem, security risks, and testing and evaluation, and provides development recommendations to support policy, standards, and OTA R&D.
