ENGLISH QUARTERLY

Vol : 12 Issue : 1 January - March 2025 Free Distribution

SOFTWARE
DEFINED VEHICLES
TRANSFORMING
THE FUTURE OF MOBILITY
TECHNOLOGY
Report
SOFTWARE DEFINED VEHICLES TRANSFORMING THE
FUTURE OF MOBILITY
Dr. Arunkumar M. Sampath
Principal Consultant, Tata Consultancy Services, Chennai

I. Introduction The automotive industry has been closely following the

developments in smartphones that have been pushing the

C ustomers of modern automobiles increasingly expect

their vehicles to offer intelligent features driven by
software that could be enhanced through Over-the-Air
limits on feature enhancement and faster turnaround of
new devices and offerings with the smartphone compa-
nies transforming the industry from hardware upgrades
(OTA) updates. An estimated 400 million vehicles world-
to software enhancements. Though industry pundits are
wide fall into the category of “Connected Cars” which
quick to point out the differences between the automotive
have the capabilities of real-time monitoring of features
industry and smartphones, the concept of software-de-
and events internal and external to the vehicle and sharing
fined vehicles (SDVs) has quickly emerged to leverage the
information with other connected cars or other Internet
increasingly standardized hardware and differentiation
of Things (IoT) through the internet. Modern vehicles
through software development. The key success factors
designed and developed by automotive Original Equipment
(KSFs) of SDVs include a) decoupling of network functions
Manufacturers (OEMs) continue to offer more high-quality
from proprietary hardware components and b) automo-
features, services, safety measures, and semi-autonomous
tive OEMs floating independent software subsidiaries to
driving capabilities. With an increased possibility of future
commercialize the software development pushing the
vehicle architectures beingf predominantly defined by
boundaries on life cycle of vehicles and the E/E compo-
Software (SW), the Software-defined Vehicles (SDVs) are
nents.
evolving from a means of transportation to “Smartphones
on Wheels” and further onto “Adaptability on Wheels”. The SDVs are expected to reduce the turnaround time
for software updates significantly, enhance in-vehicle
customer experience, and modify/enhance features and
performance of different zones in a vehicle through soft-
ware updates with little or no impact on other zones or
the overall vehicle thus reducing the cost of development
and providing significant levels of flexibility. In Figure 1,
the growth projections of SDVs over a decade are shown
(Ref [1]), with the share of commercial vehicles steadily
Figure 1. Software-Defined Vehicle (SDV) Growth Projections (Ref [1]) increasing but with passenger vehicles still accounting for

32 MARCH 2025 MOBILITY ENGINEERING

 TECHNOLOGY
Report
>80% share. The trend in SDVs is for the automotive OEMs
to continuously update the software over the air (OTA),
and introduce enhanced features, and safety aspects with
little or no modifications in the hardware or components,
thus extending the lifespan of electrical and electronic
(E/E) components.

(OS), carry out increased virtualization and containeriza-

tion, quickly turn around SW development and validation,
push OTA SW updates on demand or as needed, and offer
connected cloud services (CCS) with hybrid in-vehicle and
cloud computing in (near) real-time. The need for SDVs
Figure 2. Software-Defined Vehicle Market Share by has also risen based on the trends in revenue from vehicle
Application (Ref [1]) sales and software sales as shown in Figure 3 (Ref [2]). It
can be noticed that the SW sales revenue increased from
The software-defined vehicles (SDVs) are disrupting
3% in 2019 to 14% in 2025. Tesla, Inc. has been pioneering
and transforming the automotive industry by continu-
a new SW-based feature upgradation and charging
ously updating the featues and safety aspects through
model with a) one-time charge for pre-installation and b)
over-the-air (OTA) software updates, providing enhanced
subscription services by the end of the year. In the Over-
flexibility of using the existing hardware/components and
the-air (OTA) upgrade optional package, it is observed
offering personal customization to the end users with
that the OTA upgrades are chargeable for every upgrade
current E/E architecture and modifiable software. The
and that the online upgrades are frequently provided for
software-defined vehicle market share by application
powertrain, in-vehicle infotainment (IVI), autopilot, ADAS,
is shown in Figure 2 (Ref [1]), with the biggest share for
and chassis systems. Advanced Internet of Vehicles (IOV)
Advanced Driver Assistance Systems (ADAS), followed by
service is also provided on a monthly subscription basis
Autonomous Driving, Infotainment Systems, and Power-
comprising advanced IOV connectivity services including
train Control. ADAS, comprising multiple technologies
real-time traffic, video/music streaming (recording,
such as Lane Keep Assist (LKA), Lane Departure Warning
uploading, downloading), and karaoke.
(LDW), Automated Emergency Braking (AEB), Adaptive
Cruise Control (ACC), etc. enhances vehicle safety and
reduces the occurrence of accidents. Multiple OEMs have
been pioneering Level 3+ Autonomous Vehicle (AV) capa-
bility, with its application share being the second biggest
in Figure 2, followed by In-Vehicle Infotainment (IVI)
systems that offer customers subscription-based features
and entertainment.

Keywords: Software-defined vehicles, Over the Air

(OTA) updates, Internet of Vehicles (IOV), 5ABCD, Contain-
erization, Cybersecurity, Connected Cloud Services (CCS),
mobility insurance

II. Software Defined Vehicles

The automotive industry has been looking up to smart-
phone technologies to decouple Hardware (HW) from
Figure 3. SDVs: Trends in Vehicle and
Software (SW), build vehicle-level operating systems Software Sales Revenue (Ref [2])

MOBILITY ENGINEERING MARCH 2025 33

TECHNOLOGY
Report
pliant SW along with partial vehicle OS and API standard-
ization in Level 1.0 to Abstraction & Virtualization for both
in-vehicle and V2X communications in Level 3.0. For semi-
conductors, the evolution is from large-scale microcon-
troller units (MCUs) and Systems on Chip (SOCs) for HPC
in Level 1.0 to High-performance/large-scale Systems on
Chip (SOCs) for HPC in Level 2.0 transitioning to neuro-en-
abled semiconductors to applications outside of mobility
in Level 3.0.

