As cars evolve from hardware-driven machines to software-driven electronic products, the competitive landscape of the automotive industry is being rewritten. In the 20th century, the engine was the technological and engineering core of the automobile, but today, powerful computing power and advanced sensors are increasingly playing such roles. They enable innovative solutions to become a reality, from efficiency, connectivity and autonomous driving to electrification and new mobility solutions.
However, as the importance of electronics and software increases, complexity also increases. For example, the number of lines of software code (SLOC) inside a car has grown exponentially, from millions of lines in some cars in 2010 to approximately 150 million lines in 2016, resulting in serious software quality problems, as evidenced by recent recalls of millions of vehicles.
As vehicles move towards providing increasingly sophisticated levels of automation, automakers are also treating software quality and security as key requirements for ensuring vehicle safety, which has prompted the industry to re-think the design of vehicle software and electrical architectures.
An Urgent Industry Problem
The entire industry is undergoing a transition from hardware-defined to software-defined vehicles, with the average amount of software and electrical components in each vehicle growing rapidly.
Today, software represents about 10% of the entire structure of a D-class or large vehicle (about $1,200 USD), with this proportion expected to experience a compound annual growth rate of 11%, reaching 30% (about $5,200 USD) by 2030.
It’s therefore no surprise that every player in the digital automotive value chain wants a piece of the innovation brought about by these software and electronic technologies (Figure 1). Software and other digital technology companies are jumping from their original second- and third-tier supplier positions to become first-tier suppliers to automakers. They are expanding their involvement in the automotive technology stack, moving from providing features and apps to operating systems.
Meanwhile, traditional first-tier electronic system suppliers are boldly venturing into the territory of functions and apps occupied by technology giants, while high-end car manufacturers are moving into lower levels of this “stack,” such as operating systems, simplified hardware, and signal processing. They need to defend their technological uniqueness and advantages.
One of the consequences of this strategic move is that the vehicle architecture will become a service-oriented SOA based on a general computing platform. Developers can integrate new connectivity solutions, applications, AI elements, advanced analytics, and operating systems. Therefore, differentiation in the future will not be based on hardware as in traditional cars, but on software and UI/UX empowered by advanced electronics.
The car of tomorrow will turn to a platform that incorporates new differentiating factors (Figure 2). These factors may include innovative information entertainment, autonomous driving capabilities, and intelligent safety features based on “run-fail” (i.e., the system can still perform critical tasks despite partial malfunctions). Software will gradually move down the layer of digital technology and integrate with hardware in the form of intelligent sensors. The “stacks” will be horizontally integrated to form a new level that transforms the vehicle architecture into SOA.
Ultimately, the new software and electronic architecture will bring about new trends that change the rules of the game and drive up complexity and interdependence.
For instance, these new intelligent sensors and applications will bring about a “data explosion” in vehicles, and manufacturers will need to be more efficient in processing and analyzing this data to remain competitive;
Module-based SOA and OTA updates will become key conditions for managing fleet complex software and functions on demand (function-on-demand) business models;
Information entertainment and low-level ADAS will be further “appified” as more third-party developers provide content;
The requirement for data security will shift from focusing on pure access control policies to integrating security concepts that can predict, prevent, detect, and defend against network attacks;
The advent of highly automated driving (HAD) will require integration, high computational power, and high integration degree.
Ten assumptions about the future electronic and electrical architecture
Considering the uncertain future of technology and business models, we have made ten assumptions about the future automotive electronic and electrical architecture based on extensive research and expert opinions and analyzed their implications for the industry.
Multiple ECUs will be integrated
The automotive industry will move towards integrated ECU architecture rather than a large number of specific ECUs corresponding to specific functions (i.e., the current mode of simply adding a box when a new function is added).In the first step, most of the functionalities will be concentrated in the main vehicle domain integrated domain controller. These controllers will partially replace the functionalities currently running in different distributed ECUs.
This development has already begun and will be introduced into the market within the next two to three years. This integration is particularly suitable for the technological hierarchy related to ADAS and HAD functions, while basic vehicle functions may continue to remain decentralized.
In the evolution towards autonomous driving, software function virtualization and hardware abstraction will become more urgent. This new approach can be achieved in several different forms.
One way is to merge hardware into “stacks” with different requirements for latency and reliability, such as a high-performance stack that supports HAD and ADAS functions, as well as an independent, time-driven low-latency stack used for basic safety functions.
Another way is to replace the ECUs with a redundant “supercomputer.”
In the third scenario, the concept of control units is completely abandoned in favor of supporting a smart node computing network.
There are three driving factors behind these changes: cost, new market entrants, and demand for HAD functionality. First, cost reduction will accelerate the integration of the above-mentioned functionalities, including functional development, computing hardware, and communication hardware. The disruptive impact of software-oriented vehicle architecture brought about by new players in the automotive field will also have the same effect. The demand for HAD functionality and increasing redundancy also requires higher integration of ECUs.
Some high-end automakers and their suppliers have already taken active measures to integrate ECUs and upgrade the electronic architecture, although clear industry standards have not yet emerged.
The automotive industry will limit the number of stacks used for specific hardware
Along with integration, there will be standardization of stack limitations, separating vehicle functions from ECU hardware and improving virtualization. Hardware and embedded firmware (including operating systems) will be dependent on key non-vehicle functional conditions rather than being assigned as part of the vehicle functional domain. To achieve such separation and SOA architecture, the following four stacks may become the basis of next-generation vehicles within the next five to ten years:
-
Time-driven stack. In this domain, controllers are directly connected to sensors and actuators, and the system must support strict real-time requirements and low-latency time. Resource scheduling is based on time. This stack includes systems that achieve the highest level of automotive safety integrity, such as AUTOSAR (Automotive Open System Architecture).- Stack of Events/Time-Driven: This hybrid stack combines high-performance secure applications, such as those that support ADAS and HAD. Applications and peripherals are separated by the operating system, and application scheduling is based on time or priority for resource allocation within the application. The operating environment ensures that important safety-critical applications run independently in isolated containers, with the self-adaptive AUTOSAR being an example.
-
Event-Driven Stack: This stack centers on information and entertainment systems, which are not critical for safety. Applications and peripherals are explicitly separated, and scheduling and resource allocation follow a strategy based on optimization or event-driven policies. The user-visible and commonly used functions in this stack are the medium that enables interactions between users and the vehicle, such as Android, Automotive Grade Linux, GENIVI, and QNX.
-
Cloud Stack (Off-Board): The last type of stack is responsible for coordinating the retrieval and use of data from outside the vehicle. This stack is responsible for communication, as well as security and protection for applications, including authentication. It establishes a defined interface for the vehicle, which includes remote diagnostics.
Suppliers and technology providers have begun to establish their expertise in the above stacks. Notably, in the event-driven stack, companies are pushing the expansion of human-vehicle communication capabilities, such as 3D or augmented reality navigation. Another example is the introduction of artificial intelligence and sensors in high-performance applications, with key suppliers partnering with major automakers on developing computation platforms.
In the time-driven domain, AUTOSAR and JASPAR are supporting the standardization of the time-driven stack.
The expanded middleware layer will abstract applications from hardware.
Vehicles are constantly evolving into mobile computing platforms, and middleware will enable the reconfiguration of vehicles, as well as the installation and upgrade of software. Unlike the middleware within each different ECU today, which only deals with inter-unit communication, the middleware layer running above ECU hardware in the next generation of vehicles will be the link that provides access to domain controllers. It will implement abstraction and virtualization, SOA, and distributed computing.
There is already evidence that automakers are working towards flexible architectures, which include an overall middleware. For example, AUTOSAR’s adaptive platform is a dynamic system that includes middleware, support for complex operating systems, and state-of-the-art multicore microprocessors. However, this development is currently limited to individual ECUs.### Mid-term, the number of sensors in vehicles will increase rapidly
In the next two to three generations of automotive products, manufacturers will ensure sufficient redundancy in safety by installing multiple sensors with similar functions (see Figure 3). However, in the long run, the automotive industry will inevitably develop unique sensors to reduce the number of sensors and related costs.
We believe that in the next five to eight years, a combination of radar and cameras will dominate, and as autonomous driving capabilities gradually improve, the introduction of lidar will become necessary for ensuring redundancy in object analysis and localization.
As an example of SAE’s L4 (advanced automatic) autonomous driving, initial implementation of L4 may require four to five lidars, including a rear-mounted lidar for city operation and nearly 360-degree visibility (see Figure 3).
In the long term, there will be different situations with regards to the number of vehicle sensors: continued increase, stable number, or decrease. Which situation will actually happen depends on regulatory requirements, the maturity of different solutions, and the ability of using multiple sensors in different use cases. In terms of regulations, if driver monitoring is required to be strengthened, the number of sensors in-car will inevitably increase.
It is foreseeable that consumer electronic sensors will begin to be used in automotive interiors. Motion sensors, health monitoring for heart rate and fatigue, facial recognition, iris tracking, and more are just a few of the potential use cases. Of course, as the number of sensors increases or stays stable, the corresponding material costs will also increase, not just the cost of the sensors themselves, but also the in-car network, so reducing the number of sensors can bring significant cost savings.
With the advent of advanced autonomous driving or fully autonomous driving, future advanced algorithms and machine learning technologies will enhance the performance and reliability of sensors, and the number of redundant sensors may be reduced with stronger and higher-performance sensor technology. The sensors currently in use may become obsolete due to their functions being replaced by high-performance sensors (for example, a parking assistant function based on cameras or lidars may replace ultrasonic sensors).
Sensors will become more intelligent
The requirements of system architecture determine that intelligent and integrated sensors need to exist to manage and process the massive amounts of data required for advanced autonomous driving. Advanced functions such as sensor fusion or 3D positioning will need to run on a centralized computing platform, but preprocessing, filtering, rapid response, and more will be done more around or directly within sensors.Estimates suggest that an autonomous car will generate 4TB of data per hour. Therefore, intelligence will gradually shift from ECUs to sensors, with basic, low-latency, and low-computational pre-processing done by sensors. Processing data within the sensors should be preferred to transmitting massive amounts of data to and from the vehicle, especially when considering data processing costs. Additionally, HAD driving decision redundancy will require centralized computational power, most likely based on pre-processed data. Intelligent sensors will self-monitor their own functionalities and redundant sensors will help to improve reliability, availability, and safety of the sensor network. Moreover, a new type of sensor cleaning schemes and applications, such as de-icing and dust-proofing capabilities, will be necessary to ensure proper sensor operation in different conditions.
Redundancy in power and data networks will be a must-have for high-reliability, key safety applications, and similar applications that will leverage the entire redundancy loop to achieve complete security, such as data transmission and power supply. Electric vehicle technology, central computers, and distributed computing networks with high power demands will demand new redundant power management networks. Fault-tolerant operation systems that support wire-controlled steering and other HAD features will require redundant system designs and will be a huge improvement over the present fault safety monitoring architecture.
The current vehicle network is insufficient to meet the needs of future vehicles. The increase in HAD data rates and redundancy requirements, as well as the security and assurance needs of connected environments, and the demand for standardization protocols within the industry, will likely lead to the emergence of automotive Ethernet, especially for redundant central data buses. Ethernet solutions will need to ensure reliable inter-domain communication and meet real-time requirements through the addition of Ethernet extensions, such as Audio-Video Bridging (AVB) and Time-Sensitive Networking (TSN). Industry stakeholders and the OPEN Alliance support the adoption of Ethernet technology, and many car manufacturers have made significant progress in this area. Traditional networks, such as Local Interconnect Network and Controller Area Network, will continue to be used within the vehicle, but only for closed low-level networks, such as sensor and actuator locations. Technologies like FlexRay and MOST are likely to be replaced by automotive Ethernet and its extensions, AVB and TSN.
We expect the automotive industry to embrace future Ethernet technologies, such as High-Delay Broadband Products (HDBP) and 10 Gigabit technology, if they continue to evolve. OEMs will always strictly control data connections used for functional safety and HAD but will develop interfaces for third-party access to the data.The central connectivity gateway for sending and receiving critical data will always connect directly to the OEM backend, and except for designated requirements, third parties may access data through them. However, with the trend of vehicle “APP-ification” driving information entertainment, new open interfaces have emerged to allow content and application providers to deploy content. The OEM will maintain corresponding standards as much as possible.
The vehicle diagnostic port from today will be replaced by the connected car solution. Physical maintenance of the vehicle network will no longer be required but can be maintained through the OEM backend. OEMs will provide data ports on their vehicle backends for specific use cases, such as lost vehicle tracking or individual insurance. However, access to the vehicle internal data network by aftermarket equipment will become increasingly rare.
Fleet operation will play a more powerful role in user experience and create value for end customers, such as providing different vehicles for different purposes in a set of services (such as weekends or daily commutes). This requires them to use the backends of different OEMs and start integrating their fleet data. Subsequently, larger databases will allow fleet operators to realize the integration and analysis of data sets that are not available at the OEM level.
Cars will combine onboard information with external data through the cloud. Although the data available to vendors outside the OEM will depend on future regulation and related negotiations, handling the ever-increasing amount of non-sensitive data (i.e. non-personal or safety-related data) in cloud computing will lead to deeper insights.
As the amount of data grows, data analysis becomes crucial for processing information and turning it into actionable knowledge. The effectiveness of using data to achieve autonomous driving and other digital innovations depends on data sharing among multiple players. Although it is still unclear how or by whom this will be accomplished, major traditional suppliers and technology suppliers are already building integrated automotive platforms that can handle this new data.
Car testing systems will allow cars to automatically check the functions and integrate updates, achieving lifecycle management and enhancing or unlocking aftermarket product functions. 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 updates are a prerequisite for highly automated driving (HAD); they will also drive major changes in vehicle architecture and enable automakers to deploy functions and software faster while ensuring network security. In fact, the OTA update function is the driving force behind many of the major changes in vehicle architecture introduced earlier.
Moreover, OTA also requires an end-to-end security solution from each layer of the external stack to the ECUs in the vehicle. This security solution is still to be designed, and who will do it and how it will be done will be very interesting to observe.To achieve the upgradability of smartphones, the industry needs to overcome restrictions from dealerships contracts, regulatory requirements, as well as safety and privacy issues. Various car manufacturers have announced plans to deploy OTA services, including wireless updates for their vehicles.
OEMs will standardize their fleets on OTA platforms and work closely with technology providers in the field. As vehicle connectivity and OTA platforms become increasingly important, we can expect OEMs to gain more ownership in this niche market.
Vehicles will receive software and feature upgrades while also getting security updates for their design lifespan. Regulatory agencies may mandate software maintenance to ensure the safety integrity of vehicle designs. These updates and software maintenance tasks will lead to new business models for vehicle maintenance and operation.
Assessing the Future Impacts on Automotive Software and Electronic Architecture
The trends that are impacting today’s automotive industry bring a great deal of uncertainty to hardware-related content, and it seems that the disruptive potential for software and electronic architecture is not much lesser.
Many strategic initiatives are possible: automakers can choose to form industry alliances to standardize and streamline vehicle architectures, digital industry giants can introduce in-vehicle cloud platforms, mobility service providers can build or develop open-source vehicle stacks and software functionalities, while automakers can introduce increasingly complex connected and self-driving cars.
For traditional automotive companies, the transition from hardware-centric products to software-driven service-oriented industries is particularly challenging. However, given the trends and changes described in this article, no one in the automotive industry has any other choice but to prepare themselves. We see several major strategic forces at work:
-
Decoupling the development cycle of vehicles and their functions. OEMs and Tier 1 suppliers must determine how to develop, provide, and deploy functions from both technological and organizational perspectives, most of which are outside the vehicle development cycle. Given the current development cycle of automobiles, companies need to find a way to manage software innovation. Furthermore, they should think about creating transformation and upgrade solutions (such as computational units) for existing fleets.
-
Defining the value added to software and electronic product development. OEMs must identify characteristics that can form a differentiation control point. Also, defining the goal of the added value of their software and electronic product development is critical, and finding an area that can form a commodity or topic that only one supplier or partner can achieve is just as important.- Attach a clear price tag to the software. Detaching software from hardware means that OEMs need to reconsider their internal processes and mechanisms for purchasing software separately. In addition to the traditional settings, it is also important to analyze how agile software development methods can be fixed during the procurement process. Here, suppliers (first, second, and third tiers) also play a crucial role, as they need to provide clear commercial value for their software and system products to gain a greater share of revenue.
-
Design a specific organization (including relevant back-end) around the new electronic architecture. Industry players (OEMs and suppliers) should also consider setting up a new, separate organization for vehicle electronics-related topics, in addition to changing internal processes to deliver and sell advanced electronics and software. Primarily, the new “layered” architecture may break the current “vertical” process and introduce new “horizontal” organizational units. Also, they need to enhance the specialized capabilities and skills of their software and electronic development teams.
-
Design a business model around car features as products (especially for car suppliers). To maintain competitiveness and obtain a share in the automotive electronics field, it is crucial to analyze which functions add practical value to future architectures and can be monetized. Subsequently, players need to introduce new business models for sales of software and electronic systems, whether as products, services, or entirely new things.
As the new era of automotive software and electronics begins, it is fundamentally changing various business models, customer demands, and competitive nature in the industry’s established determinacy. We are optimistic about the revenues and profits that will be built. However, to benefit from the transformation, all industry participants need to rethink and carefully position (or reposition) their value propositions in the new environment.
McKinsey Note: This article was developed in cooperation with the Global Semiconductor Alliance.
Original article: Ondrej Burkacky, Johannes Deichmann, Georg Doll, and Christian Knochenhauer
Translated by: Jiahe Hu
Click here to view the original article.
* McKinsey: How Will the Electric Vehicle Market Achieve Scale and Profitability?
- McKinsey: We Disassembled 10 Best-Selling Electric Cars and Revealed the Top 5 Manufacturing Experiences
- McKinsey: How Vehicle Manufacturers Can Take Advantage of the New Opportunity of Shared Mobility
markdown
This article is a translation by ChatGPT of a Chinese report from 42HOW. If you have any questions about it, please email bd@42how.com.