Mobility in the Future Will Be Transformed by Software Defined Vehicles

Author: Dr. Arunkumar M. Sampath, Principal Consultant, Tata Consultancy Services (TCS), Chennai

I. Overview
Consumers of contemporary cars have a growing expectation that their cars will include intelligent features powered by software that can be improved via Over-the-Air (OTA) upgrades. An approximate 400Millions of automobiles globally are classified as “connected cars,” which are able to share data with other connected cars or other Internet of Things (IoT) devices via the internet and monitor features and events both inside and outside the vehicle in real time. Automobile Original Equipment Manufacturers (OEMs) continue to provide more superior features, services, safety features, and semi-autonomous driving capabilities in their modern automobile designs. SDVs, or software-defined vehicles, are changing from being a mode of transportation to “smartphones on wheels” as the likelihood of future vehicle architectures being mostly defined by software (SW) increases.

With smartphone businesses shifting the industry from hardware upgrades to software, the automotive sector has been closely monitoring the advancements in smartphones that have been pushing the boundaries of feature augmentation and quicker turnaround times for new devices and products. improvements. Although industry analysts are quick to highlight the distinctions between smartphones and the automotive sector, the idea of software-defined vehicles (SDVs) has swiftly surfaced in an attempt to capitalize on the growing standardization of hardware and differentiation through software development. Decoupling network services from proprietary hardware components and allowing automakers to use independent software are two of SDVs’ key success factors (KSFs) subsidiaries to market the software development that pushes the limits of the E/E components and vehicle life cycle.
It is anticipated that the SDVs will drastically cut down on software update turnaround times, improve in-vehicle user experience, and use software updates to change or improve the performance and features of certain zones within a vehicle with minimal to no effect on other zones or the vehicle as a whole, lowering development costs and offering a great deal of flexibility. The growth estimates of SDVs over a ten-year period are displayed in Figure 1 (Ref [1]), with passenger vehicles still making up more than 80% of the total, while the share of commercial vehicles is rapidly rising. Automotive OEMs are increasingly updating their software over the air (OTA) in SDVs and prolong the life of electrical and electronic (E/E) components by adding improved functionality and safety measures with few or no changes to the hardware or components.

Through over-the-air (OTA) software updates, software-defined vehicles (SDVs) are continuously improving their features and safety features, giving users more freedom in utilizing their current hardware and components, and enabling personalized Modifiable software and the current E/E architecture allow for end-user customization. Figure 2 (Ref [1]) displays the market share of software-defined vehicles by application. Advanced Driver Assistance Systems (ADAS) have the largest share, followed by Autonomous Driving, Infotainment Systems, and Powertrain Control. ADAS improves vehicle safety and lowers the frequency of accidents by combining several technologies, including adaptive cruise control (ACC), automated emergency braking (AEB), lane keep assist (LKA), and lane departure warning (LDW). Several OEMs have been in the forefront of developing Level 3+ Autonomous Vehicle (AV) technology With the second-largest application share in Figure 2, autonomous vehicle (AV) capabilities is followed by in-vehicle infotainment (IVI) systems, which provide users with entertainment and services based on subscriptions.

II. Vehicles Defined by Software
Smartphone technologies have been viewed by the automobile industry as a way to separate hardware (HW) from software (SW), create operating systems (OS) at the vehicle level, and perform more virtualization and containerization, accelerate SW development and validation, provide connected cloud services (CCS) with hybrid in-vehicle and cloud computing in (near) real-time, and send OTA SW updates as needed or on demand. The trends in software and car sales revenue, as displayed in Figure 3 (Ref [2]), have further increased the requirement for SDVs. The SW sales revenue rose from 3% in 2019 to 14% in 2025, as can be seen. A new SW-based feature upgrade and charging model has been spearheaded by Tesla, Inc. with a) one-time charge model with a) a one-time pre-installation fee and b) a year-end subscription service fee. It has been noticed that the Over-the-Air (OTA) upgrade optional package charges for each update and that powertrain, in-vehicle infotainment (IVI), autopilot, ADAS, and chassis systems are often offered online upgrades. Advanced Internet of Vehicles (IOV) connectivity services, such as real-time traffic, video/music streaming (recording, uploading, and downloading), and karaoke, are also offered on a monthly subscription basis.

Figure 4a) (Ref [3]) illustrates the many stages of vehicle evolution, starting with mechanically controlled cars (Level 0) and progressing to software-defined ecosystems (Level 5). Figure 4b illustrates the progression of various Software-Defined Vehicle (SDV) levels as well as the E/E architecture. (Source:[4]). Figure 4c) displays the progression of various traits as well as the tabular details of various levels (Ref [3], [4]). Connectivity, IT infrastructure, SW development, SW structure, cybersecurity, and semiconductors are some of the characteristics. As connectivity has developed, most functions and control systems are updated through frequent OTA SW updates (full dynamic SW management), whereas some functions or control systems are upgraded through regular OTA SW updates (semi-dynamic SW management) in Level 1.0. OTA SW updates are used to update most functions and control systems from Level 1.0 (semi-dynamic SW management) to Level 2.0 (full dynamic SW management) and continuous seamless communication between the car and outside parties, allowing for OTA SW upgrades in Level 3.0, AI-based learning and algorithm enhancement, and real-time data analysis. Level 1.0 saw the evolution of the SW structure from AUTOSAR-compliant SW with limited vehicle OS and API standardization to Level 3.0, which saw the abstraction and virtualization of both in-vehicle and V2X communications. Large-scale microcontroller units (MCUs) and Systems on Chip (SOCs) for HPC in Level 1.0 have given way to high-performance/large-scale SOCs for HPC in Level 2.0, which will then move into neuro-enabled semiconductors for applications beyond mobility in Level 3.0