III. SDV – Evolution of OEM-Supplier Ecosystem

The automotive OEM-supplier ecosystem evolution is

shown in Figure 5 (Ref [5]) with disruption in the tradi-
tional OEM-Tier 1 supplier model designing and developing
hi-tech components to a collaborative OEM-Tier 0.5 model
wherein the OEMs take a bigger lead in defining require-
ments, developing E/E and SW structure, and designing
the control algorithms and the suppliers acting more as
strategic partners in developing highly differentiated
Figure 4 a), b). SDV: Evolution of Different Levels (Ref [3], [4])
components and systems. This has resulted in the evolu-
tion of four different Automotive SW business models
as shown in Figure 5 (Ref [5]), with additional details as
given below:

1. SW custom development/Non-Recurring Engineering

Services
Figure 4 c) SDV: Tabular Format of different levels and a. Intelligent cockpit SW solutions
feature evolution (Ref [3], [4])
b. A DAS/Autonomous Driving (AD) algorithm and SW
packages
The different levels of vehicle evolution from mechanically
controlled vehicles (Level 0) towards software-defined c. Intelligent Driving (ID) solutions
ecosystems (Level 5) are shown in Figure 4a) (Ref [3]). 2. Consulting and Technical Engineering Services (CTES)
The evolution of different Software-Defined Vehicle (SDV) a.  arly-stage design and development
E
levels along with the E/E architecture shown is in Figure
b. T
 echnical drawing releases for prototype builds
4b) (Ref [4]). The tabular details of different levels and
c. Component or Software testing and debugging
the evolution of different features are shown in Figure 4
d. System level and Vehicle level validation
c) (Ref [3], [4]). The features include a) Connectivity, b)
IT infrastructure, c) SW development, d), SW structure, 3. SW Intellectual Property (IP) Licensing and Application
e) cybersecurity, and f) semiconductors. In the evolution Development
of Connectivity, some functions or control systems are a. S W modules development and release, complying
upgraded through regular OTA SW updates (semi-dynamic with AUTOSAR standards
SW management) in Level 1.0 to most of the functions/ b. A gile or Scrum-based or DevOps-based SW tool
control systems getting updated through regular OTA SW chains
updates (full dynamic SW management) in Level 2.0 and c. Specific component or System design tools
constant seamless connectivity between vehicle & external
d. Simulation and Test tools
entities enabling real-time data analysis, AI-based learning
and algorithm improvement, and OTA SW upgrades in 4. Integrated Hardware (HW) and Software (SW) Products
Level 3.0. The SW structure evolves from AUTOSAR-com- and Solutions

34 MARCH 2025 MOBILITY ENGINEERING

 TECHNOLOGY
Report

a. Domain controllers dardization of a basic controller. The architecture evolved

b. V ehicle-Cloud integrated products and service plat- towards Fusion architecture with the disappearance of
form domains and fusion of Domain Controller Units (DCUs)
c. 
Integrated Document Management System (DMS) required for ADAS functions to work effectively. The next
solutions evolution/vision in the E/E architecture is towards zonal
ECUs with centralized vehicle computer where all the
DCUs are brought together in fusion to build one central-
ized vehicle computer. The evolving vision is the transfer
of embedded functions into the cloud with a hybrid HPC
+ cloud-enabled real-time computing and the upgradation
of Autonomous Driving (AD) algorithms in response to
road conditions, weather conditions, and traffic conditions.

Figure 5. SDVs: Evolution of OEM-Supplier Ecosystem (Ref[5])

The above business models have caused a significant

disruption in the automotive industry with OEMs increas-
ingly developing their own Operating Systems (OS), lever-
aging public and private cloud on data management,
Figure 6. SDVs: Evolution of E/E Architecture (Ref [6])
analytics, and decision-making, and reaching out directly
to the automotive SW vendors bypassing the traditional The time-based evolution of E/E architecture in SDVs
Tier 1 suppliers, if required. is depicted schematically in Figure 7 (Ref [2]), split into
IV. SDV – Evolution of E/E Architecture four different time zones, viz., a) before 2020, b) 2020
to 2025 timeframe, c) 2025 to 2030 time frame, and d)
The evolution of E/E architecture is shown in Figure beynd 2030. The details of different architectures are
6 (Ref [6]) with the architecture evolving from modular given below:
architecture where each function has its own Electronic
Control Unit (ECU), sometimes operating on diverse oper-
ating systems (OSs) to a vehicle + cloud computing archi-
tecture where the embedded functions are transferred to
the cloud. In the Integration version of E/E architecture,
domain-based controllers are created through the merging
of (ECUs). This evolves towards Centralization architecture
wherein domain centralized units are created with stan-
Figure 7. SDVs: E/E Architecture Evolution (Ref [2])

MOBILITY ENGINEERING MARCH 2025 35

TECHNOLOGY
Report
1. Before 2020 (Distributed Architecture) – it has inde-
pendently functioning ECUs in a distributed environ-
ment primarily operating using CAN and LIN-based
communication interfaces. The Body Control Module
(BCM) utilizes an integrated gateway for communi-
cation with dedicated sensors and ECUs to imple-
ment the algorithms. Owing to the ECUs working
independently and sometimes on different operating
systems (OSs), the challenges include a) sub-optimal
computing power leading to redundancy, b) complex
wiring harness due to intricate in-vehicle commu-
nication requirements, and c) lack of flexibility for
upgrade and scale up.

2. In the 2020-2025 timeframe (Centralized cross-do-

main architecture) – Here, multiple major domains
are created based on specific functions of electronic
components such as powertrain, chassis, autopilot,
body, in-vehicle infotainment (IVI), etc. There is an
improvement in communication interfaces in the form
of CAN+ and Ethernet with ease of OTA upgrades
for domain ECUs. The drawbacks of this architecture
include a) higher cybersecurity requirements due to
intricate cross-domain functionality and b) higher
computing power.
3. In the 2025-2030 timeframe (centralized vehicle E/E
architecture) – it enables a centralized computing
platform and decision-making with specific zones
and zonal ECUs handling the left front, left-right,
left rear, and right rear zones of the vehicle and
acting as a gateway to distribute data and electric
power to different components and systems. There
is a marked improvement through a simplified wiring
harness design in the vehicle-zonal architecture
over the earlier cross-domain architecture leading
to a) weight reduction, b) cost benefit, c) reduced
complexity, and d) easier SW upgrade possibility. Figure 8. SDVs: E/E Architecture Evolution (Ref [7])

