In a conventional vehicle, every capability is locked into hardware at manufacture. The Software-Defined Vehicle (SDV) eliminates this constraint — treating the vehicle as a software platform where hardware is fixed and standardised, while software defines its capabilities and evolves continuously throughout its lifetime. This whitepaper covers the five engineering pillars required to realise a true SDV: E/E Architecture & SOA, High-Performance Computing, Software Design & Vehicle OS, Artificial Intelligence, and CI/CD & Automotive DevOps.

---

1. What is a Software-Defined Vehicle?

In a conventional vehicle, every capability is locked into hardware at manufacture. A new feature means a new ECU, new wiring, and months of integration work. The Software-Defined Vehicle (SDV) eliminates this constraint. The hardware provides a fixed, standardised compute and communication platform. Software — deployed over the air throughout the vehicle’s lifetime — defines what the vehicle can do and continuously redefines it.

This is not an incremental improvement. It is a structural shift in how vehicles are built and maintained. An SDV treats the vehicle as a software platform: the hardware is fixed and standardised; software defines its capabilities and evolves continuously throughout its lifetime.

1.1 The Core Principle: Hardware-Software Decoupling

A hardware abstraction layer sits between application software and physical hardware. Applications communicate with this layer, not with hardware directly. The consequences:

• Software updates change vehicle behaviour without any hardware modification
• The same application runs across different hardware generations without rewriting
• New features are deployed to vehicles already in the field, after sale
• Multiple applications safely share the same physical compute resources

1.2 Conventional Vehicle vs. SDV

---

---

2. Why SDV is Needed

The SDV transition is driven by five converging forces. No single one could be ignored; together they make the transition a strategic and engineering imperative.

2.1 Consumer Expectation

Tesla demonstrated that a 2018 vehicle could have meaningfully improved autopilot, range, and features in 2023 — no hardware change. This set a new benchmark: vehicle quality now includes how the vehicle performs two years after purchase. OEMs whose vehicles cannot improve after sale face a structural competitive disadvantage.

2.2 Architectural Scaling Limit

A modern premium vehicle has 150+ ECUs, 5+ km of wiring, and up to 300 million lines of code across incompatible environments. Adding one new function typically takes 18–24 months and costs millions. The distributed ECU architecture has reached its physical and economic scaling limit.

2.3 Post-Sale Software Revenue

Features like enhanced autopilot, performance upgrades, and premium services can be provisioned post-sale via software. The hardware is installed at manufacture; the feature is activated through an authenticated OTA update. Without SDV architecture, this model is not technically achievable.

2.4 Regulatory Requirements

• UNECE R155 (Cybersecurity) — Requires a certified Cybersecurity Management System for new type approvals from July 2024. OEMs must patch fielded vehicles remotely — only achievable with OTA infrastructure.
• UNECE R156 (Software Updates) — Mandates a regulated Software Update Management System. Remote OTA capability is a legal requirement for new type approvals.
• ISO/SAE 21434 — Requires cybersecurity maintenance across the full vehicle lifetime, including remote remediation of fielded vehicles.

2.5 Competitive Pressure

New entrants — Tesla, Rivian, NIO — were built as software platforms from day one. Volkswagen Group created CARIAD with a multi-billion euro mandate. BMW and Toyota are building proprietary vehicle operating systems. The direction of the industry is clear.

Key Takeaway: The SDV transition is driven by consumer expectations of post-sale improvement, the scaling limits of distributed ECU architecture, post-sale software revenue models, binding regulatory mandates for OTA capability, and competitive pressure from software-native entrants.

---

3. Clearing the Confusion: SDV, ADAS, Connected Vehicle, and OTA

SDV is frequently used interchangeably with ADAS, Connected Vehicle, and OTA updates. These are related but distinct concepts. Confusing them leads to wrong architectural decisions and misaligned investment.

• A Software-Defined Vehicle is an architectural concept — a vehicle whose functional software is decoupled from hardware through a standardised abstraction layer, making capabilities extensible via software throughout the vehicle’s lifetime.
• ADAS (Advanced Driver Assistance Systems) refers specifically to the perception, decision, and control software functions that assist or automate driving tasks. A vehicle can have ADAS running on dedicated, fixed ECUs that cannot be updated after manufacture — that vehicle is not software-defined. ADAS is an application that can run on an SDV, but it does not define one.
• A Connected Vehicle has wireless interfaces enabling data exchange with the cloud and infrastructure. Connectivity is necessary for OTA delivery in an SDV, but a vehicle can send cloud telemetry while its core architecture remains entirely hardware-bound.
• OTA updates are an operational capability — delivering software without a workshop visit. In a true SDV, OTA covers all software layers including safety-relevant systems.

