Within the framework of SAE International’s (formerly the Society of Automotive Engineers) six levels of automation, most vehicle manufacturers currently implement the partial driving automation capabilities of Level 1 (discrete features) and Level 2 (combined features). OEMs globally are engineering the transition to level 3 or even level 4 (conditional driving automation) – and it’s a big step.
Compared to Level 1 Advanced Driver Assistance Systems (ADAS) features, Level 2 features provide an increase in feature sophistication, for example, adaptive cruise control combined with lane centering. These features truly assist the driver and represent high-margin revenue opportunities for automotive OEMs. Despite the increased performance of Level 2 features, the driver is still considered to be driving the vehicle and retains responsibility for passenger and vehicle safety.
Beginning with Level 3 systems, the driver conditionally relinquishes responsibility to the ADAS system. One example is the ‘traffic jam chauffeur,’ where the vehicle will drive itself through congestion. Because it is conditional automation the driver must still be prepared to take control of the vehicle. With Level 4, the conditions under which the driver must take control are further reduced, in some cases to the point of completely giving over control to the vehicle.
To transition from Level 2 to Level 3 or 4, a significant technological leap is required to provide the vehicle with sufficient sensory perception and algorithmic processing or even Artificial Intelligence (AI), to successfully navigate the driving environment and differentiate between who or what is responsible for driving the vehicle.
SAE’s six levels of driving automation. SAE INTERNATIONAL
Higher Stakes
When developing systems for Levels 3 or 4, the result is that the safety of the passenger is determined to a much greater degree by the efficacy of the manufacturer’s ADAS system. These systems will either be praised or criticized for their reliability and trustworthiness. This in turn will either boost or damage the reputation of the vehicle model and its manufacturer.
However, safety is only one of the issues affecting vehicle sales and success. Vehicle manufacturers have to maintain and build upon their reputation for in-vehicle infotainment (IVI). Modern IVI systems are similar to a smartphone and use apps to provide useful, compelling, and engaging content. The number of apps and content streaming services to the vehicle is growing, as will the level of driver automation.
Many features of new cars, including safety, infotainment, and vehicle performance (handling, acceleration, emissions) are increasingly the result of complex software. This has given rise to the concept of the Software-Defined Vehicle (SDV), where such a vehicle can be upgraded throughout its lifetime, enhancing existing functions and adding new ones. However, the great majority of today’s in-vehicle systems use dedicated hardware modules and are function specific.
This includes virtually all newer Level 1 and Level 2 ADAS systems. Systems that are not software-definable and lack the ability to accept enhanced software are destined to perform only the functions for which they were designed. They thus offer limited or no ability for the manufacturer to upgrade vehicle features. True implementation of “Software Defined” requires implementation of hardware that has the ability to accept new software. It is software-definable features that create the potential to generate new revenue streams throughout the life of the consumer’s vehicle investment.
The Data Center on Wheels
A modern vehicle typically has as many as 100 Electronic Control Units (ECUs) which, between them, may include up to 100 million lines of software code (as a comparison, a commercial plane has about 14 million). The vehicle’s main ECUs are for engine, transmission, traction, anti-lock braking, and airbag control. Those providing lesser roles will encompass climate control, windows, and seat controls, for example.
This high number of ECUs, and their distribution around the vehicle, makes for a very complex architecture. This architecture is not particularly power efficient, neither in the sense of energy consumption nor in the sense of compute power, since the majority of these ECUs cannot be upgraded or used for any purpose other than the task they were designed to perform. The steady innovation in vehicle performance and features is behind the proliferation of ECU-based systems. However, moving toward a “Software Defined Vehicle”, which may primarily be a set of feature enhancements, requires a move towards a centralized, high-performance computing (HPC) architecture, with some automotive-specific additions.
An SDV can thus be thought of as a mobile data center with an HPC at its heart. Because the HPC includes a variety of powerful CPU capabilities, supporting both general purpose and specialized (e.g., video processing) computing, functions can be added years after the vehicle leaves the production line, which will reduce the rate at which vehicles have historically depreciated. Features that are enabled by software and are present on a brand-new vehicle can be added to older vehicles, assuming a compatible HPC cluster.
The SDV of tomorrow will be a data center on wheels with high performance computing at its heart and high-speed interfaces to connect to edge sensors. As a platform, the SDV will have cloud connectivity and be able to accept real-time updates. MICROCHIP TECHNOLOGIES
On the periphery of a vehicle there will be components such as smart sensors, which may perform edge processing, but as their use case is generally narrow, the need to update these with software is less relevant. Further, a move toward centralized processing may negate the need for much edge compute power in the vehicle, depending on the cost of bandwidth to move raw data compared to the cost of pre-processing data. radar, vision cameras, lidar, accelerometers, and GPS are all sensors that provide a vehicle information about its surroundings.
The data feed from these sensors can enable a variety of safety, performance, or entertainment tasks, and could be utilized by a new feature added to the vehicle. That feature, along with existing ADAS and infotainment features, would reside in the HPC.
Because Level 3 and Level 4 automation require a step-function increase in compute performance, it is logical for HPC cluster implementation to coincide with the introduction of those systems. Implementation of HPC with Level 2 ADAS features (sometimes referred to as Level 2+, though there is no such SAE definition) enables ADAS system upgrades to be offered post vehicle sale. Infotainment is already largely a compute function with specific edge peripherals (speakers, microphones, displays) and thus it is also logical to include the processing of infotainment data within the HPC cluster.
The arguments against in-vehicle HPC usually fall into two categories: complexity/risk and system cost. Both can be addressed by utilizing strategies successfully implemented in other industries. HPC hardware, though varied in features, is a known technology in data centers. Hardware design services are readily available from server ODMs, and many automotive Tier 1 suppliers have already invested in HPC system capabilities in order to support emerging OEM needs.
Use of 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 compute System-On-Chips (SoCs) and network switches are expanding their software to remove the burden of development from the OEM or system integrator. This enables the system developer to focus on system integration and policy, rather than processing algorithms or low-level drivers.
Optimized hardware with superior cost structures is in development at many levels of the supply chain, both for existing Level 2 systems and projected Level 3 systems. The use of standardized and common software within an HPC architecture reduces development costs for the OEM and enables scalability across vehicle platforms. It also greatly reduces the risk of recalls due to software bugs caused by unique software stacks developed for one-time vehicle feature set or platform.
Historically automotive manufacturers engage in a one-time financial transaction with their customers. No post-sale revenue is available except through service and repair centers. With the advent of the SDV, an additional factor in the cost-benefit equation is whether the system can generate additional revenue post sale, and whether that revenue is material to the financial results of the OEM.
The mobile phone segment has created reusable models for the development and distribution of applications (apps) that enhance and personalize their products for consumers. Most importantly, that industry benefits financially from a vast number of software developers whose products are often valuable to a very narrow set of consumers, but when taken together, result in a huge number of offerings to an even larger number of customers.
The auto industry has yet to enable third-party feature development in the form of apps, though a small number of apps from various OEMs are available. Due to liability, the separation of certain control capabilities must be ensured. However, using cruise control as an example, the successful implementation of throttle access by in-vehicle systems has already been proven, and just remains to be implemented in a controlled manner within an HPC architecture.
Generation of new features/applications for vehicles has to date remained largely the domain of vehicle manufacturers, whose software development processes are neither designed nor optimized to support narrow groups of consumers. To provide a broad range of add-on vehicle applications and generate revenue from consumers with specific interests or tastes will require the creation of an “app store” available to developers and consumers and the ability to access a standard feature interface within an HPC system.
As an example of a possible feature that is neither ADAS nor infotainment, vehicles with the ability to collect sensor data could use the data to track, monitor, and analyze the wear and tear of parts (e.g., suspension system) and make predictions about service. These predictions can be based on the results of advanced anomaly detection algorithms that recognize developing trends.
Maintenance can then be scheduled on a wear-and-tear basis rather than the traditional time- or mileage-based approaches. Immediate adjustment to one or more operating parameters may even be possible through a real-time software patch.
The ability of OEMs to charge for feature upgrades via software is already standard practice in some cases. Upgrades today typically require returning the vehicle to a garage, where the transfer takes place via a data cable. However, some examples of user upgrades through USB ports can already be found.
Over-The-Air updates are set to become the norm for future software upgrades. Compared with current requirements to perform upgrades in a certified service center, OTA upgrades for safety, emissions, or performance recalls offer substantial opportunities to reduce OEM costs, assuming the initial vehicle contains appropriate hardware to support OTA upgrades, as well as a way to enable new features.
Summary
Advanced driver assistance systems are a critical element of automotive design. In addition to delivering safety, automotive manufacturers are looking to build further on ADAS capabilities, taking vehicles to ever higher levels of autonomy in the interests of both safety and ease of use. This, plus user expectations of infotainment, personalization, and user experience, mean that cars are evolving from products that have traditionally been defined in terms of handling, power, speed, and looks, to being defined by their in-cabin experience and their ability to be augmented through featured upgrades and 3rd party apps.
To provide the requisite levels of performance/safety and market-differentiating features, vehicles are becoming software-defined, HPC data centers on wheels. This transition is leading manufacturers to approach cost models differently as some hardware investments will enable longer-term returns.
The automotive sector has historically seen the sale of every vehicle as having a one-off return, one that covers the CapEx of development and manufacturing to hit profit and business growth goals. SDVs with connectivity to OEM servers via the cloud, open opportunities to introduce subscription-based and application download models.