Research on autonomous driving software and hardware decoupling technology and trends

"In 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."

Similar to the above This 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 problem that both OEMs and suppliers have been trying to figure out. solved 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.

01 Background of software and hardware decoupling

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 or so ECUs on a vehicle. Twenty, but as electronic entertainment consumerism continues to invade all aspects of people's lives, people's functional requirements for cars are gradually increasing. In the context of a distributed architecture, each new function needs to continuously increase the corresponding ECU. 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 used for data transmission to continue to increase (according to Zos Automotive Research’s calculations, if the current distributed architecture is continued, autonomous driving will The cost of a car's wiring harness will not be less than US$1,000), and the difficulty of supplier management has also increased.

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

In this context, 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.

ECUs continue 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 undertake most of the execution functions and have weakened processing capabilities ( The ECU still has the original ability to process calculations, but it is no longer functionally required to process part of the calculations).

The EE architecture evolves from distributed to domain-centralized, and SoC replaces MCU, creating 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 automotive functional requirements for the next 5-8 years, and then based on The report formulates a 5-8 year software and hardware integration 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 car factory’s integration process and set a 5-8 year car-building plan at once, then in the first few years of vehicle manufacturing, The problem will not be too prominent yet, but in the second half of the time period of this plan, when a car is delivered to the user, both the hardware and software on the car will be far out of date.

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

When the hardware configurations of various car manufacturers have converged, and 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 perform 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 The second way. 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, in order to achieve stronger competitiveness, better independent development and a better cooperation ecology, software and hardware suppliers also have software and hardware decoupling. need.

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

It is difficult to decouple 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 certain Tier1 algorithm engineer:

"Even if we have the ability to decouple the sensing algorithm and the sensor, what will happen after the decoupling? It is also very difficult to calibrate the sensor."

Due to the high degree of coupling between software and hardware, the data of the sensor is also highly bound to the sensor. Once the sensor is replaced, it will cost a lot of money. All the data annotations made will be invalidated, and a new round of collection will have to be started. This is a very troublesome thing for the algorithm 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 have is: due to the difficulty of algorithm transplantation, a lot of additional work has been done. work.

This is because 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 impressive. It’s a headache. For example, if the cockpit chip uses Qualcomm’s 8155 or 8295, and the autonomous driving chip uses TI’s TDA4, then because their chips provide different BSPs, customized adaptation of the middleware is required during integration.”

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 (on some domain controllers, There are 2 or even 3 SoCs), and the requirements for middleware are also different.

02 Technical Dilemmas Facing Software and Hardware Decoupling

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

The current middleware actually 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 There is a middleware that covers 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.

As for the middleware, from the data transmission itself, there will be problems such as data deflection, data errors, and single module failure affecting data transmission. For example, if the data transmission volume is large, when SOME/IP is doing data acquisition, many communication signals cannot be collected, and packet loss is easy to occur.

In addition, data return errors can easily cause a series of chain reactions, ultimately affecting the decision-making and execution levels and causing adverse consequences. It can be said that data sharing has pros and cons. In theory, it can improve efficiency, but if the source is wrong, it will cause a series of errors, and there is also a lack of effective diagnosis and correction mechanisms.

In addition, time and location also have an impact on data transmission. For example, at high speeds, Autosar AP will have higher requirements for data transmission bandwidth. At this time, the conflict between the bandwidth transmission protocol and data co-line transmission will be particularly obvious. During holidays, bandwidth usage is concentrated and the load is too high, which may not be able to meet data transmission needs.

In addition to the above problems, the current middleware also has problems such as poor caching mechanism, functional groups not supporting nesting, and poor state machine collaboration. These problems All require algorithm engineers to make modifications on the basis of existing middleware, which greatly increases the difficulty of decoupling software and hardware.

03 Business dilemmas faced by software and hardware decoupling

In addition to the above technical difficulties, software and hardware decoupling also faces a series of Business dilemma.

Professional middleware manufacturers

Middleware manufacturers represented by Vector, RTI, EB, and Yitech We hope to create a set of standardized middleware that can be adapted to each company's software and hardware, and realize each company's demands for software and hardware decoupling in one step.

But the reality is not as beautiful as imagined. On the one hand, except for a few leading middleware companies, it is difficult for the products of most middleware companies to win the real trust of OEMs; on the other hand, most algorithm companies are not so willing to cooperate with middleware manufacturers. Standardize, because once the interfaces and implementation systems are unified by middleware manufacturers, it means that the substitutability of their own products will be enhanced and differentiation will be reduced, which will lead to a sudden increase in competitive pressure from algorithm companies, so they are very resistant.

In addition, when the technological development route of smart cars is not yet clear, OEMs hope that the configuration of their own cars will be different from competing products to gain competitive barriers (application layer The differentiation of middleware also needs to be supported by the differentiation of middleware), and standardized middleware will run counter to this desire. Therefore, OEMs would rather develop their own middleware than use standardized middleware developed by middleware companies.

Eventually, these middlewares become difficult to sell, and it becomes unsustainable to only do standardized middleware.

Judging from what Jiuzhang Zhijia has learned, apart from Huayutongsoft and others, they focus on modules with high technical barriers such as DDS, and have built up their capabilities through long-term accumulation. Except for companies with certain competitive advantages, most companies that were originally positioned as "middleware vendors" have basically begun to transform (expand into other fields) in the past year or two.

Suppliers

Algorithm companies, Tier 1 companies that make some software and hardware, and chip manufacturers have all started to do it. Middleware, but in practice, every family has a hard time to read.

Algorithm Company

For algorithm companies, if the standardized middleware they purchase is too generic, it will There are many adaptation problems that cannot be solved, but if you get a universal middleware delivered by a black box, it will not match the algorithm well and will cause great difficulties to the algorithm engineers. And if you purchase customized middleware, the algorithm company will also need to spend a lot of time communicating with the middleware manufacturer, and the cost will be very high.

Engineering Director of an algorithm company:

"If there is a problem, generally speaking, the company will report the problem to the middleware manufacturer, but some manufacturers are less cooperative. Low, the algorithm company needs to provide actual evidence to prove that it is a middleware problem, otherwise it will be a mess, which will consume more manpower and time and affect the development process.

"Especially, just now Algorithm companies that have started to get involved in middleware do not have a particularly professional understanding of middleware. Finding empirical evidence is more troublesome and will take more time; and if several parties cooperate in this process, the OEM will still have to find someone to coordinate, which will As a result, the progress of solving the problem is further extended. ”

Therefore, algorithm companies simply choose to develop self-developed middleware to better match their own algorithms.

In addition, international middleware manufacturers The middleware is expensive, and the middleware made by domestic start-up middleware manufacturers may not be more suitable than the middleware developed based on their own algorithms. This is also one of the reasons why algorithm companies develop their own middleware.

“If I do my own research, I will know more about my project requirements. Would it be better than letting a middleware vendor develop it? " said a system architecture engineer of an algorithm company.

In addition to the above, there is another reason why algorithm companies develop self-developed middleware: the algorithms of each algorithm company have small differences, and they need to be self-developed. Middleware to form product differentiation.

A senior director of an algorithm company said:

"Currently, the differences between algorithms are very different. It is difficult to show it, because they are all programmed in C and C. To show the difference, we need to improve the performance on the middleware and improve the reliability, that is, to enhance some advantages in functional experience. ”

However, algorithm companies also encounter many challenges when they develop self-developed middleware. First of all, OEMs’ self-developed middleware can set standards for suppliers, and if algorithm companies If you develop your own middleware, it will be difficult to convince OEMs and other suppliers to adapt to their own standards.

As the software director of an L4 company said:

"For example, Weilai and Xiaopeng make their own middleware. Because they are an automobile manufacturer, they can set a set of standards to constrain their suppliers; but if it is an autonomous driving algorithm company that makes supporting middleware It is very difficult to convince the OEM that your set of tools can be applied to other domains, or to convince other suppliers of the OEM to implement integration according to their own standards. ”

In addition, when an algorithm company develops its own middleware, if something goes wrong, it will not be able to blame it. Therefore, for algorithm companies, middleware needs to be done better. .

The chief engineer of intelligent network connection of a certain main engine factory said:

"We will sign a guaranteed service agreement with the supplier, that is, Once a serious quality accident occurs, although the car manufacturer is the first responsible person, we will naturally hold these suppliers responsible as soon as possible. If an algorithm company develops middleware, it is almost impossible for them to evade responsibility once responsibility is involved, and we will not allow them to evade responsibility

Chip manufacturers

The purpose of chip manufacturers to make middleware is to demonstrate the performance of the chip.

From a technical perspective, it is less difficult for chip manufacturers to make middleware than for algorithm companies. Because algorithm companies need to adapt to different chips, the workload is far more complicated than that of chip manufacturers making middleware, and the middleware made by chip manufacturers only needs to be able to adapt to their own chips.

Despite this, in practice, very few people use the middleware developed by chip manufacturers.

Currently, it is known that the main entities making middleware include middleware manufacturers, algorithm companies, chip manufacturers and OEMs. The market share of middleware is divided very finely. , competition is fierce. If you want to develop complete middleware at this time, who should you sell the developed middleware to? Can middleware really be used to make profits? All have become issues that need to be considered before developing middleware.

An expert from an algorithm company said:

“We usually don’t use middleware from chip companies, because they make middleware more for ecological reasons. Their middleware may have more functions, but the performance is not necessarily optimal. In other words, middleware The middleware has many functions, including AI abstraction, data record playback, and point cloud processing. It may have all been done, but in this case there will be a problem - the middleware has done all the things that the algorithm originally did. , the performance cannot be fully guaranteed, and it has to take into account the needs of multiple algorithm companies, and the flexibility will become worse."

It can be seen that although some chip manufacturers are capable To do a good job in middleware, but considering the high pressure of market competition, a lot of manpower and material resources need to be invested in research and development. Most capable chip manufacturers have no motivation to invest too much in doing a good job in middleware, but prefer to focus on doing a good job in middleware. The chip itself.

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

Original OEM

For OEMs, the need for middleware customization has always existed.

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 the middleware's data subscription, sharing, recording, playback, sending, storage, diagnosis and other functions. But these functions cannot To ensure perfect operation under the system or functional mechanism required by the OEM, conflicts may occur. At this time, middleware suppliers are needed to help get through."

However, compared to Rather than using middleware from third-party middleware companies or algorithm companies, some OEMs with stronger capabilities will be 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 delays the project docking cycle. Very long; in contrast, self-developed middleware 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 possible problems. The problem of mass production delivery delays due to the failure of a certain middleware supplier.

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 enough, the reason why upstream and downstream players in the industry are making middleware is to test the boundaries of their own capabilities. , The second is 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 develop self-developed middleware to get enough sample feedback, 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 main engine manufacturer wants to develop its own middleware, it is bound to poach 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 number of talents to build a research team. Once it is found that this road cannot go on, such a large number of employees will face There is a risk of all being laid off, and the layoff of a large number of employees will increase the sentiment among current employees that "the company is unstable."

It seems that the "self-developed middleware" of OEMs may be more often just a marketing slogan, but this does not mean that all OEMs' self-developed middleware is impossible. Successful, strong enough, and successful self-developed algorithms have a high probability of success in self-developed middleware. 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.

04 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, so that upper-level software application engineers could do their jobs without worrying about hardware adaptation issues. algorithm.

However, the reality is contrary to the original wish.

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

The software architect of an algorithm company introduced:

"The adaptation of middleware for each car model or each chip platform The capabilities are different, and the underlying software provided has different adaptability to the middleware. For example, some vehicles use the QNX operating system, and some use the Linux operating system. These two operating systems will have some customizations for the middleware. Content.

"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 functions need to be enabled. Communication methods, some need to transmit data not through a general link like traditional Ethernet, but through special links such as PCIe or memory. This requires customizing the middleware so that the middleware can support different links. road communication needs.

"Some autonomous driving software manufacturers or OEMs have their own logging methods, and some may not. Middleware is needed to provide a logging capability, so according to different users The middleware will produce corresponding customization according to its own capabilities."

Customization means that whether middleware manufacturers have to assign people to meet requirements other than standardization, or Asking the algorithm company/host manufacturer to send dedicated docking algorithm engineers to make personalized adaptation adjustments to the middleware requires additional manpower and material resources.

And 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, the middleware on different brands of models will be different. If so, its QoS (service policy) will be different, and there will be problems in parsing the data. Therefore, there may be difficulties in communication between vehicles."

Another On the other hand, "More and more players are starting 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 a main engine manufacturer or an algorithm company, instead of considering whether the middleware is easy to use and whether software and hardware are decoupled, what is really considered during project cooperation 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, I can’t help but sigh when I think back to the original intention of middleware to simplify processes and reduce workload.

05 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 at 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, but 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 It may be divided into several ways:

#1. Middleware vendors 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.

2. Middleware manufacturers, main engine manufacturers and suppliers form a middleware alliance, with the chip factory or main engine factory taking the lead to unify the rules. In testing the boundaries of the market, a very powerful OEM or chip factory will take the lead to form a unified standard for the industry alliance and unify the OS, interfaces, etc. to form industry standards.

3. Completely open source. The chip company creates a proprietary OS, allowing upstream and downstream companies to develop on this basis. Chip manufacturers create open source toolkits like NVIDIA's CUDA, which not only develop their own OS and middleware, but are also completely open source, helping upstream and downstream customers to use tools together for better adaptation development and establish a good ecosystem.

4. As a service, we provide customized middleware services and maintenance work to suppliers. Due to the low market ceiling and the difficulty in unifying middleware, middleware may not become an independent product, but a customized service. Because middleware manufacturers have better middleware research experience, they are better positioned to provide such customized services.

In the past, various mobile phone brands were in full bloom. From 2005 to 2010, when "brick phones" and smart phones were flying side by side, there were up to more than 200 mobile phone interfaces in circulation on the market. kind. Different brands of mobile phones have different charging interfaces, different headphone interfaces, various large and small interfaces with the same shape and different sizes, and even mobile phones of the same brand have different charging interfaces.

At that time, a digital expert often had to bring 5 or 6 types of chargers and 5 or 6 different cables when he went on a business trip. Even if we later have a universal charger, we can only pull out the battery of the tablet phone to charge. The problem of the inconsistency between the charging port of the smartphone and the headphone jacks of different sizes still cannot be solved.

Such a chaotic and disorderly period is also the time when the development of mobile phone technology is the most brilliant and vigorous after the rise of mobile phones, just like the current development of smart cars. Today, we see that mobile phone interfaces have been basically unified. Hundreds of mobile phone manufacturers have gradually reduced their numbers in the process of self-research and finally formed standards under the final decision of the market.

The smart car industry is deeply affected by the electronic consumer market, especially the mobile phone market. In the past two years, everyone in the industry has appeared to be very impetuous, and everyone is eager to quickly progress to an end state. , hoping to select a master in a short time. However, the automobile manufacturing industry is actually a slow-growing industry. From the production of vehicles to mass production and then to the consumer market, only by collecting feedback from tens of millions of users can we continuously optimize ourselves and form standards. And perhaps only at this time can middleware truly be unified to form a standard.

After the technology matures in the future, middleware may be used as the basic software solidified on the ASIC chip, and it is unknown whether it will no longer appear in the form of middleware alone.

06 A few final words

However, having said that, at present, when all parties are facing many difficulties, is middleware suitable? Who will do it?

Overall, if we are aiming for the goal of using standard middleware to completely realize the decoupling of software and hardware, the most suitable middleware is actually the chip manufacturer.

Two reasons: First, algorithm adaptation is ultimately based on the chip platform, and the chip is the cornerstone. Second, there are fewer chip companies than algorithm companies, and it is relatively less difficult to unify them.

But currently, based on the premise that everyone expects customization, algorithm companies are the most suitable for customized middleware.

"Chip companies pay more attention to the application of the chip itself, such as whether to add a verification mechanism, how to schedule and accelerate BSP, etc. Chip companies can implement these requirements, but chip companies cannot control the application. The software and middleware put forward better optimization suggestions, and the client can only use its mature solution, but this solution may not be able to meet all the needs of the software."

As you can see, Algorithm Company It is the role that receives the most customization requests in business practice and is asked to do middleware adaptation the most. It is most convenient to be able to directly make customized middleware that adapts to one's own algorithms.

The chief engineer of a certain OEM also has the same view:

"For now, the upper-level functional services are relatively focused, and the supply of autonomous driving solutions Providers have a deep understanding of functional applications and abstract middleware from the application layer, which can better match the underlying mainstream chip hardware solution providers, and the overall solution is more reasonable."

The above is the detailed content of Research on autonomous driving software and hardware decoupling technology and trends. For more information, please follow other related articles on the PHP Chinese website!