Automotive evolution: SDV platforms with HPC

Several major trends are driving automotive innovation, including the evolution of vehicle automation from partial to full driving assistance, and the ability to implement security, in-vehicle infotainment (IVI) and vehicle performance features through complex software. These capabilities rely on a centralized, high-performance computing (HPC) architecture tailored to the automotive environment and delivered through a software-defined vehicle (SDV) platform.

The equivalent of a mobile data center, SDV platforms accept new software so automobiles can support a growing variety of revenue-generating features and capabilities while steadily progressing through the six levels of autonomy defined by the Society of Automotive Engineers (SAE).

State of automation

Most vehicle manufacturers currently implement Level 1 of the SAE’s six automation levels. This partial-automation level consists of discrete features delivered through an advanced driver-assistance system (ADAS), while Level 2 offers more sophisticated ADAS capabilities by combining features, such as adaptive cruise control and lane centering, that are more valuable to the driver and increase revenue margins for the automotive OEM.

At Level 1 and 2 of the SAE definitions, drivers are still considered to be driving the vehicle and retain responsibility for the safety of the passenger and vehicle. OEMs are now planning the transition to Level 3 (in which the driver conditionally relinquishes responsibility for controlling the vehicle to the ADAS system) and even Level 4 (in which these hand-over conditions are further reduced).

These are substantial steps. An example of a Level 3 capability is the “traffic-jam chauffeur” in which the vehicle drives itself but the driver must be prepared to take control. With Level 4, the conditions may be eliminated and all control is given to the vehicle. Figure 1 shows how the SAE levels are defined and implemented.

Figure 1: SAE’s six levels of driving automation define hands-on/-off features and requirements. They are enabled through technologies ranging from cameras and sensors and associated data to data logging and cloud connectivity. (Source: Microchip Technology)

Moving from Level 2 to Level 3 or 4 requires that the vehicle be given adequate sensory perception as well as algorithmic processing capabilities or even artificial intelligence so that it can autonomously navigate its route. The vehicle must also be able to identify who or what is responsible for driving the vehicle at any given moment and under the given conditions, then operate accordingly.

In addition to protecting the safety of the car and passenger at all levels of the SAE automation evolution, vehicle manufacturers must continue to create a great IVI experience that, increasingly, is delivered to the vehicle much like smartphone apps are. The number of apps and high-value content-streaming services for the vehicle is growing alongside the steady evolution of driver automation.

Other capabilities are also being delivered through sophisticated software, including security updates and a variety of vehicle-handling, acceleration and emissions enhancements. Facilitating these software additions through the SDV concept ensures that vehicles can be upgraded throughout their lifetime, but this cannot be accomplished with the majority of today’s Level 1 and 2 in-vehicle ADAS systems, which use dedicated, function-specific hardware modules.

Without a software-definable platform that can accept enhanced software, ADAS systems can perform only the functions for which they were designed, and there is little or no ability to upgrade features. Today’s SDV platforms offer the additional benefit of replacing today’s extremely complex and power-hungry architecture for supporting what can be up to 100 electronic control units (ECUs) and their collective 100 million lines of software code or more.

A better way to manage ECUs while enabling the SDV

Transforming vehicles into data centers on wheels not only supports the SDV concept but also provides a better way to manage the growing variety of ECUs used for engine, transmission, traction, anti-lock braking and airbag control, as well as those for climate control, windows and seat controls, among others.

This rapid expansion of ECUs has been driven by growing demand for vehicle performance and feature innovations, but it generates an astounding increase in software code—as much as 7× that of a commercial airliner—that needs to be distributed throughout the vehicle. The architecture that has been used to accomplish this is not particularly energy-efficient, nor is it compute-efficient, as most ECUs perform a single task and cannot be upgraded.

The SDV’s HPC architecture includes a variety of powerful CPU capabilities for general-purpose computing applications as well as specialized functions, such as video processing (Figure 2).

Figure 2: The SDV architecture combines HPC, high-speed interfaces for edge sensor connection, cloud connectivity and support for real-time updates. (Source: Microchip Technology)

SDV computing functions can be added at any point in the life of the vehicle, which will have a significant impact on traditional vehicle depreciation rates. Older vehicles can be updated to include features otherwise available only on newer vehicles, as long as both cars have compatible HPC clusters.

