Lightweight DDS middleware and its application in AUTOSAR Classic platform

Abstract

The present invention relates to a lightweight DDS middleware and a construction method thereof under an AUTOSAR Classic platform. The lightweight DDS middleware includes: a data-centric publishing and subscription specification DCPS layer, located at the upper layer of the DDS middleware, and used to interact with the application layer. The setting of the DCPS layer includes: removing all communication entities related to the DCPS layer; providing the application layer with a programming interface for creating a real-time publishing and subscription RTPS layer communication entity and providing a programming interface for configuring a quality of service policy; a real-time publishing and subscription RTPS layer, located at the lower layer of the DDS middleware, and used to assume the data publishing and subscription functions of the DDS protocol stack, and the quality of service policy configuration. Compared with the prior art, the present invention removes all entities of the DCPS layer and only retains the communication entity of the RTPS layer. The communication entity of the RTPS layer will directly interact with the application layer through the programming interface provided by the DCPS layer. In addition, the RTPS layer is subjected to necessary lightweight design, thereby reducing the consumption of resources such as Flash, RAM, and CPU by the DDS protocol stack.

Description

Technical Field

[0001] The present invention relates to the technical field of vehicle-mounted Ethernet communication, and in particular to a lightweight DDS middleware and an application thereof in an AUTOSAR Classic platform. Background Art

[0002] Data Distribution Service (DDS) is the current mainstream data-oriented middleware. Its excellent performance has been verified through long-term and extensive applications in the fields of military, aerospace, and medical. As early as 2018, AUTOSAR integrated DDS technology, and ROS2 also adopted DDS as its communication middleware. DDS provides a reliable, real-time, data-oriented communication method to meet the complex data distribution and communication needs of intelligent connected vehicles.

[0003] However, with the continuous development of automotive electronic systems, the resource consumption of DDS has become an issue that cannot be ignored. The traditional implementation of DDS consumes a lot of threads, random access memory (RAM) and Flash, which is an important challenge for automotive electronic systems. Especially in resource-constrained embedded systems and edge computing environments, the resource usage of DDS may lead to performance degradation and even affect the stability of the entire automotive system.

[0004] Most of the existing DDS lightweight work is based on the XRCE DDS specification developed by the Object Manage Group (OMG). This specification runs the complex DDS protocol stack on the proxy server through the client / agent method. The client only needs to run the lightweight XRCE DDS protocol stack, realizing the lightweight DDS design for resource-constrained hardware platforms. However, this method requires a centralized proxy server, which runs counter to the "decentralized" concept of the DDS protocol. In addition, in this client / agent communication mode, nodes running lightweight clients need to be forwarded by the proxy node when publishing / subscribing data, which undoubtedly increases the end-to-end latency of the data.

[0005] In summary, if the current DDS communication protocol wants to compete with the SOME / IP protocol and become one of the optional communication middleware technologies for automotive Ethernet under the AUTOSAR Classic platform, the following key technologies still need to be solved: lightweight design of the DDS protocol, while ensuring interoperability with other DDS implementations (that is, XRCEDDS in client / agent mode cannot be used), reducing the volume of DDS program code and reducing runtime RAM consumption. Summary of the invention

[0006] The purpose of the present invention is to overcome the defects of the above-mentioned prior art and to provide a lightweight DDS middleware and its application under the AUTOSAR Classic platform. By removing all entities of the DCPS layer and retaining only the communication entities of the RTPS layer, the communication entities of the RTPS layer will directly interact with the application layer through the programming interface provided by the DCPS layer. In addition, the RTPS layer is subjected to necessary lightweight design, thereby reducing the consumption of resources such as Flash, RAM, and CPU by the DDS protocol stack.

[0007] The purpose of the present invention can be achieved by the following technical solutions:

[0008] According to a first aspect of the present invention, there is provided a lightweight DDS middleware, which is applied to a vehicle-mounted platform and includes:

[0009] The data-centric publishing and subscription specification DCPS layer is located on the upper layer of the DDS middleware and is used to interact with the application layer. The setting of the DCPS layer includes: removing all communication entities related to the DCPS layer; providing the application layer with a programming interface for creating real-time publishing and subscription RTPS layer communication entities and providing a programming interface for configuring service quality policies;

[0010] The real-time publishing and subscription RTPS layer is located at the lower layer of the DDS middleware and is used to undertake the data publishing and subscription functions of the DDS protocol stack and service quality policy configuration.

[0011] Preferably, the setting of the DCPS layer further includes: removing the synchronization condition waiting mechanism and providing an asynchronous monitoring callback mechanism for notifying the application layer of corresponding state changes;

[0012] The asynchronous monitoring callback mechanism is specifically as follows: the application layer calls the initialization function in advance, registers the required callback function with the RTPS layer communication entity, calls the pre-registered callback function when the corresponding state of the DDS protocol stack occurs, and notifies the application layer.

[0013] Preferably, the programming interface in the DCPS layer specifically includes:

[0014] Create interfaces for RTPS communication participants, RTPS data topics, RTPS data readers, and RTPS data writers;

[0015] Data publishing interface, which is called by the application layer to publish data;

[0016] The service quality configuration interface is used to customize the personalized service quality strategy for the application layer;

[0017] Registering a callback function interface, so that the application layer can register the defined callback function into the DDS protocol stack as needed and interact with the DDS protocol stack; and

[0018] The data reading interface is used by the application layer to obtain data samples from the history cache of the data reader.

[0019] Preferably, the RTPS communication message in the RTPS layer includes an RTPS message and sub-messages constituting the RTPS message;

[0020] The processing of sub-messages includes: removing the processing of sub-message types related to large data sharding; and removing the processing of sub-message types related to reliability for common application communication entities in the DDS protocol stack, where the common application entity is an RTPS layer communication entity created by the application layer calling a programming interface;

[0021] The simple discovery protocol is implemented and the related built-in entities are retained to handle the three types of sub-messages: HeartBeat, AckNack, and Gap.

[0022] Preferably, the RTPS layer further includes on-site serialization and assembly of RTPS messages, specifically:

[0023] The sub-message types contained in the RTPS message related to data transmission are limited to InfoTS, InfoDST and Data; when assembling into a complete RTPS message, the memory size occupied by each RTPS message containing the data sample to be published by the data writer is determined in advance;

[0024] When creating the data sample cache space inside the data writer, the DDS protocol stack creates memory to carry a complete RTPS message, serializes the data to be published to the corresponding offset in the cache, and fills in the RTPS header and the other two sub-messages to complete the assembly of a complete RTPS message.

[0025] Preferably, the service quality policies of the DCPS layer are all transferred to the RTPS layer through the programming interface of the service quality policy configuration, and are managed by the communication entity of the RTPS layer;

