Author: Dr. Arunkumar M. Sampath, Principal Consultant, Tata Consultancy Services (TCS), Chennai
I. Introduction
Customers of modern automobiles increasingly expect their vehicles to offer intelligent features driven by software that could be enhanced through Over-the-Air (OTA) updates. An estimated 400 million vehicles worldwide fall into the category of “Connected Cars” which have the capabilities of real-time monitoring of features and events internal and external to the vehicle and sharing information with other connected cars or other Internet of Things (IoT) through the internet. Modern vehicles designed and developed by automotive Original Equipment Manufacturers (OEMs) continue to offer more high-quality features, services, safety measures, and semi-autonomous driving capabilities. With an increased possibility of future vehicle architectures being predominantly defined by Software (SW), the Software-defined Vehicles (SDVs) are evolving from a means of transportation to “Smartphones on Wheels” and further onto “Adaptability on Wheels”.
The automotive industry has been closely following the developments in smartphones that have been pushing the limits on feature enhancement and faster turnaround of new devices and offerings with the smartphone companies transforming the industry from hardware upgrades to software enhancements. Though industry pundits are quick to point out the differences between the automotive industry and smartphones, the concept of software-defined vehicles (SDVs) has quickly emerged to leverage the increasingly standardized hardware and differentiation through software development. The key success factors (KSFs) of SDVs include a) decoupling of network functions from proprietary hardware components and b) automotive OEMs floating independent software subsidiaries to commercialize the software development pushing the boundaries on life cycle of vehicles and the E/E components.
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 software 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 increasing but with passenger vehicles still accounting for >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.
The software-defined vehicles (SDVs) are disrupting and transforming the automotive industry by continuously updating the featues and safety aspects through over-the-air (OTA) software updates, providing enhanced flexibility of using the existing hardware/components and offering personal customization to the end users with current E/E architecture and modifiable software. The software- defined vehicle market share by application is shown in Figure 2 (Ref [1]), with the biggest share for Advanced Driver Assistance Systems (ADAS), followed by Autonomous Driving, Infotainment Systems, and Powertrain Control. ADAS, comprising multiple technologies such as Lane Keep Assist (LKA), Lane Departure Warning (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) capability, 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.
II. Software Defined Vehicles
The automotive industry has been looking up to smartphone technologies to decouple Hardware (HW) from Software (SW), build vehicle-level operating systems (OS), carry out increased virtualization and containerization, 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 has also risen based on the trends in revenue from vehicle sales and software sales as shown in Figure 3 (Ref [2]). It can be noticed that the SW sales revenue increased from 3% in 2019 to 14% in 2025. Tesla, Inc. has been pioneering a new SW-based feature upgradation and charging model with a) one-time charge for pre-installation and b) subscription services by the end of the year. In the Over-the-air (OTA) upgrade optional package, it is observed that the OTA upgrades are chargeable for every upgrade and that the online upgrades are frequently provided for powertrain, in-vehicle infotainment (IVI), autopilot, ADAS, and chassis systems. Advanced Internet of Vehicles (IOV) service is also provided on a monthly subscription basis comprising advanced IOV connectivity services including real-time traffic, video/music streaming (recording, uploading, downloading), and karaoke.
The different levels of vehicle evolution from mechanically controlled vehicles (Level 0) towards software-defined ecosystems (Level 5) are shown in Figure 4a) (Ref [3]). The evolution of different Software-Defined Vehicle (SDV) levels along with the E/E architecture shown is in Figure 4b) (Ref [4]). The tabular details of different levels and the evolution of different features are shown in Figure 4 c) (Ref [3], [4]). The features include a) Connectivity, b) IT infrastructure, c) SW development, d),SW structure, e) cybersecurity, and f) semiconductors. In the evolution of Connectivity, some functions or control systems are upgraded through regular OTA SW updates (semi-dynamic SW management) in Level 1.0 to most of the functions/control systems getting updated through regular OTA SW updates (full dynamic SW management) in Level 2.0 and constant seamless connectivity between vehicle & external entities enabling real-time data analysis, AI-based learning and algorithm improvement, and OTA SW upgrades in Level 3.0. The SW structure evolves from AUTOSAR- compliant SW along with partial vehicle OS and API standardization in Level 1.0 to Abstraction & Virtualization for both in-vehicle and V2X communications in Level 3.0. For semiconductors, the evolution is from large-scale microcontroller 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-enabled 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 traditional 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 requirements, developing E/E and SW structure, and designing the control algorithms and the suppliers acting more as strategic partners in developing highly differentiated components and systems. This has resulted in the evolution of four different Automotive SW business models as shown in Figure 5 (Ref [5]), with additional details as given below:
- SW custom development/Non-Recurring Engineering Services
a. Intelligent cockpit SW solutions
b. ADAS/Autonomous Driving (AD) algorithm and SW packages
c. Intelligent Driving (ID) solutions - Consulting and Technical Engineering Services (CTES)
a. Early-stage design and development
b. Technical drawing releases for prototype builds
c. Component or Software testing and debugging
d. System level and Vehicle level validation - SW Intellectual Property (IP) Licensing and Application Development
a. SW modules development and release, complying with AUTOSAR standards
b. Agile or Scrum-based or DevOps-based SW tool chains
c. Specific component or System design tools
d. Simulation and Test tools - Integrated Hardware (HW) and Software (SW) Products and Solutions
a. Domain controllers
b. Vehicle-Cloud integrated products and service platform
c. Integrated Document Management System (DMS) solutions
The above business models have caused a significant disruption in the automotive industry with OEMs increasingly developing their own Operating Systems (OS), leveraging public and private cloud on data management, analytics, and decision-making, and reaching out directly to the automotive SW vendors bypassing the traditional Tier 1 suppliers, if required.
IV. SDV – Evolution of E/E Architecture
The evolution of E/E architecture is shown in Figure 6 (Ref [6]) with the architecture evolving from modular architecture where each function has its own Electronic Control Unit (ECU), sometimes
operating on diverse operating systems (OSs) to a vehicle + cloud computing architecture 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 standardization of a basic controller. The architecture evolved towards Fusion architecture with the disappearance of domains and fusion of Domain Controller Units (DCUs) required for ADAS functions to work effectively. The next 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 centralized 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.
The time-based evolution of E/E architecture in SDVs is depicted schematically in Figure 7 (Ref [2]), split into four different time zones, viz., a) before 2020, b) 2020 to 2025 timeframe, c) 2025 to 2030 time frame, and d) beynd 2030. The details of different architectures are given below:
- Before 2020 (Distributed Architecture) – it has independently functioning ECUs in a distributed environment primarily operating using CAN and LIN-based communication interfaces. The Body
Control Module (BCM) utilizes an integrated gateway for communication with dedicated sensors and ECUs to implement 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 communication requirements, and c) lack of flexibility for upgrade and scale up. - In the 2020-2025 timeframe (Centralized cross-domain 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.
- 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. - Beyond the 2030 timeframe (vehicle-cloud computing architecture) – the vision is to evolve towards a central computing platform that can carry out hybrid vehicle-cloud computing, interface with power, actuators, and sensors, and optimize the performance and power through a combination of in-vehicle real-time data processing and supplementary cloud computing for
- more effective and efficient decision-making, critical for realizing higher levels of Autonomous
- Driving (AD).
The evolution of legacy distributed E/E architecture into the zonal architecture initiated the SDV paradigm and led to the futuristic zonal architecture with Vehicle-to-everything (V2X) communication as shown in Figure 8 (Ref [7]). With many automotive OEMs mastering L3+ Autonomous Driving (AD), the trends in SW development include 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 fee, regular OTA upgrades, and subscription fee for specific feature enablement or upgrades.
The details of AUTOSAR Classic Platform (CP) and Adaptive Platform (AP) are shown in Figure 9 a) (Ref [6], [8]–[9]) in terms of 1) operating system, 2) code execution, 3) application address space separation, 4) scheduling, 5) compiling, 6) configuration, and 7) supported protocols. The Classic Platform (CP) is based on the OSEK operating system and is used for the highest real-time requirements. The platform is run with code executed from ROM and with fixed scheduling but with no application address space separation. The AUTOSAR CP expects a compiled system configuration and requires that all the ECUs be compiled as a whole. The platform only handles static mapping of signals to a specific service and only supports a translation from signal-oriented CAN communication to the Ethernet.
The AUTOSAR Adaptive Platform (AP) is significantly more dynamic, is suitable for greater computing power, and can be used for Service Oriented Architecture (SOA) (Ref [8]–[9]). The platform relies on
a subset of the standard POSIX OS interface that is standardized for all applications and SW components. The platform is run with code loaded onto ROM with dynamic scheduling (varying number of tasks and preemptive multitasking) and with application address space separation implemented. The system configuration is dynamically loaded at runtime from a file and can handle dynamically scheduled and installed applications.
As shown in Figure 9 b) (Ref [6], [8]–[9]), the SDVs adopt a hybrid AUTOSAR CP and AP E/E architecture. The AUTOSAR CP supports powertrain/chassis, ADAS & safety, body functions, and in- vehicle infotainment (IVI) through CAN/LIN and Ethernet communication interfaces 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
The evolution of Software Architecture in SDVs from the current structure to a new platform is shown in Figure 10 (Ref [6]). In the current HW/SW structure, the OEMs are highly dependent on Tier 1 suppliers for hardware, modules, and system-on-chip (SOC) components with the services, Application Programming Interfaces (APIs), and software “tightly coupled” to the SOC components. The wide gamut and number of ECUs in the vehicle often run on different Operating Systems (OSs) and devices for different end applications posing a mammoth challenge for feature commonality, standardization, or upgrade. As can be seen from Figure 10 (Ref [6]), the new HW/SW structure has a multi-layered SW architecture and introduces abstraction layers that absorb the differences between HW, OS, and middleware and remove the variant developments leading to a significant increase in SW reuse. The abstraction layers act as the essential building blocks to create a common or cross-platform that is independent of the middleware or operating system (OS) or the device variants. The HW abstraction layer (HWAL) enables interfacing with multiple devices agnostic of the HW. The OS abstraction layer (OSAL) enables the reuse of middleware on a variety of OS. The new SW platform enables cross-platform adaptability and a significant increase in SW reusability.
The Multi-layered Service-Oriented Architecture MSOA) is developed based on a multi-layered classification of ECUs independently interacting with GPOS and RTOS. The MSOA is developed employing encapsulation and layering to reduce fragmentation and complexity and to facilitate the usage of a generalized computing platform. The components serving specific vehicle functions will be encapsulated in three layers, viz., a) a basic layer for services such as processing sensor data, b) an extended middleware layer for data exchange and data fusion, and c) an application layer using all the data for applications.
MSOA ensures the reuse of SW components and lets developers create efficient new functions (apps) that can be easily integrated with the whole ecosystem of a device. MSOA a) enables easier SW portability across multiple vehicles, b) reduces system complexity, c) lets thorough SW testing against interfaces due to stringent encapsulation and hierarchy, and d) utilizes Agile methods and DevOps. Additionally, MSOA a) imitates security patterns already existing in the IT and consumer- electronics industries, b) facilitates functional separation, encoding, and firewalls, c) allows closer interaction between the in-vehicle E/E architecture and the back-end architecture, d) permits increasing data exchange between multiple automotive functions and the back end, and e) authorizes partial back end functional execution. Multiple researchers and developers have confirmed that the MSOA approach a) enables seamless integration of new functions and provides personalization for each user, b) provides remote updates that facilitate optimization, quality enhancements, and flexible lifecycle management, c) permits increasing data exchange between multiple automotive functions and the back end, and d) empowers usage of high-performance processors common to IT & smartphones with clear design patterns such as scalability and
hierarchy-based architecture.
The updated SW development lifecycle (SDLC) for SDVs with state-of-the-art methods and tools is shown in Figure 12 (Ref [10]) with key success factors (KSFs) identified as seamless design and documentation of in-vehicle and back-end architectures. Based on zonal multi-layered architecture, software development is carried out for specific domains in the vehicles such as B&C – body & comfort, P&C – powertrain and chassis, DA&S – driver assistance and safety, I&C – information and communication, etc. To assist with zonal SW development, communication standards such as LTE, Wi-Fi, and 5G between the in-vehicle network and backend ensure connectivity and bandwidth. Utilizing high-speed networks, mobility services, and specific applications such as Autonomous Driving (AD) functionality, In-Vehicle Infotainment (IVI), etc. are executed at the back end. The future innovation in SDV SDLC is enabled by Central Communication Server (CCS), MSOA, hierarchical E/E architecture, and seamless connectivity between in-vehicle and back-end architectures. Closer interaction between in-vehicle and back-end architectures using hi-speed networks enables a) data handling, b) remote SW updates, c) SW design for functions, and d) execution of code/algorithm on an ECU or at the back end. The updated SDLC technological innovation will provide multiple benefits such as a) seamless requirements process from customer interaction to the software architecture, b) complete modeling of E/E architectures based on SOA, c) encapsulation of content for distributed development using SOA design principles, d) agile development process, joint Scrum teams, and shared code repositories, and e) enablement of DevOps, CI/CD tools implementation and continuous integration. As Automotive SDV developers adopt the best practices from the smartphone industry, it is understood that automotive electronics development a) can piggyback on IT and consumer- electronics development and standards, b) Is expected to exceed the classic software systems in terms 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]).
A generic design of SDV MSOA is shown in Figure 13 (Ref [5]) which has been evolving to provide continuous OTA updates, countermeasures against cyber attacks, safe operations during ADAS/AD modes, etc. The need for the highest levels of safety assurance during ADAS/Autonomous Driving (AD) modes demands HW and SW redundancy and Functional Safety (FuSa) in safety-critical systems and operations, which in turn results in the design adaptation in the form of independent power supplies, multiple sensing, and consensus-driven AI. The critical requirement of dynamic and localized edge computing applications to support data processing and functional validation raises the need for runtime applications supporting edge computing to quickly develop and deploy efficient functions in terms of computing power, latency, and cost. To thwart the increased cyberattacks in CAEVs, the SDV MSOA design should offer the highest level of cybersecurity protection in the form of countermeasures at the HW and SW levels. As continuous OTA upgrades are a key success factor (KSF) of SDVs extending the lifecycle of vehicles, the MSOA design evolution should consider the multi-year span of HW along with the integration of vehicle-level, high-speed, low-latency, and low-cost networks such as Gigabit Ethernet. As SDVs need to support AD operations that acquire and process high-bandwidth visual inputs (video and images), the MSOA design evolution must consider high-performance GPUs with AI capabilities.
The SW technology stack in SDVs has been evolving in line with the vehicle-level evolution of E/E architecture in terms of Distributed Basic ADAS ECUs a) Partial Consideration of ADAS features b) Consolidated ADAS/AD features c) Vehicle Computing + HPC-based ADAS/AD features. This specifically calls for long-term scalability of SDV architecture for ADAS and AD operations by segregating HW &SW and ensuring that the features, functionalities, user experience, and SW upgrades are driven mainly by SW, agnostic of HW. The key technological changes required to realize the SW stack are a) HW abstraction, b) application middleware, c) containerization, d) virtualization, and e) a centralized E/E architecture with HPC units connected through Gigabit Ethernet. Specific design changes at the vehicle platform level are also called for such as vehicle-level operating system (GPOS and RTOS), specific ECU clusters, Type I hypervisor, and middleware that separate the dynamic SW stack (e.g., vehicle services, shared services, cloud services, apps).
VI. SDVs – High-Performance Computing
A schematic of the High Performance Computing (HPC) for abstraction in SDVs is given in Figure 15 (Ref [5]). The architecture comprises General Purpose Operating System (GPOS) and Real-Time Operating System (RTOS), Type I hypervisor, non-volatile memory, volatile memory, separate CPU clusters for GPOS and RTOS, Graphical Processing Unit (GPU), different communication protocols, and interfaces for external/cloud connectivity. GPOS forms the basis for Applications and Containers to run portable SW integrated with HW abstraction layers. RTOS provides deterministic services for
safety-critical functions such as steering and braking while GPOS focuses on general services and data processing apps. The HW abstraction services are offered by GPOS or other middleware. Utilizing both OSs, simultaneous GPOS + RTOS services are possible by using multiple CPU clusters and scalable memory. The Type I Hypervisor serves multi-purposes such as
a) providing virtualization services,
b) utilizing non-volatile memory (NVM) and volatile memory (VM), and
c) optimizing GPOS+RTOS simultaneous operations.
The HPC environment provides a wide gamut of physical interfaces to integrate with
a) CAN, LIN, and Flex Ray networks and
b) High-bandwidth networks (USB, Ethernet, PCIe).
The GPUs carry out multitasks such as a) processing ADAS/AV sensor data and applications, b) powering the processing for digital cockpit interfaces in IVI, and c) running the data processing and applications for AV and IVI.
The distinct and separate CPU clusters for GPOS and RTOS a) separate the handling of deterministic and time-sensitive networks (TSN) for low battery applications and b) enable “redundancy” of operations and “Functional Safety” (FuSa).
VII. SDV – Virtualization, Containers, and DevOps
A schematic of virtualization and DevOps in SDV development is shown in Figure 16 (Ref [11]). Utilizing the cloud computing environment provided by the Hypervisor vendors (Microsoft Azure,
Amazon AWS, Google GCP, etc.) the SDV toolchain enables
a) development tools,
b) development,validation, and integration, and
c) execution environment.
The virtualization also provides opportunities for extensive Automotive SW stack development, uploading/downloading code from GitHub marketplace, integrated Hardware-in-loop (HIL) testing, vehicle messaging, data and analytics, and Autonomous Vehicle Ops (AVOps). Multiple use cases could be generated from virtualization and DevOps in SDVs including a)accelerated SW developer onboarding due to faster familiarization, b) utilization of virtual environment and efficient deployment to simulate multiple combinations of HW and SW, c) SIL validation that includes running automated build, test and validate pipelines along with cloud services, d) HIL validation involving deployment and monitoring of multiple HIL tests, e) test fleet validation including 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 taking feedback from field trials, carrying out RCA, and doing SW upgrades to remove bugs and/or improve performance.
The SDV development involves a significant amount of SW-based simulations leading to new opportunities for Tier 1, Tier 2 suppliers, and Automotive SW vendors such as a) virtual ECU development, b) High-Performance Compute (HPC) capability build, and c) Containerized applications, all of which enable SW development in parallel to overcome the challenges of HW availability or modifications. The developers work in consonance with Connected Vehicle System Alliance Vehicle Signal Specification (COVESA-VSS) that standardizes access to vehicle data to receive inputs from various components and vehicle sensors and develop Application Programming Interfaces (APIs). Compliance with COVESA-VSS facilitates standardization to enable interoperability and HW-agnostic SW and API development.
An important aspect of SDV SW development is Container Design, Scheduling, and Optimization, the schematics of which are given in Figures 17 a) (Ref [12] and 17 b) (Ref [13]). As the schematic indicates, the containers in the Docker Cluster are tied to different ECUs (engine, maps, brakes, ADAS, ITS, etc.). The Component Docker Cluster comprises diverse in-vehicle applications facilitating various functionalities including driver assistance (e.g., ADAS), intelligent path planning (e.g., ITS), camera and sensor monitoring, media capabilities, intelligent 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-critical orchestrator that handles both mission-critical and non-critical applications within the vehicle (Ref [13]). As an example, SOAFEE-compliant architecture includes safety-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 toolkits 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 containers between the ECUs in the car as well as their resource usage and performance (Ref [13]).
The nodeExporter in the Monitoring module in Figure 17 b) in Ref [13] helps collect the vehicle status metrics, such as the number of ECUs per cluster, memory, CPU, and Power (Energy) utilization per each node. The Prometheus toolkit collects and stores time series data on the status of ECUs and containers and provides this input to the Scheduling component. The scheduler receives as input the real-time data on container status, vehicle status, and preferences and constraints, which are monitored on a regular basis. The Dashboard displays the alerts and recommendations for scheduling options and redistributing the containers among the ECUs. The Scheduler plays a critical role in multiple instances such as in the cases of a) user preference to optimize specific objectives or add new constraints and require the reallocation of vehicle applications based on the updated input and b) overloading of resources leading to the deactivation of one of the ECUs due to either an insufficient battery capacity or security issue or during OTA upgrade or due to the kickoff of the power conservation mode.
VIII. SDV – Cybersecurity
As more and more OEMs are developing technologies and SW solutions towards realizing SDV 3.0 with hybrid in-vehicle and cloud computing to process real-time data, advance L3+ Autonomous Driving, and optimize performance, cybersecurity becomes a key criterion to offer safe and secure driving and user experience. In Figure 18, multiple avenues and threats for cybersecurity in SDVs are captured (Ref [14]). In 2021, the World Forum for Harmonization of Vehicle Regulations (WP.29), a special regulatory working party within the United Nations Economic Commission for Europe (UNECE), released two new regulations (R155 and R156) that mandate minimum cybersecurity standards for vehicles for type approval. Along with WP.29’s regulations, ISO/SAE 21434 was jointly developed by the International Organization for Standardization (ISO) and the Society of Automotive Engineers (SAE), titled “Road Vehicles – Cybersecurity Engineering”, and released in Aug 2021. Cybersecurity researchers continue to develop countermeasures to address the increasingly complex and sophisticated cyberattacks through a) zero trust architectures where everything is untrusted, b) complete verification of each component to ensure trustworthiness, c) system-level interaction operating on a least privileged basis, d) increased transparency of Software Bill of Materials (SBOMs), and e) insistence of software/component certification leading towards R155 type approval.
IX. SDV – Impact on Insurance
It is estimated that by 2030 almost all modern automobiles will be connected and more than 70% of them will have ADAS and Level 3+ autonomous features, as shown in Figure 19 (Ref [15]). This has a direct impact on the complexity of SW in modern vehicles with >300 million lines of code required to run these vehicles with advanced performance and safety features, resulting in different levels of SDV functionalities as shown in Figures 4 a) and 4 b) (Ref [3], [4]).
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 assessment, insurance underwriting, actuarial modeling, and premium calculation. Owing to the higher levels of technological complexity in Connected, Autonomous, Electric Vehicles (CAEVs) with increased levels of Software and regular OTA updates, the vehicles may need dedicated service stations, specifically trained technicians, and incur higher repair costs. The insurers are expected to evaluate the risks associated with advanced software dependency, unique maintenance needs including parts embedded with sensors for ADAS features, the decision on repair vs replacement of batteries depending on their remaining useful life (RUL), and liability of driver (human) vs OEMs (machine or product) for Level 3+ Autonomous Vehicle (AV) capabilities. Additional risks include a) software reliability, b) cybersecurity and data privacy, c) functional safety and system redundancy in case of failures, and d) change in driver behaviour arising from Level 3+ AV capabilities. As the technologies and SDVs are continuously evolving, the insurers continue to have a challenge in evaluating the risk with limited or no prior vehicle history and quantification of hardware specifications and OTA SW updates in terms of insurance risk. The continuous evolution of technology, the need for compliance with local regulations, and the potential for shifting of liability from personal liability towards product liability supplied by OEMs or system suppliers for Level 3+ AV capabilities is forcing the traditional automotive insurance industry to experience “disruption” and adopt new methods of underwriting. The insurers need to disrupt the traditional insurance models by investing in new capability building and partnerships and increasingly promoting commercial automotive premiums.
Multiple studies have been carried out to understand the impact of SDV development, increased Connected Cloud Services, and OTA updates on the insurance market (Ref [16] – [18]). The McKinsey report in Ref [18] captures the trends in US personal auto insurance market direct premiums, as shown in Figure 20. The trends indicate the disruption in the automotive insurance industry with insurance premiums for conventional automotive personal lines reaching the peak of about $263 billion by 2026 and reducing to about $248 billion by 2030 along with disrupted personal lines coverage increasing from about $50 billion in 2026 to about $100 billion by 2030. The disruption is due to multiple factors including a) almost 100% connected vehicles, b) > 50% share of EVs, c) and about 70% adoption of ADAS features and Level 3+ AV capabilities. A new actuarial model is being developed with increased adoption of telematics-based dynamic insurance pricing, Generative Artificial Intelligence (Gen AI)-based claims handling, and disrupted personal lines coverage of about $100 billion for the new generation of CAEVs with customers interacting only with the insurers for dynamic OTA SW updates and not the OEMs. Insurance carriers at the forefront of technology adoption and having an in-depth understanding of safety enhancement and personalized customer experience will be influencing future actuarial models by identifying the risks and by incorporating changes in the insurance premium calculations. These pioneers will also underwrite insurance for vehicles with less technological capabilities as they coexist with vehicles with advanced technologies.
The evolution of automotive insurance models with the development of SDVs is shown in Figure 21 (Ref [18]). In insurance model 1, OEMs have the largest share as they create full-stack insurance carriers with the insurers taking 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 underwrite 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 relative 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
The need for SDV development, trends in the revenues from vehicle sales and SW releases through OTA updates, and the evolution of different levels of SDV are presented. The recent developments and the evolution of E/E architecture are given in detail with the emergence of zonal architecture in SDVs leading towards the hybrid in-vehicle and cloud-computing for L3+ AD experience. The evolution of SW architecture and the importance of the Digital Foundation Platform leveraging the multi-layered SOA is elucidated. To increasingly decouple SW development and deployment from the HW and to reduce the time-to-market for SW releases, the SDV development is adopting virtualization, container design, and optimization, and DevOps and SW toolchains for Continuous Integration and Continuous Development (CI/CD). As more OEMs are adopting hybrid in-vehicle and cloud computing to process real-time data and offering L3+ Autonomous Driving, cybersecurity becomes a key criterion for offering safe and secure driving and user experience. Multiple avenues for cyberattacks and their potential impact on the performance of the vehicles are captured. Research on cybersecurity countermeasures continues towards developing zero trust architectures, 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, actuarial modelling, and premium calculation. The impact of SDV development on auto insurance, disruption in the insurance industry, the trends in personal auto insurance premiums, and the emergence of new insurance business models are presented.
Future Work
Researchers have been working on multiple futuristic SDV technologies including software-defined Internet of Vehicles (SD-IOV). A generic software-defined IOV (SD-IOV) architecture is given in Figure
22 (Ref [19]). The SD-IOV is a result of the integration of Software Defined Networking (SDN) and IOV and works on the principle of segregation of the control plane and data plane. The generic SD-IOV architecture comprises a) logical (SDN) controllers, b) SDN switch network, c) SDN-enabled wireless access infrastructure, and d) SDN-enabled vehicles. Research continues on multiple implementation methods of wireless control paths based on their performance and complexity (Ref [19]). The automotive OEMs have been increasingly working on building a Road-to-Cloud ecosystem, offering cloud services based on SD-IOV, based on an architecture as shown in Figure 23 (Ref [20]). The development and updates are segregated into in-vehicle tasks (system integration) and vehicle- to-cloud activities (cross-domain integration). The Connected Cloud Services (CCS) enable a cloud- based development and collaboration framework to build a Digital Twin in a safe and secure environment.
Owing to concerns about data security and privacy and with a clear business proposition to monetize the enormous data generated by the Connected, Autonomous, Electric Vehicles (CAEVs), OEMs have been experimenting with private cloud layout and services with a focus on big data, advanced data analytics, and AI. Many OEMs that have been playing a leading role in SDV development have been developing their own Automotive Operating Systems (OS) and looking into the full software development lifecycle (SDLC), from design to after-sales service and support, with private cloud layout and services. As many customers seek feature upgrades and OTA updates on demand, the private cloud layouts and services enable OEMs to focus on elastic computing, data storage, networking, security, AI, IoT, and application SW. The OEMs have also been looking into the logistics vehicle fleet management and services, self driving intelligent logistics vehicles, after-sales service, and intelligent supply chain through private cloud and services.
The IOV CCS promotes the concept of a Vehicle History Record (VHR) that captures vehicle maintenance history, service records, user care, feature upgrades/changes, and operational efficiency trends/changes based on big data. The VHR typically covers multiple vehicle aspects including a) service/repair history, b) data collection/governance/analysis, c) fault prognosis/diagnosis, d) driving efficiency trends, e) security risks, f) remote diagnosis, etc. CCS comprises Infrastructure as a Service (IaaS), Platform as a Service (PaaS), and Software as a Service (SaaS). The IaaS offers public or private cloud services with computing, network, and storage facilities. The PaaS provides cloud-assisted autonomous driving (AD), simulation platforms for SW development/testing/deployment, data annotation, image rendering, etc. The SaaS includes vehicle management, production/sales data, after-sales data, service management, etc.
The IOV CCS offers multiple use cases such as a) Personalization, b) Predictive Maintenance, c) Charging Solutions, d) Safety & Security, e) Transportation Management, and f) Fleet Management. The cloud services related to in-vehicle infotainment (IVI) include entertainment apps that can integrate Instagram, Facebook, and TikTok and let users have multiple facets of user experience such as a) shoot and share or watch videos, b) listen to audiobooks, c) read newsfeeds, d) take and share pictures, e) listen to speech from text through AI-enabled text-to-speech, etc.
The IOV Automotive Cloud Services (ACS) includes R&D, production, sale, maintenance, and post- sale services of SDVs based on 5ABCD (5G, Artificial Intelligence, Blockchain, Cloud Computing, Big Data). Multiple OEMs have confirmed up to 40% cost reduction in SW & IT development costs due to the migration to cloud services (Ref [21]). Higher productivity has also been reported with CAD and CAE models getting designed, developed, and validated 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 personalized 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.
References
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,” 3rd 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,”
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
19. Chen, J., et. al, “Software defined Internet of Vehicles: architecture, challenges, and solutions,” Journal of Communications and Information Networks, Vol. 1, No. 1, June 2016, JCIN, DOI:10.11959/j.issn.2096-1081.2016.002
20. 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 15th December 2024.
21. Research in China, “Automotive Cloud Service Platform Industry Report, 2021-2022,” March 2022, http://www.researchinchina.com/Htmls/Report/2022/71754.html
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 e-Fuels.