III. SDV: The OEM-Supplier Ecosystem’s Evolution

Figure 5 (Ref [5]) illustrates the evolution of the automobile OEM-supplier ecosystem. A collaborative OEM-Tier 0.5 paradigm, in which the OEMs take a greater lead in specifying requirements, has replaced the traditional OEM-Tier 1 supplier strategy for designing and creating high-tech components.

creating the SW and E/E structures, building the control algorithms, and using suppliers more as strategic partners to create systems and components that are very unique. As a result, four distinct Automotive SW business models have evolved, as seen in Figure 5 (Ref [5]), with more information provided below:

1. Non-recurring engineering services and SW custom development
   a. Intelligent SW solutions for the cockpit
   b. SW packages and the ADAS/Autonomous Driving (AD) algorithm Solutions for Intelligent Driving (ID)
2. Technical engineering and consulting services (CTES)
   Early design and development a. Technical drawing releases for prototype builds b. Software or component testing and debugging c. Validation at the system and vehicle levels
3. SW Application Development and Intellectual Property (IP) Licensing
   a. Development and delivery of SW modules in accordance with AUTOSAR standards b. SW tool chains based on Agile, Scrum, or DevOps c. Tools for designing specific components or systems d. Tools for simulation and testing
4. Products and Solutions for Integrated Hardware (HW) and Software (SW)
   Domain controllers, cloud-based products and services for vehicles, and integrated document management system (DMS) solutions are some examples.

With OEMs increasingly creating their own operating systems (OS), utilizing public and private clouds for data management, analytics, and decision-making, and, when necessary, contacting automotive SW vendors directly rather than through the conventional Tier 1 suppliers, the aforementioned business models have significantly disrupted the automotive sector.

IV. SDV – Evolution of E/E Architecture

Figure 6 (Ref [6]) illustrates the history of the E/E architecture, which went from a modular architecture in which each function has its own Electronic Control Unit (ECU) and occasionally runs on different operating systems (OSs) to a vehicle + cloud computing architecture in which the Cloud-based embedded functions are moved. Domain-based controllers are produced by combining (ECUs) in the Integration version of the E/E architecture. This develops into a centralization architecture, in which a fundamental controller is standardized to generate domain centralized units. With the elimination of domains and the fusing of Domain Controller Units (DCUs), which are necessary for the proper operation of ADAS functions, the architecture changed to a fusing architecture. The E/E architecture’s next development or vision calls for zonal ECUs with centralized vehicle computers computer. With hybrid HPC + cloud-enabled real-time computing, the emerging vision calls for moving embedded functionalities into the cloud and improving Autonomous Driving (AD) algorithms to react to traffic, weather, and road conditions.

Figure 7 (Ref [2]) shows a schematic representation of the time-based evolution of E/E architecture in SDVs. It is divided into four time zones: a) before 2020, b) 2020 to 2025, c) 2025 to 2030, and d) after 2030. Below are the specifics of various architectures:

1. Prior to 2020, ECUs operated independently in a dispersed environment largely through CAN and LIN-based communication interfaces (dispersed Architecture). An integrated gateway is used by the Body Control Module (BCM) to communicate with certain sensors and ECUs to put the algorithms into practice. The challenges are as follows: a) suboptimal computing power resulting in redundancy; b) complex wiring harness due to intricate in-vehicle communication requirements; and c) lack of flexibility for upgrade and scale up. This is because the ECUs operate independently and occasionally on different operating systems (OSs).
2. Within the centralized cross-domain architecture span of 2020–2025 Based on the distinct roles of several electronic components, including the body, powertrain, chassis, autopilot, and in-vehicle infotainment (IVI), many primary domains have been established here. There has been progress in CAN+ and Ethernet connection interfaces that make OTA upgrades for domain ECUs simple. Because of its complex cross-domain functionality, this design has two disadvantages: a) higher cybersecurity requirements; and b) more processing power.
3. With designated zones and zonal ECUs managing the left front, left-right, left rear, and right rear zones of the vehicle and serving as a gateway to transfer information, the 2025–2030 period (centralized vehicle E/E architecture) allows for a centralized computing platform and decision-making electricity and data to various parts and systems. Compared to the previous cross-domain architecture, the vehicle-zonal architecture significantly improves through a simplified wiring harness design, which results in a) weight reduction, b) cost benefit, c) decreased complexity, and d) an easier possibility of SW upgrade.
4. The goal is to develop a central computing platform that can perform hybrid vehicle-cloud computing, interface with power, actuators, and sensors, and optimize performance and power by combining in-vehicle real-time data processing with additional cloud computing for after 2030 (the vehicle-cloud computing architecture improved decision-making skills, which are essential for achieving greater degrees of autonomous driving (AD).

Figure 8 (Ref [7]) illustrates the futuristic zonal design with Vehicle-to-everything (V2X) connectivity, which was made possible by the transformation of the legacy dispersed E/E architecture into the zonal architecture, which started the SDV paradigm. Since many automakers are becoming proficient in L3+

1) Full stack development, 2) Operating system (OS) development, 3) Core algorithm development, 4) Edge + Cloud computing, 5) Backward integration with System on Chip (SOC) manufacturers (AI-enabled chips), 6) Sustainable and Iterative product experience offering full life cycle services, and 7) Revenues from one-time fees, regular OTA upgrades, and subscription fees for specific feature enablement or upgrades are some of the trends in SW development for Autonomous Driving (AD).