[0026] The service quality strategy is integrated with the vehicle-mounted time-sensitive Ethernet communication, reducing the 22 service quality strategies to two categories and 8 types, specifically:

[0027] Category 1: Warning QoS policies, including deadline QoS policy, delay budget QoS policy, transmission priority QoS policy, and reliability QoS policy. Only the built-in entities in the second discovery phase of the DDS middleware implement the reliability QoS policy, while ordinary application entities all work in the best-effort mode.

[0028] The second category: basic service quality policies, which are used to implement related processing logic, including persistence service quality policies, historical resource service quality policies, resource limitation service quality policies and survivability service quality policies.

[0029] Preferably, the method further includes: directly mapping and filling the data of the transmission priority service quality policy configured at the application layer into the PCP field of the virtual local area network data frame, specifically:

[0030] The priority information is placed at the starting four bytes of the buffer to be sent. When the underlying UDP protocol stack encapsulates the UDP datagram, it directly indexes the PCP field of the virtual LAN data frame, and maps the priority value stored in the buffer to be sent to 0-7. The mapped data is then filled into the 3-bit PCP field in the data frame.

[0031] According to a second aspect of the present invention, there is provided an application of a lightweight DDS middleware on an AUTOSAR Classic platform, comprising:

[0032] The lightweight DDS middleware is set on the upper layer of the TCP / IP module as a SocketOwner of the TCP / IP module, and the type is configured as a complex device driver; the DDS protocol stack works on the UDP protocol stack of the TCP / IP module, including at least three main AUTOSAT Tasks to support the operation of the protocol stack;

[0033] The working tasks of the lightweight DDS middleware include:

[0034] Initialization task, used to complete the initialization of the protocol stack, and the application layer calls the interface to create the required communication entity;

[0035] The receiving data processing task is used to complete the parsing and subsequent processing of the received RTPS message. It is an extended task and is triggered by the underlying data receiving interrupt;

[0036] Timer tasks are used to process various timers registered in the protocol stack.

[0037] Preferably, the data receiving and processing task is an extended task, which is triggered by the bottom layer data receiving interrupt, specifically: when the system receives a new RTPS message, the data receiving interrupt of the Eth module is triggered, and through the callback function of the EthIf module and the TCP / IP module, the receiving callback function of the DDS protocol stack is finally called;

[0038] The receive callback function of the DDS protocol stack performs two tasks: creating a copy of the received data; setting the receive event through the SetEvent() interface of AUTOSAR Classic to trigger the DDS receive processing function to enter the ready state from the waiting state and wait for the scheduling of the operating system;

[0039] After the receiving processing task is scheduled for execution, the RTPS message to be processed is taken out from the data cache queue for subsequent processing actions.

[0040] Preferably, the timer task is an extended task, including two waiting points: the first waiting point is activated by the timer insertion operation in other tasks; the second waiting point is activated by the timer warning Alarm set by itself;

[0041] When the timer task has processed the expired timers in the queue, if there is no timer operation to be processed in the current timer queue, the extended task enters the first waiting point; otherwise, if the earliest timer in the current timer queue has not expired, the extended task enters the second waiting point;

[0042] Before entering the second waiting point, a warning Alarm is set for the timer extension task, and the expiration time of the warning Alarm is the time difference between the current time and the earliest timer.

[0043] Compared with the prior art, the present invention has the following beneficial effects:

[0044] 1) The present invention designs a lightweight DDS middleware for the vehicle-mounted resource-constrained MCU hardware platform. On the basis of retaining a simple discovery protocol to ensure interoperability with other DDS implementations, the DCPS layer and RTPS layer of the DDS protocol stack are lightweight designed. By removing all entities of the DCPS layer and retaining only the communication entities of the RTPS layer, the communication entities of the RTPS layer will directly interact with the application layer through the programming interface provided by the DCPS layer, thereby reducing the consumption of resources such as Flash, RAM, and CPU by the DDS protocol stack.

[0045] 2) The synchronization condition waiting mechanism defined in the DCPS specification in the DCPS layer is removed, reducing the runtime resource consumption of the protocol stack.

[0046] 3) Considering that the vehicle-mounted MCU node generally does not send data with excessive load and the application layer can actively fragment the large data, the processing of sub-message types related to large data fragmentation is removed from the RTPS communication message to reduce the CPU occupancy rate when the DDS protocol stack is running; considering that after the key data stream is lost in the vehicle scenario, it is difficult to meet the system's latency requirements for the key data stream by retransmission, so for the common application communication entities in the protocol stack, the processing of reliability-related sub-message type messages is removed, and the reliability of data transmission is ensured by the underlying vehicle-mounted time-sensitive Ethernet.

[0047] 4) The simple discovery protocol is implemented, and the processing of the three types of sub-messages, HeartBeat, AckNack, and Gap, by the relevant built-in entities is retained to ensure the protocol interoperability between the lightweight DDS design and other DDS implementations.

[0048] 5) When the protocol stack creates the internal data sample cache space of the data writer, it creates enough memory to carry a complete RTPS message. Subsequently, it only needs to serialize the data to be published to the corresponding offset in the cache, and fill in the RTPS header and the other two sub-messages to complete the assembly of a complete RTPS message. The RTPS message is continuous in the memory space, which greatly facilitates the processing of the underlying Ethernet protocol stack. By serializing and assembling the RTPS message in situ, the publishing efficiency of the DDS protocol stack is improved to avoid additional data copies caused by scattered message fragments or dependence on the underlying interface that supports scattered data transmission.

[0049] 6) Considering the actual needs of vehicle-mounted network communication, the lightweight DDS middleware designed in the present invention adopts a method of integrating service quality strategy with vehicle-mounted time-sensitive Ethernet communication, and reduces 22 service quality strategies to 8 to reduce the resource consumption of the DDS protocol stack.

[0050] 7) Directly map and fill the data of the transmission priority service quality policy configured at the application layer into the PCP field of the virtual LAN data frame. This direct data priority mapping method can avoid the performance overhead and transmission delay caused by frequently calling the socket attribute configuration interface to modify the socket transmission priority in the case of multiple different priorities. That is, the priority transmission of high-priority data streams is guaranteed through the TSN transmission protocol, reducing the bounded end-to-end delay of key data streams under high network load conditions.

[0051] 8) For the AUTOSAR Classic platform, by designing the three main tasks in the DDS protocol stack, namely the initialization task, the received data processing task, and the timer task, the deployment and application of the data-centric DDS protocol stack on the vehicle MCU platform is realized, promoting the overall support and deployment of the DDS protocol stack by the vehicle network platform. BRIEF DESCRIPTION OF THE DRAWINGS

[0052] Figure 1 It is a schematic diagram of the communication process of the lightweight DDS protocol stack software;

[0053] Figure 2 This is a schematic diagram of the software architecture of the DDS protocol stack that complies with the standard;

