A car bought today can genuinely be a different vehicle a year from now — not because anything was replaced under the hood, but because a software update changed how the battery is managed, how the adaptive cruise control behaves, or what the infotainment system can do. That's a fundamentally different ownership model than the automotive industry ran on for a century, and it's the same model consumer electronics has run on for years: buy the hardware once, keep receiving new capability indefinitely.
The global software-defined vehicle (SDV) market is projected to grow from roughly $447 billion in 2026 to $1.70 trillion by 2035. For hardware and firmware teams, that shift is worth understanding closely — because a car chasing this model has to solve, at a much higher stakes level, many of the same over-the-air (OTA) engineering problems that consumer electronics teams already navigate.
What Actually Changed: From Scattered ECUs to Centralized Compute
Traditional vehicles run on dozens, sometimes hundreds, of separate Electronic Control Units (ECUs) — one for the engine, one for the brakes, one for infotainment, each largely isolated from the others and each typically requiring a dealership visit to update.
Software-defined vehicles replace that scattered model with a small number of centralized, high-performance compute platforms running the vehicle's software stack, connected through zonal controllers rather than dozens of siloed ECUs. This consolidation is what actually makes OTA updates viable at scale: updating one centralized platform is a fundamentally different engineering problem than orchestrating synchronized updates across a hundred disconnected modules.
This distinction matters more than it might sound: one detailed automotive engineering analysis notes that the most common SDV program failure pattern is bolting OTA capability onto an existing distributed ECU architecture rather than rebuilding around centralized compute — an approach that can end up delivering only a fraction of an SDV's real value while still incurring most of the development cost, because each ECU still needs its own individual update and validation path.
FOTA vs. SOTA: Not All Updates Carry the Same Risk
Over-the-air vehicle updates generally split into two categories with very different engineering and safety implications:
- SOTA (Software Over-the-Air) — updates at the application level: infotainment, navigation, user interface. These are lower-risk, less complex, and require less rigorous validation before deployment.
- FOTA (Firmware Over-the-Air) — updates that touch core system firmware, including safety-relevant functions like powertrain control or driver-assistance systems. These carry materially higher stakes and require far more rigorous validation, rollback planning, and functional-safety review before release.
- Treating these as equivalent — pushing a firmware-level update through the same lightweight release pipeline as a UI tweak — is one of the more dangerous shortcuts a software-defined vehicle program can take.
The Hardware Abstraction Layer: Why It Has to Come First
One of the more counterintuitive lessons from SDV architecture is that the update capability isn't really a software feature — it's an architectural decision that has to be made in the hardware and firmware layer, years before it pays off.
A properly designed Hardware Abstraction Layer (HAL) separates application software from the specific hardware it runs on, which is what allows applications to be updated without requiring hardware-specific recertification every time. Skipping this and letting application code make direct hardware calls creates a system where every future update risks expensive application-level rework — the HAL essentially needs to be validated against a 5-7 year application development horizon from the very start, not retrofitted once the update problem becomes painful.
This is the same underlying principle behind good firmware architecture in any long-lived connected product: the abstraction boundary between hardware and application logic determines how expensive every future update will be, for the entire product lifecycle.
What This Means for Anyone Building Long-Lived Connected Hardware
Even outside automotive, the SDV shift is a useful case study in engineering discipline for any hardware product meant to receive updates over its lifetime — which increasingly describes most connected consumer and industrial devices:
Architect for updatability before the first unit ships, not after field data reveals the need for it. Retrofitting a clean hardware/software abstraction boundary into an already-shipped product is dramatically more expensive than designing it in from the start.
Separate update risk tiers explicitly. A firmware update touching safety- or health-relevant functionality should never share a release pipeline or rollback strategy with a cosmetic UI update — the validation bar has to match the consequence of failure.
Design rollback and failure-recovery paths as core requirements, not edge cases. An OTA update that bricks a device in the field is far more costly than one that simply arrives late.
Plan connectivity and cybersecurity architecture as load-bearing, not optional. Whether it's a vehicle's telematics unit or a wearable's BLE stack, the connectivity layer that enables remote updates is also the attack surface that needs to be defended — the two have to be designed together.
Budget for the validation and certification cost of every update tier, not just the initial product certification. A product designed to evolve over years needs a repeatable, budgeted process for revalidating and recertifying each meaningful update, not a one-time certification event.
Conclusion
The shift toward software-defined vehicles is really a shift toward treating hardware as a flexible, long-lived platform and treating software as the primary way the product keeps delivering new value after it ships — the same philosophy that has defined consumer electronics for years, now applied to a product where the stakes of getting firmware updates wrong are measured in safety, not just user experience. The engineering discipline underneath it — hardware abstraction, update risk tiering, rollback planning, and cybersecurity as a first-class design constraint — is directly transferable to any connected hardware product built to keep evolving long after it leaves the factory.
At CoBuild Labs, we approach connected hardware the same way: architecting the boundary between hardware and firmware early — complementary to A/B OTA rollback design.
Building long-lived connected hardware? Talk to CoBuild Labs about firmware engineering, A/B OTA rollback architecture, and edge AI model updates.