Figure 9a) displays the specifics of the AUTOSAR Classic Platform (CP) and Adaptive Platform (AP) with regard to 1) operating system, 2) code execution, 3) application address space separation, 4) scheduling, 5) compilation, 6) configuration, and 7) supported protocols (Ref [6], [8]–[9]). The Traditional Platform (CP) is utilized for the most demanding real-time applications and is built on the OSEK operating system. The platform has fixed scheduling and code that is run from ROM, but there is no application address space separation. The AUTOSAR CP demands that all of the ECUs be compiled together and anticipates a combined system configuration. The platform only facilitates a translation from signal-oriented CAN communication to the static mapping of signals to a particular service.

The AUTOSAR Adaptive Platform (AP) can be utilized for Service Oriented Architecture (SOA), is much more dynamic, and is appropriate for higher processing power (Ref [8]–[9]). The platform is based on a portion of the POSIX OS interface, which is a standard interface for SW and all programs elements. Code loaded onto ROM with dynamic scheduling (changing the number of processes and preemptive multitasking) and application address space separation powers the platform put into action. Applications that are installed and scheduled dynamically can be handled by the system configuration, which is dynamically loaded from a file at runtime.
Figure 9b) (Ref [6], [8]–[9]) illustrates how the SDVs use a hybrid AUTOSAR CP and AP E/E architecture. Because calculations may be performed using functions with low data rates, the AUTOSAR CP supports body functions, ADAS & safety, powertrain/chassis, and in-vehicle infotainment (IVI) via may/LIN and Ethernet communication interfaces. A central computing cluster (CCC), an I/O cluster, and connectivity control (CC) that connects to off-board testers, OTA connection services, and smart charging are all supported by the AUTOSAR AP.

Figure 10 (Ref [6]) illustrates how the software architecture of SDVs changed from its existing configuration to a new platform. OEMs rely heavily on Tier 1 suppliers for hardware, modules, and system-on-chip (SOC) components and services under the present HW/SW arrangement.

Applications that are “tightly coupled” to the SOC components include APIs and software.
There is a huge difficulty for feature commonality, standardization, or update because of the large range and quantity of ECUs in the vehicle, which frequently run on several Operating Systems (OSs) and devices for various end applications. Figure 10 (Ref [6]) illustrates the new HW/SW structure’s multi-layered SW architecture and the addition of abstraction layers that take into account the variations between hardware, operating systems, and middleware and eliminate the variations that result in a notable rise in SW reuse. The fundamental building blocks for developing a common or cross-platform that is not dependent on the device, operating system (OS), or middleware are the abstraction layers variations. Interfacing with various devices is made possible by the HW abstraction layer (HWAL), regardless of the HW. Middleware can be reused across different operating systems thanks to the OS abstraction layer (OSAL). Cross-platform flexibility and a notable boost in SW reusability are made possible by the new SW platform.

A multi-layered classification of ECUs that independently communicate with RTOS and GPOS is the basis of the Multi-layered Service-Oriented Architecture (MSOA). Encapsulation and layering are used in the development of the MSOA to lessen complexity and fragmentation and to make the application of a platform for generic computing. Three layers—a) a basic layer for services like processing sensor data, b) an extended middleware layer for data interchange and fusion, and c) an application layer that uses all the data for applications—will encapsulate the components performing certain vehicle activities.

MSOA guarantees the reuse of SW components and enables developers to produce effective new features (apps) that are simple to connect with a device’s whole ecosystem. MSOA decreases system complexity, facilitates comprehensive SW testing, and makes SW porting across numerous vehicles easier against interfaces because of strict hierarchy and encapsulation, and d) makes use of DevOps and Agile techniques. Moreover, MSOA a) mimics security patterns already present in the consumer electronics and IT sectors, b) makes functional separation, encoding, and firewalls easier, c) permits closer communication between the back-end architecture and the in-vehicle E/E architecture, d) permits more data exchange between the back end and various automotive functions, and e) permits partial back end functional execution. Several developers and scholars have attested to the MSOA’s The MSOA strategy a) makes it possible to integrate new features and personalize each user, b) offers remote updates that support quality improvements, optimization, and flexible lifecycle management, and c) allows for increased data exchange between various back-end and automotive operations, and d) enables the use of high-performance processors with distinct design patterns, like scalability and hierarchy-based architecture, that are common to smartphones and IT.