[0054] Figure 3 This is a schematic diagram of the lightweight DDS protocol stack software architecture;

[0055] Figure 4 Simple discovery phase execution process for DDS protocol stack software;

[0056] Figure 5 This is a schematic diagram of the data redundancy mechanism for key data streams in the lightweight DDS protocol stack;

[0057] Figure 6 A schematic diagram of a method for mapping lightweight DDS protocol stack software transmission priority to Ethernet frame priority;

[0058] Figure 7 This is a schematic diagram of the overall data serialization and packaging process in the lightweight DDS protocol stack software;

[0059] Figure 8 This is a schematic diagram of the deployment of lightweight DDS protocol stack software on the AUTOSAR Classic platform;

[0060] Fig. 9 This is a schematic diagram of the message receiving process of the lightweight DDS protocol stack software on the AUTOSAR Classic platform;

[0061] Fig.10 This is a schematic diagram of the scheduled task execution flow of the lightweight DDS protocol stack software on the AUTOSAR Classic platform. DETAILED DESCRIPTION

[0062] The following will be combined with the drawings in the embodiments of the present invention to clearly and completely describe the technical solutions in the embodiments of the present invention. Obviously, the described embodiments are part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work should fall within the scope of protection of the present invention.

[0063] Example

[0064] Figure 1 The figure shows the software communication process of the lightweight DDS protocol stack, in which the DDS communication middleware runs on the upper layer of the UDP network protocol stack. When the data writer publishes a new data sample, the data publishing interface provided by the DDS protocol stack is called to pass the data to the DDS protocol stack layer. Finally, the protocol stack will call the underlying UDP data sending interface to send the data point-to-point to the matching remote data reader. Since the DDS protocol stack works on the upper layer of the UDP protocol, it also requires corresponding Ethernet network cards, physical layer and other peripheral devices and corresponding Ethernet drivers to support the sending and receiving of Ethernet data frames.

[0065] Further, Figure 1 The layered architecture of the DDS protocol stack software is shown. The Data Centric Publish and Subscribe (DCPS) layer is defined by the DDS v1.4 specification released by the Object Management Group (OMG), which provides an application interface for the application to interact with the protocol stack and is not related to the interoperability between different implementations of the protocol. The Real Time Publish and Subscribe (RTPS) layer is defined by the DDS-RTPS2.5 specification released by OMG. As the transport layer protocol layer of DDS, it specifies the protocol-related message format, data publishing / subscription processing logic, etc., and is a key part to ensure the interoperability between different implementations of the protocol.

[0066] In order to distinguish between DDS that complies with the OMG XRCE-DDS and DDS that complies with the DDS v1.4 / DDS-RTPS2.5 specification, unless otherwise specified, the DDS implementations mentioned later refer to DDS implementations that comply with the DDS v1.4 / DDS-RTPS2.5 specification, and the lightweight DDS implementation developed according to the OMG XRCE-DDS specification is called XRCE DDS. The lightweight DDS implemented in the present invention is based on the DDSv1.4 / DDS-RTPS2.5 specification, and performs a large amount of tailoring and optimization on the DCPS layer and RTPS layer of the protocol to minimize the consumption of chip resources by the DDS protocol stack. Compared with XRCE DDS, the lightweight DDS implementation proposed in the present invention does not require the participation of proxy nodes, and can match and connect entities with other standard DDS implementations through the dynamic discovery protocol specified in the protocol, thereby avoiding the various disadvantages brought about by the introduction of intermediate proxy nodes in XRCE DDS.

[0067] Combine the following Figure 2, 3 The specific lightweight design method of this lightweight DDS protocol stack design at the DDS-DCPS layer and the DDS-RTPS layer is described in detail. Figure 2 The standard DDS software architecture is shown below. Figure 3 The software architecture of the lightweight DDS implementation of the present invention is shown.

[0068] First, as the top layer of the DDS protocol stack, the DCPS layer will interact directly with the user program, which is reflected in the upper-level application calling the protocol stack entity creation interface to create the communication participants and data reader / writer entities required by the application; creating the Quality of Service (QoS) policy required by the application, and configuring the created entity according to the quality of service; defining the event callback function and registering it with the created communication entity; calling the protocol stack initialization interface to initialize the protocol stack and enable the protocol stack to start running.

[0069] Furthermore, after the protocol stack is running, the application needs to actively call the data publishing interface provided by the DCPS layer and use a created data writing entity to publish the data. When the data reading entity of the protocol stack receives the data published by other data writing entities, it will call the callback function registered by the application to notify the application of the new data available event. After that, the application can call the data reading interface provided by the protocol stack to obtain the latest data from the data reading entity.

[0070] Furthermore, the DDS v1.4 specification defines the application / protocol stack interaction mode of Wait-sets, which provides a convenient synchronous programming interface for application programs to develop DDS applications. However, this method is particularly dependent on the corresponding programming interface provided by the operating system, such as the conditional variables provided by the CPP STL library, the semaphore mechanism provided by FreeRTOS, and the related thread programming interface provided by the POSIX specification. Compared with the interaction in the form of callback functions, the interaction in the Wait-sets mode undoubtedly increases the resource consumption of the protocol stack. Therefore, the present invention excludes the interaction mode of the Wait-sets mode and only implements the protocol stack / application interaction strategy in the form of callback functions.

[0071] Furthermore, compared with the RTPS layer, the DCPS layer only focuses on the interaction between the protocol stack and the application layer, and does not focus on how the data is published or how the received data is processed. In simple terms, the implementation of the DCPS layer does not affect the protocol interoperability between different DDS implementations. It only affects the cross-platform compatibility of upper-layer applications because it provides a programming interface to upper-layer applications. Therefore, when an application needs to migrate between different DDS implementations, application layer developers need to perform certain adaptation work based on the programming interface provided by the specific DDS implementation. Therefore, if Figure 3 As shown, for the DCPS layer design, the present invention only implements the necessary programming interfaces for use by the application layer, and removes the DCPS layer entities defined in the DDS v1.4 specification, including DDS data participants, DDS data publishers, DDS data subscribers, DDS data topics, DDS data readers, and DDS data writers, and only relies on the data reading and writing related entities of the RTPS layer to publish and subscribe to data, and mounts Topic, QoS, callback functions, etc. to the communication entities of the RTPS layer, which are monitored and maintained by them.

[0072] Furthermore, the minimum programming interface set provided by the present invention includes interfaces for creating RTPS communication participants, RTPS data topics, RTPS data readers and RTPS data writers, a data publishing interface for applications to call to publish data, a service quality configuration interface for applications to customize personalized QoS policies, an interface for registering callback functions for applications to register defined callback functions in the protocol stack as needed and interact with the protocol stack, and a data reading interface for applications to obtain data samples from the historical cache of the data reader. The QoS service quality policy specified by the DDS v1.4 protocol is moved down to the RTPS layer for processing.

