1. The definition and function of middleware
1. What is middleware?
The picture is taken from the public account "Somersault Cloud and Autonomous Driving"
During the communication, the author found that different people have different understandings of middleware. It can even be said that this concept is still vague until now. For example:
(1) Some people think that middleware only refers to those components located above the OS kernel and below functional software, providing process management, , upgrade management and other services for the upper layer; while some people think that middleware should also include the part between functional software and application software (see the figure above). According to Mao Haiyan, the former is "universal middleware", while the latter is "specialized middleware". The "middleware" mentioned in this article refers specifically to "general middleware" unless otherwise specified.
(2) There are self-driving middleware mentioned by some people, including AUTOSAR (also divided into AUTOSAR CP and AUTOSAR AP), and there are also middleware mentioned by some people, specifically ROS2, Cyber RT, DDS, etc.
(3) Xiao Meng, VP of Weidong Technology, believes that the word "middle" is relative. When there are multiple layers stacked, each layer is the middle layer between the upper and lower layers. Therefore, when using the word "middleware", we need to specifically specify "which two layers it is located between." According to Xiao Meng, when we call "ROS/ROS2 as middleware", its meaning is not equivalent to "AUTOSAR AP as middleware".
(4)Vector product expert Cai Shoequn said that the middleware he understands "provides functional support for App development and has no functional representation to the outside world; but from the perspective of the operating system kernel, there is no essential difference between middleware and App."
. The role of middleware
Wang Haowei said: "Specialized middleware was originally part of the application, but many companies need to use it for autonomous driving, so it was abstracted."
So, what is it used for?
Bi Xiaopeng believes that the most important role of autonomous driving middleware is: firstly, it can adapt to different OS kernels and architectures; secondly, it can provide a unified standard interface that is responsible for communication between various application software modules and scheduling of underlying system resources.
According to Bi Xiaopeng's explanation, the former eliminates the need for developers to consider what the underlying OS kernel is or what the hardware environment is. It not only realizes the decoupling of and between application software and OS, but also realizes the decoupling of application software and hardware; while the latter ensures that data can be transmitted safely in real time and resources can be reasonably scheduled.
Why should middleware be used to support software and hardware decoupling? Bi Xiaopeng explained:
I develop an application software, many of which have nothing to do with specific application logic, including data communication, communication security, system resource scheduling, etc. For example, if there are ten processes that require data interaction, there is no need to implement and configure each of the ten programs' software codes. In response to this situation, we can abstract the repeated parts into a service, seal it into a separate layer (this is middleware), and provide a unified library, interface and configuration method for the upper layer to call. In this case, some people specialize in middleware, and those who work on upper-layer applications do not need to consider interacting with the bottom layer.
For example, if you want to make an automatic parking system , it has different modules or different software with independent business logic. When communicating, data interaction, or calling underlying resources, you only need an interface in the middleware to implement it. Other things do not need to be considered, so developers can focus on their own business logic.
For another example, a camera needs to sense lane lines, traffic lights, etc. in front of it. Developers specialize in traffic light and lane line detection algorithms. To interact with external data, they only need to use middleware communication services (such as subscribing to camera information and publishing detection results), without caring about where the data comes from or who it is sent to.
Dr. Miao Qiankun, director of Nullmax Nullmax Technology System Platform, wrote in a previous article:
" chip computing power has increased significantly, camera pixels have doubled, lidar appears in more new car plans... No one can say with certainty that on the car How many sensors should there be, or what hardware will be added to future cars, but everyone knows that hardware changes will be more intense.
"So we can also see that cars have increasingly higher requirements for software and hardware architecture. They must not only meet current needs, but also have considerable foresight, compatibility and scalability, and be able to support subsequent software and hardware upgrades, additions and subtractions of modules. The middleware for autonomous driving is just such a modern greenhouse that can be adjusted on demand to meet various needs.
"In early development, middleware can be broken into parts, decomposing a huge software project into a number of small tasks, and solved in a decentralized manner. In later applications, it can be broken into parts, like building blocks, and the modules can be combined into a whole according to needs. , perfectly matched.”
In a live broadcast before the Spring Festival, An Zhipeng, product sales director of Neusoft Reach, said that after the software and hardware are decoupled and modularized, when problems arise, there is no need to change the entire system, only the corresponding parts. In this way, the reusability of the software is greatly improved. At the same time, the workload of verification will be reduced a lot, and the overall development efficiency will also be improved.
On the contrary, without middleware, the application layer has to directly call the interface of the operating system. If the operating system is changed later, the application layer code and algorithm may have to be overturned.
In short, middleware abstracts resources such as computing platforms and sensors, adopts modular management of algorithms, subsystems, and functions, and provides a unified interface, allowing developers to focus on the development of their respective business levels without knowing irrelevant details.
According to An Zhipeng, product sales director of Neusoft Reichi, developing middleware like AUTSOAR is not only beneficial to OEMs. "The choice of component suppliers is also widened - once the application is ready, the following software and chips can be selected from several suppliers, which is much faster than the traditional development model. Therefore, component suppliers are also beneficiaries."
In Xiao Meng's words, the most direct benefit of middleware is to "shield the complexity of the underlying layer for the upper layer." software developers personnel can ignore the differences in hardware such as chips and sensors, thereby efficiently and flexibly implementing, iterating, and transplanting upper-layer applications and functional algorithms on different platforms. Xiao Meng believes that middleware can be regarded as a "new infrastructure" in the context of autonomous driving applications.
(The picture is taken from the article "Is AUTOSAR a blessing or a worry for basic software development?" by Dr. Feng Zhanjun. AUTOSAR is only a type of middleware, but the "AUTOSAR development advantages" written here basically apply to other middleware. )
However, from the perspective of developers, the meaning of middleware may not be all positive. For example, Dr. Feng Zhanjun wrote in "Is AUTOSAR a blessing or a worry for basic software development?" "The following two points are mentioned in the article:
The bottom-level software engineers have become tool people. "As long as you click the mouse and use the tools to cooperate, it is enough." Many tests that were originally done by themselves are also done by suppliers, which in turn leads to a serious reduction in the engineer's sense of achievement. Over time, the engineer's ability to develop from 0 to 1 will also be reduced.
(The picture is taken from Dr. Feng Zhanjun’s article.Although the article talks about Autosar, in fact these problems also exist in the use of other middleware such as ROS. )
For software engineers, the problem of "capability degradation" caused by middleware is almost unsolvable. However, Dr. Feng Zhanjun believes that "it would be better if engineers from the using company were deeply involved in the development process of this middleware, put forward requirements and implemented them together."
In addition, Yin Wei mentioned in an article that Tier 1s should be very reluctant to use middleware such as AUTOSAR, "because if it does not increase the cost, it may gradually become a hardware manufacturer." But this cannot be said to be the fault of middleware. Under the general trend of software-defined cars, this is almost inevitable.
2. Common basic concepts
1. AUTOSAR CP and AUTOSAR AP
Among all middleware solutions, the most famous one is AUTOSAR.
Strictly speaking, AUTOSAR does not specifically refer to a certain operating system or middleware product developed by a certain software company, but an automotive open system architecture standard jointly developed by major global automobile manufacturers, parts suppliers, software and hardware, and electronics industries. However, in practice, the middleware developed by various companies based on the AUTOSAR standard is also called "AUTOSAR".
Currently, AUTOSAR can be divided into two platforms: Classic Platform and Adaptive Platform, which are referred to as AUTOSAR CP and AUTOSAR AP respectively.
Simply put, AUTOSAR CP mainly runs on 8bit, 16bit, and 32bit MCUs, corresponding to traditional body control, chassis control, power system and other functions. If involves automatic driving, AUTOSAR CP may not be able to implement ; while AUTOSAR AP mainly runs on high-performance MPU/SOC above 64bit, corresponding to high-performance electronic systems for automatic driving.
Strictly speaking, AUTOSAR CP is not just a "middleware", it is a complete "operating system" equivalent to "OS kernel + middleware". AUTOSAR CP defines basic upper-layer task scheduling, priority scheduling, etc.
Among the ADAS functions based on distributed architecture, AUOTSAR CP is the most common "operating system". After formed the AUTOSAR ecosystem, many chip manufacturers' MCUs came standard with AUTOSAR CP, leaving OEMs with little choice.
Since the chips under the distributed architecture are mainly MCU, there is a saying that "AUTOSAR CP mainly runs on the MCU".
In a distributed architecture, different functions correspond to different MCUs, and each MCU needs to run a set of AUTOSAR CP. If there are many types of sensors , then only ADAS-related functions will require many sets of AUTOSAR CPs. How will it be charged?
The conventional approach is to charge according to the type of MCU - if the MCUs are two heterogeneous MCUs, then AUTOSAR CP will be charged as two sets; if the MCUs are homogeneous, then AUTOSAR CP will be charged as one set.
As the EE architecture evolves from distributed to centralized and chips evolve from MCU to SOC, the amount of calculation and communication increases by orders of magnitude. In addition, the demand for multi-core processors , GPU, FPGA and dedicated accelerators, as well as OTA, etc., are beyond the support range of AUTOSAR CP.
(Picture taken from An Zhipeng’s live class)
In 2017, in order to better meet the needs for middleware for high-level autonomous driving in the centralized architecture + SOC era, the AUTOSAR Alliance launched the AUTOSAR AP platform with stronger communication capabilities, more flexible software configurability, and higher security mechanism requirements.
It should be emphasized that unlike AUTOSAR CP itself, which already contains an OS based on the OSEK standard, AUTOSAR AP is just a middleware that runs on Lunix, QNX and other POSIX standard-based OSs - it does not itself contain an OS.
combined with aFakeProgramer published "Why use AP?" published on CSDN in 2020. What exactly does Adaptive AutoSAR provide enterprises? " article and what Neusoft Reichi An Zhipeng said in a live broadcast before the Spring Festival in 2022, the main differences between AUTOSAR CP and AUTOSAR AP are as follows:
). The programming language is different - AUTOSAR CP is based on C language , while AUTOSAR AP is based on C++ language;
). The architecture is different - AUTOSAR CP uses the FOA architecture (function-oriented) architecture), while AUTOSAR AP adopts SOA architecture (service-oriented architecture);
). Different communication methods - AUTOAR CP uses a signal-based static configuration communication method (LIN\CAN... communication matrix), while AUTOSAR AP uses a service-based SOA dynamic communication method (SOME/IP);
). Different connection relationships - in AUTOSAR CP, the connection relationship of hardware resources is limited to the connection of the wiring harness, while in AUTOSAR In AP, the connection relationship between hardware resources is virtualized and is not limited to the connection relationship of communication harness;
). Different scheduling methods - AUTOSAR CP uses a fixed task scheduling configuration. Modules and configurations are statically compiled and linked before release, and executed in sequence according to established rules. AUTOSAR CP supports a variety of dynamic scheduling strategies, and services can be dynamically loaded according to application requirements and can be updated individually.
). Code execution and address space are different - in AUTOSAR CP, most of the code runs statically in ROM, and all applications share an address space, while in AUTOSAR AP, applications are loaded into RAM to run, and each application has an exclusive (virtual) address space.
These differences bring AUTOSAR The advantages of AP are as follows -
).ECU is more intelligent: based on SOA communication allows the ECU in the AP to dynamically connect with other ECUs to provide or obtain services;
).More powerful computing capabilities: based on SOA The architecture enables the AP to better support multi-core, multi-ECU, and multi-SoCs parallel processing, thereby providing more powerful computing capabilities;
). More secure: Based on the SOA architecture, each service module in the AP is independent and can be loaded independently, and IAM manages access rights;
). Agile development: Adaptive AUTOSAR services are not limited to being deployed locally in the ECU but can be distributed in the vehicle network, allowing system modules to be deployed flexibly and independently updated later (FOTA);
). High communication bandwidth: bus communication based on high communication bandwidth such as Ethernet can be achieved;
). Easier IoT: SOA communication based on Ethernet makes it easier to achieve wireless, remote, and cloud connections, making it easier to deploy V-2-X applications.
(Picture taken from Neusoft Reichi)
Of course, in some aspects, AUTOSAR AP has some "disadvantages" compared with AUTOSAR CP. For example, the latency of AUTOSAR CP can be as low as microseconds, and the functional safety level reaches ASIL-D, hard real-time; while the latency of AUTOSAR AP is at the millisecond level, and the functional safety level reaches ASIL-B, soft real-time.
The above differences also lead to different application fields between the two: AUTOSAR CP is generally used in scenarios that have high real-time and functional safety requirements but low computing power requirements, such as traditional ECUs such as engine control and braking; while AUTOSAR is used in scenarios that have certain real-time and functional safety requirements but higher computing power requirements, such as ADAS, autonomous driving, and infotainment scenarios that pursue a higher degree of freedom in dynamic deployment.
Although AUTOSAR AP has various advantages, in general, it is not mature enough at present - mainly because modules such as information security and UCM are immature. There are many mass-produced vehicles equipped with AUTOSAR AP, but they are mainly used in entertainment scenarios, and very few are actually used in autonomous driving scenarios.
In addition, since the phenomenon of SOC+MCU combination will exist for a long time, AUTOSAR AP will not be able to completely replace AUTOSAR CP for a long time in the future - the most common division of labor is that tasks requiring high computing power are handed over to AUTOSAR AP, while tasks requiring high real-time performance are handed over to AUTOSAR CP.
(picture taken from Superstar Future)
2.ROS 2
ROS is the English abbreviation of robot operating system (Robot Operating System). The native ROS is a robot OS and cannot directly meet all the needs of driverless driving. ROS 2 is used as the middleware for autonomous driving.
The main differences between ROS 2 and ROS 1 are as follows:
(1). ROS 1 is mainly built on the Linux system and mainly supports Ubuntu; ROS 2 adopts a new architecture, the bottom layer is based on the DDS (Data Distribution Service) communication mechanism, and supports real-time, embedded, distributed, and multiple operating systems. ROS 2Supported systems include Linux, windows, Mac, RTOS, and even bare metal without operating systems such as microcontroller .
(2). The communication system of ROS 1 is based on TCPROS/UDPROS and strongly relies on the processing of the master node; the communication system of ROS 2 is based on DDS, canceling the master, and provides an abstract layer implementation of DDS internally. With this abstract layer, users can not pay attention to which merchant's API is used by the underlying DDS.
(3). ROS relies on roscore when running. Once there is a problem with roscore, it will cause a major system disaster. At the same time, due to the large installation and operation volume, it will burden many low-resource systems; ROS2 is based on DDS for data transmission, and DDS is based on the decentralized communication framework of RTPS, which removes the dependence on roscore. The system is highly stable and the consumption of resources is also reduced.
(4). Due to the lack of Qos mechanism in ROS, the stability and quality of the topic are difficult to guarantee; ROS2 provides a Qos mechanism to support real-time, completeness, historical tracing and other functions of communication. This greatly enhances the framework function and avoids problems such as difficulty in applying high-speed systems.
However, the QoQ configuration of ROS2 is relatively complicated. It is currently mainly used by some professional universities or laboratories abroad, and only a few domestic companies are trying it. In addition, the ecological maturity of ROS 2 is far less than that of ROS, which also brings inconvenience to the promotion and application.
Like AUTOSAR AP, ROS 2 also runs on the soc chip and is used to meet the needs of high-level autonomous driving. However, Xiao Meng emphasized in a batch of articles last year that when we call "ROS/ROS2 as middleware", its meaning is not equivalent to "AUTOSAR AP as middleware".
Xiao Meng's article said:
When we say AutoSar is middleware, this middleware is very clear. The L.BSW layer semantics is between the computer OS and the implementation of specific functions of the vehicle ECU. It shields the ECU function implementation layer from details related to specific processors and computer OS, and provides basic services required to interact with vehicle networks, power supplies and other systems;
ROS/ROS2 As an application framework for robot development, it provides a common middle layer framework and common software modules (ROS Package) between robot applications and computer OS. Moreover, the ROS team believes that this framework is good enough to be called an operating system (OS). Although
ROS 2 has many functional overlaps with AUTOSAR AP, the ideas of the two are different:
(1). In terms of expression, AUTOSAR AP is first of all a set of standards. This standard defines a series of basic platform components. Each platform component defines a standard interface for applications, but does not define implementation details and interactive interfaces between platform components (these parts are left to AUTOSAR AP supplier implementation); ROS2 has been code-first from the beginning. Each version has a complete code implementation and also defines application-oriented standard API interfaces.
(2) AUTOSAR AP has been oriented to ASIL-B applications from the beginning; ROS 2 is not designed according to ASIL standards. The solution for ROS 2 to achieve functional safety is to replace the bottom layer with an RTOS and commercial tool chain (compiler) that meets ASIL requirements.
ROS 2 "cannot pass car regulations" seems to have become a very broad industry consensus. But in Xiao Meng's view, ROS2 was not originally designed for the real-time domain. If the vehicle control algorithm , which has high real-time requirements, must be run in ROS2, "that is a software design error, not a problem with ROS2."
Xiao Meng believes that as long as it can complete all the functions required by the L.BSW layer and complete the characteristics required by all aspects of the A-axis, ROS 2 can be used in self-driving mass production vehicles. For example, Apex.AI, a company that just received investment from ZF and other giants some time ago, has customized and developed Apex.OS based on ROS 2 and has passed the highest level of ASIL D certification.
Xiao Meng said: "This is actually based on the ROS 2 architecture to implement a set of AUTOSAR AP specifications. This can become a separate product and can be developed by investing time + people + money. Just see if it is necessary and whether it is worth it."
In specific practice, ROS 2 is in direct competition with AUTOSAR AP - although for users, there is no strictly "choose one" problem, but generally speaking, if you choose ROS 2, you will not choose AUTOSAR AP; if you choose AUTOSAR AP, you will not choose ROS 2.
3. CyberRT
Cyber RT is a middleware developed by Baidu Apollo and officially released in Apollo 3.5. Cyber RT is relatively similar to ROS2, and its underlying layer also uses an open source version of DDS.
Baidu first used ROS 1, but during the use process, it was gradually discovered that ROS 1 had the problem of "if the ROS Master fails, the communication between any two nodes will be affected", so I hope to use a "no intermediate node" communication middleware to replace ROS 1. There was no ROS2 at that time, so I made a Cyber RT.
In order to solve the problems encountered by ROS, Cyber RT deleted the master mechanism and replaced it with an automatic discovery mechanism. This communication networking mechanism is exactly the same as the automotive network CAN. In addition, the core design of Cyber RT moves scheduling and tasks from kernel space to user space.
(Picture source: https://blog.csdn.net/xhtchina/article/details/118151673)
Compared with other systems, one of the major advantages of Cyber RT is that it is specially designed for unmanned driving. Baidu has open sourced Cyber RT. The middleware used by an Internet giant's autonomous driving team is Baidu's open source Cyber RT. There is also competition between
Cyber RT and ROS 2.
When talking about the relationship between AUTOSAR AP, ROS 2 and Cyber RT middleware, Vector product expert Cai Shoequn explained:
"There is no need to classify it mechanically. You can classify AUTOSAR AP, ROS and Cyber RT is imagined as a supermarket that provides a set of middleware. Users can buy it from different supermarkets as needed. It does not mean that if you buy a middleware from one supermarket, you cannot buy it from other supermarkets.
Cai Shouqun said: AUTOSAR. The AP also includes support for the ROS interface. There is no telling which day ROS and Cyber RT will add AUTOSAR AP components, or AUTOSAR AP will introduce Cyber RT components.
.DDS (communication middleware)
(1) What is DDS?
In the field of autonomous driving, the functions of middleware involve communication, module upgrades, task scheduling, and execution management, but its most important function is communication. On the current market, whether it is Cyber RT or Basically 90% of the functions of ROS are communication. In a narrow sense, it is communication middleware.
communication can be divided into two types: open source and closed source. The open source ones are OPEN DDS, FAST DDS, Cyclone, etc., and the closed source ones are RTI's DDS and Vector's SOME/IP.The full name of DDS is Data Distribution Service, which refers to a data distribution service standard formulated by the Object Management Organization (OMG).
DDS can achieve low-latency, high reliability, and high real-time data fusion services, which can fundamentally reduce the coupling and complexity of software and improve the modularity of software. High-level autonomous driving is now basically exploring the use of DDS to solve challenges such as heterogeneous communication and low latency that cannot be solved by CP.
Automotive software integrated with DDS can better run in the next-generation automobile architecture, reduce development costs, shorten research and development time, and bring products to market faster.
(2) The relationship between DDS, ROS 2, and AUTOSAR AP.
Both the bottom layers of ROS 2 and Cyber RT use open source DDS, using DDS as the most important communication mechanism. However, some engineers from autonomous driving companies believe that DDS can replace ROS 2. From a user's perspective, there is actually a "choose one" relationship between the two.
AUTOSAR CP has never included anything related to DDS, but AUTOSAR AP began to support the DDS standard in the latest version (version 18-10) in March 2018. Combining DDS with AUTOSAR AP not only guarantees and extends the functionality of interoperability within the AUTOSAR AP system, but also opens it up to people from different ecosystems (i.e. ROS 2).
From an engineering perspective, the biggest advantage of combining AUTOSAR and DDS is that the functional domains and network topology are no longer opponents, but allies in the vehicle. The network topology is better able to adapt to the physical constraints of the vehicle. Functional domains provide a flexible overlay on top of the physical vehicle. This is the so-called partitioned architecture.
Of course, DDS is only one type of communication middleware. Regarding the similarities and differences between various types of communication middleware, we will explain in more detail in the second article of this series.
three. Is the status of AUTOSAR AP weakening?
Although AUTOSAR is the most famous autonomous driving middleware at the moment, "Nine Chapters Smart Driving" came to a conclusion in its survey of many middleware manufacturers: AUTOSAR's position in the industry chain may be weakening. Of course, those manufacturers that focus on AUTOSAR systems do not agree with this view.
We have mentioned above that as the EE architecture evolves from distributed to centralized and MCU is replaced by SOC, it is the general trend that CP AUTSAR is replaced by AUTOSAR AP, ROS 2 and Cyber RT. In the following, we mainly talk about "Will the status of AUTOSAR AP be weakened?"
In mid-December 2021, two AUTOSAR sponsoring companies Continental and Toyota joined forces with ZF, Jaguar Land Rover , Volvo , Hella and many other leading companies in the automotive industry announced their investment in the in-vehicle operating system startup Apex.AI, and Apex.AI's main product Apex.OS is developed based on ROS 2.
ZF, which has obtained 15% of the equity of Apex.AI, said in an interview with the media: "This means that we can provide customers with alternatives to AUTOSAR AP."
Although AUTOSAR AP has a standard, it has not yet been implemented. The solutions provided by companies such as , Aptiv , ZF, and Continental are still based on the AUTOSAR CP standard interface. In fact, more and more OEMs do not want to completely use AUTOSAR to solve the problems of intelligent driving operating systems.
Not only Tesla does not use AUTOSAR AP, but also several new domestic car-making forces do not use it (they use AUTOSAR CP+DDS). Even some traditional car companies that are undergoing transformation do not plan to use AUTOSAR AP.
Judging from the reactions of all parties in the industry chain, the main reasons for the “unstable status” of AUTOSAR AP are as follows:
1. The cost of use is too high
Dr. Feng Zhanjun wrote in "Is AUTOSAR a blessing or a worry for basic software development?" "The article revealed that the cost of AUTOSAR usually starts in "a few million", and "repeated charges" are required for different domain controllers and different chips, which is simply beyond the reach of ordinary small manufacturers. "There may not be any output, but millions will be spent."
In addition to the high purchase cost, both Bi Xiaopeng and Xiao Meng mentioned that AUTOSAR is very difficult to learn in the early stage and the learning cost is also very high. In order to learn how to use AUTOSAR, companies even have to train a group of people. If the trained people leave temporarily, the training cost will be wasted.
. Inefficiency
Bi Xiaopeng believes that AUTOSAR AP has many configurations. It implements its functions through configuration and part of the code. However, after too many configurations, the efficiency is not high and the code is bloated.
. The conflict of concepts between static deployment and dynamic deployment
Dr. Bi Xiaopeng mentioned that AUTOSAR AP is actually developed from AUTOSAR CP. AUTOSAR CP is a static deployment, which is only suitable for relatively simple business logic and functions. Its code is solidified, a bit like the previous feature phones - the functions cannot be changed, and it is impossible to add an APP to it; but AUTOSAR CP AP is a bit like today's smartphones. Software developers develop an APP that can be used on different mobile phones across platforms. This concept of dynamic deployment is very different from the previous concept of static deployment, but its methodology is derived from static deployment, so many problems will be encountered at the practical level.
. Unable to meet the needs of intelligent network connection
Since the operating systems used by the cloud and the car are different, AUTOSAR can only be responsible for communication in the car and cannot support communication from the car to the cloud, so it cannot support vehicle-road collaboration scenarios (communication between the car and the cloud is achieved through middleware such as MQTT and kafka). In addition, there are also great doubts about whether AUTOSAR can be compatible with the data platform, communication platform and map platform needed for vehicle networking.
Bi Xiaopeng said that after discovering these problems, some OEMs began to gradually abandon the AUTOSAR architecture and "turned to develop a new software architecture that is more suitable for dynamic deployment and lower cost."
Traditional car manufacturers came from using CP, so in terms of inertia, they may still consider whether AP is suitable for intelligent driving, but they are slowly trying to transform. For example, zFAS, the communication middleware jointly developed by Audi and TTTech, does not use AP.
Unlike AUTOSAR CP, which is already very standardized and everyone has no problem using it, the current standard of AUTOSAR AP is not very complete and is updated every year. No one knows how the specific AP can develop, and everyone is more of a wait-and-see attitude.
Bi Xiaopeng believes that the AUTOSAR standard cannot well support the development of autonomous driving applications and innovations. Therefore, it is necessary for us to establish a technical architecture and ecosystem that is more suitable for the development of intelligent driving in China and is autonomous and controllable.
Xiao Meng believes that due to the continuous lineage from AUTOSAR CP to AUTOSAR AP, some companies that have formed a path dependence on AUTOSAR will insist on using AUTOSAR AP, but after experiencing the difficulties of recruiting people and the long development cycle, they may switch to ROS 2.
Of course, companies whose main business is AUTOSAR will obviously not agree with the above-mentioned "suspected badmouthing" of AUTOSAR AP.
For example, Vector Cai Shouqun believes that AUTOSAR AP will only become more and more important, because it is a set of specifications that conforms to the continuous development of vehicle technology, and its coverage will become wider and wider.
Neusoft Ruichi Mao Haiyan also believes that merging vehicle domain controllers and smart driving domain controllers onto a unified central computing platform would be difficult to accomplish without the support of AUTOSAR AP."Not every company can build a system from scratch like Tesla. At present, the best tool is AUTOSAR AP."
