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

Therefore, most chip manufacturers' self-developed middleware is very light and basically is demo middleware that can run on the chip to demonstrate the performance of the chip to customers. Such demo middleware will certainly not be of any substantial help in decoupling software and hardware.

03 OEM

For OEMs, there is always a need for middleware customization.

The person in charge of the intelligent driving system of a certain OEM gave an example:

"For example, when writing a traffic light recognition algorithm or a binocular vision algorithm, if you want to be different from traditional algorithms or competitors' algorithms, you need a set of customized middleware, which involves data subscription, sharing, recording, and playback of the middleware , sending, storage, diagnosis and other functions. However, these functions cannot be guaranteed to run perfectly under the system or functional mechanism required by the OEM, and conflicts may occur. In this case, middleware suppliers are required to help resolve them. "

However, compared to using middleware from third-party middleware companies or algorithm companies, some powerful OEMs are more willing to develop their own middleware.

First of all, purchasing closed-source middleware such as RTI's DDS often means customizing the middleware, which not only requires more expensive costs, but also the project docking cycle will be very long; in contrast, self-developed middleware It means that you can fully control the direction of customization, get your own data, and make the product unrestricted. This way you can better control the product development process and later transformation, and solve the problem of volume that may be caused by a certain middleware supplier dropping out of the chain. Product delivery delays.

Secondly, self-developed middleware can also form certain technical barriers for OEMs. For some powerful OEMs, some upper-layer application layers are completely in their own hands. They can make their own middleware according to the needs of their upper-layer applications and can better customize some middleware. Upper-layer applications can also make some features.

In fact, when middleware technology is not yet mature and future trends are not yet obvious, the reason why upstream and downstream players in the industry are making middleware is to test the boundaries of their own capabilities and to explore the boundaries of the entire industry.

However, many autopilot engineers from OEMs believe that “Compared with algorithm companies, OEMs’ self-developed middleware has little advantage.”

First of all, most OEMs do not have much accumulation in algorithm capabilities. The cost of setting up a team specifically to make middleware is huge, but the result may not be as good as that of a supplier that specializes in doing this. The pain caused by such consumption has far exceeded that of coordinating several suppliers. pain of. It's like the pain caused by one's weak projects will be more painful than the new challenges of one's strong projects.

Secondly, it is difficult for OEMs to obtain enough sample feedback for self-developed middleware, which is not conducive to product iteration. Suppliers' algorithms and middleware are used more by everyone, and as the customer base increases, the customer feedback rate on bugs will be higher, which is more conducive to product iterative progress; however, if the OEMs develop their own products and only supply the products to themselves, it will be easy There is a lack of sufficient sample data, so the iteration is slower.

In addition, if the OEM wants to develop its own middleware, it will inevitably have to recruit technical talents from other companies. However, for talents, working in a department of a large company, they may not have such a strong sense of mission. After all, there will always be a feeling that "the sky is falling, and there are still people above to hold it up", and in the end The result is that if the abilities of the recruited talents can be utilized at 80%, it would be considered ideal. But if the same technical talent goes out to work alone and the research is related to personal interests, he will definitely have greater pressure and motivation to do it well. In such an environment, he can often display more talents. .

Finally, for OEMs, self-developed middleware requires a large amount of talent to build a research team. Once it is found that this road cannot go on, such a large number of employees will face the risk of being laid off, and a large number of employees will be laid off. Layoffs will also increase the sentiment among current employees that "the company is unstable."  

From this point of view, the "self-developed middleware" of OEMs may more often be just a marketing slogan, but this does not mean that all OEMs' self-developed middleware cannot be successful. They are strong enough to successfully develop self-developed algorithms. The probability of success of the OEM's self-developed middleware is still high. But relatively speaking, for most OEMs that are difficult to develop their own algorithms, the requirements for software and hardware decoupling still need to be met by suppliers.

4. Middleware is “deviating from its original intention”

The birth of middleware was originally to solve the problem that software and hardware cannot be developed separately. Therefore, people initially hoped that middleware could become a blocking software that could streamline processes and be adapted to all software and hardware. This allows upper-level software application engineers to do their best work without worrying about hardware adaptation issues.

However, the reality is contrary to the original wishes.

On the one hand, middleware exhibits high intensity of customization.

A software architect from an algorithm company said:

"Each car model or chip platform has different adaptability to middleware, and the underlying software provided also has different adaptability to middleware. For example, some vehicles use the QNX operating system, and some use Linux. System, these two operating systems will have some customized content for middleware.

"In addition to the underlying operating system, the software application layer also has some differentiated requirements for middleware. For example, based on a certain platform, certain special communication methods need to be enabled, and some need to transmit data instead of traditional Ethernet. This kind of universal link uses special links such as PCIe or memory, which requires the middleware to be customized so that the middleware can support the communication needs of different links.

“Some autonomous driving software manufacturers or OEMs have their own logging methods, and some may not. Middleware is needed to provide a logging capability. Therefore, according to the capabilities of different users, the middleware will produce corresponding customizations. change."

Customization means that whether you ask the middleware manufacturer to assign people to meet the needs beyond standardization, or ask the algorithm company/host manufacturer to send dedicated docking algorithm engineers to make personalized adaptation adjustments to the middleware, you need to pay extra. of human and material resources.

The customized middleware creates new difficulties for the algorithm to parse the data.

An engineer from an OEM said bluntly:

"If V2X is to be installed on mass-produced vehicles, but the middleware on different brands of models is different, then its QoS (service strategy) will be different, and there will be problems in the analysis of the data. Therefore, the communication between vehicles will be different. There may be difficulties with communication.”

On the other hand, "More and more players are beginning to bypass the AUTOSAR standard and make their own. Even if the middleware is also made according to the AUTOSAR standard, the degree of customization is also very high." A system expert from a certain OEM said. At a time when every company is developing its own middleware, most middleware only adapts to its own algorithms, interfaces, etc., and the phenomenon of inconsistency is getting worse.

Whether it is an OEM or an algorithm company, instead of considering whether the middleware is easy to use and whether software and hardware are decoupled, what they really consider when cooperating on a project is whether it can solve the actual problems encountered. If the purchased middleware fails to solve the problem and does not achieve the desired effect, then both parties will need to modify and add various contents based on the original middleware, which will lead to a situation of continuous "coupling". The customization of middleware has become an inevitable phenomenon.

So, when I think back to the original intention of middleware to simplify processes and reduce workload, I can’t help but sigh.

5. How can we achieve decoupling of software and hardware?

So, if you want to achieve software and hardware decoupling, from what angles can you start?

On the one hand, hardware virtualization can be done from the operating system level first, and interfaces, communication protocols, etc. can be standardized, so that upper-layer applications do not need to consider different issues of the underlying system. However, this requires in-depth cooperation between chip manufacturers and operating system manufacturers. , or chip manufacturers develop their own OS, so there is still a lot of difficulty.

On the other hand, although the future form of middleware is still unclear, one thing is certain. Software and hardware decoupling still needs to be solved in the form of middleware, but middleware may be differentiated into several ways:

1. Middleware manufacturers develop tool-type middleware that simplifies Autosar based on Autosar itself. Since Autosar itself is very complex, it is not easy for engineers to learn. If a simplified version of the development tool can be provided, it would be a good idea to provide this tool to upstream and downstream manufacturers who need to develop self-developed middleware to optimize their own self-developed middleware process. a choice.