[0073] The present invention has made a lot of content and functional tailoring to the DCPS layer defined in the DDS specification, at the expense of the richness of the DCPS layer interface functions, and has made considerable lightweight tailoring to the DDS specification. The lightweight DCPS layer focuses on realizing the data publishing / receiving interaction between the protocol stack and the application layer, and can meet the data publishing and subscription requirements of the resource-constrained platform.

[0074] Second, as Figure 3As shown in the figure, after a lot of lightweight tailoring design of the DCPS layer, the RTPS layer needs to undertake more functional implementations, including QoS policy configuration and inspection of communication entities, and historical cache management of data readers and writers. The RTPS layer is mainly defined by the OMG DDS-RTPS2.5 specification, which is a specification that must be implemented and complied with to ensure the interoperability of different DDS implementation protocols, and plays a vital role in the DDS protocol. As the transport layer specification of the DDS protocol, based on the aforementioned DCPS lightweight, the RTPS layer undertakes most of the functional implementations of the DDS protocol, which is reflected in the following aspects: a) It is necessary to create and maintain related communication entities and communication status; b) It is necessary to execute the dynamic discovery process implemented by DDS to complete the mutual discovery and matching work with other remote communication entities in the network; c) It is necessary to manage the historical cache of data readers and writers; d) It is necessary to match and check the QoS policy during the communication process; e) It is necessary to assemble messages during the publishing process, parse and process the received RTPS messages, and update the status of the protocol stack.

[0075] Furthermore, if Figure 2 As shown in the figure, in the DDS v1.4 / DDS-RTPS2.5 protocol, both the DCPS layer and the RTPS need to create corresponding communication entities for the protocol stack, and then jointly maintain the running status of the protocol stack, which is reflected in: a) The communication entity of the DCPS layer is directly associated with the QoS policy configured by the application layer, and the relevant policy is mapped to the relevant attributes of the communication entity of the RTPS layer; b) The communication entity of the DCPS layer directly carries the callback function registered by the application layer. When the corresponding state change event occurs, the RTPS layer obtains the associated DCPS layer entity and calls the corresponding callback function. Figure 3 As shown, the present invention removes all entities of the DCPS layer and only retains the communication entities of the RTPS layer, so the RTPS layer must directly implement the above two functions. In addition, when the communication entities of the DCPS layer are removed, the programming interface provided by the DCPS layer to the application will directly interact with the RTPS layer, which is reflected in: a) the entity creation interface directly creates the communication entity of the RTPS layer; b) the data publishing interface directly uses the RTPS layer data publisher to publish data samples; c) the QoS policy obtained by the QoS configuration interface is directly managed and used by the RTPS layer communication entity; d) the callback function registration interface directly registers the callback function defined by the application to the RTPS layer communication entity; e) the data reading interface directly accesses the historical cache of the RTPS layer data reader and obtains data samples from it.

[0076] It should be noted that the DCPS layer defines data subscriber / publisher entities to carry data reader / writer entities, but the RTPS layer only specifies data readers and data writers. Some standard implementations add data publishing / subscribing entities at the RTPS layer to manage data reader / writer entities at the RTPS layer. The lightweight DDS only implements data participants and data readers / writers at the RTPS layer to further reduce the resource consumption of the protocol stack.

[0077] Furthermore, if Figure 3 As shown, after the DCPS layer is subjected to the lightweight tailoring design, the communication entity of the RTPS layer will interact with the application layer directly through the programming interface provided by the DCPS layer. Similar to the standard DDS implementation, the application layer calls the entity creation interface to create the protocol stack communication entity required by the application. In the lightweight design, the application layer directly creates the lightweight RTPS layer entity instead of the DCPS layer entity. However, this solution is also transparent to the application, that is, the application only needs to call the interface of the protocol stack to create the required entity, without having to worry about the creation and maintenance of the communication entity within the protocol stack. The application development process is the same.

[0078] When the application layer calls the data publishing interface, the protocol stack will store the serialized data directly into the history cache of the RTPS layer data writer according to the data serialization method associated with the data writer, and traverse the remote data readers matching the data writer, and perform point-to-point data publishing according to the address information of the remote data readers recorded locally. Correspondingly, the RTPS layer communication entity directly carries the service quality policy configuration information configured by the application layer, and checks the service quality of data interaction during the operation of the protocol stack according to the configured QoS policy. The callback function is also directly registered in the RTPS layer entity by calling the callback registration interface by the reference layer. When new data arrives, the protocol stack directly obtains the callback function pre-registered in the RTPS layer data reader and notifies the application layer of the new data available event. Compared with the standard DDS implementation, the DDS lightweight implementation, by cutting the DCPS layer entity, the RTPS layer will directly interact with the application layer, reducing the processing process required for data publishing / receiving, so it can reduce the protocol stack's processing delay for data, while reducing the CPU running time of the protocol stack and reducing the CPU resource occupation of the protocol stack.

[0079] The Simple Discovery Protocol is the basic discovery protocol defined in the DDS specification and is a protocol that the RTPS specification requires every standard DDS implementation to support. It is precisely because of the mechanism support of the discovery protocol that the application layer only needs to know the name of the topic of interest when publishing and subscribing data, and can publish and subscribe to related data without the need for specific information such as the address of the data publisher / participant. Figure 4As shown, this information will be collected and matched by the built-in communication entities participating in the discovery phase during the dynamic discovery phase, and the communication connection will also be established by these built-in communication entities. Therefore, in order to support the dynamic discovery protocol and ensure the interoperability between the lightweight DDS protocol stack and other standard DDS implementations, the present invention also implements and supports the simple dynamic discovery protocol.

[0080] Specifically, Figure 4 As shown, the simple discovery protocol includes two stages: Simple Participant Discovery Protocol (SPDP) and Simple Entity Discovery Protocol (SEDP). SPDP is used for discovery and matching at the communication participant level. There are two main communication entities participating in this stage: SPDP Built-in Participant Writer and SPDP Built-in Participant Reader. Both built-in communication entities work in Best Effort mode. When the local protocol stack receives the SPDP discovery message sent by other nodes in the network through the SPDP built-in participant reader, it will create a local information entity for the remote participant to store the relevant information of the remote node, and then create the information entity of the remote data writer / reader in the SEDP stage, and match it with the local built-in communication entity participating in the SEDP stage, and enter the SEDP discovery stage.

[0081] Furthermore, the SEDP stage involves multiple built-in communication entities, and the DDS specification requires that these built-in entities all work in Reliable mode. Among them, SEDP publishes built-in writers, SEDP publishes built-in readers, SEDP subscribes to built-in writers, and SEDP subscribes to built-in readers are the four most important communication entities. Publishing-related SEDP built-in entities are used to discover and match data writer entities created by applications, and subscription-related SEDP built-in entities are used to discover and create data reader entities created by applications. Through the cooperation of these four built-in entities, the discovery and matching of local and remote data writers / data readers are ultimately completed.