The distinction: SDV is the architecture. ADAS is one application built on it. Connectivity is the communication channel. OTA is the operational outcome. All must work together for the SDV to deliver on its promise — but none of the three individually makes a vehicle software-defined.

---

4. Realising the SDV: The Five Engineering Pillars

Building an SDV requires five interdependent engineering disciplines. Each is a prerequisite for the others. A gap in any pillar limits the capability of all the rest.

Figure 1: Engineering Pillars for SDV Realisation

---

5. Pillar 1 — E/E Architecture & Service-Oriented Architecture

The E/E architecture defines how computing, communication, and power are organised across the vehicle. It is the structural foundation: every other pillar depends on it for the physical infrastructure it provides.

5.1 Architecture Evolution

Distributed Architecture

Each function has its own dedicated ECU. Separate ECU clusters for Powertrain, Chassis, Body, Infotainment, and ADAS are connected by domain-specific bus protocols — CAN, LIN, FlexRay, MOST. Software is written for a specific ECU and cannot move. Adding a function means adding hardware. The wiring harness in a premium vehicle exceeds 60 kg. The core drawback: software is inseparable from hardware. Every new function requires new hardware. The vehicle cannot evolve after it leaves the factory.

Figure 2: Distributed E/E Architecture — Five isolated domain clusters with dedicated ECUs and domain-specific bus protocols connected through a central gateway

Domain-Centralised Architecture

Domain-centralised architecture was the industry’s first response to this problem. A more powerful Domain Controller aggregates multiple ECUs within each functional domain — Powertrain, Chassis, ADAS, Infotainment. This reduces wiring within each domain and consolidates compute. However, the domains themselves remain isolated silos. Software still cannot cross domain boundaries. The hardware-software coupling is improved within a domain but not solved across the vehicle.

Figure 3: Architecture Transition — Distributed (top) evolving to Domain-Centralised (bottom) with per-domain HPCs, leading to Zonal architecture

Zonal Architecture — The SDV Foundation

The vehicle is divided by physical location (Front, Rear, Left, Right). A Zonal Controller (ZC) serves each zone, handling all functions regardless of domain. Central HPCs connect to all ZCs over Ethernet.

• Wiring reduced by up to 50% — each zone connects via one Ethernet cable instead of multiple domain buses
• Functions migrate from fixed ECUs to software services on the HPC, removing hardware-software coupling
• Applications address sensors and actuators through a vehicle API layer, not through hardware directly
• New functions are software deployments, not hardware additions

Figure 4: Zonal/Vehicle-Centralised Architecture — Zonal Controllers connected to central HPCs via Ethernet backbone

5.2 Service-Oriented Architecture

In a traditional vehicle, communication uses a static signal matrix: every CAN message has a fixed ID, format, and timing defined at build time. In a Service-Oriented Architecture, components publish named services with versioned interfaces. Any consumer discovers and subscribes at runtime, without knowing which hardware provides the service. When hardware changes, only the service implementation changes — all consumers continue through the unchanged interface.

SOME/IP — The Primary SDV Protocol

SOME/IP (Scalable service-Oriented MiddlEware over IP) is the standard in-vehicle SOA protocol in AUTOSAR Adaptive. It runs over Ethernet and supports RPC (request-response), Events (publish-subscribe), and Fields (stateful attribute). Its service discovery component (SOME/IP-SD) allows any HPC or ZC to find services dynamically at runtime.

Figure 5: Service-Oriented Protocols — SOME/IP as the primary in-vehicle protocol with context-specific alternatives

SOME/IP is the default for all in-vehicle service communication in Adaptive AUTOSAR deployments; DDS is preferred for high-frequency sensor data pipelines; gRPC for vehicle-to-cloud communication; DoIP for diagnostic sessions; MQTT for lightweight fleet telemetry; REST/HTTP for OEM mobile and web API integration; and ara::com is always present as the internal Adaptive AUTOSAR binding layer.

Key Takeaway: Zonal architecture provides the physical infrastructure. SOA provides the communication model. Without both, the SDV cannot be realised. Every other pillar runs on top of what this one provides.

---

6. Pillar 2 — High-Performance Computing

The HPC is the central compute platform where SDV services run, where AI models execute, and where OTA updates are managed. Without it, the zonal architecture is wiring without intelligence.

6.1 Why MCUs Are Not Sufficient

