Introduction

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.

Market Perspective

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.

SDV Process

The process for software development follows well-proven steps, and these are now being widely adopted by Automotive OEMs and their suppliers. Managing and tracking requirements, through design, implementation, test and delivery to customer expectations is exactly the same for software as for any other part of the vehicle. With software we have the added benefit of being able to quickly issue changes and updates, potentially delivered “over the air” (OTA). If there is a change or upgrade request, this can ripple through the process more quickly than a traditional mechanical part could.

There are many suppliers of specialist tools contributing to the SDV design cycle – the OEM has the task of selecting the best tools for the task and forming them into a workable design flow. Matching data-formats, and managing data-integrity is a significant challenge, and often outside the traditional expertise of an Automotive OEM. One of the goals of the AESIN SDV is to provide help in providing existing proven toolsets and design-flows, making it possible to recommend “known-working” SDV design tools and best-practices.

Appendix 1: SDV Business Perspectives and Benefits

Appendix 2: Traditional Vehicle versus SDV