4. Beyond the 2030 timeframe (vehicle-cloud The evolution of legacy distributed E/E architecture into
computing architecture) – the vision is to evolve the zonal architecture initiated the SDV paradigm and led to
towards a central computing platform that can carry the futuristic zonal architecture with Vehicle-to-everything
out hybrid vehicle-cloud computing, interface with (V2X) communication as shown in Figure 8 (Ref [7]). With
power, actuators, and sensors, and optimize the many automotive OEMs mastering L3+ Autonomous Driving
performance and power through a combination of (AD), the trends in SW development include 1) Full stack
in-vehicle real-time data processing and supplemen- development, 2) Operating system (OS) development, 3)
tary cloud computing for more effective and efficient Core algorithm development, 4) Edge + Cloud computing,
decision-making, critical for realizing higher levels of 5) Backward integration with System on Chip (SOC) manu-
Autonomous Driving (AD).

36 MARCH 2025 MOBILITY ENGINEERING

 TECHNOLOGY
Report
facturers (AI-enabled chips), 6) Sustainable and Iterative from a file and can handle dynamically scheduled and
product experience offering full life cycle services, and installed applications.
7) revenues from one-time fee, regular OTA upgrades,
As shown in Figure 9 b) (Ref [6], [8]—[9]), the SDVs
and subscription fee for specific feature enablement or
adopt a hybrid AUTOSAR CP and AP E/E architecture.
upgrades.
The AUTOSAR CP supports powertrain/chassis, ADAS &
safety, body functions, and in-vehicle infotainment (IVI)
through CAN/LIN and Ethernet communication inter-
faces as computations can be handled through functions
with low data rates. The AUTOSAR AP supports a central
computing cluster (CCC), I/O cluster, connectivity control
(CC) that interfaces with Smart Charging, Off-board tester,
and OTA connectivity services.

V. SDV – Evolution of SW Architecture

Figure 9 a), b). SDVs: AUTOSAR CP, AP, and Hybrid E/E Architectures
(Ref [6], [8]—[9])

The details of AUTOSAR Classic Platform (CP) and Adap- Figure 10. SDVs: Sofware Architecture Evolution (Ref [6])
tive Platform (AP) are shown in Figure 9 a) (Ref [6], [8]—
The evolution of Software Architecture in SDVs from
[9]) in terms of 1) operating system, 2) code execution,
the current structure to a new platform is shown in Figure
3) application address space separation, 4) scheduling, 5)
10 (Ref [6]). In the current HW/SW structure, the OEMs
compiling, 6) configuration, and 7) supported protocols.
are highly dependent on Tier 1 suppliers for hardware,
The Classic Platform (CP) is based on the OSEK operating
modules, and system-on-chip (SOC) components with
system and is used for the highest real-time requirements.
the services, Application Programming Interfaces (APIs),
The platform is run with code executed from ROM and with
and software “tightly coupled” to the SOC components.
fixed scheduling but with no application address space
The wide gamut and number of ECUs in the vehicle often
separation. The AUTOSAR CP expects a compiled system
run on different Operating Systems (OSs) and devices for
configuration and requires that all the ECUs be compiled
different end applications posing a mammoth challenge for
as a whole. The platform only handles static mapping of
feature commonality, standardization, or upgrade. As can
signals to a specific service and only supports a translation
be seen from Figure 10 (Ref [6]), the new HW/SW struc-
from signal-oriented CAN communication to the Ethernet.
ture has a multi-layered SW architecture and introduces
The AUTOSAR Adaptive Platform (AP) is significantly abstraction layers that absorb the differences between
more dynamic, is suitable for greater computing power, HW, OS, and middleware and remove the variant devel-
and can be used for Service Oriented Architecture (SOA) opments leading to a significant increase in SW reuse. The
(Ref [8]—[9]). The platform relies on a subset of the stan- abstraction layers act as the essential building blocks to
dard POSIX OS interface that is standardized for all appli- create a common or cross-platform that is independent of
cations and SW components. The platform is run with the middleware or operating system (OS) or the device
code loaded onto ROM with dynamic scheduling (varying variants. The HW abstraction layer (HWAL) enables inter-
number of tasks and preemptive multitasking) and with facing with multiple devices agnostic of the HW. The OS
application address space separation implemented. The abstraction layer (OSAL) enables the reuse of middle-
system configuration is dynamically loaded at runtime ware on a variety of OS. The new SW platform enables

MOBILITY ENGINEERING MARCH 2025 37

TECHNOLOGY
Report
cross-platform adaptability and a significant increase in design patterns such as scalability and hierarchy-based
SW reusability. architecture.

Figure 11. SDVs: Multi-layered Service-Oriented