Adding to the attractiveness of the SDR approach, the data feed from a modern vehicle’s radar, vision cameras, LiDAR, accelerometers, GPS and other sensors that provide information about its surroundings can enable many safety, performance or entertainment tasks. New features that are added to the vehicle can also leverage this data and reside in the HPC alongside existing ADAS and infotainment features.

When to expect HPC clusters

It is likely that HPC cluster implementation will coincide with the arrival of Level 3 and Level 4 automation, which requires a step-function increase in compute performance. But the earliest form of HPC implementation may arrive as a Level 2 ADAS feature (sometimes referred to as Level 2+) so that ADAS system upgrades can be offered after the sale of a vehicle. It is logical to include the processing of infotainment data within the HPC cluster, as it is already largely a compute function with speakers, microphones, displays and other specific edge peripherals.

Some argue against in-vehicle HPC over concerns that it will increase complexity/risk and system cost, but these issues have already been resolved in data centers and other applications. Server ODMs have ready access to hardware design services and many automotive Tier 1 suppliers are already supporting emerging OEM needs for HPC system capabilities. OEMs and system integrators can focus on ADAS application software development and application delivery using existing hardware architectures, with the option to reduce their development burden by taking advantage of the software that ADAS component suppliers offer with their compute system-on-chips (SoCs) and network switches. This allows them to focus on system integration and policy rather than processing algorithms or low-level drivers.

Meanwhile, the industry is developing optimized hardware with superior cost structures at many levels of the supply chain, across a range of both existing Level 2 systems and projected Level 3 systems. Component hardware optimized for automotive, which supports HPC architectures, includes high-performance image-processing SoCs originally developed for wireless devices and AI applications, PCIe interconnects from data centers for high-bandwidth, low-latency data sharing, and connectivity to the Ethernet in-vehicle network, now in use by almost all automotive OEMs.

Supporting standardized and common software within an HPC architecture reduces OEM development costs and enables scalability across vehicle platforms. Common software reduces recall risks by eliminating the software bugs caused by unique software stacks that are developed for a single vehicle feature set or platform.

Realizing SDV benefits

The advent of the SDV will bring an additional factor to an automotive OEM’s cost-benefit equation, which was traditionally predicated on the car manufacturer’s one-time financial transaction with customers with no opportunity for post-sale revenue other than through service and repair centers. Now, OEMs will be able to demonstrate how their solutions can generate additional after-sale revenue for the car manufacturer, as well as the extent to which this revenue is material to its financial results. And while initial revenue streams from upgrades or subscriptions may be small compared with vehicle revenue, the profitability is large and could have an outsize effect on bottom-line results.

With the ability to access a standard feature interface within an SDV’s HPC system, there is also the opportunity to create an “app store” model for developers and consumers that is similar to what exists in the mobile phone segment. This app store can contain a broad range of add-on vehicle applications that generate revenue from consumers with specific interests or tastes. As in the mobile phone segment, this approach leverages a vast number of software developers, each of whom may serve a small consumer segment but together deliver a huge number of offerings to an even larger user base.

A hypothetical example of this type of upgrade is a predictive-maintenance capability that enables servicing to be scheduled on a wear-and-tear basis rather than the traditional time- or mileage-based approaches. Vehicles with the necessary sensors could collect data from the suspension system, for instance, which could then be used to track and analyze system part conditions using advanced anomaly-detection algorithms and recommend when servicing should be scheduled. It may even be possible to make immediate adjustments to one or more operating parameters through a real-time software patch.

Rather than returning a car to the garage or certified service center for updates to these and other capabilities via a data cable or, in some cases, through USB ports, it will be possible to implement them over the air (OTA) as standard practice. The same approach can be used for safety, emissions or performance recalls, with the potential to substantially reduce OEM costs.

The arrival of SDV platforms that easily incorporate new OTA software features will enable cars to evolve from products whose key attributes are handling, power, speed and looking to data centers on wheels that deliver an increasingly personalized overall in-cabin experience. The ability to deliver this experience through featured upgrades and third-party apps will redefine the automobile manufacturer business model that until now was based on a one-time sales event. Instead, it will be possible to realize long-term returns on hardware investments, especially as SDVs with connectivity to OEM servers via the cloud create opportunities to introduce subscription-based and application-download business models.