[0082] Furthermore, when the local SEDP stage finds a remote data writer, it will match its relevant information with the local data reader. If the match is successful, an information entity will be created for the remote data writer to store and maintain the relevant information of the remote writer, and a connection will be established between the information entity and the local data reader. Similarly, when the local SEDP stage finds a remote data reader, it will match its relevant information with the local data writer. If the match is successful, an information entity will be created for the remote data reader to store and maintain the relevant information of the remote writer, and a connection will be established between the information entity and the local data writer. When the local data writer has a new data sample to be published, it will traverse all connected remote information entities and extract the address of the remote data reader as the destination address, and finally complete the data transmission.

[0083] As the transport layer of the DDS protocol, the RTPS layer defines 13 message types to support data interaction of the protocol stack. In the automotive Ethernet communication scenario, for resource-constrained embedded MCUs, lightweight DDS design is used as the principle, focusing on the MCU node to interact with other nodes in the network through the DDS protocol. The message type can be further tailored to lightweight the protocol stack processing logic.

[0084] Specifically, DataFrag, HeartBeatFrag, and NackFrag messages are used for fragmented DDS message transmission and for retransmission of fragmented messages. Considering that MCU generally does not need to transmit data packets with large loads, and when the load is large, the application can actively slice the data to be sent and send the data through Data messages. Therefore, the protocol overhead brought by the fragmentation mechanism is far less than the value it can bring. Therefore, the message fragmentation mechanism is not implemented in the lightweight DDS design, and the processing logic related to these three types of messages does not need to be implemented.

[0085] Furthermore, since in the lightweight DDS design, all communication entities created by applications work in BestEffort mode, the processing logic of HeartBeat messages, AckNack messages, and Gap messages for these entities does not need to be implemented. In addition, InfoReply messages are rarely used in the data transmission process, so the solution does not implement the processing logic related to this message.

[0086] It should be noted that the DDS protocol defines a virtual data domain, and communication is only possible between communication participants in the same domain. Considering that in the vehicle communication scenario, there is generally only one communication virtual data domain, the MCU only needs to create one communication participant to communicate with other DDS communication participants in the network. The lightweight solution considers implementing only one communication participant to accommodate all data writers and data readers, so as to further reduce the resource consumption caused by the protocol stack creating multiple communication participants.

[0087] The DDS specification defines 22 different Quality of Service (QoS) policies, and each policy has its own unique role for DDS data transmission. Among them, some policies are closely related to the operation of the protocol stack and must be configured; some QoS policies do not affect the operation of the protocol stack and the matching of the communication entity, and can use the default configuration or not set. In the application scenario of in-vehicle Ethernet communication, especially for resource-constrained embedded MCUs, implementing all QoS policies will greatly consume the chip's Flash and RAM resources and increase the chip's runtime CPU load rate. Combined with the requirements of in-vehicle communication application scenarios, the lightweight DDS design trims the QoS policies in the specification and only implements 8 of them. In addition, the implementation of some QoS is combined with the Time-Sensitive Network (TSN) technology to further reduce the lightweight protocol stack's CPU resource consumption.

[0088] Time-Sensitive Network (TSN) is a collective name for a series of data link layer protocol specifications developed by the IEEE 802.1TSN working group. It is used to guide and develop low-latency, low-jitter Ethernet local area networks with deterministic transmission time. It is an enhanced function implementation of traditional Ethernet in specific application environments such as automobiles. Compared with traditional Ethernet, TSN has the advantages of stronger real-time performance, higher reliability, and scheduling delay and resource management functions. Specifically, the main protocol standards related to TSN that have been released are shown in Table 1.

[0089] Table 1

[0090]

[0091] Furthermore, the eight QoS strategies implemented by the lightweight DDS design scheme include deadline QoS, latency budget QoS, transport priority QoS, durability QoS, history QoS, resource limit QoS, liveliness QoS, and reliability QoS.

[0092] Deadline QoS indicates the maximum update period of data and is applicable to periodic data transmission. For data readers, the deadline value they set must be greater than the deadline value provided by data writers. Otherwise, data readers and data writers will not be able to match due to QoS rule violations.

[0093] Latency Budget QoS indicates the transmission latency level of data. Similarly, the budget value specified by the data writer should be greater than the value specified by the data reader. Otherwise, the data writer cannot meet the latency requirement of the data reader and cannot match.

[0094] Transport Priority is mainly used by data writers to guide the underlying protocol stack to send high-priority data first.

[0095] Specifically, in the aforementioned lightweight DDS design, these three QoS strategies are mainly used for the configuration of TSN switches, and the lightweight DDS protocol stack will not design additional processing mechanisms to support the inspection and guarantee of these three QoS strategies.

[0096] Durability QoS has three different categories: Volatile, Transient Local, and Persistent. Since permanent storage requires storing all historical data, which requires a lot of storage space, the aforementioned lightweight design only supports the first two quality of service strategies. For the Transient Local type strategy, it is mainly used to send historical messages to remote data readers who participate in the communication later.

[0097] History QoS indicates the history cache size of the data reader / writer, that is, how much history data can be stored.

[0098] Resource Limit QoS is used together with History QoS to limit the upper limit of the history cache.

[0099] Liveliness QoS is used to determine the liveliness of communication entities. In the lightweight design, this QoS is only used to determine the liveliness of remote communication entities, and during the implementation process, no additional communication entities are created for the communication of liveliness information. The liveliness of local entities is generally triggered by periodic discovery messages, so the liveliness duration setting should be slightly longer than the discovery message sending period, so that when the remote entity receives the periodic discovery message, it will assert that the entity is alive.

[0100] Reliability QoS is used to ensure the reliability of data transmission, mainly through the confirmation retransmission mechanism. Specifically, when packet loss occurs due to network congestion, link failure, etc., the data subscriber will request the data publisher to retransmit the lost data samples through a message. There are two optional types of QoS: Reliable and Best Effort. The former is reliable. When packet loss occurs, the protocol stack will retransmit the lost data packets through the confirmation retransmission mechanism. The latter is best effort, that is, when packet loss occurs, the protocol stack will not request retransmission.