Figure 12 (Ref [10]) displays the updated SW development lifecycle (SDLC) for SDVs using cutting-edge techniques and technologies. The seamless design and documentation of in-vehicle and back-end architectures are indicated as key success factors (KSFs). Zonal multi-layered architecture is the basis for Software is developed for particular vehicle domains, such as I&C (information and communication), DA&S (driver assistance and safety), P&C (powertrain and chassis), and B&C (body and comfort). Communication technologies like LTE, WiFi, and 5G between the in-vehicle network and backend guarantee connectivity and bandwidth to support zonal SW development Mobility services, high-speed networks, and specialized applications like In-Vehicle Infotainment (IVI), Autonomous Driving (AD), etc. are carried out in the back end. MSOA, hierarchical E/E, and the Central Communication Server (CCS) facilitate future innovation in the SDV SDLC architecture, as well as smooth communication between back-end and in-car architectures. Hi-speed networks allow for closer communication between in-vehicle and back-end architectures, which facilitates a) data processing, b) remote SW updates, c) SW design for functions, and d) code/algorithm execution on an ECU or at the back end. A smooth requirements process from client engagement to the software design, full modeling of E/E architectures based on SOA, and content encapsulation for distributed systems are only a few advantages of the updated SDLC technological breakthrough agile development, collaborative Scrum teams, and shared code repositories; e) enabling DevOps, CI/CD tool implementation, and continuous integration; and d) development utilizing SOA design concepts. The finest practices from the smartphone business are being adopted by automotive SDV developers. It is acknowledged that the development of automotive electronics can a) benefit from advances in IT and consumer electronics, b) surpass traditional software systems in terms of usability, performance, safety, and security, and c) require a number of technological innovations in order to satisfy the demanding requirements of the automobile sector (Ref [10]).

Figure 13 (Ref [5]) depicts a generic architecture of SDV MSOA, which has been developing to offer safe operations during ADAS/AD modes, ongoing OTA updates, and defenses against cyberattacks, among other features. The requirement for the utmost safety guarantee while using ADAS or autonomous driving (AD) modes require Functional Safety (FuSa) and HW and SW redundancy in safety-critical systems and operations. As a result, design adaptations such as multiple sensors, independent power supply, and consensus-driven AI are implemented. Runtime applications supporting edge computing must be developed and deployed rapidly due to the crucial need for dynamic and localized edge computing apps to assist data processing and functional validation efficient in terms of cost, latency, and processing power. The SDV MSOA architecture should provide the maximum level of cybersecurity protection in the form of HW and SW level countermeasures to foil the growing cyberattacks in CAEVs.

Since ongoing OTA updates are a key success factor (KSF) of SDVs that prolong vehicle lifecycles, the MSOA design evolution should take into account the multi-year HW lifespan in addition to integrating vehicle-level, high-speed, low-cost, low-latency networks, like Gigabit Ethernet. High-performance GPUs with AI capabilities must be taken into account in the MSOA design evolution since SDVs must support AD operations that receive and analyze high-bandwidth visual inputs (video and images).

In terms of Distributed Basic ADAS ECUs, Partial Consideration of ADAS features, Consolidated ADAS/AD features, and Vehicle Computing + HPC-based ADAS/AD features, the SW technology stack in SDVs has been developing in tandem with the vehicle-level evolution of E/E architecture. This Specifically, it demands that the SDV architecture be scalable over the long term for ADAS and AD operations by separating HW and SW and making sure that SW, independent of HW, drives the majority of features, functions, user experience, and SW upgrades. HW abstraction, application middleware, containerization, virtualization, and a centralized E/E architecture with HPC units connected via Gigabit Ethernet are the main technological advancements needed to implement the SW stack. Additionally, certain platform-level design modifications are required, such as vehicle-level operations system (such as GPOS and RTOS), particular clusters of ECUs, Type I hypervisor, and middleware that divides the dynamic SW stack (such as apps, shared services, cloud services, and car services).

VI. SDVs – High-Performance Computing

Figure 15 (Ref [5]) shows a schematic of the High Performance Computing (HPC) for abstraction in SDVs. The design includes a separate CPU, Type I hypervisor, non-volatile memory, volatile memory, and General Purpose Operating System (GPOS) and Real-Time Operating System (RTOS) Graphical Processing Unit (GPU) clusters, RTOS and GPOS clusters, various communication protocols, and interfaces for cloud and external connectivity. Applications and containers that run portable SW combined with HW abstraction layers are built on top of GPOS. Deterministic services are offered by RTOS for

safety-critical features like braking and steering, whereas GPOS concentrates on general services and applications for data processing. GPOS or other middleware provides the HW abstraction services.
Multiple CPU clusters can be used to provide simultaneous GPOS + RTOS services using both OSs and RAM that is scalable. The Type I Hypervisor has several functions, including: a) virtualization services; b) use of volatile memory (VM) and non-volatile memory (NVM); and c) simultaneous operation optimization for GPOS and RTOS activities. The HPC environment offers a broad range of physical interfaces for integration with high-bandwidth networks (USB, Ethernet, PCIe) and CAN, LIN, and Flex Ray networks. The GPUs perform multiple jobs, including a) processing data from ADAS/AV sensors and applications, b) powering the IVI digital cockpit interface processing, and c) executing the AV and IVI data processing and applications. For low battery applications, the discrete and independent CPU clusters for GPOS and RTOS a) isolate the management of predictable and time-sensitive networks (TSN) and b) allow for “redundancy” of operations and “Functional Safety” (FuSa).

