Communication group| Enter "Sensor Group/Skateboard Chassis Group/Car Basic Software Group/Domain Controller Group", please scan the QR code at the end of the article , add Jiuzhang Assistant , be sure to note the name of the exchange group + real name + company + position (no remarks Unable to pass friend verification)
Author | Lan Siqi
"In the era of software-defined cars, the status of software is getting higher and higher, and the development of the smart car industry needs to realize the decoupling of software and hardware."
Words similar to 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 an important issue for both OEMs and suppliers. Find a solution to the problem.
However, the standard is still difficult to unify, and the interfaces of each company are still different. Even after so many years, the decoupling of software and hardware still faces many difficulties.
one. Background of software and hardware decoupling
01
Evolution of EE Architecture
(Readers who are familiar with the topic of this part 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, but as electronic entertainment consumerism continues to invade all aspects of people's lives, people's functional requirements for cars are gradually increasing, and in the distributed architecture In the background, every new function needs to continuously increase the corresponding ECU. This is even more so for self-driving cars, so the number of ECUs on a self-driving car has grown to a maximum of one or two hundred.
The increasing number of ECUs has led to an increase in the total length and total cost of the wiring harness used for data transmission (according to the calculation of Zuosi Automotive Research Institute, if the current distributed architecture is used, the cost of the wiring harness for autonomous vehicles will not be less than 1,000 US dollars) , 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 (the MCU in it), and they are also separated from each other (this does not conform to the first principle, which 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 realized through the same SoC.
In this context, how to improve the space utilization rate and maximize the performance of the ECU in a limited space has become the next development direction in the industry. Therefore, the automotive EE architecture opened the door to evolve from a distributed architecture to a centralized architecture. For this reason, a domain controller was born, and 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 on the car have also changed from the original part of the calculation to the "screw" that only needs to undertake most of the execution functions and has weakened processing capabilities (the ECU still has the original ability to process calculations, but only functionally) It is no longer needed to handle part of the computation).
The evolution of EE architecture from distributed to domain-centralized, and the replacement of MCU by SoC have created prerequisites for the cross-domain transition of the automotive industry from the era of "hardware is king" to the era of "software-defined cars".
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 the SoC chip to have the ability to process large amounts of data in addition to multitasking concurrently. Replacing part of the MCU with SoC chips is like replacing the ordinary leaders of multiple departments of a company with a super-excellent CEO who pays one to one hundred.
In the era when hardware is king, due to the high degree of coupling between software and hardware, OEMs will first find a consulting company to make an analysis report on automotive functional requirements in the next 5-8 years, and then formulate a 5-8-year software-hardware integration based on the report plan. When the software and hardware are put into the production line, until the OEM installs various components and leaves the car, within 5-8 years, it is difficult for the car to change whether it is software or hardware.
In the era of software-defined cars, if we still follow the integration process of the original car factory and set a one-time car manufacturing plan for 5-8 years, then the problem will not be too prominent in the first few years of car manufacturing, but in this plan time In the second half of the interval, when a car is delivered to the user, both the hardware and software on the car are far outdated.
Therefore, in the product design stage, subsequent iterations 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 "unreliable". 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 develop their own software and algorithms, and solve all problems by themselves, including the decoupling of software and hardware; the other is to find suitable suppliers to provide iterative requirements after decoupling software and hardware.
If you want to take the first path, OEMs need very strong capabilities, 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 clear Tier1, Tier2, and Tier3 relationships to blurred boundaries.
In this context, various software and hardware suppliers also have the need for software and hardware decoupling for stronger competitiveness, better independent development and better cooperation ecology.
However, although the slogan of software and hardware decoupling has been shouted for several years, the effect is not ideal.
02
It is difficult to decouple sensors, chips and algorithms
Since algorithms and sensors are highly bound, in practical applications, such binding has caused a lot of trouble for algorithm engineers. For example, after the camera used in a car is changed from 2 megapixels to 8 megapixels, the algorithm must not be rewritten.
In addition, an algorithm engineer of a Tier1:
"Even if it is possible to decouple the perception algorithm and the sensor, how to calibrate the sensor after decoupling is particularly difficult."
Due to the high degree of coupling between software and hardware, the sensor data is also highly bound to the sensor. Once the sensor is replaced, all the expensive data annotations made before will be invalidated, and a new round of collection has to be started. This is very important for 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 location, and installation angle on each vehicle are different, so the algorithm is also different. The perception algorithm is different, and the regulation and control algorithm is 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 pain points they all had in common was: due to the difficulty of algorithm transplantation, a lot of extra work was done.
This is due to the fact that the frequency of algorithm migration is unpredictable. The competition and product iterations of chip manufacturers often affect the market preference, and you can't be sure whether there will be new and better chips for sale in the next trend.
Changes in market preferences will allow OEMs to specify replacement chips. At this time, for algorithm engineers, maybe you have just changed the algorithm based on this chip, 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 an OEM explained:
"The adaptation of the middleware to the lower layer BSP is quite troublesome. For example, the cockpit chip uses Qualcomm's 8155 or 8295, and the autopilot chip uses TI's TDA4, so the BSPs provided by their chips are different. It is necessary to make customized adaptations to the middleware.”
Not only the differences in chip platforms make the middleware unable to be reused, but also two domain controllers based on the same chip platform, if the hardware architecture is different (some domain controllers have 2 or even 3 SoCs), the middleware needs are also different.
2. The technical difficulties faced by the decoupling of software and hardware
Middleware is the most important tool needed to realize the decoupling of software and hardware. Therefore, the problem of decoupling software and hardware 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 standardized middleware needs to be adapted by algorithm companies or OEMs. It is difficult to say that there is a middleware that can cover Live everything. Because all middleware will have some restrictions 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.
From the data transmission itself, the middleware will have problems such as data deflection, data errors, and single module failure affecting data transmission. For example, the amount of data transmission is large. When SOME/IP is doing data collection, many communication signals cannot be collected, and packet loss is prone to occur.
In addition, data return errors can easily cause a series of chain reactions, which will eventually affect the decision-making and execution layers, causing adverse consequences. It can be said that data sharing has both advantages and disadvantages. 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 will also have an impact on data transmission. For example, at high speeds, Autosar APs have higher requirements for data transmission bandwidth. At this time, the conflict between the bandwidth transmission protocol and data collinear 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 requirements.
In addition to the above problems, the current middleware still has problems such as the caching mechanism is not well done, the function group does not support nesting, and the state machine coordination is not well done. These problems require algorithm engineers to build on the existing middleware. Then make modifications, which greatly increases the difficulty of decoupling software and hardware.
3. The business dilemma faced by software and hardware decoupling
In addition to the above-mentioned technical difficulties, the decoupling of software and hardware also faces a series of commercial difficulties.
01
Professional Middleware Vendor
Middleware manufacturers represented by Vector, RTI, EB, and ETAS hope to produce a set of standardized middleware that can be adapted to each company's software and hardware, and realize the demands of each company's 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 true trust of OEMs; on the other hand, most algorithm companies are not so willing to cooperate with middleware manufacturers Do standardization, because once the interface and successful system are unified by middleware manufacturers, it means that the substitutability of their own products will be enhanced and the differentiation will be reduced, which will lead to a sharp increase in the competitive pressure of algorithm companies, so they are very resistant.
In addition, when the technical development route of smart cars is not yet clear, OEMs hope that the configuration of their own cars will be differentiated from competing products to gain competition barriers (differentiation in the application layer also needs to be supported by differentiation in middleware) ), and standardized middleware would run counter to this desire. Therefore, OEMs would rather develop their own middleware than use standardized middleware developed by middleware companies.
In the end, these middleware became hard to sell, and it became unsustainable to only do standardized middleware.
According to the situation learned from Jiuzhang Zhijia, except Huayutongsoft and other companies that focus on modules with high technical barriers such as DDS and have established certain competitive advantages through long-term accumulation, most of the initial positioning Companies that are "middleware vendors" have basically begun to transform (expand to other fields) in the past one or two years.
02
supplier
Algorithm companies, Tier 1 companies that do some software and hardware, and chip manufacturers have all started to make middleware, but in practice, every family has a hard-to-read scripture.
2.1 Algorithm company
For algorithm companies, if the standardized middleware they purchase is too general, there will be many adaptation problems that cannot be solved. Engineers cause great difficulty. And if customized middleware is purchased, the algorithm company still needs to spend a lot of time communicating with middleware manufacturers, and the cost will be 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 have a low degree of cooperation and need the algorithm company to provide actual evidence to prove that it is a problem with the middleware, otherwise it will be arguing. It consumes manpower and time and affects the development process.
"In particular, algorithm companies that have just started to get involved in middleware do not have a particularly professional understanding of middleware. Finding evidence is more troublesome and will take more time; and if several parties cooperate in this process, OEMs have to do it. Coordination, which will lead to further delay in solving the problem."
Therefore, algorithm companies simply choose self-developed middleware to better match their own algorithms.
In addition, the middleware of international middleware manufacturers is expensive, and the middleware made by domestic start-up middleware manufacturers may not be more suitable than the middleware developed by themselves based on their own algorithms, which is also the middleware developed by algorithm companies. one of the reasons.
"If self-developed, I have a better understanding of the needs of my project, will it be better than letting middleware manufacturers develop it?" said a system architecture engineer of an algorithm company.
In addition to the above, there is another reason for the self-developed middleware of the algorithm company: the algorithm difference of each algorithm company is small, and the product differentiation needs to be formed through the self-developed middleware.
A senior director of an algorithm company said:
"At present, it is difficult to reflect the differences of various algorithms, and they are all programmed in C and C++. To reflect the differences, we must improve the performance and reliability of the middleware, that is, enhance the functional experience. some of the advantages."
However, algorithm companies have encountered many challenges in self-developed middleware. First of all, the self-developed middleware of OEMs can raise standards for suppliers, but if algorithm companies develop their own middleware, it will be difficult to persuade OEMs and other suppliers to adapt to their own standards.
As the software director of a L4 company said:
"For example, like Weilai Xiaopeng, they make middleware by themselves, because he is an automaker, he can set a set of standards to restrain his suppliers; but if an autonomous driving algorithm company makes supporting middleware, whether it is to persuade It is difficult for OEMs to convince OEMs that your set of tools can be applied to other domains, or to persuade other suppliers of OEMs to integrate according to their own standards."
In addition, after the algorithm company develops its own middleware, if there is a problem, it cannot be blamed. Therefore, for the algorithm company, the middleware needs to be better.
The chief engineer of the intelligent network connection of an OEM said:
"We will sign a guaranteed service agreement with suppliers, that is to say, once a serious quality accident occurs, although the car manufacturer is the first responsible person, we will naturally let these suppliers take responsibility as soon as possible. So if the algorithm company does If the middleware is involved, they will basically be unable to escape when it comes time to take responsibility, at least we will not let him escape.”
2.2 Chip manufacturers
The purpose of chip manufacturers to do middleware is to show the performance of the chip.
From a technical point of view, it is less difficult for chip manufacturers to do middleware than for algorithm companies. Because algorithm companies need to adapt to different chips, the workload is far more complicated than that of middleware made by chip manufacturers, and as long as the middleware made by chip manufacturers can be adapted to their own chips, it will be fine.
Even so, in practice, the middleware developed by chip manufacturers is rarely used.
At present, it is known that the main body of middleware includes middleware manufacturers, algorithm companies, chip manufacturers, and OEMs. The market share of middleware is divided into small parts and the competition is fierce. If you want to develop complete middleware at this time, who should you sell the developed middleware to? Is it really possible to make money through middleware? 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 do middleware more for ecology. Their middleware may have more functions, but the performance may not be optimal. That is to say, middleware does many functions, Including the abstraction of AI, the playback of data records, and the processing of point clouds, all may be done, but in this case, there will be a problem-the algorithm is supposed to do things, but the middleware has done all the things, and the performance cannot be fully guaranteed. , and it has to take into account the needs of multiple algorithm companies, and the flexibility will become poor.”
It can be seen that although some chip manufacturers are capable of doing a good job of middleware, considering the pressure of market competition, they still need to invest a lot of manpower and material resources in research and development. middleware, but prefer to focus on doing a good job of the chip itself.
Therefore, the self-developed middleware of most chip manufacturers is very light, and what they do is basically demo middleware that can run on the chip to show customers the performance of the chip. Such demo middleware, of course, will not have any substantial help in the decoupling of software and hardware.
03
OEM
For OEMs, the need for customization of middleware has always existed.
The person in charge of the intelligent driving system of an OEM gave an example:
"For example, when writing traffic light recognition algorithms or binocular vision algorithms, if you want to distinguish them from traditional algorithms or competitors' algorithms, you need a set of custom middleware, which involves data subscription, sharing, recording, and playback of middleware. , transmission, storage, diagnosis and other functions. However, these functions cannot be guaranteed to run perfectly under the system or function mechanism required by the OEM, and there may be conflicts. At this time, middleware suppliers are needed to help get through. "
However, compared to using middleware from third-party middleware companies or algorithm companies, some OEMs with stronger capabilities are more willing to develop their own middleware.
First of all, purchasing closed-source middleware such as RTI's DDS often means customization of middleware, which not only requires more expensive costs, but also lengthens the project docking cycle; 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, so that you can better control the product development process and later transformation, and solve the problem that may be caused by a middleware supplier falling off the chain. The problem of 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, and they can make their own middleware according to the needs of their upper-layer applications, which can better customize some middleware. Upper-layer applications can also make some features.
In fact, when the middleware technology is not yet mature and the future trend is not obvious enough, the reason why upstream and downstream players in the industry are doing middleware is to test the boundaries of their own capabilities, and to explore the boundaries of the entire industry.
However, several autopilot engineers of OEMs believe that "compared with algorithm companies, OEMs have little advantage in self-developed middleware."
First of all, most OEMs do not have much accumulation in algorithmic capabilities. The cost of setting up a team to do middleware is huge, but the result may not be as good as that of suppliers who specialize in these. The pain caused by such consumption has far exceeded that brought by coordinating several suppliers pain of. It's like the distress caused by one's own short board 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 obtain enough sample feedback, which is not conducive to product iteration. Suppliers’ algorithms and middleware are widely used, and the customer base increases, so the feedback rate of customers on bugs is higher, which is more conducive to the iterative progress of products; There is not enough sample data, so the iteration is relatively slow.
In addition, if OEMs want to develop their own middleware, they will have to recruit technical talents from other companies. However, for talents, they may not have such a strong sense of mission when working in a department of a large company. After all, there will always be a feeling of "the sky is falling, and the people above will support it". The result is that if the ability of the recruited talents can be brought into play by 80%, it is considered very ideal. But the same technical talent, if he comes out to do it 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 lot 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 the risk of being laid off, and a large number of employees will be laid off. Layoffs will also increase the sentiment that "the company is unstable" in the minds of employees.
From this point of view, the "self-developed middleware" of OEMs may be more of a marketing slogan, but this does not mean that all OEM middleware cannot be successful, and they are strong enough to successfully develop their own algorithms. The probability of success of the self-developed middleware developed by OEMs is still high. Only relatively speaking, for most OEMs whose algorithms are difficult to develop by themselves, the demand for software and hardware decoupling still needs to be met by suppliers.
4. Middleware is "deviating from the original intention"
The birth of middleware is to solve the problem that software and hardware cannot be developed separately. Therefore, people initially hope that middleware can become a software with a blocking effect, which can simplify the process and adapt to all software and hardware. Let the upper-level software application engineers not to consider the hardware adaptation problem, and do the algorithm with peace of mind.
However, the reality runs counter to the original wish.
On the one hand, middleware presents high-intensity customization.
A software architect of an algorithm company introduced:
"Each model or each 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, while others use the Linux operating system. system, these two operating systems will have some customized content for the 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, some special communication methods need to be enabled, and some need to transmit data instead of traditional Ethernet. This general-purpose link uses special links such as PCIe or memory, which requires customization of the middleware so that the middleware can support the communication requirements of different links.
"Some autopilot software manufacturers or OEMs have their own log recording methods, and some may not, so they need middleware to provide a log record capability, so according to the capabilities of different users, the middleware will generate corresponding customizations. change."
Customization means that whether it is to let middleware manufacturers assign people to meet requirements other than standardization, or to let algorithm companies/mainframe manufacturers send dedicated docking algorithm engineers to do personalized adaptation and adjustment of middleware, they need to pay extra. human and material resources.
And the customized middleware brings new difficulties for the algorithm to analyze the data.
An engineer from an OEM said bluntly:
"If V2X is used on mass-produced vehicles, but the middleware on different brand models is different, then its QoS (service policy) is different, and there will be problems in the analysis of data. Therefore, the communication between vehicles Communications may be difficult."
On the other hand, "more and more players are starting to bypass the AUTOSAR standard and make it themselves. Even the middleware that is also given the AUTOSAR standard has a high degree of customization." A system expert of an OEM said. At the moment when all companies are developing their own middleware, most of the middleware are only adapted to their own algorithms, interfaces, etc., and the phenomenon that they cannot be unified is also intensified.
Whether it is an OEM or an algorithm company, rather than considering whether the middleware is easy to use or whether the software and hardware have been decoupled, they really consider whether they can solve the actual problems encountered during project cooperation. If the purchased middleware fails to solve the problem or achieve the desired effect, then both parties need to modify and add various contents on the basis of the original middleware, which will form a situation of continuous "coupling". The customization of middleware has become an inevitable phenomenon.
Therefore, recalling the original intention of middleware to simplify the process and reduce the workload, I can't help but sigh.
5. How can software and hardware be decoupled?
So, if you want to realize the decoupling of software and hardware, from what angles can you start to do it?
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 problems of the underlying system, but this requires deep 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, the decoupling of software and hardware still needs to be solved in the form of middleware, but middleware may be divided 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 difficult for engineers to learn. If a simplified version of the development tool can be provided, this tool can be provided to upstream and downstream manufacturers who need self-developed middleware, and optimize their own self-developed middleware process. an option.
2. Middleware factories, OEMs and suppliers form a middleware alliance, and the chip factory or OEM takes the lead to unify the rules. In the exploration of market boundaries, a strong OEM or chip factory takes the lead to form a unified industry alliance standard, unify OS, interface, etc., and form an industry standard.
3. It is completely open source, and the chip company creates an exclusive OS for upstream and downstream companies to develop on this basis. Chip manufacturers make open source toolkits like Nvidia 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 and development, and to establish a good ecosystem.
4. As a service, come to the supplier to provide customized middleware services and maintenance work. Due to the low market ceiling and the difficulty of unifying middleware, middleware may not become an independent product, but a customized service. Because middleware manufacturers have better middleware research experience, they are better than players who provide such customized services.
In the past, all kinds of mobile phone brands flourished. From 2005 to 2010, when "brick phones" and smart phones flew side by side, there were as many as 200 mobile phone interfaces circulating on the market. Different brands of mobile phones have different charging ports, different headphone jacks, various ports with the same shape and different sizes, and even mobile phones of the same brand have different charging ports.
At that time, a digital expert often had to bring 5 or 6 types of chargers and 5 or 6 different cables when he was on a business trip. Even if we have a universal charger later, we can only pull off the battery of the brick machine to charge it. The problem that the charging port of the smart phone and the earphone jacks of different sizes cannot be unified still cannot be solved.
Such a chaotic and disorderly period, but after the rise of mobile phones, the development of mobile phone technology is the most brilliant and vigorous time, just like the development of smart cars now. Today, we see that the interface of mobile phones has been basically unified. Hundreds of mobile phone manufacturers, in the process of their own research, gradually decreased under the final choice of the market, and finally formed a standard.
The smart car industry is deeply affected by the consumer electronics market, especially the mobile phone market. In the past two years, everyone in the industry has been very impetuous. Everyone is eager to quickly progress to an end state, and hopes to be able to do so in a very short time. Select a master in the 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, and finally to collect feedback from tens of millions of users, we can continuously optimize ourselves and form standards. And maybe only at this time, the middleware can be truly 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.
last words
However, having said that, at present, when all parties are facing difficulties, who is the middleware suitable for?
Generally speaking, if we are aiming at the goal of completely decoupling software and hardware with standard middleware, chip manufacturers are the most suitable for middleware.
Two reasons: First, the adaptation of the algorithm is ultimately based on the chip platform, and the chip is the cornerstone. The second is that there are fewer chip companies than algorithm companies, and it is relatively less difficult to unify.
But for now, 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 achieve it, but chip companies cannot provide better optimization suggestions for application software and middleware. Users The terminal can only use its mature solution, but this solution may not be able to meet all the needs of the software."
It can be seen that algorithm companies receive the most customization requests and are required to do middleware adaptation in business practice. It is most convenient to directly make customized middleware that adapts to their own algorithms.
The chief engineer of an OEM also had the same opinion:
"At present, the upper-level functional services are relatively focused, and the autonomous driving solution suppliers have a deep understanding of functional applications. The middleware abstracted from the application layer can better match the underlying mainstream chip hardware solution providers, and the overall solution is more reasonable. "
references:
1. What is a software-defined car
2. 117-page in-depth research report on the automotive industry: smart cars, the most powerful computing terminals in the future
3. The main engine factory will take over the ownership of the software - the evolution of the electrical and electronic architecture
4. What is a domain controller? https://zhuanlan.zhihu.com/p/265346871SOA
5. Comparison of protocol DDS and SOME/IP: https://blog.csdn.net/u012739527/article/details/124842965
6. Inventory of in-vehicle middleware solutions https://www.dongchedi.com/article/7089022156352569889
Communication group| Enter "Sensor Group/Skateboard Chassis Group/Car Basic Software Group/Domain Controller Group", please scan the QR code above, add Jiuzhang Assistant , be sure to note the name of the communication group + real name + company + position (no remarks Unable to pass friend verification)
write at the end
communicate with the author
If you want to communicate directly with the author of the article, you can directly scan the QR code on the right and add the author's own WeChat.
Note: Be sure to note your real name, company, and current position when adding WeChat, thank you!
About Contribution
If you are interested in contributing to "Nine Chapters Smart Driving" ("knowledge accumulation and sorting" type articles), please scan the QR code on the right and add staff WeChat.
Note: Be sure to note your real name, company, and current position when adding WeChat, thank you!
Quality requirements for "knowledge accumulation" manuscripts:
A: The information density is higher than most reports of most brokerages, and not lower than the average level of "Nine Chapters Smart Driving";
B: Information needs to be highly scarce, and more than 80% of the information needs to be invisible on other media. If it is based on public information, it needs to have a particularly powerful and exclusive point of view. Thank you for your understanding and support.
Recommended reading:
◆ Nine chapters - a collection of articles in 2022
◆ "Your budget is too much, so we can't cooperate" - Jiuzhang Zhijia 2nd Anniversary Review (Part 2)
◆ The 4D millimeter-wave radar is clearly explained in the long text of 4D
◆ Application of deep learning algorithm in automatic driving regulation and control
◆ Challenges and dawn of wire control shifting to mass production and commercial use