The software-defined vehicle (SDV) initiative is widely discussed automotive concept that promises to transform the way mobility solutions will be architected, designed, and delivered. The SDV will encompass software and hardware components, such as sensors, processors, and wireless networks, to enable advanced features including real-time data processing, in-service vehicle configuration automated driving, and cloud-based services. However, the development of SDVs is not without its challenges. These challenges include cybersecurity risks, data privacy concerns, standardization issues, and regulatory frameworks.
This white paper provides the current view of the AESIN community on what the software-defined vehicle is touching on the market perspective, the SDV process, business perspectives and a comparison between the traditional vehicle and the SDV.
Software Defined Vehicle: Definition
The term “Software Defined Vehicle” covers a wide spectrum of embedded software and design tools, and also connectivity outside the vehicle to cloud-based resources, but a widely accepted definition in the automotive industry is “A vehicle where the features and functions are primarily enabled through software”. This document further qualifies the definition, to reflect the different roles that AESIN members could assume with SDV activities.
Design and market decisions on feature innovation, and vehicle functions are primarily driven by the automotive OEMs, and they have specific needs to meet their revenue and market share objectives. SDV also impacts Tier 1 and Tier 2 suppliers, and this paper attempts to summarise their contribution also.
Software has become one of the fastest-growing elements of the vehicle, and the value of the “SDV Market” is predicted to double in the next five years. There are many market factors which make the SDV different. The SDV goes beyond being just a “connected car”. Over its life, it will make best use of the underlying (and increasingly commoditised) hardware to provide updates to and new driver features in software form. An SDV might be referred to as a “computer on wheels”, or “a smartphone on wheels”, even though software and ECUs (electronics control units) have been used in vehicles since the early 1980’s. The difference today arises because an SDV will include one or more new high-power “central compute units” to host the changing and evolving software applications, rather than utilising the established architecture of resource-constrained ECUs within the underlying distributed E&E embedded system.
In an SDV, software features really are a differentiator between the vehicle manufacturers (OEMs). The OEMs are looking to roll-out new and unique features, they aren’t just “fast following”. The SDV is an enabler for today’s Automotive CASE Megatrends (Connected, Autonomous, Shared, Electrified) and it also presents an opportunity for the OEMs to make aftersales from subscription services or App Stores, beyond traditional servicing and parts.
In a SDV we might talk about the “user” rather than the “owner” or the “driver”. The user gets excited by, and talks about the new features and latest software updates such as “my car just got blind-spot monitoring” and not just “my car has a six litre-engine and 20-inch alloy wheels”. Interestingly, the vehicle contains its best feature set at the point of sale, but also its worst, as the vehicles features and functions continue to evolve in the field throughout its life.
It is worth noting that the SDV should not be considered as simply a platform for data collection (“big-data mining”). Although there may be many useful applications for data that can be collected, especially considering diagnostics, preventative maintenance (prognostics) etc., users will not welcome an SDV whose primary goal is for marketing or advertising. User privacy should always be respected especially taking into consideration aspects such as recent GDPR legislations.