MCUs are excellent for single-function deterministic control — braking, airbag, EPS. But they cannot host Linux, support virtual machines, run containerised services, or sustain neural network inference. The HPC addresses all of this through multicore ARM processors (Cortex-A for applications, Cortex-M for real-time), gigabytes of RAM, POSIX OS support, and domain-specific hardware accelerators.

6.2 Hardware Accelerators

• LLCE (Low-Latency Communications Engine) — Handles all CAN/LIN/FlexRay processing in dedicated hardware. Without it, every CAN frame triggers a CPU interrupt. With it, CAN processing is fully offloaded; the CPU receives only finished, timestamped frames.
• PFE (Packet Forwarding Engine) — Routes Ethernet packets between zones at wire speed in hardware. Without it, inter-zone routing consumes CPU cycles proportional to traffic.
• HSE (Hardware Security Engine) — Executes AES, ECDSA, and SHA operations in tamper-resistant hardware. Keys provisioned into the HSE cannot be extracted by software at any privilege level — even a full OS compromise cannot read them.
• NPU/GPU — In ADAS-class HPCs, dedicated neural processors run AI inference at TOPS scale. A pedestrian detection network that takes 2+ seconds on a general-purpose CPU runs in under 10ms on a dedicated NPU.

6.3 MCU or HPC: The Decision

The IPCF (Inter-Platform Communications Framework) connects MCU real-time cores and HPC application cores on the same SoC. It uses shared SRAM and hardware interrupt signalling to transfer sensor data from the real-time Cortex-M7 to the Cortex-A53 for service publication — with sub-millisecond bounded latency.

Figure 6: IPCF Inter-Core Communication — Cortex-M7 writes sensor data to shared SRAM and signals Cortex-A53 to wake and process

Key Takeaway: HPC hardware accelerators are not optional enhancements — they are the mechanisms through which CAN processing, cryptographic security, and AI inference meet real-time automotive requirements.

---

7. Pillar 3 — Software Design & Vehicle Operating System

The right hardware is necessary but not sufficient. The software architecture — OS, virtualisation, middleware, and application framework — determines whether the vehicle evolves over its lifetime or stagnates. Software abstraction is what turns hardware capability into lasting vehicle capability.

7.1 Software Abstraction: A Concrete Example

Consider a radar sensor used for speed regulation. Without abstraction, the application is written to that specific radar’s hardware interface. When the OEM upgrades to a newer radar, the application must be rewritten and re-certified. With abstraction, the application is written to a standardised ‘radar service’ interface. Only the service driver changes. The application continues working without modification.

7.2 Mixed-Criticality: Hypervisor Isolation

An SDV HPC must simultaneously run ASIL-D certified braking and steering software alongside Quality-Managed infotainment and navigation applications — on the same physical chip. Without isolation between these, ISO 26262 certification of the safety software is not achievable. A Type-1 hypervisor resolves this through hardware-enforced partitioning. Each partition receives its own dedicated OS — QNX Neutrino or AUTOSAR OS for the safety domain, Linux or Android Automotive for the non-safety domain — along with its own memory space, allocated CPU time, and controlled peripheral access rights. A fault, crash, or security breach in the infotainment partition is physically prevented from propagating to the braking or steering partition by the hypervisor’s hardware boundary.

7.3 AUTOSAR Classic vs. Adaptive

AUTOSAR provides two software platform specifications that are not alternatives to each other — both are present in a full SDV implementation, serving different parts of the vehicle with different requirements.

• AUTOSAR Classic was designed for microcontrollers running safety-critical functions. Its communication model is entirely static — the full message schedule across all ECUs is defined at build time. Classic AUTOSAR runs on Zonal Controllers and safety ECUs — braking, EPS, airbag, body control.
• AUTOSAR Adaptive was designed for HPC-class processors running Linux or QNX. Its communication is dynamic — services are published and discovered at runtime via SOME/IP-SD. Individual services can be updated via OTA independently of the rest of the system. Adaptive AUTOSAR runs on the central HPCs — gateway services, telematics, OTA management, and AI inference hosting.

The two stacks interoperate through a Signal-to-Service Gateway: Classic AUTOSAR ECUs continue communicating via CAN signals in their domain; the gateway translates those signals into SOME/IP services that Adaptive AUTOSAR applications on the HPC can consume. Neither stack replaces the other — the vehicle needs both.

Key Takeaway: Software abstraction removes hardware dependency. The hypervisor enables mixed-criticality on one chip. Classic AUTOSAR handles safety ECUs; Adaptive AUTOSAR handles HPC services. Together they form the software foundation of the SDV.

---

8. Pillar 4 — Artificial Intelligence in SDV