VII. SDV – Virtualization, Containers, and DevOps

Figure 16 (Ref [11]) provides a schematic of virtualization and DevOps in SDV development.
The SDV toolchain facilitates a) development tools, b) development, validation, and integration, and c) execution environment by leveraging the cloud computing environment offered by the Hypervisor suppliers (Microsoft Azure, Amazon AWS, Google GCP, etc.). Additionally, the virtualization offers chances for comprehensive development of the Automotive SW stack, code uploading and downloads via the GitHub marketplace, integrated hardware-in-loop (HIL) testing, data and analytics, vehicle messaging, and autonomous vehicle operations (AVOps).

Virtualization and DevOps in SDVs could lead to a number of use cases, such as: a) quicker familiarization and onboarding of SW developers; b) efficient deployment and use of virtual environments to replicate various HW and SW combinations; and SIL. HIL validation, which involves deploying and monitoring multiple HIL tests; e) test fleet validation, which includes root cause analysis (RCA) and vehicle behavior analysis from SW updates based on logs and traces of SW applications; f) faster and traceable SW releases for vehicle fleet tracking and SW updates using DevOps best practices; and g) Continuous Integration/Continuous Deployment (CI/CD) by incorporating feedback from field trials, performing RCA, and performing SW updates to fix issues and/or boost efficiency.

A large number of SW-based simulations are used in the SDV development process, which opens up new possibilities for Tier 1, Tier 2 suppliers, and automotive SW providers, including a) virtual ECU development, b) the development of High-Performance Compute (HPC) capabilities, and c) containerized applications, all of which make it possible for SW development to proceed concurrently in order to get over the difficulties caused by HW availability or revisions. The developers provide Application Programming Interfaces (APIs) in accordance with the Connected Vehicle System Alliance Vehicle Signal Specification (COVESA-VSS), which standardizes access to vehicle data for receiving inputs from various components and vehicle sensors. Standardization made possible by COVESA-VSS compliance promotes interoperability and the creation of SW and APIs that are independent of hardware.

Figures 17 a) (Ref [12]) and 17 b) (Ref [13]) provide the schematics for Container Design, Scheduling, and Optimization, a crucial component of SDV SW development. The Docker Cluster’s containers are connected to several ECUs (engine, maps, brakes, etc.), as the graphic shows ITS, ADAS, etc.). Various in-vehicle applications, such as driver assistance (ADAS), intelligent path planning (ITS), camera and sensor monitoring, media capabilities, intelligent speed control, traffic signal detection, and engine and brake management, are made possible by the Component Docker Cluster.

OEMs developing SDVs are implementing a mixed-critical orchestrator that manages both mission-critical and non-critical apps inside the vehicle in accordance with SOAFEE (Scalable Open Architecture for Embedded Edge) requirements (Ref [13]). As A non-critical IVI application or a climate control application operating concurrently with safety-critical braking or steering system apps is an example of a SOAFEE-compliant architecture. The scheduling module reschedules the containers to satisfy the changing vehicle requirements by keeping an eye on the container metrics, the vehicle’s current real-time requirements, and the state of various containers connected to various ECUs. The Monitoring module includes the Prometheus Query Language (PromQL) to query the state of real-time distribution, Grafana for cloud observability, and Prometheus for container metrics monitoring and alerting. of containers on each node and clustered activated nodes. The Monitoring module’s Cadvisor gives details on the operating containers’ default allocation among the vehicle’s ECUs, as well as their performance and resource consumption (Ref [13]).

Vehicle status metrics, including memory, CPU, power (energy) consumption per node, and the number of ECUs per cluster, are gathered with the assistance of the nodeExporter in the Monitoring module (Figure 17b) in Ref [13]. Time series data on the condition of ECUs is gathered and stored using the Prometheus toolset containers and gives the Scheduling component this input. Real-time information on vehicle and container status, as well as preferences and limitations, are fed into the scheduler as input and are regularly checked. Alerts and suggestions for scheduling alternatives and allocating the containers among the ECUs are shown on the dashboard. The scheduler is essential in a number of situations, including when a user wants to maximize particular goals or add impose further restrictions, mandate that vehicle applications be reallocated in accordance with the updated input, and b) resource overloading that results in one of the ECUs being deactivated because of a security flaw, insufficient battery capacity, an OTA upgrade, or the start of the power-saving mode.

VIII. SDV – Cybersecurity

