A brief discussion on the technical difficulties currently faced by decoupling autonomous driving software and hardware

"In the context of the era of software-defined cars, the status of software is getting higher and higher, and the development of the smart car industry requires the decoupling of software and hardware."

Words like the above must be familiar to everyone. In the past few years of the development of smart cars, the composition of the automotive supply chain has undergone earth-shaking changes, and the decoupling of software and hardware has become a key issue for both OEMs and suppliers. Find a way to solve the problem.

However, standards are still difficult to unify, and the interfaces of each company are still different. Even after so many years, software and hardware decoupling still faces many difficulties.

one. Background of software and hardware decoupling

01 Evolution of EE architecture

(Readers who are familiar with this topic can skip it and go directly to the next section)

A few years ago, there were only a dozen to twenty ECUs in a vehicle. However, as electronic entertainment consumerism continues to invade all aspects of people's lives, people's functional requirements for cars have gradually increased. In the distributed architecture, In the background, each new function requires the corresponding ECU to be continuously added. This is especially true for self-driving cars. As a result, the number of ECUs on a self-driving car has grown to nearly one or two hundred at most.

The continuous increase of ECUs has caused the total length and total cost of wire harnesses for data transmission to continue to increase (according to Zos Automotive Research's calculations, if the current distributed architecture is continued, the cost of the wire harness for autonomous vehicles will not be less than US$1,000) , the difficulty of supplier management has also increased.

In addition, under the distributed architecture, functions such as ACC and AEB are bound to the sensor (MCU in the medium) and are separated from each other (this is not in line with first principles, and this is not the case when people drive). The requirement for high-level autonomous driving is that each function is an organism, so it needs to be implemented through the same SoC.

Against this background, how to improve space utilization and maximize ECU performance in a limited space has become the next development direction in the industry. As a result, the automotive EE architecture opened the door to evolve from a distributed architecture to a centralized architecture. To this end, domain controllers were born, many ECUs began to be replaced by domain controllers, and the main control chip was upgraded from the previous MCU to SoC.

The number of ECUs continues to decrease, and the remaining ECUs in the car have also transformed from being responsible for part of the calculations to being "screws" that only need to bear most of the execution functions and have weakened processing capabilities (ECUs still have the original ability to process calculations, but functionally It is no longer needed to handle some calculations).

The evolution of EE architecture from distributed to domain-centralized and SoC replacing MCU have created prerequisites for the automotive industry to move from the era of "hardware is king" to the era of "software-defined cars" across domains.

The SoC chip integrates multiple modules such as DSP, GPU, and NPU. It not only has a control unit but also integrates a large number of computing units. This allows SoC chips to not only multi-task concurrently, but also have the ability to process large amounts of data. Replacing some MCUs with SoC chips is like replacing ordinary leaders of multiple departments of a company with a super-excellent CEO who can equal one to a hundred.

In an era where hardware is king, due to the high degree of coupling between software and hardware, OEMs will first find a consulting company to do an analysis report on vehicle functional requirements for the next 5-8 years, and then formulate a 5-8 year software and hardware integration plan based on the report. plan. When the software and hardware are put into production line production, until the vehicle manufacturer has installed various components and shipped the vehicle, it will be difficult for the vehicle to change in either software or hardware within 5-8 years.

In the era of software-defined cars, if we still follow the original integration process of the car factory and set a 5-8 year car manufacturing plan at once, then the problem will not be too prominent in the first few years of vehicle manufacturing, but during this plan time In the second half of the range, a car is delivered to the user, and both the hardware and software on the car are far out of date.

Therefore, during the product design stage, subsequent iteration issues should be considered. To solve the iteration problem, software and hardware must be developed separately.

When the hardware configurations of various car manufacturers have converged, the hardware has become "rollable". In order to achieve differentiation, OEMs need to be able to collect the changing needs of users with very fast response capabilities and carry out corresponding software iterations. . At this time, OEMs have two options: one is to self-develop software and algorithms and solve all problems by themselves, including decoupling software and hardware; the other is to find a suitable supplier to provide iteration requirements after decoupling software and hardware.

If you want to take the first path, the OEMs need to be very strong, but not all OEMs have such capabilities, so most OEMs will prefer to take the second path. As a result, the status of software algorithm companies began to improve, and the automotive supply chain relationship changed from the original clear Tier1, Tier2, and Tier3 to a relationship with blurred boundaries.

In this context, there is also a need for software and hardware decoupling among various software and hardware suppliers for stronger competitiveness, better independent development, and a better cooperative ecology.

However, although the slogan of software and hardware decoupling has been shouted for several years, the effect is not ideal.

02 Difficulty in decoupling sensors, chips and algorithms

Since algorithms and sensors are highly bound, in practical applications, such binding causes a lot of trouble to algorithm engineers. For example, after the camera previously used in a car is changed from a 2-megapixel one to an 8-megapixel one, the algorithm must not be rewritten.

In addition, a Tier1 algorithm engineer:

“Even if it is possible to decouple the sensing algorithm from the sensor, it is particularly difficult to calibrate the sensor after decoupling.”

Due to the high degree of coupling between software and hardware, sensor data is also highly bound to the sensor. Once the sensor is replaced, all the previously expensive data annotations will be invalidated, and a new round of collection will have to be started. This is very important to the algorithm. It is a very troublesome matter for the company, but there is currently no good solution to this matter.

In addition, the sensor configuration, installation position, and installation angle on each vehicle are different, so the algorithms are also different. The sensing algorithms are different, and the control algorithms are different.

If the decoupling of algorithms and sensors is just troublesome, then the decoupling of algorithms and chips is very difficult.

For example, when the author communicated with many algorithm engineers about issues related to software and hardware decoupling, I found that one of the common pain points they all shared was that a lot of extra work was required due to the difficulty of algorithm transplantation.

This is due to the fact that the frequency of algorithm migration is unpredictable. The competition and product iterations of chip manufacturers often affect market preferences. You can't be sure whether there will be new and better chips selling hot in the next trend.

Changes in market preferences will cause OEMs to specify replacement chips. At this time, for algorithm engineers, maybe your algorithm based on this chip has just been improved, and there will be new algorithm transplant requirements.

The reason for the above phenomenon is the strong binding relationship between the algorithm and the chip. Different chips provide different BSPs, which makes it difficult to reuse the middleware used to decouple chips and algorithms, and different customized adaptations must be made for different chips.

The person in charge of the intelligent driving system of a certain OEM explained:

"The adaptation of the middleware to the lower BSP layer is quite troublesome. For example, the cockpit chip uses Qualcomm's 8155 or 8295, and the autonomous driving chip uses TI's TDA4, so because their chips provide different BSPs, the integration Then you need to make customized adaptations to the middleware.”

Not only do differences in chip platforms prevent middleware from being reused, but also two domain controllers based on the same chip platform have different hardware architectures (some domain controllers have 2 or even 3 SoCs). The needs are also different.

2. Technical difficulties faced by software and hardware decoupling

Middleware is the most important tool required to achieve software and hardware decoupling. Therefore, the problem of software and hardware decoupling will be concentrated on middleware. 

In fact, the current middleware needs to be customized according to the function, hardware platform, and operating system. Even the most highly standardized middleware requires algorithm companies or OEMs to adapt it. It is difficult to say that there is a middleware that can cover Accommodation has everything. Because all middleware will have some limitations or restrictions, for example, some cannot quickly define communication interfaces, some are not particularly friendly to some cross-platform support, and some do not match well on other chips.