By ATN Editorial Team
Guest Insights piece by Sami Kassimäki, Product Manager, Tuxera: why OTA updates are forcing engineers to rethink A/B partitioning in software-defined vehicles.
Not that long ago, vehicle software followed a fairly predictable pattern. Most functionality was finalised before production began, and updates after vehicles left the factory were relatively uncommon, and in most cases, the car had to be taken to the dealership to implement an update safely. If software changed after deployment, it was often to correct defects or deliver relatively modest enhancements, such as map updates, improvements to in-vehicle infotainment (IVI) systems or new third-party applications, rather than introduce entirely new vehicle capabilities.
Today, software-defined vehicles continue evolving throughout their operational lives. Manufacturers regularly deploy cybersecurity patches, improve driver assistance systems, introduce new digital cockpit features and, increasingly, update AI-driven functionality through over-the-air (OTA) software delivery. What was once considered post-production maintenance has become an essential part of the vehicle lifecycle.
As a result, OTA architecture is attracting renewed attention. For years, A/B partitioning has been the preferred approach for ensuring software updates can be delivered safely. It remains a proven method for protecting systems against failed updates by maintaining two full copies of critical software locally on the device storage. If something goes wrong during installation, the vehicle can simply revert to the previous version.
The question many engineering teams are now asking is whether the assumptions behind A/B partitioning still make sense for software-defined vehicles that receive frequent updates and support increasingly complex software.
Bigger software changes the equation
Vehicle software has grown significantly over the past decade and that trend is expected to continue. Research has found that software-defined vehicles could contain up to 600 million lines of code by 2027 as ADAS, autonomous driving capabilities, and onboard AI models become increasingly sophisticated. Advanced driver assistance systems process more sensor data than ever before while digital cockpit platforms continue adding applications and richer user experiences. Connected services generate larger volumes of telemetry and diagnostic information, and cybersecurity requirements mean software maintenance is now expected throughout the vehicle’s lifetime. AI capabilities are also beginning to move onto the vehicle itself, bringing larger models and supporting software into production platforms.
Each of these developments increases the amount of software that needs to be stored, managed and updated. A/B partitioning remains a proven and widely adopted approach for ensuring reliable over-the-air updates, providing a straightforward rollback mechanism should an update fail. However, as software images become larger, maintaining duplicate partitions also requires additional flash capacity. For platforms expected to receive frequent updates throughout long operational lifecycles, engineers are increasingly weighing that storage overhead against alternative approaches that can deliver the same resilience while making more efficient use of available flash.
That trade-off was relatively easy to accept when software images were smaller and updates happened only occasionally. However, as software-defined vehicles continue evolving, the storage overhead becomes much more noticeable.
OTA updates as an operational challenge
Anyone involved in deploying OTA updates knows that delivering software reliably across a connected fleet is far more complicated than simply transferring a new software image.
Updates must be downloaded, validated, installed, and monitored carefully. If something interrupts the process, vehicles need a reliable way to recover without compromising safety or functionality. As manufacturers increase the frequency of software releases, these processes become part of day-to-day vehicle operations rather than occasional maintenance activities.
Larger software images make every stage of that process more demanding. More data has to be transferred, more storage is required during installation, and validation takes longer. They also increase the mobile bandwidth required to deliver updates across connected vehicle fleets, adding operational costs for OEMs regardless of whether those costs are absorbed directly or passed on through different service models. At the same time, rollback mechanisms become increasingly important because software is being updated more frequently than ever before.
None of this diminishes the value of A/B partitioning or larger or even full system updates. This leads to an important engineering question around whether permanently reserving duplicate storage is always the most efficient way to achieve reliable software updates.
Beyond duplicate partitions
More platform teams are looking at OTA architecture from a different perspective. Rather than relying exclusively on duplicate partitions, newer approaches use snapshots to capture the state of a system before an update begins. Instead of downloading and installing a complete software image, only the changes, or diffs, need to be transferred and applied. Managed through the file system, snapshots track changes at the block level, allowing unchanged data to be shared while only modified blocks are written during the update.
This approach offers benefits beyond reducing the amount of data that needs to be downloaded. Smaller updates can be installed more quickly, place less strain on flash storage, and reduce the amount of capacity that must be reserved for the update process. At the same time, the pre-update snapshot provides a reliable rollback mechanism should an installation fail, preserving the resilience that automotive platforms require.
Combined with dynamic storage management techniques such as shared storage pools, subvolumes and quotas, snapshot-based approaches offer another way of thinking about storage. Critical software can still be isolated and protected, while storage is managed more efficiently as software evolves throughout the life of the vehicle. The goal is to optimise the storage capacity and, in many cases, reduce the over-provisioning while preserving the reliability expected of automotive systems.
Designing storage architecture for long-term software growth
As software-defined vehicles mature, engineering discussions are gradually shifting. A few years ago, much of the conversation centred on delivering richer user experiences through new applications, connected services and digital features, and ensuring vehicle platforms had enough flash capacity to support them. That remains an important consideration, but capacity alone doesn’t determine how efficiently storage will be used over a vehicle’s lifetime.
Storage architecture plays an equally important role. How software is organised, how updates are managed and how rollback mechanisms are implemented all influence the amount of usable storage available to the platform years after production begins.
For automotive engineers, that’s becoming an increasingly important design consideration. Vehicle software will almost certainly continue growing throughout the coming decade, driven by connected services, AI capabilities, regulatory requirements and customer expectations for continuous improvement.
A/B partitioning remains a robust and well-understood approach, and it will continue to be appropriate for many applications. But as software-defined vehicles become more capable and update cycles become more frequent, it’s natural that engineers are beginning to re-examine the architectures beneath those updates as carefully as the software itself.
For more Software Defined Vehicle news, click here.
