As the car continues to move from hardware-driven to software-controlled devices, competition rules in the automotive industry are changing dramatically.
The engine was the technological and engineering core of the 20th century automobile. Today, this role is increasingly played by software, large computing power and modern sensors; most of the innovations are connected with all this. Everything depends on these things, from the efficiency of cars, their access to the Internet and the possibility of autonomous driving, ending with electric mobility and new mobile solutions.
However, along with the importance of electronics and software, their level of complexity is also growing. Take, for example, the growing number of lines of code (SLOC) contained in modern cars. In 2010, some cars had about ten million SLOCs; by 2016, this figure increased by 15 times and amounted to approximately 150 million lines of code. The avalanche-like complexity causes serious problems with the quality of the software, as evidenced by numerous reviews of new cars.
Cars have an increased level of autonomy. Therefore, people working in the automotive industry consider the quality and safety of software and electronics to be key requirements for ensuring the safety of people. The automotive industry needs to rethink modern approaches to software, as well as to electrical and electronic architecture.
Solving an acute industry problem
As the automotive industry moves from hardware-driven to software-controlled devices, the average number of software and electronics on a vehicle is growing rapidly. Today, software accounts for 10% of the total vehicle content for a larger segment D or larger car (approximately $ 1,220). The average share of software is expected to grow by 11%. It is predicted that by 2030 software will account for 30% of the total contents of cars (about $ 5200). Unsurprisingly, people involved in one stage or another of car making are trying to capitalize on innovations implemented with software and electronics.
Software companies and other digital players no longer want to be in the background. They are trying to attract automakers as first-tier suppliers. Companies are expanding their participation in the “stack” of automotive technology through a shift from features and applications to operating systems. At the same time, companies accustomed to working with electronic systems boldly enter the field of application of technologies and applications from technical giants. Premium car manufacturers are not standing still and are developing their own operating systems, hardware abstractions and signal processing methods so that their products are unique in nature.
The above strategy has consequences. In the future, we are waiting for a service-oriented architecture (SOA) of the vehicle based on common computing platforms. Developers will add a lot of new things: solutions in the field of providing access to the Internet, applications, artificial intelligence elements , advanced analytics and operating systems. The differences will not be in the traditional car hardware, but in the user interface and in the work with software and advanced electronics.
Cars of the future will move to a platform of new brand competitive advantages.
Most likely, they will include infotainment innovations, autonomous driving capabilities and intelligent safety features based on “fault-tolerant” behavior (for example, a system that can perform its key function, even if part of it fails). The software will continue to move down the digital stack to become part of the hardware under the guise of smart sensors. Stacks will become horizontally integrated and will receive new levels that will translate the architecture into SOA.
Fashion trends are changing the rules of the game. They affect software and electronic architecture. These trends determine the complexity and interdependence of technology. For example, new smart sensors and applications will create a “data boom” in the vehicle . If car companies want to stay competitive, they need to process and analyze data efficiently. Modular SOA updates and wireless updates (OTA) will be key requirements for supporting sophisticated fleet software. They are also very important for the implementation of new business models in which functions appear on demand. Infotainment systems and, to a lesser extent, advanced driver assistance systems (ADAS) will be used more and more. The reason is that there are more and more third-party application developers who provide products for vehicles.
Due to digital security requirements, a conventional access control strategy is no longer interesting. It's time to move on to an integrated security concept designed to predict, prevent, detect, and protect against cyber attacks. When highly automated driving capabilities (HADs) are available, we need functional convergence, superior computing power and a high degree of integration.
Studying ten hypotheses about future electrical or electronic architecture
The development path for both technology and the business model has not yet been clearly defined. But based on our extensive research and expert opinions, we have developed ten hypotheses regarding the future electrical or electronic architecture of the car and its consequences for the industry.
Increasingly, the consolidation of electronic control units (ECU / ECU) will be carried out.
Instead of many specific ECUs for specific functions (as in the current model in the style of “add a function, add a window”), the industry will switch to the integrated architecture of a car ECU.
At the first stage, most of the functionality will be focused on the integrated domain controllers. For the domains of the main vehicles, they will partially replace the functionality that is now available in distributed ECUs. Development is already underway. We are waiting for the finished product in the market in two to three years. Consolidation is likely to occur on stacks associated with the ADAS and HAD functions, while more basic vehicle functions may retain a higher degree of decentralization.
We are moving towards autonomous driving. Therefore, virtualization of software functions and abstracting from hardware will become simply necessary. This new approach can be implemented in different ways. You can combine hardware into stacks that meet different requirements with respect to latency and reliability. For example, you can take a high-performance stack that supports the functionality of HAD and ADAS, and a separate time-controlled stack with low latency for basic security functions. Or you can replace the computer with one backup "supercomputer." Another possible scenario is when we completely abandon the concept of a control unit in favor of a smart computer network.
The changes are due primarily to three factors: costs, new market participants and demand for HAD. Reducing the cost of developing features and the necessary computing equipment, including communications equipment, will speed up the consolidation process. The same can be said about new participants in the automotive market, which are likely to undermine the industry with a program-oriented approach to car architecture. The growing demand for HAD functions and redundancy will also require a higher degree of ECU consolidation.
Some premium automakers and their suppliers are already actively participating in ECU consolidation. They are taking the first steps to update their electronic architecture, although at the moment there is no prototype yet.
The industry will limit the number of stacks used for specific equipment
Consolidation tracking normalizes stack constraints. It will allow you to separate the functions of the vehicle and the hardware of the computer, which includes the active use of virtualization. The hardware and firmware (including the operating system) will depend on the basic functional requirements, and not on a part of the functional domain of the vehicle. To ensure separation and service-oriented architecture, you need to limit the number of stacks. The following are the stacks that can become the basis for future generations of cars in 5-10 years:
- Time driven stack. In this domain, the controller is directly connected to the sensor or to the actuator, while systems must support stringent requirements in real time and at the same time have a low latency; resource planning is time-based. This stack includes systems that achieve the highest level of vehicle safety. An example is the classic automotive open source architecture domain (AUTOSAR).
- Stack driven by time and events. This hybrid stack combines high-performance security applications through, for example, ADAS and HAD support. Applications and peripherals are separated by the operating system, while applications are scheduled in time. Within an application, resource planning can be based on time or priority. The operating environment enables the execution of critical applications in insulated containers, clearly separating these applications from other applications in the vehicle. A good example is adaptive AUTOSAR.
- Event driven stack. This stack focuses on an infotainment system that is not critical to security. Applications are clearly separated from peripherals, and resources are planned using optimal or event-based planning. The stack contains visible and commonly used functions: Android, Automotive Grade Linux, GENIVI, and QNX. These functions allow the user to interact with the vehicle.
- Cloud stack. The last stack covers data access and coordinates it and the car's functions from the outside. This stack is responsible for communication, as well as for application security verification (authentication) and establishes a specific car interface, including remote diagnostics.
Car suppliers and technology manufacturers have already begun to specialize in some of these stacks. A striking example is the infotainment system (event-driven stack), where companies are developing communications capabilities - 3D and advanced navigation. A second example is artificial intelligence and sensing for high-performance applications, where suppliers team up with key automakers to develop computing platforms.
In a time-controlled domain, AUTOSAR and JASPAR support the standardization of these stacks.
Middleware will abstract applications from hardware
As vehicles continue to evolve towards mobile computing platforms, middleware will allow cars to be reconfigured, their software installed and updated. Now the middleware in each computer facilitates communication between devices. In the next generation of vehicles, it will associate a domain controller with access functions. Using in-car ECU hardware, middleware will provide abstraction, virtualization, SOA, and distributed computing.
There is already evidence that auto business representatives are moving towards more flexible architectures, including middleware. For example, the adaptive AUTOSAR platform is a dynamic system that includes middleware, support for a complex operating system, and modern multi-core microprocessors. However, the developments currently available are limited to only one computer.
In the medium term, the number of airborne sensors will increase significantly
In the next two to three generations of vehicles, car manufacturers will install sensors with similar functions to ensure that safety reserves are sufficient.
In the long run, the automotive industry will develop special sensor solutions to reduce their quantity and cost. We believe that combining radar and camera may be the most popular solution in the next five to eight years. As autonomous driving capabilities continue to grow, lidars will need to be introduced. They will provide redundancy both in the field of analysis of objects, and in the field of localization. For example, to configure an autonomous driving SAE International L4 (high automation) at the beginning, you probably need four to five lidar sensors, including those that will be installed at the back for navigation in the city and for visibility of almost 360 degrees.
In the long run, it’s hard to say anything about the number of sensors in vehicles. Either their number will increase, or decrease, or remain the same. It all depends on the regulations, technical maturity of decisions and the ability to use several sensors in different cases. Regulatory requirements may, for example, strengthen driver control, which will lead to an increase in the number of sensors inside the vehicle. It can be expected that more consumer electronics will be used in the car interior. Motion sensors, health monitoring (heart rate and drowsiness), face and iris recognition are just some of the possible uses. However, in order to increase the number of sensors or even leave everything as is, a broader list of materials will be required, not only in the sensors themselves, but also in the vehicle network. Therefore, it is much more profitable to reduce the number of sensors. With the advent of highly automated or fully automated vehicles, advanced algorithms and machine learning can increase the performance and reliability of sensors. Thanks to more powerful and functional touch technologies, extra sensors may no longer be needed. The sensors used today may become outdated - more functional sensors will appear (for example, ultrasonic sensors may appear instead of a parking assistant based on a camera or lidar).
Sensors get smarter
System architecture will need intelligent and integrated sensors to control the massive amounts of data that are needed for highly automated driving. High-level functions, such as combining sensors and three-dimensional positioning, will work on centralized computing platforms. Cycles of pre-processing, filtration and quick reaction are likely to be located at the border or run directly in the sensor itself. According to one estimate, the amount of data that an autonomous car will generate every hour is four terabytes. Consequently, artificial intelligence will move from the computer to the sensors for basic pre-processing. It requires low latency and low computational performance, especially if you compare the cost of processing data in sensors and the cost of transferring large amounts of data in a vehicle. The redundancy of road decisions in HAD, however, will require convergence for centralized computing. Most likely, these calculations will be calculated based on pre-processed data. Intelligent sensors will monitor their own functions, while redundancy of sensors will increase the reliability, availability and, therefore, the security of the sensor network. To ensure the correct operation of the sensor in any conditions, applications for cleaning the sensors will be required - anti-icing products and means for removing dust and dirt.
Full power and redundant data networks required
Key and safety-critical applications requiring high reliability will use fully redundant cycles for everything that is necessary for safe maneuvering (data transfer, power supply). The introduction of electromobile technologies , central computers, and energy-intensive distributed computing networks will require new redundant power management networks. Fail-safe systems that support wired control and other HAD functions will require the development of redundancy systems. This will significantly improve the architecture of modern failover monitoring implementations.
Automotive Ethernet will rise and become the backbone of the car
Modern car networks are not enough to meet the needs of future vehicles. Higher data rates, redundancy requirements for HAD, the need for security and protection in connected environments, and the need for cross-industry standardized protocols are likely to lead to the emergence of automotive Ethernet. It will become a key enabler, especially for a redundant central data bus. Ethernet solutions will be required to provide reliable cross-domain communication and meet real-time requirements. This will be possible thanks to the addition of Ethernet extensions such as Audio Video Bridging (AVB) and time-sensitive networks (TSN). Industry and OPEN Alliance support the adoption of Ethernet technology. Many car manufacturers have already taken this big step.
Traditional networks such as local interconnected networks and controller networks will continue to be used in the vehicle, but only for closed lower-level networks, for example, in sensors. Technologies such as FlexRay and MOST are likely to be replaced by automotive Ethernet and its extensions - AVB and TSN.
In the future, we expect the automotive industry to also use other Ethernet technologies - HDBP (high-delay bandwidth products) and 10-gigabit technologies.
OEMs will always strictly control data connectivity for functional security and HAD, but they will open interfaces so that third parties can access the data.
Central communication gateways that transmit and receive security-critical data will always be directly connected to the OEM backend. Access to data will be open to third parties when it is not prohibited by the rules. Infotainment is an "application" to the vehicle. In this area, emerging open interfaces will allow content providers and applications to deploy their products, while OEMs will adhere to standards as far as possible.
Today's on-board diagnostic port will be replaced by connected telematics solutions. Access to maintenance for the automotive network will no longer be required, but will be able to pass through OEM backends. OEMs will provide data ports at the rear of the vehicle for specific uses (tracking stolen vehicles or personal insurance). However, after-sale devices will have less access to internal data networks.
Large fleet operators will play a more important role in the user experience and will create value for end customers. They will be able to offer different vehicles for different purposes within the same subscription (for example, for daily trips to work or on weekends). They will require the use of server parts from various OEMs and the consolidation of data in their fleets. Then large databases will allow fleet operators to monetize consolidated data and analytics that are not available at OEM level.
Cars will use cloud services to combine on-board information with external data
“Insensitive” data (that is, data that is not associated with identity or security) will increasingly be processed in the cloud for more information. The availability of this data outside of the OEM will depend on future laws and agreements. As data volumes grow, data analytics will be impossible to do . Analytics are needed to process information and extract important data. We are committed to autonomous driving and other digital innovations. Data efficiency will depend on the exchange of data between several market players. It is still unclear who will do this and how. However, major car suppliers and technology companies are already creating integrated automotive platforms that can handle the new data set.
Updatable components will appear in cars that will support two-way communication
On-board test systems will allow cars to automatically check for updates. We will be able to control the life cycle of the car and its functions. All ECUs will send and receive data from sensors and actuators, extracting data. This data will be used in the development of innovations. An example is the construction of a route based on vehicle parameters.
The ability to upgrade OTA is a prerequisite for HAD. Thanks to these technologies, we will have new features, cybersecurity and a faster deployment of functions and software. In fact, it is the ability to update OTA that is the driving force behind many of the important changes described above. In addition, this feature also requires a comprehensive security solution at all levels of the stack - both outside the vehicle and inside the computer. This decision has yet to be developed. It is interesting to see who does this and how.
Will car updates be installed on a smartphone? Industries need to overcome limitations in supplier contracts, regulatory requirements, and security and privacy issues. Many carmakers have announced plans to roll out OTA service offerings, including wireless updates for their cars.
OEMs will standardize their fleets on OTA platforms, working closely with technology providers in this area. Vehicle connectivity and OTA platforms will soon become very important. OEMs understand this and are seeking more ownership in this market segment.
Vehicles will receive software updates and features, as well as security updates for their design life. Supervisory authorities are likely to provide software maintenance to ensure vehicle design integrity. The need to update and maintain software will lead to the emergence of new business models for the maintenance and operation of vehicles.
Assessment of the future impact of automotive software and electronic architecture
Trends affecting the automotive industry are generating serious hardware uncertainties. Nevertheless, the future of software and electronic architecture looks promising. All opportunities are open to the industry: car manufacturers could create industry associations to standardize vehicle architecture, digital giants could implement on-board cloud platforms, mobility players could produce their own vehicles or develop stacks of open source vehicles and features software, automakers could implement increasingly sophisticated autonomous machines, with the ability to connect to the Internet .
Products will soon cease to be hardware oriented. They will be software oriented. This transition will be difficult for automobile companies that are used to producing a traditional auto industry. Nevertheless, given the described trends and changes, even small companies will have no choice. They will have to prepare.
We see several key strategic steps:
- Separate vehicle development cycles and vehicle functions. OEMs and tier-one suppliers must decide how they will design, offer, and deploy features. They should be independent of vehicle development cycles, both from a technical and organizational point of view. Given the current vehicle development cycles, companies need to find a way to manage innovation in software. In addition, they should consider upgrading and updating options (such as computing units) for existing fleets.
- Define target value added for software and electronics development. OEMs must identify the distinctive features for which they can set breakpoints. In addition, it is extremely important to clearly define the target value added for their own software and electronics developments. You also need to identify areas in which products will be required and topics that should only be discussed with a supplier or partner.
- Set an explicit price for the software. To separate software from hardware, OEMs need to rethink internal processes and mechanisms in order to buy software directly. In addition to traditional customization, it is also important to analyze how a flexible approach to software development can be tied to the procurement process. Here suppliers (first level, second level and third level) also play a decisive role, since they need to give a clear business value to their program and system offers so that they can receive a large share of the income.
- Develop a specific organization scheme for the new electronics architecture (including backends). Auto industry representatives need to change internal processes for the supply and sale of advanced electronics and software. They also need to consider various organizational settings for electronic topics related to vehicles. Basically, the new "multi-level" architecture requires the potential destruction of the current "vertical" setting and the introduction of new "horizontal" organizational units. In addition, it is necessary to expand the capabilities and skills of software and electronics developers in teams.
- Develop a business model of the individual components of the vehicle as a product (especially for suppliers). It is imperative to analyze which functions add real value to the future architecture and therefore can be monetized. This will help you stay competitive and get a significant share of the value in automotive electronics. Subsequently, it will be necessary to find new business models for the sale of software and electronic systems, whether it is a product, service or something completely new.
When the new era of automotive software and electronics begins, it fundamentally changes everything about business models, customer needs and the nature of competition. We believe that it will be possible to earn a lot. But in order to capitalize on the impending change, all industry representatives must rethink their approach to auto manufacturing and intelligently establish (or change) their proposals.
This article was developed in collaboration with the Global Semiconductor Alliance.