Cybersecurity is becoming a crucial requirement to provide safe and secure solutions as more OEMs create technologies and SW solutions to realize SDV 3.0 with hybrid in-vehicle and cloud computing to analyze real-time data, progress L3+ Autonomous Driving, and optimize performance user experience and driving. Figure 18 shows several cybersecurity concerns and channels in SDVs (Ref [14]). In 2021, two new regulations (R155 and R156) requiring minimum cybersecurity criteria for automobiles for type certification were announced by the World Forum for Harmonization of Vehicle Regulations (WP.29), a special regulatory working body inside the United Nations Economic Commission for Europe (UNECE). In addition to the rules in WP.29, ISO/SAE 21434 was jointly “Road Vehicles – Cybersecurity Engineering,” created by the Society of Automotive Engineers (SAE) and the International Organization for Standardization (ISO), was published in August 2021. Researchers in cybersecurity are constantly creating defenses against the growing complexity ofand advanced cyberattacks by a) creating zero trust architectures in which nothing can be trusted, b) thoroughly verifying each component to guarantee reliability, c) implementing least privileged system-level interaction, d) making Software Bill of Materials (SBOMs) more transparent, and e) insisting on software/component certification in order to obtain R155 type approval.

IX. SDV – Impact on Insurance

As seen in Figure 19 (Ref [15]), it is predicted that by 2030, nearly all contemporary cars will be networked, and over 70% of them will have ADAS and Level 3+ autonomous characteristics. This directly affects how complicated SW is in contemporary cars, where more than 300 million lines of code are needed to operate these cars with cutting-edge safety and performance features, leading to varying degrees of SDV functionality, as seen in Figures 4a) and 4b) (Ref [3], [4]).

As seen in Figure 19 (Ref [15]), the percentage of electric vehicles (EVs) will surpass 50% by 2030, posing new difficulties for auto insurers in the areas of risk assessment, insurance underwriting, actuarial modeling, and premium computation computation. Connected, Autonomous, Electric Vehicles (CAEVs) may require specialized service stations due to their higher technological sophistication, which includes more software and frequent OTA updates skilled specialists, and suffer greater repair expenses. highly skilled personnel, and more expensive repair charges due to their technological complexity. The insurers are supposed to assess the risks related to advanced software dependency, special maintenance requirements, such as parts with sensors for ADAS features, the choice between battery replacement and repair based on remaining useful life (RUL), and driver (human) versus OEM (machine) liability product) for Autonomous Vehicles (AV) with Level 3+ capability. Software dependability, cybersecurity and data privacy, functional safety and system redundancy in the event of breakdowns, and driver behavior changes brought on by Level 3+ AV capabilities are additional hazards as the technology. Even though SDVs are always changing, insurers still struggle to quantify hardware specs and OTA SW upgrades in terms of insurance risk and assess risk when there is little to no past vehicle history. The traditional auto insurance sector is being forced to adapt to the constant advancements in technology, local regulations, and the possibility of shifting liability from personal liability to product liability provided by OEMs or system suppliers for Level 3+ AV capabilities undergo “disruption” and implement fresh underwriting techniques. By making investments in new alliances and competence creation, as well as by aggressively pushing commercial vehicle premiums, the insurers must upend the established insurance structures.

To comprehend the effects of SDV development, expanded Connected Cloud Services, and OTA updates on the insurance business, numerous research have been conducted (Ref [16] – [18]). Direct premium trends for the US personal auto insurance industry are captured in the McKinsey research in Ref [18], as as seen in Figure 20. With insurance premiums for traditional auto personal lines peaking at roughly $263 billion by 2026 and falling to roughly $248 billion by 2030, as well as with disrupted personal lines coverage rising from roughly $50 billion in 2026 to roughly $100 billion by 2030, the trends show that the automotive insurance market is being disrupted. There are several reasons for the disruption, such as

a) Nearly all cars are connected,

b) EVs make up more than 50% of the total,

c) and ADAS features and Level 3+ AV capabilities are adopted at a rate of roughly 70%. With the growing use of telematics-based dynamic insurance pricing

Generative Artificial Intelligence (Gen AI)-based claims processing, and interrupted personal lines coverage of around $100 billion will be spent on the next generation of CAEVs, where consumers will solely communicate with insurers for dynamic OTA SW upgrades rather than OEMs. By detecting the risks and implementing modifications to the insurance premium calculations, insurance companies who are at the forefront of technology adoption and possess a thorough understanding of safety enhancement and tailored customer experience will have an impact on future actuarial models. As these innovators cohabit alongside cars with cutting-edge electronics, they will also underwrite insurance for cars with less sophisticated technology.

Figure 21 (Ref [18]) illustrates how auto insurance models have changed as SDVs have emerged. Due to their creation of full-stack insurance carriers, which include reinsurance and third-party administrator-handled claims, OEMs hold the highest share in insurance model 1.

As they form partnerships with insurers who underwrite insurance along both personal and business lines, the OEM investment in Model 2 is lower than in Model 1. OEMs present themselves as aggregators or create platforms and interface with insurers for individual policies under Model 3, where they monetize the insurance leads. Compared to Models 1 or 2, Model 3 has the largest proportion of carriers managing commercial insurance, with no direct link between the driver and and the OEM, unlike in Models 1 and 2.