[0101] It should be noted that the DDS-RTPS2.5 protocol stipulates that the built-in communication entities participating in the Simple Entity Discovery Protocol (SEDP) all operate in reliable mode. Therefore, in order to ensure that the lightweight DDS protocol stack can realize the discovery and matching of communication entities through the dynamic discovery phase with other standard DDS, the lightweight design must still ensure that the communication entities participating in SEDP operate in reliable mode. However, the confirmation and retransmission mechanism will undoubtedly increase the resource consumption of the protocol stack and increase the CPU's operating load rate. Moreover, in the in-vehicle communication scenario, for critical data streams, data retransmission is bound to increase the data transmission delay, thereby affecting system performance. Therefore, in the lightweight design, for ordinary entities in the data transmission phase, the confirmation and retransmission mechanism is removed, and they are only allowed to operate in best effort mode. As Figure 5 As shown, for the key data flow in the network, in order to ensure its reliability, the lightweight design scheme adopts the path redundancy mechanism provided by the 802.1CB protocol in the TSN protocol cluster.

[0102] Obviously, the introduction of the underlying TSN protocol can offload some of the functional implementations of the DDS protocol stack, further reduce the resource consumption of the protocol stack and reduce the CPU's operating load rate while ensuring data reliability.

[0103] On the third aspect, in order to realize the combination of the lightweight DDS design and TSN, the priority transmission of high-priority data streams is guaranteed through the TSN transmission protocol, and the bounded end-to-end delay of key data streams under high network load conditions is reduced. The lightweight DDS design invention provides a specific method for mapping the Transport Priority QoS value set at the application layer in DDS to the PCP field of the Ethernet VLAN data frame.

[0104] Specifically, Figure 6 As shown, the lightweight DDS protocol stack in the present invention works on the upper layer of the User Datagram Protocol (UDP), and sends and receives data through the network socket interface. Generally, when the application layer needs to control various attributes in the data transmission process, it is necessary to call the socket attribute modification function interface to personalize the attributes of the socket to change the various configurations used by the underlying protocol stack when sending data, such as modifying the VLAN Priority field. Specifically, the lightweight design reserves two sending-related sockets for the DDS protocol stack, and all data writers created by the subsequent application layer will use these two sockets to send data. If the Transport Priority QoS configured by the data writer has different priority values, the protocol stack needs to call the Socket attribute setting function provided by the protocol stack to set the VLAN Priority value of the Socket, and then write the transmission priority value set by the QoS into the PCP field of the VLAN data frame. Obviously, this method will bring a certain delay to data transmission because it needs to frequently call the Socket attribute setting function.

[0105] Furthermore, the lightweight DDS design provides a lightweight VLAN data frame priority setting method, such as Figure 6As shown. The aforementioned data writer history cache contains a fixed number of complete RTPS messages to be sent, and the memory occupied by them has been determined in advance when creating the data writer according to the topic and data type associated with it. In order to transmit data priority information between protocol stacks, the lightweight DDS protocol stack will apply for 4 more bytes of memory for each RTPS message memory block when applying for memory for the history cache. The first three bytes store the characters "P", "R", and "I" for subsequent priority setting checks, and the fourth byte is used to store the Transport Priority QoS priority value set by the application layer. It is worth noting that the priority field PCP in the VLAN data frame has only 3 bits and the allowed value is 0-7. Therefore, the DDS protocol stack needs to map the Transport Priority QoS priority value set by the application layer to the range of 0-7 when sending data, and write it to the starting fourth byte position of the RTPS message to be sent.

[0106] Furthermore, when the DDS protocol stack calls the underlying data transmission interface (here, the UDP transmission interface), the address of the message to be sent will be passed to the underlying layer as a parameter. Generally, the underlying transmission function needs to complete the copying of user-mode data to kernel-mode data, that is, to apply to the underlying Ethernet driver to obtain the kernel-mode data transmission cache, and according to the user data pointer passed in by the application, copy the user-mode data to be sent to the requested kernel-mode cache. Then, it is necessary to modify the underlying Ethernet transmission function to determine whether the four bytes before the user-mode data pointer are priority setting related data: whether the first three bytes are "P", "R", "I", and whether the fourth byte is between 0-7. If the conditions are met, it is necessary to obtain the VLAN PCP field corresponding to the kernel-mode data cache and write the priority value to the PCP field. In the vehicle-mounted embedded MCU platform, it generally runs a lightweight TCP / IP protocol stack software, which can be customized and configured to a high degree. The optional part of the IP datagram header can be removed, and the header is fixed to 20 bytes. Therefore, when filling the UDP data packet, the VLAN field can be accessed in the order of the UDP header, IP header, and MAC header, and then the PCP field in the VLAN domain can be modified. Therefore, the priority mapping and configuration method is feasible.

[0107] Fourthly, when the application calls the data writing interface provided by the DCPS layer to publish a new data sample, the application only needs to specify the data writer and the location of the data sample in the memory. After calling the data writing interface and entering the protocol stack, the DDS protocol stack will perform subsequent data serialization and insert the serialized data into the history manager of the data writer, then trigger the sending of the data sample, complete the assembly of the RTPS message, and finally traverse the remote data reader matched by the data writer, call the underlying message sending interface to send the assembled message, and finally reach the remote data reader.

[0108] Furthermore, a complete RTPS message consists of an RTPS header and numerous sub-messages, where the number of sub-messages depends on the situation and is mainly related to communication requirements. The RTPS layer protocol specifies 13 sub-messages, of which the Data and DataFrag sub-message types are used to transmit data samples published by applications, and their message lengths are mainly related to the length of the published data; the AckNack and Gap sub-message types contain variable-length sequence set data types, so their message lengths are also uncertain. In addition to these four sub-message types, the lengths of the remaining sub-message types are basically fixed. The lightweight design combines the in-vehicle application communication scenarios to tailor the message types required for applications to create communication entities. Among the retained message types, only the Data sub-message type has an uncertain message length.

[0109] Furthermore, the uncertainty of the length of the Data sub-message type is relative. For a specific data publisher, the associated topic name and data type are determined. If the data type does not contain a variable-length data type, then the length of the Data sub-message type involved in its communication process is also determined. Specifically, for publish / subscribe topics that contain variable-length data types, such as topics that contain string data types, the maximum length of the string is generally specified in use. Therefore, the maximum message length of the Data sub-message containing variable-length data types can basically be determined.

[0110] In the existing standard DDS implementation, the data writer's history cache only contains serialized data samples, so it is necessary to assemble it with other sub-messages and RTPS headers into a complete RTPS message, so as to subsequently call the message sending interface of the underlying protocol stack to send it to other remote data readers in the network, thereby completing the data release. Since the data samples to be sent, other sub-message types, and RTPS message headers are scattered in different memory areas, it is necessary to copy all the messages to be sent to a continuous memory area and assemble them into a complete message when sending them later; or use a data sending interface that supports multiple scattered message fragments.

