Delta OTA Updates: How OEMs Reduce Update Size and Flash Time

Transmitting a full ECU firmware image over cellular costs bandwidth, time, and money. A gateway ECU firmware image can exceed 500 MB. A 1 GB infotainment update transmitted as a full image consumes 1 GB of cellular data per vehicle per update campaign. Across a fleet of 50,000 vehicles, that is 50 terabytes of data transfer for a single update, a cost that scales linearly with fleet size and update frequency.  

The global automotive OTA delta update software market reached USD 2.45 billion in 2024, growing to USD 13.62 billion by 2033 at a CAGR of 21.5% (MarketIntelo, 2025), driven by one straightforward engineering reality: transmitting only the changes between software versions is always faster, cheaper, and less disruptive than transmitting the entire binary.  

That is the core argument for delta OTA, and as vehicles become more software-defined and update frequency increases, it shifts from a cost optimisation to an operational and engineering necessity.   

Full OTA vs Delta OTA: What Changes 

Full OTA (Firmware Over-The-Air) transmits the complete firmware binary image to the ECU. The bootloader verifies, erases, and writes the entire flash partition regardless of how much of the software actually changed. This is simple to implement and easy to validate but operationally expensive at scale. 

Delta OTA transmits only the binary difference (the patch) between the version currently installed on the ECU and the new target version. The patch is generated at the OEM backend using a binary diffing algorithm applied to the source and target firmware images.  

The ECU bootloader reconstructs the target firmware using the currently installed firmware image together with the received delta patch. Depending on the ECU architecture, this reconstruction may occur in a secondary flash partition, scratch memory, or other OEM-specific update strategies before the final firmware image is validated and activated. 

Consider a practical example: updating a 1 GB infotainment image using a delta package of 70 to 150 MB reduces network transmission by hundreds of megabytes per vehicle (Excelfore, 2026). At fleet scale, this translates directly to campaign completion time, data cost reduction, and vehicle downtime per update. 

The operational advantages over full OTA are immediate across three dimensions: 

• Bandwidth: delta patches for typical maintenance and security updates represent 5 to 20% of the full image size, reducing cellular data consumption by 80 to 95% per vehicle per update; the actual ratio depends on the proportion of code changed between versions 
• Flash time: smaller payloads download faster and require fewer flash write cycles, reducing vehicle downtime during update application, critical for commercial fleet operators where downtime is lost revenue. Although Delta OTA significantly reduces download time, patch reconstruction introduces additional CPU processing on the ECU. For most production ECUs, the reduction in transmission time far outweighs the reconstruction overhead, resulting in a substantially shorter overall update duration compared to full-image updates. 
• Campaign scalability: the same cellular infrastructure that struggles to push full image updates to 100,000 vehicles simultaneously can push delta patches to millions, making fleet-wide update campaigns practical on standard 4G networks without scheduling constraints 

Binary Diffing Algorithms: The Engine Behind Delta OTA 

The quality of a delta OTA implementation depends critically on the binary diffing algorithm selected. The algorithm determines patch size, ECU-side RAM consumption during patch application, and processing time on the target microcontroller. These three variables have direct trade-offs, and the right choice depends on the ECU’s hardware constraints. 

bsdiff  

bsdiff uses a suffix array approach to identify differences between binary files and is specifically optimised for compiled executable code, producing very compact patches. Its key constraint is that the diff generation process, which runs on the OEM backend server rather than on the ECU, requires up to 17 times the source file size in RAM. The ECU-side patch application tool, bspatch, has a far lower memory requirement of source file size plus target file size, making it viable on mid-range ECUs. For resource-constrained microcontrollers where even bspatch’s combined source-and-target RAM overhead is prohibitive, HDiffPatch is the better choice. 

Xdelta3 / VCDIFF  

Xdelta3 uses a linear-time sliding window algorithm producing patches in the standard VCDIFF format (RFC 3284), enabling interoperability with any VCDIFF-compatible toolchain. Its lower memory footprint makes it suitable for mid-range ECUs where bsdiff’s RAM demands are prohibitive. 

HDiffPatch  

HDiffPatch combines bsdiff-level compression quality with significantly lower memory requirements. Its HPatchLite variant is specifically designed for embedded systems and microcontrollers, with a patch application engine that can run on as little as 1 KB of RAM. HDiffPatch is increasingly the algorithm of choice for resource-constrained automotive ECUs where both patch size and RAM budget are binding constraints. 

ECU-Side Architecture: What the Bootloader Must Support 

Delta OTA is not solely a backend problem. The ECU bootloader must be designed to support patch application from the ground up. Three architectural requirements are non-negotiable: 

• Sufficient RAM for patch engine: the patch application algorithm runs entirely in ECU RAM during the update. The bootloader must allocate a contiguous RAM region large enough to hold the patch engine, the source firmware read buffer, and the output write buffer simultaneously. For HDiffPatch, this can be as low as 32 to 64 KB; for bsdiff-based approaches, it may require 512 KB or more. This constraint must be defined at ECU hardware selection, not at software integration 
• A/B partition management: the patch is applied to an inactive memory partition while the ECU continues running on the current firmware. The partition switchover occurs only after the complete new firmware image passes integrity verification. This eliminates the risk of a bricked ECU from a failed or interrupted patch application, and is a mandatory requirement under AIS-190 for OTA-capable ECUs 
• Source version verification: before applying a delta patch, the bootloader must verify that the currently installed firmware exactly matches the source version the patch was generated against. Applying a patch intended for v1.2 to an ECU running v1.1 produces a corrupted output. Version pinning via a stored firmware hash checked before patch application prevents this class of failure entirely 

