The Benefits and Opportunities of Software-Defined Vehicles

The automotive industry is investing aggressively in the development of Software-Defined Vehicles. These vehicles greatly facilitate the vehicle’s electrification, optimization and personalization, as well as the attainment of higher levels of driving automation. More broadly, these vehicles change how the industry designs, makes, sells, and services vehicles, and in the process enable a new customer experience.

The drive to develop zero emissions vehicles, particularly battery electric, that are automated, or autonomous, is causing automakers to focus on Software-Defined Vehicles. A Software-Defined Vehicle is one whose capabilities are enabled and enhanced by software that is running on commoditized hardware. A prime example of a capability that could only be offered by a Software-Defined Vehicle is Smart Summon of Tesla vehicles that can be initiated from the company’s consumer-facing mobile application.

The Software-Defined Vehicle relies on an architecture that separates the software from the hardware. It’s functionality is created by a variety of high-level applications, like Tesla’s Smart Summon, and low-level ones, like applying the vehicle’s brakes. Similar to personal computers and smartphones, the Software-Defined Vehicle’s architecture consists of hardware, application software, and operating system software that sits between applications and hardware. This newer digital architecture is made possible by the fact that several of the mechanical components found in prior generation vehicles, such as steering or braking, have been replaced by electronic components that can now be controlled by application-level software rather than just firmware. In vehicles using conventional architectures the firmware included with each Electronic Control Unit (ECU), and today’s vehicles contain tens, if not hundreds, of ECUs, blends application and operating system software.

The architecture of Software-Defined Vehicles is based on the principles of modern High-Performance Computing (HPC). It relies on compute (clustering multicore CPUs, GPUs, and increasingly AI processors) that can perform quickly and cost-effectively the operations required by the various applications and the operating system, ample storage for the big data that is generated and processed, and a fast network for the communication between compute and storage. Applications and the vehicle’s operating system comprise the vehicle’s software platform. The compute, storage, and communications network together with the vehicle’s powertrain, chassis/skateboard and network of sensors and actuators comprise the vehicle’s hardware platform. By standardizing around a few such architectures, OEMs will enable broad adoption of Software-Defined Vehicles, in the same way that architecture standardization led to the broad adoption of personal computers and smartphones.

A Software-Defined Vehicle (SDV) may be developed using a “clean-sheet approach” or a “retrofit approach”. Under the clean-sheet approach, the vehicle’s software and hardware platforms are new and built from the ground up. Vehicles such as Tesla’s Model S, GM’s Lyriq, NIO’s ES6, and XPeng’s G9 were developed using the clean-sheet approach. In the retrofit approach the hardware platform is derived from an existing conventional vehicle architecture, and is paired with a simpler software platform to enable the Over-the-Air (OTA) updates. The Ford Mach-E crossover SUV was developed using the retrofit approach that combines Ford’s GE1 hardware platform and its FNV software platform. GE1 is a derivative of Ford’s global compact (C2) vehicle architecture.

The adopted approach depends on how quickly the OEM wants to introduce to the market vehicles with features requiring an SDV architecture, the cost of adopting a particular architecture, and what capabilities, e.g., OTA updates and driving automation, the OEM wants the Software-Defined Vehicle to have. In Mach-E’s case, Ford focused on producing an electric vehicle with OTA update capability. The decision to use the retrofit approach enabled Ford to start producing the Mach-E within a year after announcing it. On the other hand, in addition to producing an electric vehicle that would be capable of receiving OTA updates, GM wanted the Cadillac Lyriq midsize SUV to utilize a new battery technology, and be capable of Level 3 driving automation. For this reason, GM decided to use the clean-sheet Ultium/Ultifi SDV platforms. However, due to this decision GM will only be able to start the Lyriq’s production in the spring of 2022, more than a year after Ford’s launch of the Mach-E. The Model Y will still be the vehicle to beat even though the Lyriq will give it a run for its money.

There are several advantages of the clean-sheet over the retrofit approach:

1. It results in more robust and interconnected hardware and software platforms because these are developed under a single design and implementation philosophy that is adopted by all participating partners.
2. It provides a better opportunity to introduce more applications in and around the vehicle because of the cleaner separation between software and hardware.
3. It enables software-based control at the hardware architecture’s lowest level, resulting in easier OTA updates.
4. It facilitates hardware upgrading as technologies improve.
5. It results in better long-term economics for the OEM, its supply chain partners, and the vehicle’s operator because of more frequent, easier and less expensive updates, resulting in higher margins for the OEM and better ROI for the operator.
6. It creates better in-vehicle data management because of the improved ability to control and filter the data in the vehicle before it is transmitted to the cloud, and improved utilization and economics of the cloud-based systems.

Ideally, a Software-Defined Vehicle’s hardware platform should consist of a single central computing server that interacts with the vehicle’s storage, sensors, and actuators via messages that are communicated using a broadband network. Let’s call this the Central Computer architecture. We expect Software-Defined Vehicles to be based on such an architecture by the end of the decade. For this to happen 