AI enables the vehicle to perform tasks that rule-based software cannot handle: recognising objects in complex scenes, predicting road user behaviour, detecting early component failure, and adapting to individual drivers. In the SDV, AI is not a background analytics function — for real-time vehicle applications, it is a performance-critical processing component executing within strict timing constraints.

8.1 Hardware Determines AI Capability

The same AI model on different hardware produces vastly different latency results. In automotive, latency determines whether the system is deployable or not:

• Pedestrian detection network on NVIDIA DRIVE Orin (254 TOPS NPU): under 10ms. On a general-purpose ARM CPU: over 2,000ms. The algorithm is identical. The hardware determines whether it meets the safety timing budget.
• Multi-modal sensor fusion at 20 Hz requires sustained parallel matrix compute achievable only with GPU or DLA accelerators. Without them, fusion drops to 2–3 Hz — insufficient for highway-speed dynamics.
• Quantised LLM inference for voice interaction requires NPU hardware for 4-bit matrix operations. Without it, response latency exceeds several seconds — not usable in a real driving context.

8.2 AI Application Domains

• Obstacle perception — CNNs and BEV transformer models running on the ADAS HPC NPU provide real-time environment understanding for automated driving functions.
• Driver monitoring — Facial landmark detection and gaze tracking detect drowsiness and distraction. Mandatory under EU General Safety Regulation from 2024.
• Predictive maintenance — Anomaly detection models predict component failures 200–500 hours ahead, reducing unscheduled downtime and safety incidents.
• Personalisation — Preference learning models automatically configure seat, climate, route, and media settings per individual driver without manual input.
• Voice interaction — Quantised LLM inference on the HPC NPU enables natural language vehicle control without a touch interface.

8.3 On-Board vs. Cloud AI

On-board execution on the HPC with hardware accelerators is the only viable context for real-time vehicle functions. Cloud round-trip latency is 50–200ms; real-time vehicle decisions require responses in under 50ms. Cloud AI for real-time control is architecturally excluded by physics, not by technology choice. Cloud AI has genuine value for non-real-time functions: AI model retraining from fleet data, predictive maintenance analysis across thousands of vehicles, and OTA scheduling.

Key Takeaway: AI pillar value is hardware-determined. On-board, hardware-accelerated AI is the only viable path for real-time functions. The AI pillar must be co-designed with the HPC pillar: the compute platform must match the AI workload profile from the start.

---

9. Pillar 5 — CI/CD and Automotive DevOps

The SDV’s ability to continuously improve depends on the engineering process used to create, validate, and deploy software. CI/CD automates building, testing, signing, and deploying vehicle software so updates reach millions of vehicles safely and reliably. Automotive CI/CD differs from consumer software CI/CD in one critical respect: a failed deployment can have safety consequences. Every stage must generate evidence of correctness and provide a clear rollback path.

Figure 7: Automotive CI/CD Pipeline — Continuous loop from Plan through Monitor with safety-integrated testing and regulated OTA deployment

9.1 Pipeline Stages and Requirements

Stage	What Happens
Plan	Decide what to build and check if it affects safety software. Map out all changes before coding starts.
Code	Write software following strict automotive coding rules. Every change is peer-reviewed before acceptance.
Build	Compile the full software automatically. Scan for security flaws and quality issues on every submission.
Test	Validate at three levels — on a computer, in a simulated vehicle, and on real hardware. Real hardware testing is mandatory for safety software.
Release	Document all software components, complete regulatory checklists, and digitally sign the package before deployment.
Deploy	Roll out to 1% of fleet, monitor, then expand to 10%, then 100%. Auto-reverse if anything goes wrong.
Operate	Monitor all vehicles continuously for faults and unusual behaviour. Auto-rollback if a threshold is crossed.
Monitor	Feed field data back into the next development cycle. Fast-track security fixes. Retrain AI on new edge cases.

9.2 Virtual ECU: Software Development Without Hardware

Virtual ECU (V-ECU) technology runs automotive software in a simulated hardware environment. This removes the 18–24 month hardware dependency from early development. Full regression suites run in cloud CI infrastructure. Multi-supplier integration is validated before physical vehicle integration. V-ECU simulation is structured across five fidelity levels:

---

10. Conclusion

“The software-defined vehicle is not a single technology decision. It is the result of five engineering disciplines — architecture, HPC, software design, artificial intelligence, and continuous delivery — working together as one coherent system. Each pillar depends on the others. The E/E architecture provides the physical foundation; the HPC provides the processing power; software design makes that platform evolvable; AI makes it intelligent; and CI/CD makes the entire system continuously improvable after the vehicle leaves the factory. When all five are in place and integrated correctly, the vehicle stops being a product that depreciates and becomes a platform that grows. That is the SDV.”

