1. SDVs emerging through the clarification of CASE
In recent years, the term SDV (Software Defined Vehicle) has rapidly gained traction in the mobility industry and has become a common topic in mainstream media. The term CASE*1 began to spread in 2016, and over time, it has been dissected into various elements essential for its realisation, such as AI technology innovations, cybersecurity measures, high-performance semiconductor technology, advancements in connectivity and adaptation to the circular economy. As the clarity of the term CASE increased, SDV emerged as one of its critical components. It is now widely recognised that without the realisation of SDVs, the transformation of CASE and the mobility ecosystem would not be possible (Figure 1).
2. What is an SDV?
a. SDVs are not just mobility itself, but an ecosystem with the user at its centre
Unlike SAE*2 levels of autonomous driving or vehicle electrification (HEV, PHEV, BEV, FCEV), the definition of SDV (Software Defined Vehicle) remains ambiguous, with varying interpretations depending on the perspective of the key players involved. Although the term ‘vehicle’ is part of SDV, it includes not only the mobility itself but also both the inside and outside of mobility (in-car/out-car), as well as the concept of delivering value to users derived from these elements. Therefore, we define SDV as ‘an ecosystem that continuously provides new value and experiences to users by updating features through software at its core, connecting both the inside and outside of mobility’.
It is crucial to understand that the core of SDV is not the mobility itself, but rather the user and the value or experiences offered to them. Mobility, cloud technologies and other related technologies should be viewed as means to fulfil the needs of users (Figure 2).
The stakeholders involved in SDVs include vehicle OEMs, Tier 1 suppliers, Tier 2 suppliers (including software vendors), semiconductor suppliers, OTA (Over-The-Air) server operators, other service providers and government agencies. Given the wide array of perspectives among these stakeholders, the interpretations of SDV can vary significantly. We believe that defining SDV as the entire foundational ecosystem and taking a comprehensive view is essential for accurately understanding its entirety.
b. Defining SDV levels
PwC believes that SDVs (Software Defined Vehicles) can be represented in levels ranging from Level 0 to Level 5, as the SAE-defined levels for autonomous vehicles. If we define SDVs as being Level 3 or higher, following a similar approach to SAE’s autonomous driving levels, the current leading companies have reached Level 4, with many aiming to progress from Level 2 to Level 3, or from Level 3 to Level 4. At Level 0, the focus was predominantly on mechanics and hardware, but with each increase in level, users will perceive more value through software and services related to mobility (Figure 3).
- Level 0: Mechanically Controlled Vehicle
A vehicle where driving functions are primarily realised through the coordination of mechanical components, with only a small part of functions, like engine control, managed by electrical and electronic systems.
- Level 1: E/E Controlled Vehicle
A vehicle with multiple independent ECUs (Electronic Control Units) that has advanced in its E/E (electrical and electronic) functions. This type primarily uses discrete components for E/E control and is equipped with ECUs that have relatively small-scale microcontrollers embedded with software.
- Level 2: Software Controlled Vehicle
With the increase in functions required for mobility beyond driving, the number of ECUs has increased. As a result, the vehicle is managed by a bus through in-vehicle networks such as CAN (Controller Area Network) communications. These networks are segmented by domain and operate at several Mbps (megabits per second).
The scale of the microcontrollers is also relatively large, and SoCs (Systems on a Chip) are partially utilised, resulting in vehicles with relatively large-scale software. Although OTA functionality is available, it is limited to infotainment-related updates and software bug fixes, such as those for recalls, which are primarily handled through wired communication (e.g. with diagnostic tools).
- Level 3: Partial Software Defined Vehicle
Through domain architecture*3, the integration of ECUs progresses, with large-scale SoCs for HPC (High-Performance Computing) handling the control of integrated functions. Additionally, the standardisation of vehicle OS and APIs (Application Programming Interfaces) is advancing in some areas. In-vehicle communication speeds are increasing, utilising in-vehicle Ethernet communication ranging from 100 Mbps to around 1 Gbps, with a trend towards centralisation around domain controllers. Active software updates via OTA are implemented not only for fixing issues but also for adding new features and enhancing product value, with some adopting revenue models beyond just mobility sales. Levels 3 and above are defined as SDV.
- Level 4: Full Software Defined Vehicle
With the adoption of zone architecture*4, the optimal placement and scalability of functions are enhanced. The standardisation of vehicle OS and APIs accelerates the decoupling of hardware and software, further driving a shift-left approach through cloud-based virtual development environments and software-first development processes. To maximise the effects of decoupling, hardware is designed to be rich and future-ready, incorporating reservation design principles. In-vehicle communication speeds exceed several Gbps, facilitating large-scale and high-speed data transmission required for autonomous driving and other advanced functions. Frequent and proactive OTA software updates are implemented to add new features and improve product value, ensuring that the mobility’s value continues even after purchase. Additionally, multiple revenue models beyond vehicle sales are established.
- Level 5: Software Defined Ecosystem
Mobility and external systems are seamlessly connected at all times, enabling the transfer of AI-driven control functions to external systems. This not only allows for software updates within the vehicle but also enables continuous learning outside the vehicle, ensuring that market data and user needs are constantly met. In the realm of infotainment, common apps and services can be provided regardless of the vehicle, significantly shifting the value of mobility towards software and services. As API standardisation advances further, general users will be able to develop and sell vehicle apps, much like smartphone applications. The increased ease of plug-and-play hardware also allows for value continuity through hardware updates. As a result, touchpoints between users and mobility, including in the development domain, will increase more than ever before. These advancements elevate the overall value of mobility across the ecosystem, continuously maximising and updating user value and experience.
At PwC, the SDV levels are broken down into ten elements (UX, revenue structure, app/service sales, IT infrastructure/data, connectivity, E/E architecture, software development, software structure, cybersecurity and semiconductors). Each element’s state is defined at different levels. This means that while one element might be at Level 3, another might be at Level 4. Therefore, it is essential for each player involved to accurately assess the current state of each element and set targeted goals for each one, which will help clarify the ‘desired SDV vision’ across the industry. Furthermore, these ten elements of the SDV levels are designed to be flexibly expanded in the future, accommodating industry growth and the addition of new technological elements (Figure 4).
3. Acceleration of SDVs will further promote autonomous driving and electrification development
With electrification, the number of components in vehicles decreases dramatically, simplifying the powertrain and making actuator control relatively straightforward. This simplicity makes electrification well-suited for tackling the large-scale and complex challenges of autonomous driving development. Additionally, when considering the rapid evolution of functions, the collection of data, post-release feature improvements, centralisation and the optimal E/E architecture that supports these advancements—along with shift-left development practices like CI/CD and digital twins—the affinity between SDVs and autonomous driving development is exceptionally high.
In terms of electrification, the high affinity with SDVs is further evident when considering aspects such as battery status management, real-time information integration with external systems, energy management across the entire mobility system including grid power and an E/E architecture capable of accurately monitoring the overall vehicle status. By advancing the SDV level, the development of both autonomous driving and electrification can be significantly accelerated (Figure 5).
ICE: Internal Combustion Engine Vehicle
HEV: Hybrid Electric Vehicle
PHEV: Plug-in Hybrid Electric Vehicle
BEV: Battery Electric Vehicle
FCEV: Fuel Cell Electric Vehicle
4. Traditional OEMs and emerging OEMs have very different strategies
Many traditional OEMs, which have spent a long time advancing technological innovations from ICE development, are leveraging their accumulated technical expertise, design assets, extensive development resources, global supply chains and global sales networks to drive SDV adoption, autonomous driving and electrification. However, these traditional OEMs face the challenge of managing a full lineup, from ICE to BEV/FCEV, with their SDV efforts currently spread across Level 2 (software-controlled vehicle) ECUs, each managed by separate development teams. It is necessary to maintain this structure while gradually advancing to SDV Level 3 (partially software-defined vehicles) with domain controllers and to Level 4 (fully software-defined vehicles) with zone/central controllers. Balancing immediate profitability from SDV Level 2 and ICE/HEV-focused organisations with future investment and resource allocation for SDV Levels 3 to 4 is a significant challenge, making bold and rapid investment decisions difficult.
On the other hand, emerging OEMs, established within the past decade or so, lack extensive historical assets and resources, but they benefit from having no legacy constraints. These companies have committed to BEVs from the outset, focusing their limited resources on rapidly developing optimal E/E architectures such as domain and zone architectures. Starting without organisational barriers allows them to create optimal structures without being tied down by legacy issues. However, while they may be able to build ‘running vehicles’, ensuring long-term, high-quality, safe and reliable mobility that meets numerous laws and regulations is no easy task. They cannot quickly catch up to traditional OEMs in terms of global scale and accumulated experience and knowledge. For emerging OEMs to achieve significant scale, they need to learn from the strengths of traditional OEMs and suppliers and attract the right talent from outside their organisations (Figure 6).
Given the vastly different circumstances faced by traditional OEMs and emerging OEMs, it is essential for each to advance SDVs, autonomous driving and electrification in ways that are suited to their specific situations. Unlike OEMs, suppliers must constantly and accurately understand both traditional and emerging strategies and conditions. They need to decide whether to support both approaches or align more closely with one. For mega-suppliers with extensive product lineups, it is generally necessary to address both strategies. Therefore, while staying aligned with traditional approaches, it is crucial for them to respond swiftly to development and changes.
5. SDV is crucial now, but other big challenges will emerge in the future. The most important aspects are the flexibility and adaptability to continuously evolve according to the situation.
Currently, the term SDV is a central topic in the mobility industry, and companies are being pressured to respond. In today’s unstable and uncertain world, new technologies, challenges and concepts will continue to emerge and be defined. It is possible that today’s emerging OEMs will become similar to traditional OEMs in the next decade, while new emerging OEMs and players will arise. Therefore, it is crucial to always accurately assess the current situation, envision the desired future and approach the tasks each company must undertake with flexibility and agility. Being able to adapt smoothly to these changes is of utmost importance.
*1 CASE: An acronym for Connected, Autonomous, Shared & Service, Electric.
*2 SAE: An abbreviation for the Society of Automotive Engineers.
*3 Domain Architecture: An E/E architecture built around functional elements (domains) such as powertrain, infotainment, ADAS/autonomous driving, etc.
*4 Zone Architecture: An E/E architecture that optimally places functions based on the physical placement of sensors and actuators (zones), rather than focusing on functional elements (domains).