ElectRay’s Secure Flash Bootloader is architected for delta OTA from the ground up, with configurable patch algorithm support and A/B partition. 

Patch Validation and Security: Same Bar as Full Image OTA 

A delta patch is a binary artifact that modifies ECU firmware directly. Its security requirements are identical to a full firmware image, not lighter. The fact that the patch is smaller does not reduce the consequence of a malicious or corrupted patch being applied successfully. Two security requirements are absolute: 

• Cryptographic signing and verification: every delta patch must be signed by the OEM at the backend using a private key held in a Hardware Security Module (HSM). The ECU bootloader verifies the patch signature using the stored OEM public key before any patch application begins. An unsigned or incorrectly signed patch must be rejected and the event audit-logged. This is required by AIS-189 and UNECE R155 as part of a certified Cybersecurity Management System (CSMS) 
• Output integrity verification: after patch application produces the new firmware image in the target partition, the bootloader must verify the CRC or cryptographic hash of the resulting image against the expected value included in the update manifest. If verification fails, the bootloader must not switch partitions and must retain the previous valid firmware state. This is the final safety net that prevents a subtly corrupted patch from producing an ECU that boots and operates incorrectly 

Anti-rollback protection applies equally to delta OTA: the update manifest must include the target firmware version number, and the bootloader must reject any update that would install a version older than the currently installed firmware, preventing attackers from using crafted delta patches to downgrade ECUs to versions with known vulnerabilities. 

Multi-ECU Orchestration at Fleet Scale 

A vehicle software update rarely involves a single ECU. A typical SDV platform update may touch 10 to 30 ECUs in a defined dependency sequence. The gateway ECU must be updated before domain controllers. Domain controllers must be updated before leaf node ECUs that depend on them. Applying delta patches out of sequence or in parallel without dependency management produces version mismatches that can trigger communication faults or safety system failures. 

Fleet-scale delta OTA orchestration requires a campaign management layer that handles update sequencing across the ECU network, partial update resilience for individual ECU failures within a campaign, rollback coordination across multiple ECUs when any single ECU in a dependency chain fails verification, and update state tracking per vehicle and per ECU across the deployed fleet. Without this orchestration layer, delta OTA reduces transfer size but does not reduce the operational risk of fleet-wide update campaigns. 

When Full OTA Is Still the Better Choice 

Delta OTA delivers substantial bandwidth and deployment advantages, but it is not the optimal solution for every update campaign. 

OEMs typically prefer Full OTA in situations where reconstructing firmware from an existing image introduces unnecessary complexity or risk. 

Full-image updates are generally preferred when: 

• The Flash Bootloader itself is being updated  
• Flash memory layout or partition structure changes  
• Cryptographic keys or Secure Boot certificates are rotated  
• Major AUTOSAR platform upgrades require complete software replacement  
• Factory recovery or emergency restoration is required  
• The cumulative software changes are so extensive that the delta package approaches the size of the full image  

In these situations, transmitting the complete firmware image simplifies validation and reduces dependency on the previously installed software version. 

Most production OTA platforms therefore support both Full OTA and Delta OTA, selecting the most appropriate update strategy based on software version, ECU resources, firmware size, network conditions, safety requirements, and campaign objectives. 

Rather than competing technologies, Full OTA and Delta OTA are complementary strategies within a mature Software Update Management System (SUMS). OEMs increasingly use Full OTA for major software releases and Delta OTA for incremental feature updates, cybersecurity patches, and bug fixes. 

AIS-190 and UNECE R156: Regulatory Requirements for Delta OTA 

Delta OTA is not exempt from the regulatory requirements that govern full image OTA. India’s AIS-190 and UNECE R156 (Software Update Management System, SUMS) apply to all forms of ECU software update delivery, including differential updates. The requirements that delta OTA must satisfy include authenticated firmware delivery with cryptographic integrity verification, anti-rollback protection with version traceability, rollback capability to the previous valid firmware state, and version traceability across all ECUs for up to 10 years post-production. 

Additionally, AIS-189 requires that the OTA update pipeline, including the backend patch generation infrastructure, patch signing key management, and the vehicle-side patch application and verification process, is covered within the OEM’s certified CSMS. Delta OTA introduces a backend patch generation step that must itself be secured: a compromised patch generation server is as dangerous as a compromised firmware signing server. 

Conclusion 

Delta OTA is not a bandwidth optimisation. At the scale of modern EV and SDV fleet deployments, it is the difference between update campaigns that are operationally viable and ones that are not. The binary diffing algorithm, the bootloader architecture, the patch validation security chain, and the multi-ECU orchestration layer are all engineering decisions that must be made at program inception, not retrofitted after the first fleet-scale update campaign reveals their cost.  

With the automotive OTA delta update market growing at 21.5% annually and AIS-190 mandating authenticated, traceable software update management across all ECUs, OEM programs that build delta OTA capability into their bootloader and FOTA architecture from day one will deliver faster updates, lower campaign costs, and demonstrably compliant software lifecycle management throughout the vehicle’s operational life.