As the automobile continues its transition from hardware-driven to software-driven devices, the rules of competition 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 filled by software, large computing power and modern sensors; most innovations are related to 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 electromobility and new mobility solutions.
However, along with the importance of electronics and software, their level of complexity also grows. Take as an example the growing number of lines of code (SLOC) contained in today's cars. In 2010, some cars had around ten million SLOCs; by 2016, this figure had increased 15 times and amounted to approximately 150 million lines of code. Snowballing complexity causes serious software quality issues, as evidenced by numerous new car reviews.
Machines have a higher 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 electrical and electronic architecture.
Solving an acute problem in the industry
As the automotive industry moves from hardware-driven to software-driven devices, the average amount of software and electronics on a vehicle is rapidly increasing. To date, software accounts for 10% of total vehicle content for a segment D or larger vehicle (approximately $1220). 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 content of cars (about $ 5200). It is not surprising that the people involved in one way or another of the creation of cars are trying to capitalize on the innovations implemented through software and electronics.
Software companies and other digital technology players no longer want to be on the sidelines. They are trying to attract automakers as first tier suppliers. Companies are expanding their participation in the automotive technology stack by moving from features and applications to operating systems. At the same time, companies accustomed to working with electronic systems are boldly entering the sphere of application of technologies and applications from tech giants. Premium car manufacturers are moving forward and developing their own operating systems, hardware abstractions, and signal processing techniques to make their products unique in nature.
The above strategy has implications. The future is a Service Oriented Architecture (SOA) vehicle based on common computing platforms. Developers will add a lot of new things: Internet access solutions, applications, , advanced analytics and operating systems. The differences will not be in the traditional hardware of the car, but in the user interface and in working with software and advanced electronics.
Cars of the future will move to a platform of new branded competitive advantages.
Most likely, they will include infotainment innovations, and intelligent safety features based on "fail-safe" behavior (for example, a system that is able to perform its key function even if part of it fails). 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 influence software and electronic architecture. These trends define the complexity and interdependence of technologies. For example, new smart sensors and applications will create . If car manufacturing companies want to stay competitive, they need to process and analyze data efficiently. Modular SOA upgrades and over-the-air (OTA) upgrades will be key requirements to support complex software in fleets. They are also very important for the implementation of new business models in which features appear on demand. Infotainment systems will be used more and more, and, to a lesser extent, advanced . The reason is that there are more and more third-party app developers that provide vehicle products.
Due to digital security requirements, the conventional access control strategy is no longer interesting. It's time to move on , designed to predict, prevent and detect cyber attacks, as well as protect against them. When highly automated driving (HAD) capabilities emerge, we will need functional convergence, superior computing power, and a high degree of integration.
Examining ten hypotheses about future electrical or electronic architecture
The path of development for both the technology and the business model is not yet clearly defined. But based on our extensive research and expert opinion, we have developed ten hypotheses about the future electric or electronic architecture of the car and its implications 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 “add a function, add a window” style model), the industry will move to a unified vehicle ECU architecture.
In the first phase, most of the functionality will be focused on federated domain controllers. For the main vehicle domains, they will partially replace the functionality currently available in distributed ECUs. Development is already underway. We are waiting for the finished product on the market in two or three years. Consolidation is most likely to occur in stacks related to 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 abstraction from hardware will become essential. This new approach can be implemented in different ways. It is possible to combine hardware into stacks that meet different requirements in terms of latency and reliability. Examples include a high-performance stack that supports HAD and ADAS functionality, and a separate, time-driven, low-latency stack for core security functions. Or you can replace the ECU with one backup "supercomputer". Another possible scenario is when we completely abandon the concept of a control unit in favor of a smart grid.
Changes are driven primarily by three factors: costs, new market entrants, and demand for HAD. Reducing the cost of feature development and required computing hardware, including communications hardware, will speed up the consolidation process. The same can be said for the new entrants in the automotive market, who are likely to disrupt the industry with a software-driven 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 involved in ECU consolidation. They are taking the first steps to update their electronic architecture, although there is no prototype yet.
The industry will limit the number of stacks used for specific equipment
Consolidation accompaniment normalizes the stack limit. It will allow to separate the functions of the vehicle and the ECU hardware, which includes the active use of virtualization. The hardware and firmware (including the operating system) will depend on the underlying functional requirements and not part of the vehicle's functional domain. To ensure separation and service-oriented architecture, you need to limit the number of stacks. The following are the stacks that could form the basis for future generations of cars in 5-10 years:
- A stack controlled by time. In this domain, the controller is directly connected to the sensor or to the actuator, while the systems must support stringent requirements in real time and at the same time have low latency; resource scheduling is time based. This stack includes systems that achieve the highest level of vehicle safety. An example is the Classic Automotive Open Systems Architecture Domain (AUTOSAR).
- A stack driven by time and events. This hybrid stack integrates high performance security applications through, for example, support for ADAS and HAD. Applications and peripherals are separated by the operating system, while applications are scheduled by time. Within an application, resource scheduling can be based on time or priority. The operating environment enables mission-critical applications to run in isolated containers, clearly separating those applications from other applications in the vehicle. A good example is adaptive AUTOSAR.
- An event-driven stack. This stack is focused on the infotainment system, which is not safety critical. Applications are clearly separated from peripherals, and resources are scheduled using best or event-based scheduling. The stack contains visible and commonly used features: Android, Automotive Grade Linux, GENIVI, and QNX. These features allow the user to interact with the vehicle.
- cloud stack. The last stack covers data access and coordinates it and car functions from the outside. This stack is responsible for communication, as well as application security checks (authentication) and establishes a specific automotive interface, including remote diagnostics.
Automotive suppliers and technology makers have already begun to specialize in some of these stacks. A prime example is the infotainment system (event-driven stack), where companies develop communication capabilities – 3D and advanced navigation. The second example is artificial intelligence and sensing for high performance applications, where vendors are teaming up with key automakers to develop computing platforms.
In a time-driven 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 vehicles to be reconfigured and their software installed and updated. Now middleware in each ECU facilitates communication between devices. In the next generation of vehicles, it will associate a domain controller with access functions. With the ECU hardware in the car, the middleware will provide abstraction, virtualization, SOA and distributed computing.
There is already evidence that the automotive business is moving towards more flexible architectures, including middleware. For example, the AUTOSAR adaptive platform is a dynamic system that includes middleware, complex operating system support, and modern multi-core microprocessors. However, the developments currently available are limited to only one ECU.
In the medium term, the number of onboard sensors will increase significantly
In the next two to three generations of vehicles, automakers will install sensors with similar functions to ensure that safety-related reserves are sufficient.
In the long term, the automotive industry will develop custom sensor solutions to reduce their number and cost. We believe that the combination of radar and camera may be the most popular solution in the next five to eight years. As the possibilities for autonomous driving continue to grow, it will be necessary to introduce lidars. They will provide redundancy both in the field of object analysis and in the field of localization. For example, a SAE International L4 (high automation) autonomous driving configuration will likely require four to five lidar sensors initially, including those mounted at the rear for city navigation and nearly 360-degree visibility.
It is difficult to say anything about the number of sensors in vehicles in the long term. Either their number will increase, or decrease, or remain the same. It all depends on the regulations, the technical maturity of the solutions and the ability to use several sensors in different cases. Regulatory requirements can, for example, increase control over the driver, which will lead to an increase in the number of sensors inside the vehicle. It can be expected that more consumer electronics sensors will be used in the vehicle interior. Motion sensors, health monitoring (heart rate and sleepiness), face and iris recognition are just some of the possible use cases. However, to increase the number of sensors or even leave everything as it is, a wider list of materials will be required, not only in the sensors themselves, but also in the network of vehicles. Therefore, it is much more profitable to reduce the number of sensors. With the advent of highly automated or fully automated vehicles, improved algorithms and machine learning can improve sensor performance and reliability. Thanks to more powerful and functional sensor technologies, extra sensors may no longer be needed. The sensors used today may become obsolete - 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 manage the vast amounts of data required for highly automated driving. High-level functions such as sensor fusion and XNUMXD positioning will run on centralized computing platforms. The pre-treatment, filtering and fast response cycles are likely to be at the boundary or run directly in the sensor itself. One estimate puts the amount of data an autonomous vehicle will generate every hour at four terabytes. Therefore, artificial intelligence will move from the ECU to the sensors to perform basic pre-processing. It requires low latency and low computational performance, especially when comparing the cost of processing data in sensors and the cost of transmitting large amounts of data in a vehicle. The redundancy of decisions made on the road in HAD, however, will require convergence for centralized computing. Most likely, these calculations will be calculated based on pre-processed data. Smart sensors will control their own functions, while sensor redundancy will increase the reliability, availability and therefore security of the sensor network. Sensor cleaning applications such as de-icing and dust and dirt removers are required to ensure that the sensor works properly in all conditions.
Requires full power and redundant data networks
Critical and safety-critical applications requiring high reliability will use fully redundant cycles for everything that is necessary for safe maneuvering (data transmission, power supply). , central computers and power-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 redundant systems. This will significantly improve the architecture of modern implementations of fault-tolerant monitoring.
"Automotive Ethernet" will rise and become the backbone of the car
Current automotive networks are not enough to meet the needs of future vehicles. Increased 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 automotive Ethernet. It will become a key enabler, especially for a redundant central data bus. Ethernet solutions will be required to provide reliable communication between domains and meet real-time requirements. This will be possible with the addition of Ethernet extensions such as Audio Video Bridging (AVB) and time-sensitive networks (TSN). The industry and the OPEN Alliance support the adoption of Ethernet technology. Many automakers 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 low-level closed networks, such as 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 such as 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 up interfaces so that data can be accessed by third parties.
Central communication gateways transmitting and receiving security-critical data will always connect directly to the OEM backend. Access to data will be open to third parties when it is not prohibited by the rules. Infotainment is an "attachment" to a vehicle. In this area, emerging open interfaces will allow content providers and applications to deploy their products while OEMs adhere to standards as much as possible.
Today's on-board diagnostic port will be replaced by connected telematics solutions. Maintenance access for the automotive network will no longer be required, but will be able to go through OEM backends. OEMs will provide data ports at the rear of the vehicle for specific use cases (tracking stolen vehicles or personal insurance). However, devices after the sale will have less and less access to internal data networks.
Large fleet operators will play a larger role in 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 commuting or weekend getaways). They will need to use server parts from different OEMs and consolidate data across their fleets. Larger databases would then allow fleet operators to monetize consolidated data and analytics not available at the OEM level.
Cars will use cloud services to combine on-board information with external data
"Insensitive" data (that is, data that is not related to identity or security) will increasingly be processed in the cloud to obtain additional information. The availability of this data outside of the OEM will be subject to future laws and arrangements. As volumes grow . Analytics is needed to process information and extract important data. We are committed to autonomous driving and other digital innovations. The efficiency of using data will depend on the exchange of data between several market players. It is still unclear who and how will do it. However, large automotive suppliers and technology companies are already creating integrated automotive platforms that can handle a new set of data.
Upgradable 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 manage 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 building a route based on vehicle parameters.
The ability to update OTA is a prerequisite for HAD. With these technologies, we will have new features, cybersecurity, and faster rollout of features 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 capability also requires a comprehensive security solution at all levels of the stack - both outside the vehicle and inside the ECU. This solution is yet to be developed. It will be interesting to see who does it and how.
Can updates be installed on cars like on a smartphone? The industry needs to overcome limitations in supplier contracts, regulatory requirements, and security and privacy concerns. Many automakers have announced plans to roll out OTA service offerings, including over-the-air updates for their vehicles.
OEMs will standardize their fleets on OTA platforms by 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 and feature updates, as well as security updates for their design life. Regulatory authorities will likely provide software maintenance to ensure the integrity of the vehicle's design. The need to update and maintain software will lead to new business models for the maintenance and operation of vehicles.
Assessing the future implications of automotive software and electronic architecture
The trends affecting the automotive industry are generating significant hardware-related uncertainties. Nevertheless, the future of software and electronic architecture looks promising. Opportunities are open to the industry: automakers could form industry associations to standardize vehicle architectures, digital giants could implement on-board cloud platforms, mobility players could build their own vehicles or develop open source vehicle stacks and features software, automakers could implement ever more sophisticated autonomous cars with Internet connectivity.
Products will soon stop being hardware-centric. They will be software oriented. This transition will be difficult for auto companies that are accustomed to producing the traditional auto industry. However, given the trends and changes described, even small companies will have no choice. They will have to prepare.
We see several major strategic moves:
- Separate vehicle development cycles and vehicle functions. OEMs and Tier XNUMX vendors must decide how they will develop, offer, and deploy features. They should be independent of vehicle development cycles, both technically and organizationally. Given current vehicle development cycles, companies need to find a way to manage software innovation. In addition, they should consider retrofit and upgrade options (such as compute units) for existing fleets.
- Determine the target value added for software and electronics development. OEMs must identify 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 where 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 their internal processes and mechanisms in order to buy software directly. In addition to traditional customization, it is also important to analyze how an agile approach to software development can be tied into the procurement process. Vendors (Tier XNUMX, Tier XNUMX, and Tier XNUMX) also play a critical role here, as they need to give clear business value to their software and system offerings so they can capture a larger share of the revenue.
- Develop a specific organization scheme for the new electronics architecture (including backends). The automotive industry needs to change internal processes to supply and sell advanced electronics and software. They also need to consider different organizational settings for electronic topics related to vehicles. Basically, the new "layered" architecture requires the potential destruction of the current "vertical" setup 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 for individual vehicle components as a product (especially for suppliers). It is critical to analyze which features add real value to the future architecture and therefore can be monetized. This will help you stay competitive and capture a significant share of the cost in automotive electronics. Subsequently, it will be necessary to find new business models for selling software and electronic systems, whether it be a product, a service, or something completely new.
As the new era of automotive software and electronics begins, it will dramatically change everything about business models, customer needs, and the nature of competition. We believe that it will be possible to earn a lot from this. But to capitalize on the coming change, everyone in the industry must rethink their approach to auto manufacturing and set (or modify) their offerings wisely.
This article was developed in collaboration with the Global Semiconductor Alliance.
Source: habr.com