The engine was the technology and engineering core of the 20th-century automobile. Today, software, large computing power, and advanced sensors increasingly step into that role; they enable most modern innovations, from efficiency to connectivity to autonomous driving to electrification and new mobility solutions.
Fique em dia com seus tópicos favoritos
However, as the importance of electronics and software has grown, so has complexity. Take the exploding number of software lines of code (SLOC) contained in modern cars as an example. In 2010, some vehicles had about ten million SLOC; by 2016, this expanded by a factor of 15, to roughly 150 million lines. Snowballing complexity is causing significant software-related quality issues, as evidenced by millions of recent vehicle recalls.
With cars positioned to offer increasing levels of autonomy, automotive players see the quality and security of vehicle software and electronics as key requirements to guarantee safety. And this is requiring the industry to rethink today’s approaches to vehicle software and electrical and electronic architecture.
Addressing an urgent industry concern
As the automotive industry is transitioning from hardware- to software-defined vehicles, the relevance of software for core technology trends is increasing rapidly. Not surprisingly, players across the digital automotive value chain are attempting to capitalize on innovations enabled through software and electronics (Exhibit 1). Software companies and other digital-technology players are leaving their current tier-two and tier-three positions to engage automakers as tier-one suppliers. They’re expanding their participation in the automotive technology “stack” by moving beyond features and apps into operating systems. At the same time, traditional tier-one electronic system players are boldly entering the tech giants’ original feature-and-app turf, and premium automakers are moving into areas further down the stack such as operating systems, hardware abstractions, and signal processing in order to protect the essence of their technical distinction and differentiation.
One consequence of these strategic moves is that the vehicle architecture will become a service-oriented architecture (SOA) based on generalized computing platforms. Developers will add new connectivity solutions, applications, artificial-intelligence elements, advanced analytics, and operating systems. The differentiation will not be in the traditional vehicle hardware anymore but in the user-interface and experience elements powered by software and advanced electronics.
Tomorrow’s cars will shift to a platform of new brand differentiators (Exhibit 2). These will likely include infotainment innovations, autonomous-driving capabilities, and intelligent safety features based on “fail-operational” behaviors (for example, a system capable of completing its key function even if part of it fails). Software will move further down the digital stack to integrate with hardware in the form of smart sensors. Stacks will become horizontally integrated and gain new layers that transition the architecture into an SOA.
Ultimately, the new software and electronic architecture will result out of several game-changing trends that drive complexity and interdependencies. For example, new smart sensors and applications will create a “data explosion” in the vehicle that players need to handle by processing and analyzing the data efficiently if they hope to remain competitive. A modularized SOA and over-the-air (OTA) updates will become key requirements to maintain complex software in fleets and enable new function-on-demand business models. Infotainment, and, to a lesser degree, advanced driver-assistance systems (ADAS), will increasingly become “appified” as more third-party app developers provide vehicle content. Digital-security requirements will shift the focus from a pure access-control strategy to an integrated security concept designed to anticipate, avoid, detect, and defend against cyberattacks. The advent of highly automated driving (HAD) capabilities will require functionality convergence, superior computing power, and a high degree of integration.
Mastering automotive software-launch excellence
Exploring ten hypotheses on future electrical or electronic architecture
The path forward for both the technology and the business model is far from fixed. But based on our extensive research and insights from experts, we developed ten hypotheses regarding tomorrow’s automotive electrical or electronic architecture and its implications for the industry.
There will be an increasing consolidation of electronic control units (ECUs)
Instead of a multitude of specific ECUs for specific functionalities (the current “add a feature, add a box” model), the industry will move to a consolidated vehicle ECU architecture.
Would you like to learn more about Automotive & Assembly Practice?
In the first step, most functionality will be centered on consolidated domain controllers for the main vehicle domains that will partially replace functionality currently running in distributed ECUs. These developments are already under way and will hit the market in two to three years' time. This consolidation is especially likely for stacks related to ADAS and HAD functionality, while more basic vehicle functions might keep a higher degree of decentralization.
In the evolution toward autonomous driving, virtualization of software functionality and abstraction from hardware will become even more imperative. This new approach could materialize in several forms. One scenario is a consolidation of hardware into stacks serving different requirements on latency and reliability, such as a high-performance stack supporting HAD and ADAS functionality and a separate, time-driven, low-latency stack for basic safety features. In another scenario, the ECU is replaced with one redundant “supercomputer,” while in a third, the control-unit concept is abandoned altogether in favor of a smart-node computing network.
The change is driven primarily by three factors: costs, new market entrants, and demand through HAD. Decreasing costs, both for the development of features as well as the required computing hardware, including communication hardware, will accelerate the consolidation. So too will new market entrants into automotive that will likely disrupt the industry through a software-oriented approach to vehicle architecture. Increasing demand for HAD features and redundancy will also require a higher degree of consolidation of ECUs.
Several premium automakers and their suppliers are already active in ECU consolidation, making early moves to upgrade their electronic architecture, although no clear industry archetype has emerged at this point.
The industry will limit the number of stacks used with specific hardware
Accompanying the consolidation will be a normalization of limited stacks that will enable a separation of vehicle functions and ECU hardware that includes increased virtualization. Hardware and embedded firmware (including the operating system) will depend on key nonvehicle functional requirements instead of being allocated part of a vehicle functional domain. To allow for separation and a service-oriented architecture, the following four stacks could become the basis for upcoming generations of cars in five to ten years:
- Time-driven stack. In this domain, the controller is directly connected to a sensor or actuator while the systems have to support hard real-time requirements and low latency times; resource scheduling is time based. This stack includes systems that reach the highest Automotive Safety Integrity Level classes, such as the classical Automotive Open System Architecture (AUTOSAR) domain.
- Event- and time-driven stack. This hybrid stack combines high-performance safety applications, for example, by supporting ADAS and HAD capability. Applications and peripherals are separated by the operating system, while applications are scheduled on a time base. Inside an application, scheduling of resources can be based on time or priority. The operating environment ensures that safety-critical applications run on isolated containers with clear separation from other applications within the car. A current example is adaptive AUTOSAR.
- Event-driven stack.This stack centers on the infotainment system, which is not safety critical. The applications are clearly separated from the peripherals, and resources are scheduled using best-effort or event-based scheduling. The stack contains visible and highly used functions that allow the user to interact with the vehicle, such as Android, Automotive Grade Linux, GENIVI, and QNX.
- Cloud-based (off-board) stack. The final stack covers and coordinates access to car data and functions from outside the car. The stack is responsible for communication, as well as safety and security checks of applications (authentication), and it establishes a defined car interface, including remote diagnostics.
Automotive suppliers and technology players have already begun to specialize in some of these stacks. Notable examples are in infotainment (event-driven stack), where companies are developing communications capabilities such as 3-D and augmented navigation. A second example is artificial intelligence and sensing for high-performance applications, where suppliers are joining with key automakers to develop computing platforms.
In the time-driven domain, AUTOSAR and JASPAR are supporting the standardization of these stacks.
An expanded middleware layer will abstract applications from hardware
As vehicles continue to evolve into mobile computing platforms, middleware will make it possible to reconfigure cars and enable the installation and upgrade of their software. Unlike today, where middleware within each ECU facilitates communication across units, in the next vehicle generation it will link the domain controller to access functions. Operating on top of ECU hardware in the car, the middleware layer will enable abstraction and virtualization, an SOA, and distributed computing.
Evidence already suggests automotive players are moving toward more flexible architectures, including an overarching middleware. AUTOSAR’s adaptive platform, for example, is a dynamic system that includes middleware, support for a complex operating system, and state-of-the-art multicore microprocessors. However, current developments appear restricted to a single ECU.
In the middle term, the number of onboard sensors will spike significantly
In the next two to three vehicle generations, automakers will install sensors with similar functionalities to ensure that sufficient safety-related redundancies exist (Exhibit 3). In the long term, however, the automotive industry will develop specific sensor solutions to reduce the number of sensors used and their costs. We believe that a combined solution of radar and camera might be dominant for the next five to eight years. As autonomous-driving capabilities continue to rise, the introduction of lidars will be necessary to ensure redundancy for both object analysis and localization. Configurations for SAE International L4 (high automation) autonomous driving, for example, will likely initially require four to five lidar sensors, including rear-mounted ones for city operation and near-360-degree visibility.
In the long term, we see different possible scenarios concerning the number of sensors in vehicles: further increase, stable numbers, or decrease. Which scenario will come to pass depends on regulation, the technical maturity of solutions, and the ability to use multiple sensors for different use cases. Regulatory requirements might, for example, enforce closer driver monitoring, resulting in an increase of sensors inside the vehicle. It can be expected that more consumer-electronics sensors will be used in the automotive interior. Motion sensors and health monitoring of measures such as heart rate and drowsiness, as well as face recognition and iris tracking, are just a few of the potential use cases. However, as an increase or even a stable number of sensors would require a higher bill of materials, not only in the sensors themselves but also in the vehicle network, the incentive to reduce the number of sensors is high. With the arrival of highly automated or fully automated vehicles, future advanced algorithms and machine learning can enhance sensor performance and reliability. Combined with more powerful and capable sensor technologies, a decrease of redundant sensors can be expected. Sensors used today might become obsolete as their functions are overtaken by more capable sensors (for instance, a camera- or lidar-based parking assistant could replace ultrasound sensors).
Sensors will become more intelligent
System architectures will require intelligent and integrated sensors to manage the massive amounts of data needed for highly automated driving. While high-level functions such as sensor fusion and 3-D positioning will run on centralized computing platforms, preprocessing, filtering, and fast reaction cycles will most likely reside in the edge or be done directly in the sensor. One estimate puts the amount of data an autonomous car will generate every hour at four terabytes. Consequently, intelligence will move from ECUs into sensors to conduct basic preprocessing requiring low latency and low computing performance, especially if weighting costs for data processing in the sensors versus costs for high-volume data transmission in the vehicle. Redundancy for driving decisions in HAD will nevertheless require a convergence for centralized computing, likely based on preprocessed data. Intelligent sensors will supervise their own functionality while redundancy of sensors will increase reliability, availability, and hence safety of the sensor network. To ensure correct sensor operation in all conditions, a new class of sensor-cleaning applications—such as deicing capabilities and those for dust or mud removal—will be required.
Full power and data-network redundancy will be necessary
Safety-critical and other key applications that require high reliability will utilize fully redundant circles for everything that is vital to safe maneuvering, such as data transmission and power supply. The introduction of electric-vehicle technologies, central computers, and power-hungry distributed computing networks will require new redundant power-management networks. Fail-operational systems to support steer-by-wire and other HAD functions will require redundancy system designs, which is a significant architectural improvement on today’s fail-safe monitoring implementations.
The ‘automotive Ethernet’ will rise and become the backbone of the car
Today’s vehicle networks are insufficient for the requirements of future vehicles. Increased data rates and redundancy requirements for HAD, safety and security in connected environments, and the need for interindustry standardized protocols will most likely result in the emergence of the automotive Ethernet as a key enabler, especially for the redundant central data bus. Ethernet solutions will be required to ensure reliable interdomain communication and satisfy real-time requirements by adding Ethernet extensions like audio-video bridging (AVB) and time-sensitive networks (TSN). Industry players and the OPEN Alliance support the adoption of Ethernet technology, and many automakers have already made this leap.
Traditional networks such as local interconnected networks and controller area networks will continue to be used in the vehicle, but only for closed lower-level networks, for instance, in the sensor and actor area. Technologies such as FlexRay and MOST are likely to be replaced by automotive Ethernet and its extensions, AVB and TSN.
Going forward, we expect the automotive industry to also embrace future Ethernet technologies such as high-delay bandwidth products (HDBP) and 10-gigabit technologies.
OEMs will always tightly control data connectivity for functional safety and HAD but will open interfaces for third parties to access data
Central connectivity gateways transmitting and receiving safety-critical data will always connect directly and exclusively to an OEM back end, available to third parties for data access, except where obliged by regulation. In infotainment, however, driven by the “appification” of the vehicle, emerging open interfaces will allow content and app providers to deploy content, while OEMs will keep the respective standards as tight as possible.
Today’s on-board diagnostics port will be replaced with connected telematic solutions. Physical maintenance access to the vehicle network will not be required anymore but can go through the OEMs’ back ends. OEMs will provide data ports in their vehicle back end for specific use cases such as lost-vehicle tracking or individualized insurance. Aftermarket devices, however, will have less and less access to vehicle internal data networks.
Large fleet operators will play a stronger role in the user experience and will create value for end customers, for example, by offering different vehicles for different purposes under one subscription (such as weekend or daily commute). This will require them to utilize the different OEMs’ back ends and start consolidating data across their fleets. Larger databases will then allow fleet operators to monetize consolidated data and analytics not available on the OEM level.
Cars will use the cloud to combine onboard information with offboard data
Nonsensitive data (that is, data that are not personal or safety related) will increasingly be processed in the cloud to derive additional insights, though availability to players beyond OEMs will depend on future regulation and negotiations. As the volumes of data grow, data analytics will become critically important for processing the information and turning it into actionable insights. The effectiveness of using data in such a way to enable autonomous driving and other digital innovations will depend on data sharing among multiple players. It’s still unclear how this will be done and by whom, but major traditional suppliers and technology players are already building integrated automotive platforms capable of handling this new plethora of data.
Cars will feature updateable components that communicate bidirectionally
Onboard test systems will allow cars to check function and integration updates automatically, thus enabling life-cycle management and the enhancement or unlocking of aftersales features. All ECUs will send and receive data to and from sensors and actuators, retrieving data sets to support innovative use cases such as route calculation based on vehicle parameters.
OTA update capabilities are a prerequisite for HAD; they also will enable new features, ensure cybersecurity, and enable automakers to deploy features and software quicker. In fact, it’s the OTA update capability that is the driver behind many of the significant changes in vehicle architecture described previously. In addition, this capability also requires an end-to-end security solution across all layers of the stack outside the vehicle to the ECUs in the vehicle. This security solution remains to be designed, and it will be interesting to see how and by whom this will be done.
To achieve smartphone-like upgradability, the industry needs to overcome restrictive dealer contracts, regulatory requirements, and security and privacy concerns. Here too, a variety of automotive players have announced plans to deploy OTA service offerings, including over-the-air updates for their vehicles.
Facing digital disruption in mobility as a traditional auto player
OEMs will standardize their fleets on OTA platforms, working closely with technology providers in this space. As vehicle connectivity and OTA platforms will become increasingly mission critical, we can expect OEMs to take more ownership in this market segment.
Vehicles will receive software and feature upgrades as well as security updates for the designed life span. Regulators will likely enforce software maintenance to ensure the safety integrity of the vehicle designs. The obligation to update and maintain software will lead to new business models for maintenance and operations of vehicles.
Assessing the future implications of vehicle software and electronic architecture
While the trends affecting the automotive industry today are generating major hardware-related uncertainties, the future looks no less disruptive for software and electronic architecture. Many strategic moves are possible: automakers could create industry consortia to standardize vehicle architecture, digital giants could introduce onboard cloud platforms, mobility players could produce their own vehicles or develop open-source vehicle stacks and software functions, and automakers could introduce increasingly sophisticated connected and autonomous cars.
The transition from hardware-centric products to a software-oriented, service-driven world is especially challenging for traditional automotive companies. Yet, given the described trends and changes, there is no choice for anyone in the industry but to prepare. We see several major strategic pushes:
- Decouple vehicle and vehicle-functions development cycles. OEMs and tier-one suppliers need to identify how to develop, offer, and deploy features largely apart from vehicle-development cycles, both from a technical and organizational perspective. Given current vehicle-development cycles, companies need to find a way to manage innovations in software. Further, they should think about options to create retrofitting and upgrade solutions (for example, computing units) for existing fleets.
- Define the target value add for software and electronics development. OEMs must identify the differentiating features for which they are able to establish control points. In addition, it is crucial to clearly define the target value add for their own software and electronics development and to identify areas that become a commodity or topics that can only be delivered with a supplier or partner.
- Attach a clear price tag to software. Separating software from hardware requires OEMs to rethink their internal processes and mechanisms for buying software independently. In addition to the traditional setup, it is also important to analyze how an agile approach to software development can be anchored in procurement processes. Here suppliers (tier one, tier two, and tier three) also play a crucial role as they need to attach a clear business value to their software and system offerings to enable them to capture a larger revenue share.
- Design a specific organizational setup around new electronics architecture (including related back ends). Next to changing internal processes in order to deliver and sell advanced electronics and software, automotive players—both OEMs and suppliers—should also consider a different organizational setup for vehicle-related electronics topics. Mainly, the new “layered” architecture asks for potentially breaking up the current “vertical” setup and introducing new “horizontal” organizational units. Further, they need to ramp up dedicated capabilities and skills for their own software and electronics development teams.
- Design a business model around automotive features as a product (especially for automotive suppliers). To remain competitive and capture a fair share of value in the field of automotive electronics, it is crucial to analyze which features add real value to the future architecture and therefore can be monetized. Subsequently, players need to derive new business models for the sale of software and electronics systems, be it as a product, a service, or something completely new.
As the new era of automotive software and electronics begins, it’s drastically changing a wide variety of prior industry certainties about business models, customer needs, and the nature of competition. We are optimistic about the revenue and profit pools that will be created. But to benefit from the shifts, all players in the industry need to rethink and carefully position (or reposition) their value propositions in the new environment.
This article was developed in collaboration with the Global Semiconductor Alliance.
