Ask any OEM about its driver assistance roadmap and the answer will sound familiar: lane keeping will become smoother; emergency braking will recognize more scenarios; assisted driving will extend to roads and conditions it cannot handle today; and ADAS software improvements will continue after the production of any individual vehicle. However, many of those improvements will never reach the car. The obstacle is not the algorithms – it is where the software that needs changing actually lives
ADAS functions are distributed across multiple vehicle systems. Cameras and radar modules handle sensing; the domain controller processes perception; the central ADAS computing platform makes decisions; and brake, steering and chassis ECUs carry out actuation. These controllers often come from different suppliers, each using its own tools, software update formats and validation processes. As a result, improving a single feature, such as adaptive cruise control’s response to a vehicle cutting in, can require software changes across multiple controllers.
Most OEM over-the-air (OTA) systems were not built for that. They were designed around the head unit, the telematics module and central compute, where the early value of OTA lay in maps, apps and infotainment. ECUs and smart sensors further out in the architecture are updated at service intervals, or not at all. For ADAS, that is where the roadmap stalls.
Rearchitecting is only part of the answer
The obvious response is to rearchitect. Zonal and centralized architectures consolidate functions into fewer, more powerful computers and promise a cleaner path for software. They are the right direction, but they will not close the gap on their own.
No OEM is replacing every legacy controller in a single vehicle generation. Manufacturers adopting zonal architectures are retaining many proven ECUs because requalifying them is costly and time-consuming. Even in highly centralized vehicles, sensors still run their own firmware, while braking and steering systems rely on dedicated controllers, often supplied by specialists. As a result, future ADAS features may require access to sensors and actuators at the vehicle’s edge, rather than relying solely on the central computing platform.
Regulation raises the stakes further. UN R156 requires manufacturers to operate a certified software update management system and to manage updates across the vehicle’s service life. Software relevant to type approval is tracked through a software identification number, the RXSWIN, so any change to a type-approved driver assistance function has to be controlled, documented and traceable across every ECU involved. That traceability has to work vehicle by vehicle, not just model by model. Cars in the same fleet will be running different software at any given time, depending on which updates each one has received and when. The OEM needs to know exactly what is installed on every ECU in every car, and a technician working on that car needs to be able to see it too. When those ECUs come from five suppliers with five different update processes, keeping that vehicle-level record becomes a reconciliation exercise rather than a system.
What full-vehicle reach requires
Closing this gap requires four key elements, starting with a common software update architecture across suppliers. Regardless of who manufactures an ECU, it must be able to receive, verify and install software through standardized interfaces. This gives OEMs a consistent way to distribute updates and monitor software status across the entire vehicle, rather than reconciling separate supplier-specific reports. Standards such as those developed by the eSync Alliance aim to provide this common framework.
The second is coordinated multi-ECU updates. An ADAS improvement that touches the camera, the domain controller and the brake ECU has to be delivered as one campaign. Each component must be verified before activation, and if the update to any part fails, in any individual vehicle, the whole set for that vehicle must roll back to a known good state. A half-updated driver assistance system is not acceptable on a safety-relevant function.
The third is reporting. Every ECU in every vehicle needs to report the outcome of each update back to the OEM, whether it installed, failed or rolled back, along with the software version it is now running. That is what turns an update campaign into a record that can be kept, inspected and produced on request, for the regulator and for the workshop. Without it, the OEM is assuming the software state of its fleet rather than knowing it.
The fourth is supplier commitment from the start of a program. Update capability belongs in the sourcing specification, alongside cost and performance. Retrofitting it into a controller after nomination is slow and expensive and often does not happen at all.
Already working at production scale
This is already happening on vehicles in customers’ hands. The Tata Sierra SUV was engineered from the outset as a software-defined vehicle, with OTA updates and remote diagnostics built into the architecture rather than added later. Its OTA system is an implementation of eSync Alliance specifications, delivered by Alliance member Excelfore with Tata Motors Passenger Vehicles.
The implementation supports secure firmware and software updates, differential delta delivery, rollback and recovery and coordinated campaign management across multiple ECUs.
The initial deployment was on the internal combustion engine (ICE) version of the Sierra. Many OEMs are expected to retain a similar distribution of ECUs in their next generation of ICE models. Across the Sierra SUV range, Tata uses eSync over-the-air technology to coordinate updates for both ICE and all-electric variants. The system is already deployed at production scale in India, the world’s third-largest car market, with coordinated multi-ECU updates and rollback mechanisms of the kind required for ADAS updates already in use.
Questions to ask now
For vehicles still in development, there is an opportunity to address these challenges, but the window closes once sourcing decisions are made. Teams planning future ADAS roadmaps should establish which ECUs each planned driver assistance improvement will affect and how many can be reached by the existing OTA system. They should also confirm whether suppliers have committed to a common update interface or whether each controller will require separate integration. Can the camera, domain controller and brake ECU be updated as part of a single campaign, with all three rolled back if an update fails on any vehicle in the fleet? Finally, can the OEM demonstrate to a type approval authority exactly which software is running on every ECU involved in a driver assistance function, across the entire fleet and at any point in the vehicle’s life?
If the honest answer to any of those is no, the ADAS roadmap is promising more than the vehicle can deliver. Customers will notice, and so will regulators. It’s far better to find out at the specification stage than three years after launch.
EXPLORE: What the London Assembly’s autonomous vehicle report means for the UK’s CAM ecosystem