Architecture MSOA (Ref [6], [10])
Figure 12. SDVs: Updated SW Development Lifecycle (Ref [10])
The Multi-layered Service-Oriented Architecture MSOA)
The updated SW development lifecycle (SDLC) for
is developed based on a multi-layered classification of
SDVs with state-of-the-art methods and tools is shown in
ECUs independently interacting with GPOS and RTOS.
Figure 12 (Ref [10]) with key success factors (KSFs) iden-
The MSOA is developed employing encapsulation and
tified as seamless design and documentation of in-vehicle
layering to reduce fragmentation and complexity and to
and back-end architectures. Based on zonal multi-lay-
facilitate the usage of a generalized computing platform.
ered architecture, software development is carried out
The components serving specific vehicle functions will
for specific domains in the vehicles such as B&C – body
be encapsulated in three layers, viz., a) a basic layer for
& comfort, P&C - powertrain and chassis, DA&S - driver
services such as processing sensor data, b) an extended
assistance and safety, I&C – information and communica-
middleware layer for data exchange and data fusion, and
tion, etc. To assist with zonal SW development, commu-
c) an application layer using all the data for applications.
nication standards such as LTE, Wi-Fi, and 5G between
MSOA ensures the reuse of SW components and lets the in-vehicle network and backend ensure connectivity
developers create efficient new functions (apps) that can and bandwidth. Utilizing high-speed networks, mobility
be easily integrated with the whole ecosystem of a device. services, and specific applications such as Autonomous
MSOA a) enables easier SW portability across multiple Driving (AD) functionality, In-Vehicle Infotainment (IVI),
vehicles, b) reduces system complexity, c) lets thorough etc. are executed at the back end. The future innovation
SW testing against interfaces due to stringent encapsu- in SDV SDLC is enabled by Central Communication Server
lation and hierarchy, and d) utilizes Agile methods and (CCS), MSOA, hierarchical E/E architecture, and seamless
DevOps. Additionally, MSOA a) imitates security patterns connectivity between in-vehicle and back-end architec-
already existing in the IT and consumer-electronics indus- tures. Closer interaction between in-vehicle and back-end
tries, b) facilitates functional separation, encoding, and architectures using hi-speed networks enables a) data
firewalls, c) allows closer interaction between the in-ve- handling, b) remote SW updates, c) SW design for func-
hicle E/E architecture and the back-end architecture, d) tions, and d) execution of code/algorithm on an ECU or
permits increasing data exchange between multiple auto- at the back end. The updated SDLC technological inno-
motive functions and the back end, and e) authorizes vation will provide multiple benefits such as a) seamless
partial back end functional execution. Multiple researchers requirements process from customer interaction to the
and developers have confirmed that the MSOA approach software architecture, b) complete modeling of E/E archi-
a) enables seamless integration of new functions and tectures based on SOA, c) encapsulation of content for
provides personalization for each user, b) provides remote distributed development using SOA design principles, d)
updates that facilitate optimization, quality enhancements, agile development process, joint Scrum teams, and shared
and flexible lifecycle management, c) permits increasing code repositories, and e) enablement of DevOps, CI/
data exchange between multiple automotive functions CD tools implementation and continuous integration. As
and the back end, and d) empowers usage of high-perfor- Automotive SDV developers adopt the best practices from
mance processors common to IT & smartphones with clear the smartphone industry, it is understood that automo-

38 MARCH 2025 MOBILITY ENGINEERING

 TECHNOLOGY
Report
tive electronics development a) can piggyback on IT and visual inputs (video and images), the MSOA design evolu-
consumer-electronics development and standards, b) Is tion must consider high-performance GPUs with AI capa-
expected to exceed the classic software systems in terms bilities.
of safety, security, performance, and usability, and c) must
reinvent many of the technologies so that they meet the
stringent automotive industry demands (Ref [10]).

Figure 13. SDVs: Multi-layered Architecture and Figure 14. SDVs: Software Technology Stack
Design Evolution (Ref[5]) Evolution (Ref[5])

A generic design of SDV MSOA is shown in Figure 13 The SW technology stack in SDVs has been evolving in
(Ref [5]) which has been evolving to provide continuous line with the vehicle-level evolution of E/E architecture in
OTA updates, countermeasures against cyber attacks, terms of Distributed Basic ADAS ECUs  Partial Consider-
safe operations during ADAS/AD modes, etc. The need ation of ADAS features  Consolidated ADAS/AD features
for the highest levels of safety assurance during ADAS/  Vehicle Computing + HPC-based ADAS/AD features. This
Autonomous Driving (AD) modes demands HW and SW specifically calls for long-term scalability of SDV archi-
redundancy and Functional Safety (FuSa) in safety-critical tecture for ADAS and AD operations by segregating HW
systems and operations, which in turn results in the design &SW and ensuring that the features, functionalities, user
adaptation in the form of independent power supplies, experience, and SW upgrades are driven mainly by SW,
multiple sensing, and consensus-driven AI. The critical agnostic of HW. The key technological changes required to
requirement of dynamic and localized edge computing realize the SW stack are a) HW abstraction, b) application
applications to support data processing and functional vali- middleware, c) containerization, d) virtualization, and e)
dation raises the need for runtime applications supporting a centralized E/E architecture with HPC units connected
edge computing to quickly develop and deploy efficient through Gigabit Ethernet. Specific design changes at the
functions in terms of computing power, latency, and cost. vehicle platform level are also called for such as vehi-
To thwart the increased cyberattacks in CAEVs, the SDV cle-level operating system (GPOS and RTOS), specific ECU
MSOA design should offer the highest level of cyberse- clusters, Type I hypervisor, and middleware that sepa-
curity protection in the form of countermeasures at the rate the dynamic SW stack (e.g., vehicle services, shared
HW and SW levels. As continuous OTA upgrades are a key services, cloud services, apps).
success factor (KSF) of SDVs extending the lifecycle of VI. SDVs – High-Performance Computing
vehicles, the MSOA design evolution should consider the
multi-year span of HW along with the integration of vehi- A schematic of the High Performance Computing (HPC)
cle-level, high-speed, low-latency, and low-cost networks for abstraction in SDVs is given in Figure 15 (Ref [5]).
such as Gigabit Ethernet. As SDVs need to support AD The architecture comprises General Purpose Operating
operations that acquire and process high-bandwidth System (GPOS) and Real-Time Operating System (RTOS),

MOBILITY ENGINEERING MARCH 2025 39

TECHNOLOGY
Report
Type I hypervisor, non-volatile memory, volatile memory, VII. SDV – Virtualization, Containers, and DevOps
separate CPU clusters for GPOS and RTOS, Graphical
A schematic of virtualization and DevOps in SDV devel-
Processing Unit (GPU), different communication protocols,
opment is shown in Figure 16 (Ref [11]). Utilizing the cloud
and interfaces for external/cloud connectivity. GPOS forms
computing environment provided by the Hypervisor
the basis for Applications and Containers to run portable
vendors (Microsoft Azure, Amazon AWS, Google GCP, etc.)
SW integrated with HW abstraction layers. RTOS provides
the SDV toolchain enables a) development tools, b) devel-
deterministic services for
opment,

