When Software Becomes Part of the Vehicle Architecture
Software in a car is nothing new. For decades, electronic control units have managed functions ranging from engine and transmission control to braking, climate control and infotainment. Electric vehicles have added another layer, with software controlling critical functions such as battery management, charging, thermal management and electric powertrain operation.
So what makes a vehicle software-defined?
The difference is not simply the amount of software it contains. It lies increasingly in how vehicle functions are organized, controlled and allowed to evolve.
From Many Controllers to a More Centralized Architecture
In a conventional vehicle architecture, different functions are often handled by separate electronic control units (ECUs). As vehicles have gained more electronic functions, the number of controllers, networks and associated wiring has grown with them.
Software-defined vehicles are driving a shift away from this highly distributed architecture. Functions that once depended on individual controllers are increasingly being consolidated into domain or zonal architectures, supported by more powerful central computing platforms.
A zonal architecture groups electronic functions according to their physical location in the vehicle, while central computers can take responsibility for higher-level processing and coordination. This can reduce wiring complexity and, more importantly, create an architecture in which more vehicle functionality can be managed through software.
For an EV, that matters because software already plays a significant role in determining how the battery, powertrain, charging and energy-management systems behave. More centralized computing can bring functions and data that were previously distributed across controllers into more integrated architectures.
More Than an Architectural Change
The transition does not mean that every ECU will disappear or that hardware becomes less important. In practice, many vehicles are likely to retain dedicated controllers for particular safety-critical or legacy functions while other functions become more centralized. The transition from distributed to zonal architectures is therefore evolutionary rather than a single architectural leap.
What changes is the relationship between the hardware and the functions it delivers. When more functionality can be defined at the software level, engineers gain greater flexibility to develop, integrate and modify vehicle functions without redesigning a dedicated piece of hardware every time. The vehicle begins to move from a collection of electronically controlled components towards a computing architecture capable of supporting functions across several systems.
If vehicle functionality is increasingly defined by software, how do engineers develop and validate that software before all the vehicle hardware is available – and ensure that changes in one function do not create problems elsewhere?
That is where software-defined vehicles begin to change not only the architecture of the EV, but the way the EV itself is engineered.
When Software Changes the Engineering Process
As vehicle functions become increasingly software-defined, the way they are developed and validated also begins to change. In a traditional development process, software could often be tested once the relevant electronic control unit or physical hardware became available. In an SDV, waiting until that stage can leave too much integration and validation work too late in the development cycle.
The challenge is not simply writing more software. Battery management, propulsion, charging, thermal control and other vehicle functions interact with physical systems whose behavior changes with operating conditions. Software therefore needs to be tested not only for whether the code performs as intended, but for how the vehicle responds when that code interacts with sensors, controllers, actuators and the underlying physics.
This is where virtual development becomes particularly important.
Engineers can begin testing control strategies and software functions before the complete physical vehicle – or even the final electronic hardware – is available. Model-in-the-Loop (MiL) environments can evaluate control logic against models of the system. Software-in-the-Loop (SiL) moves the actual software into a virtual test environment, while virtual ECUs allow parts of the electronic architecture to be represented before production hardware is ready. Hardware-in-the-Loop (HiL) then brings real controller hardware into the test environment while the rest of the vehicle or system remains simulated.
The objective is not simply to replace physical prototypes with virtual ones. It is to move more questions earlier in the engineering process.
A battery-management algorithm, for example, can be exposed virtually to different states of charge, temperatures and operating conditions. A propulsion controller can be evaluated across different loads and driving scenarios. Engineers can also introduce faults or unusual combinations of conditions that may be difficult, expensive or unsafe to reproduce repeatedly in a physical vehicle.
This becomes increasingly valuable as functions interact. A change intended to improve one aspect of vehicle behavior may affect another system or create an unexpected response under a particular operating condition. Virtual environments allow engineers to explore many more combinations before the software reaches the vehicle.
But virtual development introduces its own requirement: the models and test environments must represent the relevant physical behavior with sufficient fidelity. A software function that performs correctly against an inadequate model may still behave differently when connected to the real system. Physical hardware and vehicle testing therefore remain essential for validating both the software and the assumptions behind its virtual environment.
The shift towards software-defined EVs does not remove physical testing. It changes when testing begins, how often it can be repeated, and how much can be learned before the complete vehicle exists.
When the Vehicle Continues to Evolve
For a conventional vehicle, the start of production has traditionally marked the point at which most of its functionality is largely fixed. Software-defined vehicles begin to change that relationship.
Over-the-air (OTA) updates allow software to be modified after the vehicle has entered service. Updates may correct faults, improve existing functions or change the way particular vehicle systems operate without requiring the underlying hardware to be replaced.
For an EV, this capability can extend beyond infotainment or user-interface features. Software influences battery management, charging, thermal control, energy management and powertrain behavior. Changes to that software can therefore influence how the physical vehicle itself performs.
If the software changes after the vehicle leaves the factory, how do engineers ensure that the updated vehicle continues to behave safely and as intended?
Validation Does Not End at Launch
A software update cannot be considered only in terms of whether the new code works. Engineers also need to understand how the change interacts with other functions, different hardware configurations and the range of operating conditions the vehicle may encounter.
This makes the virtual development environments used before production relevant throughout the vehicle lifecycle. Software updates can be evaluated using simulation, Software-in-the-Loop and Hardware-in-the-Loop environments before being released to physical vehicles. Engineers can test normal operation as well as fault conditions and investigate whether a change produces unintended behavior elsewhere in the system.
The challenge becomes greater when vehicles in the field are not all identical. They may have different hardware versions, software configurations or previous updates. Managing these variations while maintaining compatibility, functional safety and cybersecurity becomes part of the engineering problem.
Software updates themselves are therefore increasingly subject to formal processes. UN Regulation No. 156 establishes requirements for software updates and software-update management systems, while UN Regulation No. 155 addresses cybersecurity and cybersecurity-management systems for vehicles.
Rethinking Where Vehicle Engineering Ends
None of this means that the physical vehicle becomes secondary. Batteries, motors, power electronics, sensors, actuators and mechanical systems ultimately determine what the vehicle can physically do. Software operates within those boundaries.
What changes is the relationship between the two. As vehicle functions become more software-defined, engineers increasingly have to consider hardware and software together – from early virtual development and integration through physical validation and subsequent software updates.
The engineering lifecycle therefore begins to extend beyond the traditional development program. A vehicle released today may not behave exactly the same way several years later – not simply because its physical components have aged, but because its software may also have evolved.
For a software-defined EV, the engineering challenge is no longer only to validate the vehicle that leaves the factory. It is also to maintain confidence in the vehicle it may become.
References
- International Energy Agency (IEA), Vehicle software and software-defined vehicles, Global EV Outlook 2026, May 2026.
- Singh, J., Shaikh, A., Mane, R. and Burangi, P., “Virtual ECU: Development & Validation Platform,” SAE International, 2026-26-0683, 2026.
- UNECE, UN Regulation No. 156 – Uniform provisions concerning the approval of vehicles with regards to software update and software updates management system.
- UNECE, UN Regulation No. 155 – Uniform provisions concerning the approval of vehicles with regard to cyber security and of their cybersecurity management systems.
Images generated by: ChatGPT