Conclusions
The progression of various SDV levels, trends in car sales revenue, and SW releases via OTA updates are all discussed, along with the necessity for SDV development. The latest advancements and the E/E architecture’s development are described in depth, with the advent of zonal architecture in The hybrid in-car and cloud computing for L3+ AD experience is being driven by SDVs. The development of SW architecture is explained, as is the significance of the Digital Foundation Platform’s use of the multi-layered SOA. To further disentangle SW deployment and development from the HW and SDV development is implementing virtualization, container design and optimization, and DevOps and SW toolchains for Continuous Integration and Continuous Development (CI/CD) in order to shorten the time-to-market for SW releases. In order to process real-time data and provide L3+ Autonomous Driving, more OEMs are implementing hybrid in-vehicle and cloud computing One of the most important requirements for providing a safe and secure driving and user experience is cybersecurity. The various ways that cyberattacks can occur and how they might affect the vehicles’ performance are noted.

The goal of ongoing research on cybersecurity countermeasures is to create zero trust architectures, least privileged system-level interactions, and more transparent SBOMs. Vehicle insurers face new difficulties in risk assessment, insurance underwriting, actuarial modeling, and premium calculation as a result of increased electrification, a greater number of OTA SW updates, and features that impact performance and drivability. The presentation covers the effects of SDV development on auto insurance, market disruption, trends in personal auto insurance prices, and the rise of new insurance business models.

Future Work

Software-defined Internet of Vehicles (SD-IOV) is one of several cutting-edge SDV technologies that researchers have been working on. Figure 22 (Ref [19]) depicts a generic software-defined IOV (SD-IOV) architecture. Software Defined Networking (SDN) and IOV are integrated to create the SD-IOV and operates under the idea that the control plane and data plane should be kept separate. Logical (SDN) controllers, SDN switch networks, SDN-enabled wireless access infrastructure, and SDN-enabled automobiles make up the general SD-IOV architecture. Various wireless control path implementation techniques are still being researched, depending on their complexity and performance (Ref [19]).

With an architecture depicted in Figure 23 (Ref [20]), the automakers have been working more and more to create a Road-to-Cloud ecosystem and provide cloud services based on SD-IOV.
The upgrades and development are divided into two categories: vehicle-related tasks (system integration) and in-vehicle duties cross-domain integration (to-cloud) activities. Building a Digital Twin in a safe and secure setting is made possible by the Connected Cloud Services (CCS), which provide a framework for cloud-based creation and collaboration.

OEMs have been experimenting with private cloud designs and services with an emphasis on big data and advanced data due to worries about data security and privacy as well as a clear business plan to monetize the massive amounts of data created by Connected, Autonomous, Electric Vehicles (CAEVs).

AI and analytics. In addition to creating their own automotive operating systems (OS), many OEMs that have been at the forefront of SDV development are investigating the entire software development lifecycle (SDLC), from design to post-purchase service and maintenance, using private cloud architecture and services. OEMs may concentrate on elastic computing, data storage, networking, security, artificial intelligence, the Internet of Things, and application SW thanks to private cloud architectures and services, while many customers request feature upgrades and OTA updates on demand SW. Additionally, the OEMs have been investigating intelligent supply chain management and services via private cloud, self-driving intelligent logistics vehicles, after-sales support, and logistics vehicle fleet management and services.

The idea of a Vehicle History Record (VHR), which stores vehicle maintenance history, service records, user care, feature upgrades and modifications, and operational efficiency trends and changes based on big data, is promoted by the IOV CCS. Numerous vehicle elements are usually covered by the VHR, such as a) service and repair history, b) data gathering, governance, and analysis, and c) fault d) driving efficiency trends, e) security issues, f) remote diagnostics, prognosis/diagnosis, etc. Software as a Service (SaaS), Platform as a Service (PaaS), and Infrastructure as a Service (IaaS) make up CCS. IaaS provides network, storage, and computing services in both public and private cloud environments. The PaaS offers cloud-assisted autonomous driving (AD), picture rendering, data annotation, simulation platforms for SW development, testing, and deployment, and more. Vehicle management, production/sales data, after-sales data, service management, and more are all included in the SaaS.

Personalization, Predictive Maintenance, Charging Solutions, Safety & Security, Transportation Management, and Fleet Management are just a few of the use cases that the IOV CCS provides.
Among the in-vehicle infotainment (IVI) cloud services are entertainment applications that can Combine Instagram, Facebook, and TikTok to give users access to a variety of user experiences, including the ability to: a) record and share videos, b) listen to audiobooks, c) browse newsfeeds, d) take and share images, e) use AI-enabled text-to-speech to hear text read aloud, etc.

R&D, production, selling, maintenance, and post-sale services for SDVs based on 5ABCD (5G, Artificial Intelligence, Blockchain, Cloud Computing, Big Data) are all included in the IOV Automotive Cloud Services (ACS). Up to 40% of SW and IT development expenses have been validated by some OEMs as a result of cloud service migration (Ref [21]). Using HPC hybrid cloud models to design, build, and evaluate CAD and CAE models has also been shown to increase productivity. Additionally, the IOV ACS facilitates ongoing SW upgrades by supporting back-end cloud platforms and OTA services. IOV ACS supports the development of customized apps, new cloud services, and OTA updates on demand as OEMs continue to concentrate on product differentiation to draw more consumers to their brands and automobiles.

Reference

1. Global Market Insights, “Software-Defined vehicle market – by vehicle type, by propulsion type, by
   level of autonomy, by offering, by application, forecast 2023-2032,” Report ID: GMI6887, October
   2023, https://www.gminsights.com/industry-analysis/software-defined-vehicle-market/