Figure 16. SDVs: Virtualization and DevOps (Ref [11])

validation, and integration, and c) execution environ-

ment. The virtualization also provides opportunities for
extensive Automotive SW stack development, uploading/
Figure 15. SDVs: Higher Performance Computing (HPC) downloading code from GitHub marketplace, integrated
for Abstraction (Ref [5])
Hardware-in-loop (HIL) testing, vehicle messaging, data
safety-critical functions such as steering and braking and analytics, and Autonomous Vehicle Ops (AVOps).
while GPOS focuses on general services and data Multiple use cases could be generated from virtual-
processing apps. The HW abstraction services are offered ization and DevOps in SDVs including a) accelerated SW
by GPOS or other middleware. Utilizing both OSs, simulta- developer onboarding due to faster familiarization, b)
neous GPOS + RTOS services are possible by using multiple utilization of virtual environment and efficient deployment
CPU clusters and scalable memory. The Type I Hypervisor to simulate multiple combinations of HW and SW, c) SIL
serves multi-purposes such as a) providing virtualization validation that includes running automated build, test and
services, b) utilizing non-volatile memory (NVM) and vola- validate pipelines along with cloud services, d) HIL vali-
tile memory (VM), and c) optimizing GPOS + RTOS simul- dation involving deployment and monitoring of multiple
taneous operations. The HPC environment provides a wide HIL tests, e) test fleet validation including root cause anal-
gamut of physical interfaces to integrate with a) CAN, LIN, ysis (RCA) and vehicle behavior analysis from SW updates
and Flex Ray networks and b) High-bandwidth networks based on logs and traces of SW applications, f) faster and
(USB, Ethernet, PCIe). The GPUs carry out multitasks such traceable SW releases for vehicle fleet tracking and SW
as a) processing ADAS/AV sensor data and applications, updates using DevOps best practices, and g) Continuous
b) powering the processing for digital cockpit interfaces Integration/Continuous Deployment (CI/CD) by taking
in IVI, and c) running the data processing and applications feedback from field trials, carrying out RCA, and doing SW
for AV and IVI. The distinct and separate CPU clusters for upgrades to remove bugs and/or improve performance.
GPOS and RTOS a) separate the handling of deterministic
The SDV development involves a significant amount
and time-sensitive networks (TSN) for low battery appli-
of SW-based simulations leading to new opportunities
cations and b) enable “redundancy” of operations and
for Tier 1, Tier 2 suppliers, and Automotive SW vendors
“Functional Safety” (FuSa).
such as a) virtual ECU development, b) High-Performance

40 MARCH 2025 MOBILITY ENGINEERING

 TECHNOLOGY
Report
Compute (HPC) capability build, and c) Containerized applications, all of which ITS, etc.). The Component Docker
enable SW development in parallel to overcome the challenges of HW avail- Cluster comprises diverse in-vehicle
ability or modifications. The developers work in consonance with Connected applications facilitating various func-
Vehicle System Alliance Vehicle Signal Specification (COVESA-VSS) that stan- tionalities including driver assistance
dardizes access to vehicle data to receive inputs from various components (e.g., ADAS), intelligent path planning
and vehicle sensors and develop Application Programming Interfaces (APIs). (e.g., ITS), camera and sensor moni-
Compliance with COVESA-VSS facilitates standardization to enable interopera- toring, media capabilities, intelligent
bility and HW-agnostic SW and API development. speed control, traffic signal detection,
and management of the engine and
brakes. In line with SOAFEE (Scalable
Open Architecture for Embedded
Edge) standards, OEMs working on
SDVs are adopting a mixed-crit-
ical orchestrator that handles both
mission-critical and non-critical
applications within the vehicle (Ref
[13]). As an example, SOAFEE-com-
pliant architecture includes safe-
ty-critical braking or steering system
applications running independently
to a non-critical IVI application or a
climate control application in parallel.
The Scheduling module monitors the
container metrics, current real-time
requirements of the vehicle, and the
status of different containers tied
to different ECUs and reschedules
the Containers to meet the dynamic
vehicle requirements. The Monitoring
module comprises open-source tool-
kits Prometheus for monitoring and
alerting on container metrics and
Grafana for cloud observability along
with the Prometheus Query Language
(PromQL) to query the status of real-
time distribution of containers per
node and activated nodes in a cluster.
The Cadvisor in the Monitoring
module provides information on the
default distribution of the running
Figure 17 a), b). SDVs: Container Design, Scheduling, containers between the ECUs in the
and Optimization (Ref [12], [13]) car as well as their resource usage
and performance (Ref [13]).
An important aspect of SDV SW development is Container Design, Sched-
uling, and Optimization, the schematics of which are given in Figures 17 a) The nodeExporter in the Moni-
(Ref [12] and 17 b) (Ref [13]). As the schematic indicates, the containers in toring module in Figure 17 b) in Ref
the Docker Cluster are tied to different ECUs (engine, maps, brakes, ADAS, [13] helps collect the vehicle status

MOBILITY ENGINEERING MARCH 2025 41

TECHNOLOGY
Report
metrics, such as the number of ECUs per cluster, memory, tory working party within the United Nations Economic
CPU, and Power (Energy) utilization per each node. The Commission for Europe (UNECE), released two new regu-
Prometheus toolkit collects and stores time series data on lations (R155 and R156) that mandate minimum cyberse-
the status of ECUs and containers and provides this input curity standards for vehicles for type approval. Along with
to the Scheduling component. The scheduler receives as WP.29’s regulations, ISO/SAE 21434 was jointly developed
input the real-time data on container status, vehicle status, by the International Organization for Standardization
and preferences and constraints, which are monitored on (ISO) and the Society of Automotive Engineers (SAE),
a regular basis. The Dashboard displays the alerts and titled “Road Vehicles – Cybersecurity Engineering”, and
recommendations for scheduling options and redistrib- released in Aug 2021. Cybersecurity researchers continue
uting the containers among the ECUs. The Scheduler plays to develop countermeasures to address the increasingly
a critical role in multiple instances such as in the cases of a) complex and sophisticated cyberattacks through a) zero
user preference to optimize specific objectives or add new trust architectures where everything is untrusted, b)
constraints and require the reallocation of vehicle appli- complete verification of each component to ensure trust-
cations based on the updated input and b) overloading of worthiness, c) system-level interaction operating on a
resources leading to the deactivation of one of the ECUs least privileged basis, d) increased transparency of Soft-
due to either an insufficient battery capacity or security ware Bill of Materials (SBOMs), and e) insistence of soft-
issue or during OTA upgrade or due to the kickoff of the ware/component certification leading towards R155 type
power conservation mode. approval.

