This article is the second in the popular science series on autonomous driving middleware. The previous article was one of the autonomous driving middleware: Is AUTOSAR being "marginalized"?
As the number of sensors increases, data sources become more numerous and larger in scale. How can these multi-source heterogeneous data be efficiently and stably transferred between chips and between task processes? What about ensuring that "the right data is delivered at the right time, and that the data reaches the right place"?
What information will be shared between modules? How can I send this information encoded into the message? How to pass messages from one module to another module? How to decode the message after receiving it? How long does it take to communicate between each module?
How can the process not be interrupted during OTA?
These problems need to be solved through "communication middleware".
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. In the current market, whether it is Cyber RT or ROS, basically 90% of the functions are communication. In a narrow sense, they are communication middleware (also known as "message middleware").
So, what characteristics should a good communication middleware have? What types of communication middleware can be divided into? What are the advantages and disadvantages of common SOME/IP and DDS? How will the market landscape evolve? Next, we will briefly sort out these contents.
one. What kind of communication middleware is needed for autonomous driving?
In traditional network communication, under the TCP protocol, after the information is sent, the receiver needs to send a signal to tell the sender "I received it". If the signal is not received, the next message cannot be sent; in UDP transmission mode , the sender will keep sending regardless of whether the receiver has received it or not.
In the past, when communication middleware was not used, in order to develop upper-layer applications, developers had to define the data format, sender and receiver of data by themselves; Data-centric" publishing and subscription model, developers only need to know what kind of data I need and where to send the data, without knowing who and how the data is sent.
Data-centric is compared to the traditional "message-centric". The essential difference is that the communication middleware knows what data it stores and can control how to share the data.
With traditional message-centric middleware, programmers must write code to send messages, while with data-centric middleware, programmers only need to write code for how and when to share data, and then share data directly value.
Communication middleware includes three working modes: point-to-point, message queue and publish/subscribe. Both SOME/IP and DDS adopt the publish/subscribe mode.
The point-to-point mode has strong time and space coupling, which greatly limits the flexibility of communication; the message queue mode transmits messages through a message queue, which solves the problem of loose coupling of time and space between the communicating parties, but cannot implement messages. Consumer communication is asynchronous, and there are also server bottlenecks and single point failures, and reliability cannot be guaranteed; in the publish/subscribe model, publishers and subscribers are related through topics, and both parties do not need to know where the other party is. It is not necessary to be online at the same time, realizing multi-dimensional loose coupling of communication parties in time, space and data communication.
In addition, DDS and SOME/IP are both service-oriented communication protocols compared to signal-oriented CAN. The difference between the two is: signal-oriented data transmission will always be sent in a loop regardless of whether the network needs it or not; while service-oriented communication is different, it will only be sent to the client when the client requests or the server notifies a specific subscriber. Data is exchanged in a client-server configuration, which ensures that bandwidth is never wasted and that data is communicated/exchanged only when and where it is needed.
Therefore, service-oriented communication protocols can greatly reduce network load and improve communication efficiency.
SAIC engineer Yin Wei said in an article that the introduction of communication middleware can help developers improve work efficiency as a whole.
Both SOME/IP and DDS have been included in the platform standards of AUTOSAR AP.
Chuangjing Information Technology said in an article on its official WeChat public account: “Business interests aside, from an engineering perspective, the biggest advantage of combining AUTOSAR and DDS is that functional domains and network topology are no longer rivals. , but rather allies in the vehicle. The network topology is better able to adapt to the physical constraints of the vehicle, while the functional domains provide a flexible overlay on top of the physical vehicle."
Communication middleware should include the following modules: data type specification language, messaging system, log/playback tools and real-time analysis tools. These modules should have the following characteristics:
1. The data type specification language should be independent of the platform and specific programming language to eliminate the need for users to implement marshalling code while ensuring runtime type safety;
2. Messaging systems need to transmit messages between different processes and provide low-latency messaging capabilities and eliminate dependence on central communications, making it easier to work with mixed simulation, recording and real-time data sources;
3. A large number of logging, playback and traffic inspection tools need to be provided to simplify common development and debugging tasks.
The main criteria for measuring the quality of a communication middleware are as follows:
1. Is the interface convenient? The convenient interface is the reason why many people like to use ros.
2. Is it safe and stable? Security means that data loss cannot occur during the communication process; stability means that the process of publishing and subscribing cannot go down even if it runs for several days and nights.
3. How many nodes and across how many cores can the transmission support?
4. Is it possible to configure flexibly and quickly under different communication scenarios and communication requirements?
5. Throughput and delay. By sending packets of the same size, is the throughput higher and the latency lower than with other methods?
Throughput, that is, how much data is passed per unit time; delay, that is, how much delay is in the transmission of data packets. If the communication speed is so slow that it takes 200 milliseconds for the perceived information to be transmitted to the executive system, then no matter how good the perception is, it will not help.
The higher the vehicle speed and the larger the data volume, the higher the requirements for the data throughput and delay of the middleware. A communications middleware manufacturer reported that their products sold very well in the passenger car market, but did not respond well in the commercial vehicle market. One reason is that the driving scenarios of commercial vehicles are simple, and the data throughput capabilities and latency of the middleware are affected. The requirements are relatively low.
two. Common Communication Middleware
According to whether the source code is open or not, communication middleware can be simply divided into closed source and open source. Closed-source communication middleware mainly includes Vector's SOME/IP, RTI's DDS, etc.; open-source communication middleware mainly includes OPEN DDS, FAST DDS, Cyclone DDS, etc.
Below, we will give a brief introduction to these types of communication middleware.
01
SOME/IP
The full name of SOME/IP is: Scalable service-Oriented Middleware over IP, which is a service-oriented transport protocol. Strictly speaking, SOME/IP is not a specific product, but a technical standard. It was first developed by BMW in 2012-2013 and integrated into AUTOSAR 4.2.1 in 2014.
Currently, the world's largest supplier of commercial SOME/IP products is Vector. The open source version of SOME/IP is maintained by the Genivi Association.
02
DDS（Data Distribution Service）
When talking about DDS, you have to mention the OMG organization. OMG is an international, open, non-profit computer industry standards association. Many familiar standards (such as UML) come from OMG. DDS is also one of the standards launched by the OMG organization.
(Picture from Chuangjing Information Technology Company)
The full name of DDS is Data Distribution Service (Data Distribution Service). It is a distributed communication specification released by OMG. It adopts a publish/subscribe model and provides a variety of QoS service quality strategies to ensure real-time, efficient and flexible data distribution. Various application requirements for distributed real-time communication.
DDS defines the data transmitted in the distributed network as "topic", and defines the data generating and receiving objects as "publisher" and "subscriber" respectively, thereby forming a publish/subscribe transmission model of data. There is no logical master-slave relationship between each node. There is a peer-to-peer relationship between points. The communication method can be point-to-point, point-to-many, many-to-many, etc. The connection is established under the control of QoS, and network parameters are automatically discovered and configured. .
DDS was first used in the U.S. Navy to solve the compatibility problems of a large number of software upgrades in the complex network environment of ships. It was later expanded to aviation, aerospace, shipbuilding, national defense, finance, communications, automobiles and other fields, including combat systems, ship navigation and Control systems, ship defense systems, UAV driving systems and ground control systems, armored vehicle control systems, simulation and training systems, radar processing and air traffic management systems, financial systems, etc.
In 2018, DDS was introduced into AUTOSAR AP for the first time as one of the optional communication methods. In March 2018, RTI Corporation, the main provider of DDS, announced that the latest version of AUTOSAR AP (version 18-03) already has complete network binding of the DDS standard.
Both ROS 2 and Cyber RT use open source DDS at the bottom layer, using DDS as the most important communication mechanism. Correspondingly, DDS interfaces are also reserved on SOC chips for autonomous driving such as Xaver and Orin.
The standard specification of AUTOSAR CP does not support DDS, but after making some modifications, DDS can also be integrated on the CP.
Globally, the supplier with the largest DDS market share (about 80%) is the American RTI company (full name Real-Time Innovations) founded in 1991. As a member of the board of directors of the OMG organization, RTI has led the formulation of the DDS standard. It has been responsible for chairing the work of the DDS working group since 2004. It has now become a leader in this industry and has sufficient authority for the DDS standard.
The DDS developed by RTI is branded as Connext, so it is also called Connext DDS.
03
Open source DDS: FAST DDS and OPEN DDS
Open source DDS is mainly compared to commercial RTI Connext DDS, etc. It is also developed according to OMG official standards, but the source code is open.
The more influential open source DDS in the field of autonomous driving is FastDDS launched by eProsima, a company founded by former core team members of RTI in Europe. After eProsima released the source code of FastDDS, users can download it directly from github for free. But FastDDS is cumbersome to use. At this time, users need to pay eProsima for support.
OpenDDS was developed by the ACE/TAO team of Object Computing in St. Louis and Phoenix. It has certain similarities with FastDDS - both are based on RTPS, a data-oriented communication framework, and follow the same standard. Typical features of this type of framework are decentralization, support for QoS mechanisms, and support for real-time communication. Usually it is bound to serialization tools such as protobuf.
In many cases, FastDDS, OpenDDS can interoperate/communicate with RTI's Connnext DDS. Of course, it depends on the scene. For example, there are 23 QoS (service policies) in open source DDS, and if everyone interacts with these 23 QOS, they can interoperate; if Connext uses QoS beyond the 23 custom ranges, then open source DDS cannot resolve them. In addition, if you use the DDS tool that OMG does not open source, it will not be interoperable.
According to the person in charge of a domestic middleware manufacturer, due to cost considerations, NVIDIA's Xavier's own Driver.OS uses open source DDS such as FastDDS or OpenDDS.
RTI believes that open source DDS is its biggest competitor.
Of course, the threshold for using open source DDS is also very high. For example, RTI DDS has more than 50 service policies, but open source DDS has only 23 service policies, which is far less complete than the former. In addition, RTI's DDS has passed ASIL-D certification, but open source DDS has not.
According to Bi Xiaopeng, co-founder of Huayutongsoft, the communication middleware developed based on the open source version of DDS has the problem of "insufficient stability".
04
MQTT (open source)
MQTT is an instant messaging protocol developed by IBM. Its full name is Message Queuing Telemetry Transport. The MQTT protocol also adopts the publish/subscribe model. All IoT terminals are connected to the cloud through TCP. The cloud manages the communication content concerned by each device through topics, and is responsible for forwarding messages between devices.
Due to poor functions such as delay control and relatively few service strategies, MQTT is not suitable for high-speed projects and large-scale projects, but it can be used in low-bandwidth and unreliable network scenarios to provide data transmission and monitoring of remote devices based on cloud platforms . In the field of autonomous driving, a typical application scenario of MQTT is V2X.
In addition, MQTT is also applicable in the field of low-speed vehicles. It is extremely small and can provide simple QoS guarantees. It is very suitable for projects with simple functions and limited hardware resources such as toy cars and sweepers.
MQTT is also an open source communication middleware.
三．SOME/IP & DDS
At this stage, SOME/IP and DDS are the two most commonly used types of communication middleware in autonomous driving. As mentioned above, the common points of the two are: both are service-oriented communication protocols; both adopt a "data-centric" publishing and subscription model. So, what are the main differences between the two?
01
Different application scenarios
SOME/IP was born specifically for the automotive field. It defines a set of communication standards for the needs of the automotive field, and has been deeply cultivated in the automotive field for a long time; DDS is an industrial-level strong real-time communication standard. It It has strong adaptability to scenes, but requires special tailoring when used in the automotive/autonomous driving field.
02
Different flexibility, scalability
Compared with SOME/IP, DDS introduces a large number of standard built-in features, such as content- and time-based filtering, transport-independent reliability, persistence, survivability, delay/deadline monitoring, extensible types, etc. When AUTOSAR AP works with DDS to build a communication framework, the framework is not only compatible with existing ara::com APIs and applications, but also provides important reliability, performance, flexibility and scalability. benefit.
03
Whether the subscriber and the publisher are strongly coupled
In SOME/IP, before normal data transmission, the client needs to establish a network connection with the server and ask the server whether to provide the required service. At this level, there is still a certain degree of coupling between nodes. The subscriber of the service needs to know where the server is, and the publisher of the service needs to tell the server which service to provide. For example, when writing a program that needs sensor data, the program needs to ask the server whether it can provide sensor data; and under the DDS standard , each subscriber or publisher only needs to subscribe or publish sensor data in its own program, and does not need to care about any connections. It can be understood that in DDS, the decoupling of service subscribers and publishers is more thorough. What data is needed, just write a line of code, and there is no need to do binding.
04
Different service strategies
Better QoS (service policy) is the most important feature of the DDS standard compared to SOME/IP.
SOME/IP has only one QoS, which is the definition of reliability; while RTI DDS and open source DDS have more than 50 and more than 20 QoS respectively, and these QoS can basically cover most foreseeable intelligent driving scenarios.
What is QoS specifically, and what is its purpose? Bi Xiaopeng, co-founder and vice president of technology of Huayutongsoft, gave several examples:
(1) Transmission priority, data reliability, resource restrictions, time filtering, etc. in communication all need to be set in QoS.
(2) Frame loss may occur during data transmission, that is, not every frame can reach the receiving end. To address this phenomenon, we need to consider the scene requirements. If it is critical information (alarm command), we need the sender to resend it. If it is non-critical information (high-frequency sensor data), the system does not need to retrieve all the lost parts. All these only need to configure the reliability of QoS.
(3) In the case of redundancy in the sensing system, once one sensor goes down, a second sensor is needed to take over. In response to this situation, QoS can configure an ownership to prioritize the data from the two sensors. After configuration, there is no need to recompile, because it is dynamically deployed. After configuration, it can run according to the latest configuration to complete the publish and subscribe between different nodes.
(4). The decoupling mode of DDS allows a topic publisher to still publish data without subscribers, but subscribers who join later may be interested in the historical records of this topic. For example, after a new node goes online, it needs to monitor the operation of other nodes. These nodes may release a message saying that they are "running normally" every long period of time. Then the newly online node needs to understand the release history of other nodes. Information to determine its running status, that is, it hopes to receive historical data published by other nodes before it went online. This situation can be achieved by simply configuring QoS. The new node can learn how long and how long the data stream of the node was before it went online, and pay attention to its historical data, etc.
(5) After the new node responsible for monitoring goes online, it is necessary to monitor the operation of other nodes. Usually, these nodes publish a message every hour saying that they are "running normally", but it is also possible that the "running normal" node publishes first, and the monitoring node releases it half an hour later. At this time, whether the monitoring node can still receive The data released by other nodes before it went online? In this case, it also needs to be configured through QoS. QoS can configure how long and how long the data flow of the new node is before it goes online, and pay attention to its historical data, etc.
Furthermore, QoS can provide the performance, predictability and resource controllability required by real-time systems, and can guarantee the modularity, scalability and robustness of the publish/subscribe model. Therefore, DDS can meet very complex and very flexible data flow requirements.
In contrast, SOME/IP only solves the publish-subscribe problem, but because there is no such QoS, the result is that many functions that can be realized by automatically configuring service policies need to be realized by software developers writing code, which will cause Waste a lot of time.
In addition, due to the lack of QoS, SOME/IP cannot solve the problem of packet loss when the amount of data is large, causing instructions to be stuck somewhere and unable to be sent out, and then the entire system cannot operate normally.
05
Different application scenarios
From the perspective of application scenarios, SOME/IP is more biased towards in-vehicle networks and can only be used in network environments based on IP type network layers, while DDS has no special restrictions on transmission methods and is not suitable for non-IP based network environments. Networks such as shared memory, cross-core communication, PCI-e and other network types can be supported. Moreover, DDS also has a complete Internet of Vehicles solution. Its unique DDS Security and DDS Web functions can provide users with a one-stop car-cloud-mobile solution.
In commercial implementation, DDS and SOME/IP are in direct competition. According to a RIT representative, for users, DDS and SOME/IP are a "choice of two."
However, Bi Xiaopeng, Neusoft Ruichi Marketing General Manager Mao Haiyan, and Junlian Zhixing Chief Architect Wang Haowei all believe that although DDS and SOME/IP have a strong competitive relationship, they can also coexist.
Bi Xiaopeng said that some OEMs use both DDS and SOME/IP, but the usage scenarios are different—sometimes it communicates between processes on a core, and sometimes it communicates between cores. , sometimes the domain controller communicates with other car entertainment systems, etc. "Now it is really not necessary to choose one or the other. It is also possible to choose DDS for some scenarios and SOME/IP for other scenarios."
Mao Haiyan said that in AP AUTOSAR, some standard frameworks provided by CM are compatible with both DDS and SOME/IP. "We have used both SOME/IP and DDS. Generally speaking, SOME/IP emphasizes communication and is relatively small in size; DDS has more functions, but is relatively large in size and needs to be tailored before it can be used for autonomous driving."
Wang Haowei pointed out that DDS is suitable for the autonomous driving domain, while SOME/IP can be extended to the entire vehicle domain.
Vector product expert Cai Shouqun said: "DDS and SOME/IP have been used in some projects we have been involved in." Cai Shouqun even believes that DDS and SOME/IP are not competitive. They are reasonable as long as they exist, and users can choose according to their needs.
So, in practice, who has a higher market share?
Bi Xiaopeng said: "Because SOME/IP itself is a communication standard formulated for the automotive industry, the usage rate of SOME/IP will be slightly higher before, and DDS has only been gradually adopted by many new car manufacturers and companies in the past two years. adopted by OEMs. But judging from the trend, in the future, the market share of DDS will be greater than that of SOME/IP."
Of course, "DDS is better than SOME/IP" is mainly the argument of DDS manufacturers. In order to avoid the opinions of this article being influenced by the positions of manufacturers, the author asked Vector Cai Shouqun for confirmation with these doubts. In this regard, Cai Shouqun’s answer is as follows——
"Many people now say that DDS is better than SOME/IP, largely from the perspective of richness of functions. Indeed, DDS contains more functions than SOME/IP, but it is said that DDS is better than SOME/IP just for this reason. It is inappropriate for SOME/IP. It is like comparing a car with an engine:
SOME/IP is the product of AUTOSAR CP. The design principle of AUTOSAR is to modularize the functions, and realize the high reusability of the modules by improving the granularity of the modules; and then improve the modules through continuous reuse and continuous testing. Therefore, SOME/IP did not consider continuously adding functions when it was first produced. For example, SD used in conjunction with SOME/IP is a separate module.
In contrast, the additional QoS provided by DDS is implemented in the Ethernet controller driver based on VLAN in AUTOSAR CP; data is stored in AUTOSAR with a separate storage management module; Security also has corresponding communication security in AUTOSAR and encryption management module.
"DDS manufacturers believe that, compared to SOME/IP, DDS has other available functions besides providing a communication protocol. But in fact, these functions are carried out by other functional modules whether in CP or AP. In addition, deployment can be selected based on system requirements. SOME/IP is only a part of CP/AP.
"On the other hand, the rich functions of DDS will inevitably require it to occupy more resources. In the field of automotive MCUs, resources are a very sensitive topic. To run DDS in the MCU (including the real-time core of the SoC chip), you can only Artificial tailoring of project-level functions makes it difficult to reuse across projects and platforms, making it difficult to achieve mature productization; moreover, engineering tailoring during the development phase and subsequent testing will significantly increase project costs.
“Of course, this is just the current situation that I personally see. I don’t know if the commercial version of DDS is already considering functional modularization and tool configurability within DDS to make up for the shortcomings in this area. (Jiuzhang Zhijia is here After seeking verification from RTI agent Chuangjing Technology, the feedback we received is: Judging from our current mass production and application projects, many customers have deployed DDS in multiple generations of products containing MCUs. DDS is very important in terms of reusability. There is no "immaturity" problem.)
"In addition, another problem with DDS is that it cannot be perfectly integrated into the existing automotive electronic and electrical design, development, and testing tool chains. Although we have already started to support DDS in design (PREEvision) and testing (CANoe) , but the work in this area has just begun, and the tools of both sides need to be constantly tested and run-in, and seamless compatibility cannot be achieved in the short term.
"From a protocol perspective, DDS is a data-oriented access system, suitable for multi-node, big data interaction application scenarios; SOME/IP is a service-oriented access system, which can be easily used for RPC (remote procedure call) ) and change notifications. For data throughput, there is no significant difference in the performance of DDS and SOME/IP in terms of the proportion of valid data.
“So, I have always believed that DDS and SOME/IP will coexist in vehicle communications, and APPs can choose appropriate communication channels based on application scenarios. This is why AUTOSAR AP supports both DDS and SOME/IP.
"We also know that there are indeed some OEMs currently considering using DDS as the only backbone network (central computing platform + azimuth domain controller) communication protocol, but from the perspective of maturity, resource occupation (there must be MCU-based nodes on the backbone network) and From the perspective of the tool chain, we think it is still open to question.”
References:
Autonomous driving communication middleware
https://blog.csdn.net/qq_23981335/article/details/106563676
Catch all automotive Ethernet SOME/IP in one place (Part 1)
https://mp.weixin.qq.com/s/kDDIvnijKo2tn07t20M4Cg
Catch all automotive Ethernet SOME/IP in one place (Part 2)
https://mp.weixin.qq.com/s/iMi1TVhhUK1xZbuOlSZUZw
Middleware DDS (Data Distribution Service)
https://zhuanlan.zhihu.com/p/428892842
Dialogue with Huayu Tongruan Bi Xiaopeng: Smart driving on domestic roads, some people open the road when they encounter mountains, and some people cross bridges when they encounter water | Huayu Wiki
https://mp.weixin.qq.com/s/IVZtiOwUOwqdiIv2_OztyA
Understand the "middleware" of autonomous driving in one article
https://zhuanlan.zhihu.com/p/372712318
Introduction to RTI DDS
https://blog.csdn.net/liulihuo_gyh/article/details/79704062
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 WeChat account.
Note: Be sure to note your real name, company and position when adding WeChat
Waiting for the information, thank you!
Operating system exchange group
Professionals in the field of operating system, if you want to join the group communication, you can scan the QR code on the right to add staff WeChat, and provide a business card, and then pull you into the group.
Note: Be sure to note your real name, company and position when adding WeChat
Waiting for information, thank you
About submission
If you are interested in contributing to "Nine Chapters of Intelligent Driving" ("knowledge accumulation and compilation" type articles), please scan the QR code on the right and add the staff WeChat.
Note: Be sure to note your real name, company and position when adding WeChat
And information such as submission intention, thank you!
Quality requirements for "knowledge accumulation" manuscripts:
A: The information density is higher than most reports of most brokerage firms, and not lower than the average level of "Nine Chapters Smart Driving";
B: Information must be highly scarce, and more than 80% of the information needs to be unavailable in other media. If it is based on public information, it needs to have a particularly powerful and exclusive perspective. Thank you for your understanding and support.
Recommended reading:
◆ One of the autonomous driving middleware: Is AUTOSAR being "marginalized"?
◆ This driverless company is actually positioned as an “environmental sanitation company”
◆ This driverless company actually started a "manned driving" transportation business
◆ Two pain points of autonomous driving simulation test
◆ Understand the autonomous driving simulation test scenarios and scenario library in one article