[0111] Furthermore, considering the communication requirements of in-vehicle Ethernet and its integration with TSN technology, this paper further reduces the sub-message types required by data writers working in best-effort mode to three types: InfoDst, InfoTs, and Data. The memory size occupied by the first two sub-messages is fixed. For the Data sub-message type, when the data type is known, the maximum memory occupancy can be calculated based on the adopted serialization strategy. Therefore, the lightweight design proposes an integrated data serialization and message assembly strategy, such as Figure 7 As shown. When the lightweight protocol stack is initialized, it will allocate sufficient memory area in the global data area as a historical cache for each data writer in advance according to the memory size required by the RTPS message calculated in advance and the number of historical cache messages configured in the historical cache QoS. Each data in the historical cache not only contains the serialized data sample, but also contains the memory area required by InfoDst, InfoTs and the RTPS header. When sending a serialized data sample in the historical cache, it is only necessary to modify the header information of the InfoDst / InfoTs and Data sub-messages according to the actual situation, saving unnecessary data copying operations; and the memory occupied by the message to be sent is continuous, so it does not rely on the data sending interface that supports multiple scattered message fragments.

[0112] Although the DDS protocol stack is a communication middleware and has nothing to do with the specific operating system, its specific implementation still uses various programming interfaces such as threads, synchronization, and resource locks provided by the operating system. In addition, the DDS protocol stack works on the upper layer of the TCP / IP protocol stack, so it is also necessary to use the network send / receive interface provided by the operating system or the underlying protocol stack to support the operation of the DDS protocol stack. The following will be combined with the accompanying drawings and specific implementations to explain in detail the specific implementation methods of the key components in the lightweight DDS protocol stack software on the AUTOSAR Classic platform.

[0113] Figure 8 The figure shows the architecture of lightweight DDS software in the AUTOSAR Classic platform, which works on the upper layer of the TCP / IP module as a socket owner. This configuration generates the TcpIp_DDSGetSocket interface for the DDS protocol stack to use to obtain the socket from the TCP / IP module. The TcpIp_UdpTransmit interface is used when sending data; when receiving data, the underlying TCP / IP module notifies the DDS protocol stack as its socket owner through the TcpIp_DDSRxIndication interface.

[0114] Fig. 9The figure shows the receiving processing logic of the DDS protocol stack under the AUTOSAR Classic platform.

[0115] 901, using an interrupt method to notify a message receiving event, and performing preliminary processing of the received message in the interrupt context.

[0116] 902, the AUTOSAR standard module EthIf processes the received message, mainly by calling the corresponding upper layer module receiving notification function according to the type field of the Ethernet frame.

[0117] 903, the frame type of the RTPS message is 0x0800, so the corresponding processing callback function of the IP module is called. Then, the subsequent callback is performed here according to the transport layer protocol type.

[0118] 904, the DDS protocol stack works on the UDP upper layer, so the receiving callback function of the UDP module is called here. Then, the socket is located here through the socket quintuple, and the receiving callback function of the socket owner is called.

[0119] 905, when executing here, it is still in the interrupt context, so it is necessary to end TcpIp_DDSRxIndication as soon as possible to reduce the time of system interrupt shutdown and avoid the message receiving interrupt service routine from executing too long, which affects the real-time performance of the system. Here, the received message is mainly cached in the reserved receiving queue, waiting for subsequent processing. In addition, through the Event mechanism provided by the AUTOSAR Classic platform, the receiving event is set to trigger the execution of subsequent receiving tasks.

[0120] 906, when the receiving event is set, the DDS receiving processing task enters the ready state from the waiting state and waits for the scheduling of the operating system. When the task is scheduled for execution by the operating system, it obtains the message to be processed from the receiving buffer queue, parses and processes the message.

[0121] There are multiple timing-related execution requirements in the DDS protocol stack, mainly concentrated in the dynamic discovery phase, such as the periodic sending of multicast discovery messages in the first simple discovery phase; the timing processing of HeartBeat, AckNack, and Gap messages by communication entities working in reliable mode in the second discovery phase, etc. Therefore, the lightweight DDS protocol stack needs to design timing processing tasks to handle various timing events inserted by the protocol stack during operation.

[0122] The present invention combines the basic objects such as Task, Event, Alarm and Resource in the AUTOSAR Classic platform to provide a specific implementation process of the timer thread (in the AUTOSAR Classic platform, the concept of thread is similar to Task). It should be noted that since there may be many timer operations to be processed at the same time, the use of periodic tasks may cause the task to time out and trigger an OS Limit error. Therefore, the timer thread is implemented using an extended task in the AUTOSAR Classic platform.

[0123] Fig.10 The figure shows the execution flow of the timer task under the AUTOSAR Classic platform. The main body of the timer task is executed in an infinite loop because for the extended task under the AUTOSAR Classic platform, it generally switches between the three states of waiting / ready / execution when applied. The extended task will not end, but will actively release the CPU during the execution process, enter the waiting state, wait for the wake-up of a specific event, and enter the ready state after wake-up, and continue to wait for the scheduling of the operating system.

[0124] 1001 / 1005 / 1009, use the Resource mechanism under the AUTOSAR Classic platform to protect the data consistency of timer execution operations.

[0125] 1002, here is the implementation body of the timer task. Specifically, the earliest timer to be executed is obtained from the timer queue. If the timer has expired, the callback function operation registered in the timer is executed. Then the timer queue is updated, and the earliest timer is tried again, and the cycle repeats.

[0126] 1008, if there is no timer operation to be executed in the current timing queue, the timer task should actively release the CPU and enter the waiting state, waiting for the timer insertion operation to set event e1. The setting of e1 will cause the timer task to enter the ready state from the waiting state, and enter the subsequent execution process after the operating system schedules the execution.

[0127] 1009. Before the timer task calls WaitEvent to enter the waiting state, it is necessary to call ReleaseResource to release the previously acquired resources to prevent deadlock.

[0128] 1003. If there are unexpired timers in the timer queue, the scheduled task should wait for time1 before continuing to execute, where the value of time1 is determined by the difference between the expected execution time of the timer and the current system time.

[0129] 1004, here the Alarm mechanism under the AUTOSAR Classic platform is used to implement the limited time waiting operation required in the previous step. When the Alarm time arrives, the event e2 will be actively set to wake up the timer task in the waiting state.

[0130] 1005. Similarly, before entering the waiting state, the previously acquired Resource resources must be released.

[0131] 1006. Since the timer insertion operation may wake up the timer task in the waiting state, it is necessary to determine the specific wake-up source here.

[0132] 1007, if the wake-up source is e2, it means that the alarm has not expired, so the previously set timed alarm should be canceled to prevent repeated wake-ups.

[0133] In general, the above specific embodiments describe in detail the design ideas of the lightweight DDS protocol stack of this application and the implementation methods of its key components on the AUTOSAR Classic platform. It should be noted that the lightweight DDS design scheme in this application needs to rely on the operating system and the corresponding Ethernet protocol stack. For different basic software combinations, technicians are required to appropriately adapt the software.