2. Deloitte, “Software-defined vehicles: A forthcoming industrial evolution,”
   https://www2.deloitte.com/content/dam/Deloitte/cn/Documents/consumer-business/deloitte-cn-
   cb-software-defines-vehicles-en-210225.pdf
3. Watanabe, S. and Itoda, S., “What is an SDV (Software Defined Vehicle)? Defining SDVs beyond
   just vehicles,” 3 rd Oct 2024, https://www.pwc.com/jp/en/knowledge/column/definition-of-sdv.html
4. Liu, Z., Zhang, W., and Zhao, F., “Impact, Challenges, and Prospect of Software-Defined Vehicles,”
   Automotive Innovation, March 2022, DOI:10.1007/s42154-022-00179-z/
5. SBD Automotive, “The Software-defined vehicle: Enabling the updatable car,”
   https://insight.sbdautomotive.com/rs/164-IYW-366/images/Preview%20-%20The%20Software-
   defined%20Vehicle%20report.pdf
6. Yu, D. and Xiao, X., “The Digital Foundation Platform – A Multi-layered SOA Architecture for
   Intelligent Connected Vehicle Operating System,” https://www.sae.org/publications/technical-
   papers/content/2022-01-0107/
7. Teixeira, P.V., et. al, “Software Defined Vehicles for Development of Deterministic Services,” 24
   July 2024, http://dx.doi.org/10.48550/arXiv.2407.17287
8. Rumez, M. et. al, “An overview of Automotive Service-Oriented Service Architectures and
   implications for security countermeasures,” DOI: 10.1109/ACCESS.2020.3043070
9. Tischer, M., “AUTOSAR Adaptive — The computing centre in the vehicle,” Electronik Automotive,
   Special Issue “Bordnetz”, Sep 2018, https://cdn.vector.com/cms/content/know-how/_technical-
   articles/AUTOSAR/AUTOSAR_Adaptive_ElektronikAutomotive_201809_PressArticle_EN.pdf
10. Traub, M., Maier, A., and Barbehön, K.L., “Future Automotive Architecture and the Impact of IT
    Trends,” Software Technology, IEEE Software, vol. 34, no. 3, pp. 27-32, May-Jun 2017,
    DOI:10.1109/MS.2017.69/
11. Microsoft Learn, “Software-defined vehicle DevOps toolchain,” https://learn.microsoft.com/en-
    us/azure/architecture/industries/automotive/software-defined-vehicle-reference-architecture
12. Jujjavarapu, P.R., “Containerized Design of Services in Software defined Vehicles for Vehicle and
    in Cloud [Part-1],” https://medium.com/@jujjavarapurpratap/containerized-design-of-services-in-
    software-define-vehicles-for-vehicle-and-in-cloud-part-1-566c49b13ff1
13. Ghammam, A., Khalsi, R., Kessentini, M., and Hassan, F., “Efficient management of containers for
    Software Defined Vehicles,” ACM Transactions on Software Engineering and Methodology, vol. 33,
    Issue 8, Article No. 197, pp. 1-36, http://dx.doi.org/10.1145/3672461
14. Rawal, D., “How do we secure vehicles that are now tech products,” T Systems Insights, March
    19, 2024, https://www.t-systems.com/in/en/insights/newsroom/expert-blogs/automotive-security-
    for-software-defined-vehicles-973836
15. Zaffiro, G. and Marone, G., “Smart Mobility: New roles for Telcos in the emergence of electric
    and autonomous vehicles,” https://www.researchgate.net/publication/334784348
16. Otuteye, T. et. al, “Projection of On-Road Liability Losses for Autonomous Driving,” CAS E-Forum
    Spring (May) 2023, https://eforum.casact.org/article/74845-projection-of-on-road-liability-losses-
    for-autonomous-driving
17. Hersch, K., Colaco, J., and Canaan, M., “2025 global insurance outlook: Evolving industry
    operating models to build the future of insurance,” Deloitte Insights, 29 Sep 2024,
    https://www2.deloitte.com/us/en/insights/industry/financial-services/financial-services-industry-
    outlooks/insurance-industry-outlook.html
18. Catlin, T. et. al, “Navigating unknowns: Auto insurance questions in a new mobility era,” April
    2024, https://www.mckinsey.com/~/media/mckinsey/industries/auto
19. Continental Automotive, “From the road to the cloud – from virtual to real: Know-how and
    solutions for Future Mobility,” https://www.continental-automotive.com/en/focus-topics/software-
    defined-vehicle.html, accessed on 15 th December 2024.
20. Research in China, “Automotive Cloud Service Platform Industry Report, 2021-2022,” March
    2022, http://www.researchinchina.com/Htmls/Report/2022/71754.html

About Author:

Dr. Arunkumar M. Sampath works as a Principal Consultant in Tata Consultancy Services (TCS) in Chennai. His interests include Hybrid and Electric Vehicles, Connected and Autonomous Vehicles, 5G/6G, Cybersecurity, Functional Safety, Advanced Air Mobility (AAM), AI, ML, Data Analytics, and Data Monetization Strategies