• The automakers must continue to develop and refine their new vehicle architectures. 
• Systems with more computing power, lower power consumption, and reasonable cost must become available.
• The cost of next-generation sensors and actuators must decrease while their capabilities must continue to increase.
• Battery performance (including energy density and cost per kWh) must continue to improve. 

Until Central Computer architectures become a reality, hardware platforms will rely on two alternatives: Zone-Based architectures, employed in clean-sheet SDVs, and Domain-Based architectures, employed in retrofit Software-Defined Vehicles.

In a Zone-Based architecture, a computing server, called Zone Controller, controls a set of components (Electronic Control Units, sensors, and actuators) based on their physical location in the vehicle. For example, the ECUs, sensors, and actuators handling driving automation function together with the corresponding components relating to the body control functions for the vehicle’s entire front area. Tesla, and NIO, use a Zone-Based architectures. 

Zone-Based architectures require a small number of powerful Zone Controllers to process the data and perform the complex operations associated with vehicle’s functions. For example, Tesla’s Zone Controller has a peak performance of 73 TOPS. These controllers are developed specifically for these architectures. Each Zone Controller runs its own operating system. The operating system may be the same across all controllers or each controller may use a different operating system.

In a Domain-Based architecture, each group of related ECUs, typically the ECUs that are already part of the architecture being retrofitted, is organized into a separate domain that is controlled by a single Domain Controller. Domain-Based architectures include at least four to five domains (powertrain, ADAS, infotainment, body control, and passive safety). A typical Domain Controller has a CPU that performs the higher-level domain functions and provides a simplified interface to other Domain Controllers. Domain Controllers communicate via a high-speed network. Similar to Zone Controllers, each Domain Controller runs its own operating system. A domain’s ECUs perform the lower-level functions. Ford’s Mach-E uses a Domain-Based architecture.

One of the Software-Defined Vehicle’s biggest advantages and opportunities is that it will usher a new customer experience both inside the vehicle, e.g., occupant safety, security, productivity, comfort, communication, convenience, and entertainment, but also outside the vehicle. This new customer experience will start the moment a potential customer (consumer or corporate) expresses their intent to consider a vehicle brand, progresses during the sale process and the ownership period, and stops when the relationship with the OEM ends, i.e., it can span several vehicles and owners. It includes not only the vehicle itself but the OEM’s entire set of mobility-related capabilities, e.g., vehicle financing, and insurance, that can address each customer’s specific mobility needs based on its continuously updated understanding of these needs. For example, imagine a Software-Defined Vehicle that analyzes data from the battery system, the conditions of the road ahead and the weather conditions, determines that it will need to be re-charged in the next 50 miles, and offers to make a reservation at a particular fast-charging station to minimize the wait time, settles the charging fee automatically, and provides entertainment content recommendations appropriate for the charging period.

The new customer experience will be based on: 

1. The type of relationship the OEM wants to establish during the customer journey from intention to acquire the vehicle, to the vehicle’s actual acquisition, and post acquisition use. Not every automaker will want to establish a rich, context-dependent relationship with every customer segment for every vehicle model in their lineup, and not every customer will want to have a deep, long-lasting relationship with the automaker but they will have the opportunity.
2. The types, quality, and quantity of data from the customer and the Software-Defined Vehicle the OEM is willing and is permitted to collect, and the understanding that the collected data enables.
3. The capabilities that the automaker decides to standardize for each target customer segment through every Software-Defined Vehicle model. This will motivate the investments, partnerships, and the level of openness of the platform interfaces the automaker decides to make, including with its technology partners, to achieve the desired customer relationship.

This experience is enabled by the way Software-Defined Vehicles are designed, made, sold, and serviced. Because many Software-Defined Vehicles will be battery electric, their powertrain is simpler and has fewer parts. Fewer parts mean that the vehicle is easier and less expensive to manufacture with fewer points of potential failure during the assembly process. The OEM can offer each Software-Defined Vehicle model in fewer configurations but with improved personalization capability through the software applications its architecture enables. This approach leads to higher customer satisfaction because the customer pays only for what they believe they need. Because the Software-Defined Vehicle’s functionality can be augmented as a result of data collection combined with OTA updates, the vehicle’s residual value could actually increase over time.

Because of its architecture a Software-Defined Vehicle can be experienced and configured by its prospective buyers virtually. This capability, combined with the addition of new sales channels beyond the dealer network will change the way these vehicles are sold. It will increase the customer’s connection with the vehicle from the first time the prospective customer interacts with the vehicle’s systems.

The Software-Defined Vehicle is safer, of higher quality, and better uptime. Safer vehicles result in lower cost of ownership and better ROI for the customer. Higher quality vehicles imply higher customer satisfaction and loyalty but also lower warranty costs, (with many recalls and repairs handled via OTA updates) and accruals for the automaker.

Customers are quickly becoming aware of the benefits that features such as OTA updates and higher levels of driving automation offer. They are also expressing their strong desire for a different mobility-related customer experience. As they begin to associate these advantages with Software-Defined Vehicles, the demand for such vehicles will increase and will result in new benefits and opportunities for customers and the automotive industry alike.