We keep seeing the same story: a new software update is announced for the ENYAQ (or ELROQ), but not all vehicles receive it. Or it’s only available via a workshop visit even though Over-the-Air (OTA) updates should be possible by now. Understandably, this creates frustration. But the root cause often lies much deeper: in the fundamental architecture of our vehicles. And that architecture is a legacy of the past decades.
The principle: “Outsource everything that’s not core business”
In the automotive world, including at Škoda, the strategy for decades was simple: focus on bodywork, engines, and assembly; outsource the rest. Major suppliers like Bosch, Continental or ZF developed and delivered the components, including their control units (ECUs) and software for lighting, braking, HVAC, battery management, and more.
The OEM (e.g., Škoda) would define a requirements specification, a list of what the function or part had to achieve, and the supplier would implement it.
This worked fine in a world where software rarely changed, updates were limited to recalls, and nobody expected OTA functionality. Vehicles followed a function-oriented, distributed ECU architecture, with each control unit responsible for a specific task. Each with its own software, its own update capabilities, and often little compatibility with others. This shaped the entire E/E (electrical/electronic) system.
MEB: A modern EV built on outdated software foundations
The Modular Electric Drive Toolkit (MEB), introduced in 2020, brought modern electric cars like the Škoda ENYAQ and the ELROQ in 2025. But under the surface, much of the system architecture remained the same. MEB is still built on the same legacy approach: many ECUs, many suppliers, many interfaces.
My 2024 ENYAQ RS, for example, has an incredible 79 separate ECUs.
Why? Because MEB had to be market-ready quickly (thanks to the Diess-era push), and VW relied heavily on technology from its combustion-based MQB platform. This saved cost and time but limited the future viability of the system, especially regarding software updates.
So if Škoda wants to deliver a system-wide update, e.g. for improved battery management or new regenerative braking logic, it’s never just about the infotainment. It requires:
- New software from multiple suppliers
- Individual approvals for each affected ECU
- Compatibility checks across all other units
- A functioning update mechanism (e.g., OTA support)
- Rigorous testing for every configuration (including hardware revisions)
Even within a single model year, ECUs can vary. A different supplier? A slightly changed hardware spec? You may need a different software package. Even if the visible version in the car looks the same.
Example 1: When updating from SW2.0 to SW3.0 on the ENYAQ iV, all-wheel-drive models didn’t receive “Traction Mode” because their ABS ECU was not updatable. Vehicles shipped from the factory with SW3.0 had it enabled.
Example 2: Current ENYAQ models with Matrix LED headlights (SW5.2) can receive SW5.4 via OTA. But cars with standard LED headlights need a workshop visit due to differing hardware paths.
Why not just do everything OTA?
Škoda would love to offer all updates Over-the-Air. It’s far more cost-effective. Workshop updates that are free for the customer still require Škoda to pay a service fee to the workshop.
But an OTA update requires that:
- The ECU has sufficient processing power and memory
- Communication (e.g., via the vehicle gateway) is secure and stable
- The update is approved, often by the supplier
- No unexpected effects occur, on braking, charging behavior, or safety systems
And that’s rarely the case with older MEB vehicles. Many ECUs were never designed for OTA, not even for regular software maintenance. If an OTA update fails, for example, due to a corrupted ECU flash the car may be unusable. That’s why OTA requires fail-safes, rollback systems, energy stability, and complex approval chains. All of which take time, money, and staff and aren’t economically viable for a 3-year-old ECU.
This leads to a second factor: the business case. Sometimes, it’s just not worth the effort, at least from Skodas perspective.
Where Do We Go From Here? New Architectures for New Challenges
To solve these issues, you need a completely new software and hardware platform which is exactly what newcomers like Tesla, XPENG, Rivian, or NIO have done. These companies didn’t carry the burden of legacy architectures.
You can improve and evolve an existing platform like MEB demanding better integration and OTA capabilities from suppliers but you won’t escape the core architectural limits.
Only a complete redesign of the E/E architecture can change that. That’s what the SSP (Scalable Systems Platform) is intended to deliver. The transition involves skipping the “domain architecture” stage, already found in many other brands, and moving straight to zonal architecture. Škoda and VW are actively working on this, together with Rivian.
Domain Architecture (Intermediate Step)
- ECUs are grouped by function (e.g., powertrain, body, infotainment)
- Each group has a domain controller managing multiple subsystems
- Reduces complexity, simplifies updates, enables OTA for defined areas
Zone Architecture (State of the Art)
- Vehicle is split into geographic zones (e.g., front-left, rear-right)
- High-performance central computers provide intelligence
- Zone controllers act as “dumb” distributors
- Fewer ECUs, fewer cables, full OTA capability, higher flexibility
Example: Rivian’s 2nd-generation architecture
→ Read more at PopSci
Conclusion
Today’s chaotic update landscape isn’t the result of laziness or incompetence. It’s the inevitable consequence of legacy architecture and siloed supply chains.
Anyone building a car with distributed ECUs today is also building in the software limitations of tomorrow. That’s why true OTA capability is still years away for many brands and why only a radical architectural shift will unlock the software-defined future of the car.
