A software-defined vehicle (SDV) is a car whose features, behaviour and safety functions are defined mainly by software running on a small number of powerful central computers, rather than by dozens of fixed-function electronic control units. As the industry moves from the Internal Combustion Engine, the heart of the vehicle becomes what this post calls the Internal Compute Engine: the processors, accelerators and networks that run driver assistance, infotainment, diagnostics and over-the-air updates. That shift changes how cars are designed, sold and kept safe over their lifetime.
As we transition from traditional petrol cars with Internal Combustion Engines (ICE) to software-defined vehicles, the heart of the vehicle is shifting from mechanical to computational. These Internal Compute Engines will be responsible for processing large amounts of data to control everything from automated driving and in-vehicle entertainment to real-time diagnostics and over-the-air updates.
This shift is a major change for the automotive industry, making vehicles more adaptable, efficient and connected. Software is moving to the centre of what defines a vehicle's capabilities and user experience. "Internal Compute Engine" is the author's own term for this transition, chosen because it keeps the familiar ICE abbreviation while capturing the move from mechanical to computational cores.
Key takeaways
- An SDV separates software from hardware, so features can be added or fixed after sale through over-the-air (OTA) updates.
- The electrical architecture moves from many distributed ECUs to zonal controllers connected to a few central computers.
- Driver assistance (ADAS), predictive maintenance and vehicle-to-everything (V2X) connectivity all depend on this central compute.
- Software defined does not mean self-driving: most SDVs on the road still need a human driver, and safety gains depend on how much driving is actually automated.
- Safety and cybersecurity are governed by standards and regulations such as ISO 26262, ISO 21448, ISO/SAE 21434 and UNECE R155 and R156.
From ECUs to central compute: how an SDV is built
A conventional car can contain many tens of electronic control units, each supplied with its own software by a different supplier, and each tied to one function such as braking, windows or the radio. Changing a feature means changing a box. An SDV reorganises this in three layers:
| Layer | Traditional vehicle | Software-defined vehicle |
|---|---|---|
| Compute | Many small ECUs, one per function | A few high-performance central computers plus zonal controllers |
| Network | CAN and LIN buses, point-to-point wiring | Automotive Ethernet backbone, with CAN kept at the edges |
| Software | Fixed at the factory, tied to each ECU | Layered platform with a hardware abstraction, updated over the air |
| Feature changes | New hardware or a dealer visit | Software release, often remotely |
For the semiconductor industry this is the important part. The central computers use automotive-grade system-on-chips that combine CPU clusters, GPUs and neural network accelerators, safety islands and high-speed interfaces, for example platforms such as NVIDIA DRIVE and Qualcomm Snapdragon Ride. These chips must meet AEC-Q100 reliability qualification and ISO 26262 functional safety requirements, which makes them some of the most demanding parts in the industry.
Continuous software updates
One of the key advantages of SDVs is the ability to receive over-the-air (OTA) updates. Vehicles can continually improve their performance, safety features and user experience without a physical visit to a service centre. These updates can include new safety protocols, bug fixes and feature enhancements, so vehicles stay equipped with current technology to protect drivers and passengers.
OTA updates need careful engineering: a secure boot chain, signed software images, enough memory to hold a fallback image, and a process for deciding which updates are safe to install while the vehicle is in use. In the markets that apply UNECE regulations, R156 sets requirements for a manufacturer's software update management system.
Advanced driver assistance systems (ADAS)
SDVs integrate sophisticated advanced driver assistance systems, which can significantly improve driving safety. Features such as lane-keeping assist, adaptive cruise control and automatic emergency braking are designed to prevent accidents by assisting the driver in real time. These systems use sensors, cameras and radar, and in some vehicles lidar, to monitor the vehicle's surroundings and respond to potential hazards, reducing the likelihood of collisions.
The SAE J3016 levels are a useful way to place these features. Most ADAS on the road today is Level 1 or Level 2: the system can steer, brake and accelerate in some conditions, but the driver must supervise at all times. Level 3 and above, where the system is responsible for driving in defined conditions, is available only in limited models and regions.
| SAE level | Who drives | Example |
|---|---|---|
| 0 | Driver, with warnings only | Forward collision warning |
| 1 | Driver, with steering or speed support | Adaptive cruise control |
| 2 | Driver supervises; system steers and controls speed | Lane centring with adaptive cruise |
| 3 | System drives in defined conditions; driver takes over on request | Traffic jam pilot in approved markets |
| 4 and 5 | System drives without a fallback driver, in limited areas (4) or everywhere (5) | Robotaxi services in limited areas (Level 4) |
Predictive maintenance and connectivity
Another important aspect of SDVs is predictive maintenance. By using real-time data and analytics, SDVs can predict potential issues before they become serious problems, reducing the risk of breakdowns and accidents. Battery health in electric vehicles, brake wear and tyre pressure trends are typical examples.
Enhanced connectivity also allows vehicles to communicate with other vehicles (vehicle-to-vehicle, V2V) and with infrastructure (vehicle-to-infrastructure, V2I). This communication can help prevent collisions and improve traffic flow. The main technologies are cellular V2X (C-V2X), which uses the 5.9 GHz band and mobile networks, and the older Wi-Fi based DSRC, with adoption varying widely by country.
Reduced human error
One of the most significant potential benefits of SDVs is the reduction of human error, a leading factor in road accidents. A widely cited NHTSA survey from 2015 attributed the critical reason for about 94 percent of the crashes it studied to the driver, although NHTSA itself notes that this does not mean the driver was the only cause.
To the extent that SDVs rely on software and sensors rather than human input, they can reduce common causes of accidents such as distracted driving, fatigue and poor judgement. The original version of this post said they can eliminate these causes; that holds only for fully automated driving. With Level 2 systems the driver is still responsible, and overreliance on assistance is itself a recognised risk, so driver monitoring cameras are increasingly part of the design. The shift towards automation and intelligent systems can still improve road safety substantially.
Proactive safety measures and cybersecurity
SDVs are equipped with proactive safety measures that continuously monitor vehicle performance and environmental conditions. This lets the vehicle adjust its speed to road conditions or alert drivers to potential hazards.
With the growing reliance on software, robust cybersecurity is essential to protect against hacking and unauthorised access and to keep vehicle systems secure and reliable. Four documents shape most of this work:
- ISO 26262: functional safety of electrical and electronic systems, with Automotive Safety Integrity Levels (ASIL A to D).
- ISO 21448 (SOTIF): safety of the intended functionality, covering hazards that arise when a correctly working system, such as a perception algorithm, misjudges a situation.
- ISO/SAE 21434: cybersecurity engineering for road vehicles.
- UNECE R155 and R156: regulations requiring a cybersecurity management system and a software update management system for vehicle type approval in the countries that apply them.
At chip level this means hardware security modules, secure boot, isolated safety islands, lockstep CPU cores and memory protection, all designed in from the start rather than added later.
Ethical and legal considerations
As SDVs become more common, ethical and legal questions need to be addressed. Liability in the event of an accident, especially when an automated system was in control, and clear regulations for the use of autonomous vehicles are critical issues that must be resolved for the safe and responsible deployment of SDVs. Data privacy is a further question: a connected vehicle collects location, camera and driving behaviour data, and owners need clear rules on who can use it.
What the Internal Compute Engine means for chip makers
- Demand moves from many low-cost microcontrollers towards fewer, much larger SoCs, alongside zonal microcontrollers and power devices.
- Product lifetimes are long. Automotive customers expect supply and software support for many years, which shapes process node and packaging choices.
- Software ecosystems, development kits and safety documentation become part of the product, not an extra.
- Chiplets and advanced packaging are being explored for automotive compute to scale performance across vehicle tiers.
Frequently asked questions
Is a software-defined vehicle the same as a self-driving car?
No. SDV describes the architecture: features defined by updatable software on central compute. A software-defined vehicle can still be driven entirely by a human. Self-driving is one feature that such an architecture makes easier to deliver.
What is an Internal Compute Engine?
It is the author's term for the central computing platform of an SDV, the processors, accelerators, memory and networks that take over the central role the internal combustion engine played in a traditional car.
Can over-the-air updates make a car less safe?
They can if they are poorly controlled, which is why update management is regulated in many markets and why updates are signed, tested and installed with a fallback. Done well, they let safety fixes reach every vehicle quickly instead of waiting for a recall visit.
Your comments will be moderated before it appears here.