[0134] The above is only a specific embodiment of the present invention, but the protection scope of the present invention is not limited thereto. Any technician familiar with the technical field can easily think of various equivalent modifications or replacements within the technical scope disclosed by the present invention, and these modifications or replacements should be included in the protection scope of the present invention. Therefore, the protection scope of the present invention shall be based on the protection scope of the claims.

Claims

1. A lightweight DDS middleware, characterized in that: Applied to vehicle platforms, including: The data-centric publishing and subscription specification DCPS layer is located on the upper layer of the DDS middleware and is used to interact with the application layer. The setting of the DCPS layer includes: removing the communication entities related to the DCPS layer, including DDS data participants, DDS data publishers, DDS data subscribers, DDS data topics, DDS data readers, and DDS data writers; mounting the Topic, QoS, and callback functions of the DCPS layer to the communication entity of the RTPS layer; providing the application layer with a programming interface for creating real-time publishing and subscription RTPS layer communication entities and a programming interface for configuring service quality policies; The real-time publishing and subscription (RTPS) layer is located at the lower layer of the DDS middleware and is used to undertake the data publishing and subscription functions of the DDS protocol stack, as well as the configuration of service quality policies; The programming interface in the DCPS layer specifically includes: Create interfaces for RTPS communication participants, RTPS data topics, RTPS data readers, and RTPS data writers; Data publishing interface, which is called by the application layer to publish data; The service quality configuration interface is used to customize the personalized service quality strategy for the application layer; Registering a callback function interface, so that the application layer can register the defined callback function into the DDS protocol stack as needed and interact with the DDS protocol stack; and The data reading interface is used by the application layer to obtain data samples from the history cache of the data reader.

2. A lightweight DDS middleware according to claim 1, characterized in that: The DCPS layer configuration also includes: removing the synchronization condition waiting mechanism and providing an asynchronous monitoring callback mechanism for notifying the application layer of corresponding state changes; The asynchronous monitoring callback mechanism is specifically as follows: the application layer calls the initialization function in advance, registers the required callback function with the RTPS layer communication entity, calls the pre-registered callback function when the corresponding state of the DDS protocol stack occurs, and notifies the application layer.

3. The lightweight DDS middleware according to claim 1, characterized in that: The RTPS communication message in the RTPS layer includes an RTPS message and sub-messages constituting the RTPS message; The processing of sub-messages includes: removing the processing of sub-message types related to large data shards; And for the common application communication entity in the DDS protocol stack, remove the processing of reliability-related sub-message types, wherein the common application entity is an RTPS layer communication entity created by the application layer calling the programming interface; The simple discovery protocol is implemented and the related built-in entities are retained to handle the three types of sub-messages: HeartBeat, AckNack, and Gap.

4. A lightweight DDS middleware according to claim 3, characterized in that: The RTPS layer also includes on-site serialization and assembly of RTPS messages, specifically: The sub-message types contained in the RTPS message related to data transmission are limited to InfoTS, InfoDST and Data; when assembling into a complete RTPS message, the memory size occupied by each RTPS message containing the data sample to be published by the data writer is determined in advance; When creating the data sample cache space inside the data writer, the DDS protocol stack creates memory to carry a complete RTPS message, serializes the data to be published to the corresponding offset in the cache, and fills in the RTPS header and the other two sub-messages to complete the assembly of a complete RTPS message.

5. The lightweight DDS middleware according to claim 1, characterized in that: All the service quality policies of the DCPS layer are transferred to the RTPS layer through the programming interface of service quality policy configuration, and are managed by the communication entity of the RTPS layer; The service quality strategy is integrated with the vehicle-mounted time-sensitive Ethernet communication, reducing the 22 service quality strategies to two categories and 8 types, specifically: Category 1: Warning QoS policies, including deadline QoS policy, delay budget QoS policy, transmission priority QoS policy, and reliability QoS policy. Only the built-in entities in the second discovery phase of the DDS middleware implement the reliability QoS policy, while ordinary application entities all work in the best-effort mode. The second category: basic service quality policies, which are used to implement related processing logic, including persistence service quality policies, historical resource service quality policies, resource limitation service quality policies and survivability service quality policies.

6. The lightweight DDS middleware according to claim 1, characterized in that: Also includes: The data of the transmission priority service quality policy configured at the application layer is directly mapped and filled into the PCP field of the virtual LAN data frame, specifically: The priority information is placed at the starting four bytes of the buffer to be sent. When the underlying UDP protocol stack encapsulates the UDP datagram, it directly indexes the PCP field of the virtual LAN data frame, and maps the priority value stored in the buffer to be sent to 0-7. The mapped data is then filled into the 3-bit PCP field in the data frame.

7. A method for applying the lightweight DDS middleware according to any one of claims 1 to 6 on an AUTOSAR Classic platform, characterized in that: include: The lightweight DDS middleware is set on the upper layer of the TCP / IP module as a socket owner of the TCP / IP module, and the type is configured as a complex device driver; the DDS protocol stack works on the UDP protocol stack of the TCP / IP module, including at least three AUTOSAT tasks to support the operation of the protocol stack; The working tasks of the lightweight DDS middleware include: Initialization task, used to complete the initialization of the protocol stack, and the application layer calls the interface to create the required communication entity; The receiving data processing task is used to complete the parsing and subsequent processing of the received RTPS message. It is an extended task and is triggered by the underlying data receiving interrupt; Timer tasks are used to process various timers registered in the protocol stack.

8. The application method according to claim 7, characterized in that: The receiving data processing task is an extended task, which is triggered by the bottom layer data receiving interrupt. Specifically, when the system receives a new RTPS message, the data receiving interrupt of the Eth module is triggered, and through the callback function of the EthIf module and the TCP / IP module, the receiving callback function of the DDS protocol stack is finally called; Two tasks are performed in the receive callback function of the DDS protocol stack: creating a copy of the received data; setting the receive event through the SetEvent() interface of AUTOSARClassic to trigger the DDS receive processing function to enter the ready state from the waiting state and wait for the scheduling of the operating system; After the receiving processing task is scheduled for execution, the RTPS message to be processed is taken out from the data cache queue for subsequent processing actions.

9. The application method according to claim 7, characterized in that: The timer task is an extended task, which includes two waiting points: the first waiting point is activated by the timer insertion operation in other tasks; the second waiting point is activated by the timer warning Alarm set by oneself; When the timer task has processed the expired timers in the queue, if there is no timer operation to be processed in the current timer queue, the extended task enters the first waiting point; otherwise, if the earliest timer in the current timer queue has not expired, the extended task enters the second waiting point; Before entering the second waiting point, a warning Alarm is set for the timer extension task, and the expiration time of the warning Alarm is the time difference between the current time and the earliest timer.

Images