VIII. SDV – Cybersecurity IX. SDV – Impact on Insurance

As more and more OEMs are developing technologies It is estimated that by 2030 almost all modern automo-
and SW solutions towards realizing SDV 3.0 with hybrid biles will be connected and more than 70% of them will
in-vehicle and cloud computing to process real-time data, have ADAS and Level 3+ autonomous features, as shown
advance L3+ Autonomous Driving, and optimize perfor- in Figure 19 (Ref [15]). This has a direct impact on the
mance, cybersecurity becomes a key criterion to offer complexity of SW in modern vehicles with >300 million
safe and secure driving and user experience. In Figure 18, lines of code required to run these vehicles with advanced
multiple avenues and threats for cybersecurity in SDVs are performance and safety features, resulting in different
captured (Ref [14]). In 2021, the World Forum for Harmo- levels of SDV functionalities as shown in Figures 4 a) and
nization of Vehicle Regulations (WP.29), a special regula- 4 b) (Ref [3], [4]).

Figure 18. SDVs: Cybersecurity Issues & Countermeasures (Ref [14])

42 MARCH 2025 MOBILITY ENGINEERING

 TECHNOLOGY
Report

Figure 19. Connected, autonomous, and electric cars market trends from
2017 to 2030 in the US, Europe, and China (Ref [15])

As the share of Electric Vehicles (EVs) crosses 50% by

2030 as shown in Figure 19 (Ref [15]), it introduces new
challenges to the vehicle insurers in terms of risk assess-
ment, insurance underwriting, actuarial modeling, and Figure 20. Trends in US personal auto insurance market
direct premiums in $billions (Ref [18])
premium calculation. Owing to the higher levels of tech-
nological complexity in Connected, Autonomous, Elec- Multiple studies have been carried out to understand
tric Vehicles (CAEVs) with increased levels of Software the impact of SDV development, increased Connected
and regular OTA updates, the vehicles may need dedi- Cloud Services, and OTA updates on the insurance market
cated service stations, specifically trained technicians, (Ref [16] – [18]). The McKinsey report in Ref [18] captures
and incur higher repair costs. The insurers are expected the trends in US personal auto insurance market direct
to evaluate the risks associated with advanced software premiums, as shown in Figure 20. The trends indicate
dependency, unique maintenance needs including parts the disruption in the automotive insurance industry with
embedded with sensors for ADAS features, the decision insurance premiums for conventional automotive personal
on repair vs replacement of batteries depending on their lines reaching the peak of about $263 billion by 2026
remaining useful life (RUL), and liability of driver (human) and reducing to about $248 billion by 2030 along with
vs OEMs (machine or product) for Level 3+ Autonomous disrupted personal lines coverage increasing from about
Vehicle (AV) capabilities. Additional risks include a) soft- $50 billion in 2026 to about $100 billion by 2030. The
ware reliability, b) cybersecurity and data privacy, c) func- disruption is due to multiple factors including a) almost
tional safety and system redundancy in case of failures, 100% connected vehicles, b) > 50% share of EVs, c) and
and d) change in driver behaviour arising from Level 3+ about 70% adoption of ADAS features and Level 3+ AV
AV capabilities. As the technologies and SDVs are continu- capabilities. A new actuarial model is being developed
ously evolving, the insurers continue to have a challenge in with increased adoption of telematics-based dynamic
evaluating the risk with limited or no prior vehicle history insurance pricing, Generative Artificial Intelligence (Gen
and quantification of hardware specifications and OTA AI)-based claims handling, and disrupted personal lines
SW updates in terms of insurance risk. The continuous coverage of about $100 billion for the new generation of
evolution of technology, the need for compliance with CAEVs with customers interacting only with the insurers
local regulations, and the potential for shifting of liability for dynamic OTA SW updates and not the OEMs. Insur-
from personal liability towards product liability supplied ance carriers at the forefront of technology adoption and
by OEMs or system suppliers for Level 3+ AV capabilities having an in-depth understanding of safety enhancement
is forcing the traditional automotive insurance industry and personalized customer experience will be influencing
to experience “disruption” and adopt new methods of future actuarial models by identifying the risks and by
underwriting. The insurers need to disrupt the traditional incorporating changes in the insurance premium calcu-
insurance models by investing in new capability building lations. These pioneers will also underwrite insurance for
and partnerships and increasingly promoting commercial vehicles with less technological capabilities as they coexist
automotive premiums. with vehicles with advanced technologies.

MOBILITY ENGINEERING MARCH 2025 43

TECHNOLOGY
Report
measures continues towards developing zero trust archi-
tectures, system-level interactions operating on a least
privileged basis, and increased transparency of SBOMs.
Increased electrification and the higher number of OTA
SW updates and features affecting the performance and
drivability introduce new challenges to vehicle insurers in
terms of risk assessment, insurance underwriting, actu-
arial modelling, and premium calculation. The impact of
Figure 21. Evolution of Insurance Business Models (Ref [18]) SDV development on auto insurance, disruption in the
insurance industry, the trends in personal auto insurance
The evolution of automotive insurance models with the
premiums, and the emergence of new insurance business
development of SDVs is shown in Figure 21 (Ref [18]). In
models are presented.
insurance model 1, OEMs have the largest share as they
create full-stack insurance carriers with the insurers taking Future Work
up reinsurance and claims handled by the third-party
administrator. In Model 2, the OEM stake is smaller than
in Model 1 as they build alliances with insurers who under-
write policies along both personal lines and commercial
lines. In Model 3, OEMs monetize the insurance leads and
position themselves as Aggregators or build platforms
and interface with insurers for personal policies. The rela-
tive share of carriers handling commercial insurances in
Model 3 is the highest (more than Models 1 or 2) with no
direct connection between the driver and the OEM, unlike
in Models 1 and 2.