---

References

[01]	Bosch Mobility Solutions — Software-Defined Vehicle: Architecture, Platform and Technology Overview. Robert Bosch GmbH, Stuttgart.
[02]	NXP Semiconductors — S32G274A Vehicle Network Processor Reference Manual (Doc. No. S32G2RM). NXP Semiconductors N.V.
[03]	AUTOSAR Consortium — Adaptive Platform Specification R22-11; Classic Platform Specification R21-11. AUTOSAR GbR.
[04]	ISO/SAE 21434:2021 — Road Vehicles — Cybersecurity Engineering. ISO / SAE International.
[05]	ISO 26262:2018 — Road Vehicles — Functional Safety, Parts 1–12. ISO.
[06]	UNECE WP.29 — UN Regulation No. 155 (Cybersecurity/CSMS) and No. 156 (Software Updates/SUMS). United Nations Economic Commission for Europe.
[07]	SAE International — SAE J3016: Taxonomy and Definitions for Driving Automation Systems. SAE International.

---

Abbreviations and Acronyms

Abbreviation	Full Form and Context
ASIL	Automotive Safety Integrity Level (ISO 26262: QM, A, B, C, D)
AUTOSAR	AUTomotive Open System ARchitecture
BEV	Bird’s Eye View — a neural network perception model that represents the scene from above
BSW	Basic Software — the lower-level software stack in AUTOSAR Classic
CAN	Controller Area Network — serial communication protocol standard in automotive ECUs
CI/CD	Continuous Integration / Continuous Deployment — automated software build, test, and delivery pipeline
DDS	Data Distribution Service — OMG standard real-time publish-subscribe middleware
DoIP	Diagnostics over Internet Protocol (ISO 13400) — IP-based vehicle diagnostic transport
E/E	Electrical/Electronic — refers to the vehicle’s overall electrical and electronic architecture
ECU	Electronic Control Unit — embedded computer controlling a specific vehicle function
gRPC	Google Remote Procedure Call — open-source RPC framework using HTTP/2 and Protocol Buffers
HIL	Hardware-in-the-Loop — test methodology using real ECU hardware with simulated vehicle environment
HPC	High-Performance Computer — centralised compute node in zonal SDV architecture
HSE	Hardware Security Engine — dedicated tamper-resistant cryptographic processor in NXP S32G274A
IPCF	Inter-Platform Communications Framework — NXP mechanism for shared-memory inter-core communication between Cortex-M7 and Cortex-A53
LIN	Local Interconnect Network — low-cost single-wire serial bus for simple actuators and sensors
LLCE	Low-Latency Communications Engine — NXP S32G274A hardware accelerator for CAN/LIN/FlexRay processing
LLM	Large Language Model — transformer-based AI model used for natural language understanding and generation
MCU	Microcontroller Unit — single-chip computer with CPU, memory, and peripherals for embedded real-time control
MQTT	Message Queuing Telemetry Transport — lightweight publish-subscribe protocol for V2Cloud telemetry
NPU	Neural Processing Unit — dedicated silicon for accelerating matrix operations in AI inference workloads
OEM	Original Equipment Manufacturer — vehicle manufacturer (e.g., BMW, Toyota, Ford)
OTA	Over-the-Air — wireless delivery of software updates to vehicles without workshop access
PFE	Packet Forwarding Engine — NXP S32G274A hardware accelerator for wire-speed Ethernet packet routing
SDV	Software-Defined Vehicle — vehicle in which functionality is defined, extended, and maintained through software via hardware abstraction
SIL	Software-in-the-Loop — simulation method executing production software in a virtual hardware environment
SOA	Service-Oriented Architecture — design paradigm in which software components expose functionality as discoverable, named services
SOME/IP	Scalable service-Oriented MiddlEware over IP — AUTOSAR-standard in-vehicle service communication protocol over Ethernet
TOPS	Tera Operations Per Second — unit measuring AI inference throughput of neural processing hardware
V-ECU	Virtual Electronic Control Unit — software-simulated ECU environment for hardware-independent development and testing
ZC	Zonal Controller — high-end ECU aggregating all functions within a physical zone of the vehicle

---

This whitepaper is authored by Ms. Kavitha Sasikumar, Senior Embedded and SDV Trainer at ANCIT. Technical content reviewed and approved by Dr. Kaarthick Balakrishnan, Research Director and Head of Engineering, ANCIT. For training enquiries, contact us at info@ancitconsulting.com or call +91 9840378602.