Software-defined cars bring new business models to autonomous driving

Within the six-level automation framework of SAE International (formerly the Society of Automotive Engineers), most automakers have currently achieved partial automation of driving functions at Level 1 and Level 2. OEMs around the world are designing the transition to Level 3 and even Level 4.

Compared to L1 ADAS features, L2 provides more sophisticated features, such as adaptive cruise control combined with lane centering. These features truly assist the driver and generate high-margin revenue for automotive OEMs. Despite the performance improvements of L2 features, the driver is still considered the person driving the vehicle and is responsible for the safety of the passengers and the vehicle.

Starting from L3, the driver conditionally hands over responsibility to the ADAS system. An example is "traffic jam", where the vehicle will drive itself in a congested section of road. Since this is conditional automation, the driver must still be ready to take over the vehicle. In L4, the conditions for the driver to take over the vehicle are further reduced, and in some cases even completely hand over control to the vehicle.

To move from L2 to L3 or L4 requires a significant technological leap to provide vehicles with enough sensing and algorithmic processing or even artificial intelligence (AI) to successfully navigate the driving environment and distinguish who or what is responsible for driving the vehicle.

SAE's six levels of driving automation. SAE INTERNATIONAL

Higher Stakes

When developing L3 or L4 systems, the safety of passengers depends largely on the effectiveness of the manufacturer's ADAS systems. The reliability and trustworthiness of these systems is important because it can enhance or damage the manufacturer's reputation.

However, safety is only one factor that affects the sales and success of a car. Automakers must maintain and build on their reputation for in-vehicle infotainment (IVI). Modern IVI systems are similar to smartphones, using apps to deliver useful, compelling, and engaging content. The number of apps and content streaming services for cars is growing, and the level of driving automation will continue to increase.

Many features of new cars, including safety, infotainment and vehicle performance (handling, acceleration, emissions), are increasingly implemented by complex software. This has given rise to the concept of software-defined vehicles (SDVs), which can be upgraded throughout their lifecycle to enhance existing features and add new functions. However, the vast majority of today's in-vehicle systems use dedicated hardware modules and are function-specific.

This includes nearly all newer L1 and L2 ADAS systems. Systems that are not software defined and lack the ability to accept enhanced software are doomed to perform only the functions for which they were designed. As a result, they offer manufacturers limited or no ability to upgrade vehicle functionality. True implementation of “software defined” requires the implementation of hardware that is capable of accepting new software. It is software definable functionality that creates the potential to generate new revenue streams throughout the lifecycle of a consumer’s vehicle investment.

Data Center on Wheels

A modern car typically has up to 100 electronic control units (ECUs), which between them may contain up to 100 million lines of software code (compared to around 14 million in a commercial aircraft). The main ECUs in a car are for engine, transmission, traction, anti-lock brakes and airbag control. Those ECUs that provide smaller functions will include things like climate control, window and seat controls, etc.

Such a large number of ECUs and their distribution around the vehicle makes the architecture very complex. This architecture is not particularly energy-efficient, both from the perspective of energy consumption and computing power, as most ECUs cannot be upgraded or used for anything other than the task for which they were designed. The continuous innovation of vehicle performance and functionality is the reason for the proliferation of ECU systems. However, the move to a "software-defined car" requires a move to a centralized high-performance computing (HPC) architecture and the addition of some automotive-specific features.

Therefore, SDV can be seen as a mobile data center with HPC at its core. Since HPC includes a variety of powerful CPU functions that support both general-purpose computing and specialized computing (such as video processing), functions can be added to the vehicle many years later, which will increase the vehicle's value retention rate. If a compatible HPC cluster exists, software-enabled functions that exist on new vehicles can be added to older vehicles.

The SDV of the future will be a data center on wheels, with high-performance computing at its core and equipped with high-speed interfaces to connect edge sensors. As a platform, the SDV will have cloud connectivity and be able to receive real-time updates.

On the periphery of the vehicle, there will be components, such as smart sensors, that can perform edge processing, but since their use cases are generally narrow, the need to update these components with software is less important. In addition, moving to centralized processing may eliminate the need for a lot of edge computing power in the vehicle, depending on the bandwidth cost of transmitting raw data versus the cost of pre-processing the data. Radar, vision cameras, lidar, accelerometers, and GPS are all sensors that provide the vehicle with information about its surroundings.

The data provided by these sensors can be used to implement various safety, performance or entertainment tasks and can be used by the vehicle's newly added functionality. This functionality, along with existing ADAS and infotainment functions, will reside in the HPC.

Since L3 and L4 require incremental increases in computing performance, it is logical that the implementation of HPC clusters is synchronized with the introduction of these systems. Implementing HPC with L2 ADAS capabilities (sometimes called L2+, although SAE does not have such a definition) allows ADAS systems to continue to be upgraded after the vehicle is sold. Infotainment is already largely a computing function with specific edge peripherals (speakers, microphones, displays), so it is also logical to include the processing of infotainment data in the HPC cluster.

Arguments against in-vehicle HPC generally fall into two categories: complexity/risk and system cost. Both can be addressed by leveraging strategies successfully implemented in other industries. HPC hardware, while varying in capabilities, is a known technology in the data center. Server ODMs are readily available to provide hardware design services, and many automotive Tier 1 suppliers have already invested in HPC system capabilities to support emerging OEM requirements.

Using existing hardware architectures enables OEMs to focus on ADAS application software development and application delivery. To reduce software complexity, manufacturers of ADAS components such as computing systems-on-chip (SoCs) and network switches are extending their software to offload the development burden from OEMs or system integrators. This enables system developers to focus on system integration and strategy rather than dealing with algorithms or low-level drivers.

Optimized hardware with superior cost structures is being developed at multiple levels of the supply chain, both for existing Level 2 systems and for planned Level 3 systems. Using standardized and common software in HPC architectures reduces development costs for OEMs and enables scalability across vehicle platforms. It also significantly reduces the risk of recalls due to software bugs caused by unique software stacks developed for one-off vehicle feature sets or platforms.

Historically, automakers have had one-time financial transactions with customers. There is no after-sales revenue, except through service and repair centers. With the advent of SDVs, another factor in the cost-benefit equation is whether the system can generate additional revenue after the sale, and whether that revenue has a significant impact on the OEM’s financial performance.

The mobile phone industry has created a reusable model for developing and distributing applications that enhance and personalize products for consumers. Most importantly, the industry has benefited financially from a large number of software developers whose products are often valuable only to a small fraction of consumers but when combined create a large product for a much larger number of customers.

The automotive industry does not yet allow third-party functional development in the form of apps, although a small number of apps are available from various OEMs. For liability reasons, separation of certain control functions must be ensured. However, in the case of cruise control, throttle access has been successfully demonstrated in vehicle systems and only needs to be implemented in a controlled manner within the HPC architecture.

To date, the development of new features/applications for vehicles has been primarily the responsibility of automotive OEMs, whose software development processes are neither designed nor optimized to support small groups of consumers. Offering a broad range of additional vehicle applications and generating revenue from consumers with specific interests or tastes requires the creation of an “app store” that can be used by developers and consumers, with access to standard functional interfaces within HPC systems.

As an example of a possible function that is neither ADAS nor infotainment, a vehicle with the ability to collect sensor data could use that data to track, monitor, and analyze wear and tear on parts (such as suspension systems) and make predictions about service. These predictions could be based on the results of advanced anomaly detection algorithms that identify trends.