Conclusions Figure 22. A generic software defined IOV architecture (Ref [19])

The need for SDV development, trends in the revenues

Researchers have been working on multiple futuristic
from vehicle sales and SW releases through OTA updates,
SDV technologies including software-defined Internet
and the evolution of different levels of SDV are presented.
of Vehicles (SD-IOV). A generic software-defined IOV
The recent developments and the evolution of E/E archi-
(SD-IOV) architecture is given in Figure 22 (Ref [19]). The
tecture are given in detail with the emergence of zonal
SD-IOV is a result of the integration of Software Defined
architecture in SDVs leading towards the hybrid in-vehicle
Networking (SDN) and IOV and works on the principle
and cloud-computing for L3+ AD experience. The evolu-
of segregation of the control plane and data plane. The
tion of SW architecture and the importance of the Digital
generic SD-IOV architecture comprises a) logical (SDN)
Foundation Platform leveraging the multi-layered SOA is
controllers, b) SDN switch network, c) SDN-enabled wire-
elucidated. To increasingly decouple SW development and
less access infrastructure, and d) SDN-enabled vehicles.
deployment from the HW and to reduce the time-to-market
Research continues on multiple implementation methods
for SW releases, the SDV development is adopting virtu-
of wireless control paths based on their performance and
alization, container design, and optimization, and DevOps
complexity (Ref [19]).
and SW toolchains for Continuous Integration and Contin-
uous Development (CI/CD). As more OEMs are adopting The automotive OEMs have been increasingly working
hybrid in-vehicle and cloud computing to process real- on building a Road-to-Cloud ecosystem, offering cloud
time data and offering L3+ Autonomous Driving, cyberse- services based on SD-IOV, based on an architecture as
curity becomes a key criterion for offering safe and secure shown in Figure 23 (Ref [20]). The development and
driving and user experience. Multiple avenues for cyberat- updates are segregated into in-vehicle tasks (system inte-
tacks and their potential impact on the performance of the gration) and vehicle-to-cloud activities (cross-domain
vehicles are captured. Research on cybersecurity counter-

44 MARCH 2025 MOBILITY ENGINEERING

 TECHNOLOGY
Report
integration). The Connected Cloud Services (CCS) enable data annotation, image rendering, etc. The SaaS includes
a cloud-based development and collaboration framework vehicle management, production/sales data, after-sales
to build a Digital Twin in a safe and secure environment. data, service management, etc.
Owing to concerns about data security and privacy and The IOV CCS offers multiple use cases such as a) Person-
with a clear business proposition to monetize the enor- alization, b) Predictive Maintenance, c) Charging Solutions,
mous data generated by the Connected, Autonomous, d) Safety & Security, e) Transportation Management, and
Electric Vehicles (CAEVs), OEMs have been experimenting f) Fleet Management. The cloud services related to in-ve-
with private cloud layout and services with a focus on big hicle infotainment (IVI) include entertainment apps that
data, advanced data analytics, and AI. Many OEMs that have can integrate Instagram, Facebook, and TikTok and let
been playing a leading role in SDV development have been users have multiple facets of user experience such as a)
developing their own Automotive Operating Systems (OS) shoot and share or watch videos, b) listen to audiobooks,
and looking into the full software development lifecycle c) read newsfeeds, d) take and share pictures, e) listen to
(SDLC), from design to after-sales service and support, with speech from text through AI-enabled text-to-speech, etc.
private cloud layout and services. As many customers seek
The IOV Automotive Cloud Services (ACS) includes
feature upgrades and OTA updates on demand, the private
R&D, production, sale, maintenance, and post-sale services
cloud layouts and services enable OEMs to focus on elastic
of SDVs based on 5ABCD (5G, Artificial Intelligence, Block-
computing, data storage, networking, security, AI, IoT, and
chain, Cloud Computing, Big Data). Multiple OEMs have
application SW. The OEMs have also been looking into
confirmed up to 40% cost reduction in SW & IT develop-
the logistics vehicle fleet management and services, self-
ment costs due to the migration to cloud services (Ref
driving intelligent logistics vehicles, after-sales service, and
[21]). Higher productivity has also been reported with CAD
intelligent supply chain through private cloud and services.
and CAE models getting designed, developed, and vali-
dated using HPC hybrid cloud models. The IOV ACS also
enables continuous SW upgrades through OTA services
and back-end cloud platform support. As OEMs continue
to focus on product differentiation to lure more customers
to their brands and vehicles, IOV ACS help create person-
alized applications, new cloud services, and OTA updates
on demand. Enhanced customer experience is also assured
through subscription-based real-time services, OTA
updates, and feature enhancement on demand.

Figure 23. SDVs: Internet of Vehicles – Cloud Services (Ref [20]) References
1. Global Market Insights, “Software-Defined vehicle
The IOV CCS promotes the concept of a Vehicle History
market – by vehicle type, by propulsion type, by level
Record (VHR) that captures vehicle maintenance history,
of autonomy, by offering, by application, forecast 2023-
service records, user care, feature upgrades/changes,
2032,” Report ID: GMI6887, October 2023, https://www.
and operational efficiency trends/changes based on big
gminsights.com/industry-analysis/software-defined-ve-
data. The VHR typically covers multiple vehicle aspects
hicle-market/
including a) service/repair history, b) data collection/
2. Deloitte, “Software-defined vehicles: A forthcoming indus-
governance/analysis, c) fault prognosis/diagnosis, d)
trial evolution,” https://www2.deloitte.com/content/
driving efficiency trends, e) security risks, f) remote diag-
dam/Deloitte/cn/Documents/consumer-business/
nosis, etc. CCS comprises Infrastructure as a Service (IaaS),
deloitte-cn-cb-software-defines-vehicles-en-210225.pdf
Platform as a Service (PaaS), and Software as a Service
3. Watanabe, S. and Itoda, S., “What is an SDV (Software
(SaaS). The IaaS offers public or private cloud services
Defined Vehicle)? Defining SDVs beyond just vehicles,”
with computing, network, and storage facilities. The PaaS
3rd Oct 2024, https://www.pwc.com/jp/en/knowledge/
provides cloud-assisted autonomous driving (AD), simula-
column/definition-of-sdv.html
tion platforms for SW development/testing/deployment,

MOBILITY ENGINEERING MARCH 2025 45

TECHNOLOGY
Report
4. Liu, Z., Zhang, W., and Zhao, F., “Impact, Challenges, 15. Zaffiro, G. and Marone, G., “Smart Mobility: New roles
and Prospect of Software-Defined Vehicles,” Automo- for Telcos in the emergence of electric and autono-
tive Innovation, March 2022, DOI:10.1007/s42154-022- mous vehicles,” https://www.researchgate.net/publica-
00179-z/ tion/334784348
5. SBD Automotive, “The Software-defined vehicle: Enabling 16. Otuteye, T. et. al, “Projection of On-Road Liability Losses
the updatable car,” https://insight.sbdautomotive.com/ for Autonomous Driving,” CAS E-Forum Spring (May)
rs/164-IYW-366/images/Preview%20-%20The%20Soft- 2023, https://eforum.casact.org/article/74845-projec-
ware-defined%20Vehicle%20report.pdf tion-of-on-road-liability-losses-for-autonomous-driving
6. Yu, D. and Xiao, X., “The Digital Foundation Platform – A 17. Hersch, K., Colaco, J., and Canaan, M., “2025 global insur-
Multi-layered SOA Architecture for Intelligent Connected ance outlook: Evolving industry operating models to build
Vehicle Operating System,” https://www.sae.org/publi- the future of insurance,” Deloitte Insights, 29 Sep 2024,
cations/technical-papers/content/2022-01-0107/ https://www2.deloitte.com/us/en/insights/industry/
7. Teixeira, P.V., et. al, “Software Defined Vehicles for Devel- financial-services/financial-services-industry-outlooks/
opment of Deterministic Services,” 24 July 2024, http:// insurance-industry-outlook.html
dx.doi.org/10.48550/arXiv.2407.17287 18. Catlin, T. et. al, “Navigating unknowns: Auto insurance
8. Rumez, M. et. al, “An overview of Automotive Service-Ori- questions in a new mobility era,” April 2024, https://
ented Service Architectures and implications for security www.mckinsey.com/~/media/mckinsey/industries/
countermeasures,” DOI: 10.1109/ACCESS.2020.3043070 auto motive%20and%20assembly/our%20insights/
9. Tischer, M., “AUTOSAR Adaptive — The computing navigating%20unknowns%20auto%20insurance%20
centre in the vehicle,” Electronik Automotive, Special questions%20in%20a%20new%20mobility%20era/
Issue “Bordnetz”, Sep 2018, https://cdn.vector.com/ navigating-unknowns-auto-insurance-ques-
cms/content/know-how/_technical-articles/AUTOSAR/ tions-in-a-new-mobility-era.pdf
AUTOSAR_Adaptive_ElektronikAutomotive_201809_ 19. Chen, J., et. al, “Software defined Internet of Vehicles:
PressArticle_EN.pdf architecture, challenges, and solutions,” Journal of
10. Traub, M., Maier, A., and Barbehön, K.L., “Future Auto- Communications and Information Networks, Vol. 1, No. 1,
motive Architecture and the Impact of IT Trends,” Soft- June 2016, JCIN, DOI:10.11959/j.issn.2096-1081.2016.002
ware Technology, IEEE Software, vol. 34, no. 3, pp. 27-32, 20. Continental Automotive, “From the road to the cloud –
May-Jun 2017, DOI:10.1109/MS.2017.69/ from virtual to real: Know-how and solutions for Future
11. Microsoft Learn, “Software-defined vehicle DevOps Mobility,” https://www.continental-automotive.com/en/
toolchain,” https://learn.microsoft.com/en-us/azure/ focus-topics/software-defined-vehicle.html, accessed on
architecture/industries/automotive/software-de- 15th December 2024.
fined-vehicle-reference-architecture 21. Research in China, “Automotive Cloud Service Platform
12. Jujjavarapu, P.R., “Containerized Design of Services Industry Report, 2021-2022,” March 2022, http://www.
in Software defined Vehicles for Vehicle and in Cloud researchinchina.com/Htmls/Report/2022/71754.html
[Part-1],” https://medium.com/@jujjavarapurpratap/
containerized-design-of-services-in-software-define-ve-
hicles-for-vehicle-and-in-cloud-part-1-566c49b13ff1 About the Author
13. Ghammam, A., Khalsi, R., Kessentini, M., and Hassan, Dr. Arunkumar M. Sampath works
F., “Efficient management of containers for Software as a Principal Consultant in Tata
Defined Vehicles,” ACM Transactions on Software Engi- Consultancy Services (TCS) in
neering and Methodology, vol. 33, Issue 8, Article No. 197, Chennai. His interests include
pp. 1-36, http://dx.doi.org/10.1145/3672461 Hybrid and Electric Vehicles,
14. Rawal, D., “How do we secure vehicles that are now tech Connected and Autonomous
products,” T Systems Insights, March 19, 2024, https:// Vehicles, 5G/6G, Cybersecurity,
www.t-systems.com/in/en/insights/newsroom/expert- Functional Safety, Advanced Air Mobility (AAM), AI,
blogs/automotive-security-for-software-defined-vehi- ML, Data Analytics, and e-Fuels.
cles-973836

46 MARCH 2025 MOBILITY ENGINEERING