A method, apparatus, vehicle, and storage medium for processing DDS messages.

By capturing and parsing RTPS protocol data packets, establishing entity relationships, and performing deserialization, the difficulty in locating problems caused by the complex interactions between DDS application modules is solved, and the troubleshooting efficiency is improved.

CN116132514BActive Publication Date: 2026-05-26CHONGQING CHANGAN TECH CO LTD

Patent Information

Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
CHONGQING CHANGAN TECH CO LTD
Filing Date
2023-02-28
Publication Date
2026-05-26

AI Technical Summary

Technical Problem

During the integration testing phase, the interactions between DDS application modules are complex, making it difficult for developers to intuitively locate the problem, resulting in low troubleshooting efficiency.

Method used

By capturing RTPS protocol data packets, parsing and classifying them for storage, establishing a correspondence between participants, subscribers, publishers and topic names, performing deserialization processing, and displaying the data in a tree structure on the user interface, abnormal connections are prominently displayed.

Benefits of technology

It enables rapid location of DDS network transmission problems, improving troubleshooting speed and efficiency.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN116132514B_ABST
    Figure CN116132514B_ABST
Patent Text Reader

Abstract

This invention discloses a method, apparatus, vehicle, and storage medium for processing DDS messages. The method includes: obtaining participant identifiers and establishing a classification strategy table based on the participant identifiers; obtaining subscriber identifiers, publisher identifiers, and topic names, and establishing a correspondence between participants, subscribers, publishers, and topic names according to the classification strategy table; obtaining RTPS sub-message data, and classifying and storing the RTPS sub-message data according to the correspondence. This application allows developers or users to intuitively see the interaction between different DDS applications, thereby quickly locating the problem and improving the troubleshooting speed during DDS network transmission.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This invention relates to the field of communication technology, and in particular to a method, apparatus, vehicle, and storage medium for processing DDS messages. Background Technology

[0002] Data Distribution Service (DDS) is used to distribute data among participants in a distributed application, such as publishing and subscribing to messages in a publish / subscribe pattern. Two DDS applications can only communicate through that topic after publishing and subscribing to a service with the same topic name (topic_name) or registering for subscription and notification events. Larger projects may involve multiple DDS applications, with relationships that may be one-to-one or one-to-many, increasing the complexity of mapping topics to publishers (writers) and subscribers (readers). During the integration testing phase, when different application modules are interfacing, developers or users cannot directly see the interactions between different DDS applications, making it difficult to quickly pinpoint where a problem occurs. Summary of the Invention

[0003] In view of the shortcomings of the prior art described above, the present invention discloses a method, apparatus, vehicle and storage medium for processing DDS messages, which enables developers or users to intuitively see the interaction between different DDS applications, thereby quickly locating the problem and improving the troubleshooting speed during DDS network transmission.

[0004] This invention discloses a method for processing DDS messages, comprising the following steps: capturing corresponding data packets and filtering out RTPS protocol data packets; parsing the RTPS protocol data packets and classifying and storing the parsed data; deserializing the classified and stored parsed data; and displaying the deserialized data.

[0005] In one example of the processing method of the present invention, the step of classifying and storing the parsed data includes: obtaining the identifiers of participants and establishing a classification strategy table based on the identifiers of the participants; obtaining the identifiers of subscribers, the identifiers of publishers, and the topic names, and establishing a correspondence between participants, subscribers, publishers, and topic names based on the classification strategy table; obtaining RTPS sub-message data, and classifying and storing the RTPS sub-message data according to the correspondence.

[0006] In one example of the processing method of the present invention, the deserialization processing of the classified and stored parsed data includes: importing the corresponding IDL file; generating computer programming language code from the imported IDL file and storing it in a specified path; obtaining different structure names from the parsed data; searching for the computer programming language code corresponding to the different structure names in the path where the computer programming language code is stored; and calling the deserialization interface to obtain the deserialized data.

[0007] In one example of the processing method of the present invention, displaying the deserialized data includes: displaying the correspondence between participants, publishers, subscribers and topic names in the classification strategy table in a tree structure, and displaying the deserialized data in the tree structure accordingly.

[0008] In one example of the processing method of the present invention, the step of displaying the correspondence between participants, publishers, subscribers and topic names in the classification strategy table in a tree-like structure includes: prominently displaying topic names with abnormal connections in the tree-like structure.

[0009] In one example of the processing method of the present invention, the step of displaying the deserialized data further includes: listing the data of the same participant in the same data list, and viewing the specific data content of each participant by clicking on each of the data lists.

[0010] In one example of the processing method of the present invention, the data list also stores the time when the publisher sends the data and the time when the corresponding subscriber receives the data.

[0011] This invention discloses a DDS message processing device, comprising: a capture module for capturing corresponding data packets and filtering out RTPS protocol data packets; a parsing module for parsing the RTPS protocol data packets and classifying and storing the parsed data; a deserialization module for deserializing the classified and stored parsed data; and a display module for displaying the deserialized data.

[0012] The present invention discloses a vehicle, comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the DDS message processing method as described above.

[0013] The present invention discloses a computer-readable storage medium having a computer program stored thereon, which is executed by a processor to implement the DDS message processing method as described above.

[0014] This invention discloses a method, apparatus, vehicle, and storage medium for processing DDS messages. By automatically capturing RTPS protocol data packets and classifying the parsed data according to a classification strategy table, it establishes a correspondence between various entities, facilitating rapid location of the two ends of data transmission. When problems occur at either end of the communication, it can quickly pinpoint the source of the problem. Furthermore, by deserializing and displaying the parsed data, developers or users can intuitively see the interactions between different applications, thereby quickly locating the precise location of the problem during DDS message data communication and improving the troubleshooting speed in DDS communication transmission networks. Attached Figure Description

[0015] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application. It is obvious that the drawings described below are merely some embodiments of this application, and those skilled in the art can obtain other drawings based on these drawings without any inventive effort. In the drawings:

[0016] Figure 1 yes Figure 1 This is a schematic diagram illustrating the implementation environment of a DDS message processing method according to an exemplary embodiment of this application;

[0017] Figure 2 This is a flowchart illustrating a method for processing DDS messages according to an exemplary embodiment of this application;

[0018] Figure 3 This is an exemplary embodiment of the present application illustrating the overall architecture of a method for processing DDS messages;

[0019] Figure 4 This is a flowchart illustrating a method for processing DDS messages in an exemplary embodiment of this application, showing the process of capturing data packets.

[0020] Figure 5 This is an exemplary embodiment of the present application illustrating the overall flowchart of the data packet parsing process in the DDS message processing method;

[0021] Figure 6 This is a flowchart illustrating the data packet parsing process in a DDS message processing method according to an exemplary embodiment of this application;

[0022] Figure 7 yes Figure 4 Step S22 in the illustrated embodiment is a flowchart of an exemplary embodiment;

[0023] Figure 8 yes Figure 4Step S23 in the illustrated embodiment is a flowchart of an exemplary embodiment;

[0024] Figure 9 yes Figure 2 The flowchart of step S3 in the illustrated embodiment is shown in an exemplary embodiment;

[0025] Figure 10 This is an exemplary embodiment of the present application illustrating a tree-like relationship structure between entities in a classification strategy table;

[0026] Figure 11 This is a block diagram illustrating a DDS message processing apparatus according to an exemplary embodiment of this application;

[0027] Figure 12 This is a schematic diagram of the vehicle structure shown in an exemplary embodiment of this application. Detailed Implementation

[0028] The following specific examples illustrate the implementation of the present invention. Those skilled in the art can easily understand other advantages and effects of the present invention from the content disclosed in this specification. The present invention can also be implemented or applied through other different specific embodiments, and various details in this specification can also be modified or changed based on different viewpoints and applications without departing from the spirit of the present invention. It should be noted that, unless otherwise specified, the following embodiments and sub-samples in the embodiments can be combined with each other.

[0029] It should be noted that the illustrations provided in the following embodiments are only schematic representations of the basic concept of the present invention. Therefore, the drawings only show the components related to the present invention and are not drawn according to the actual number, shape and size of the components in the actual implementation. In the actual implementation, the form, quantity and proportion of each component can be arbitrarily changed, and the layout of the components may also be more complex.

[0030] In the following description, numerous details are explored to provide a more thorough explanation of embodiments of the invention. However, it will be apparent to those skilled in the art that embodiments of the invention may be practiced without these specific details. In other embodiments, well-known structures and devices are shown in block diagram form rather than in detail to avoid obscuring embodiments of the invention.

[0031] The terms "first," "second," etc., used in the specification, claims, and accompanying drawings of this disclosure are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate for the embodiments of this disclosure described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion.

[0032] Unless otherwise stated, the term "multiple" means two or more.

[0033] In this embodiment of the disclosure, the character " / " indicates that the objects before and after it are in an "or" relationship. For example, A / B means: A or B.

[0034] The term "and / or" describes an association between objects, indicating that three relationships can exist. For example, A and / or B means: A or B, or A and B.

[0035] First, it's important to clarify that DDS (Data Distribution Service) is a next-generation distributed real-time communication middleware protocol. It employs a publish / subscribe architecture, emphasizing a data-centric approach and providing rich QoS (Quality of Service) policies to ensure real-time, efficient, and flexible data distribution, meeting the needs of various distributed real-time communication applications. DDS is a network middleware that simplifies complex network programming. It implements a publish-subscribe pattern for sending and receiving data, events, and commands between nodes. Nodes that generate information, acting as publishers (writers), create "topics" (e.g., temperature, location, pressure) and publish "samples." DDS delivers the samples to subscribers (readers) who have declared interest in the topic. DDS handles transport chores: message addressing, data marshalling and unmarshalling (so subscribers (readers) can be on different platforms than publishers (writers), delivery, flow control, retries, etc. Any node can be a publisher (writer), a subscriber (reader), or both. The smallest unit of DDS data publishing is a topic. A topic has three key elements: a) Data type: It only supports data types defined by the OMG Interface Definition Language (IDL), supports basic data structures, and supports nested structures; b) Topic name (topic_name): Defined by the user, and the publisher (writer) and subscriber (reader) must have the same name; c) QoS (Quality of Service) configuration: This refers to a network's ability to utilize various underlying technologies to provide better service capabilities for specified network communications.

[0036] Real-time Publish / Subscribe (RTPS) is a protocol used by DDS for communication.

[0037] Participant, Writer, and Reader: These are entities within DDS that manage the publishing and receiving of data.

[0038] Please see Figures 1 to 12 This application provides a method, apparatus, vehicle, and storage medium for processing DDS messages. In this DDS message processing method, transmitted data packets can be automatically captured, and RTPS data packets within the data packets can be parsed. The parsed data is then categorized and stored, making the correspondence between various entities more intuitive, thereby enabling quick location of the connection entity where the problem occurs. By deserializing the parsed data and displaying it, developers or users can intuitively view the interactions between different applications, thus quickly locating the problem point during DDS communication network transmission, thereby improving the efficiency of communication fault diagnosis.

[0039] Please see Figure 1 , Figure 1 This is a schematic diagram illustrating the implementation environment of a DDS message processing method according to an exemplary embodiment of this application. Figure 1 The smart terminal 110 shown can be any monitoring terminal device that supports the installation of information release cycles, such as a smartphone, in-vehicle computer, tablet computer, laptop computer, or wearable device, but is not limited to these. Figure 1 The filling server 120 shown is a navigation server, which can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN (Content Delivery Network), and big data and artificial intelligence platforms. No restrictions are placed on this. The smart terminal 110 can communicate with the navigation server 220 via wireless networks such as 3G (third-generation mobile information technology), 4G (fourth-generation mobile information technology), and 5G (fifth-generation mobile information technology). No restrictions are placed on this as well.

[0040] Please see Figure 2 and Figure 3 , Figure 2 This is a flowchart illustrating a method for processing DDS messages, as shown in an exemplary embodiment of this application. Figure 3 This is an exemplary embodiment of the present application illustrating the overall architecture of a DDS message processing method. This processing method can be applied to... Figure 1The implementation environment is described above, and the process is specifically executed by the smart terminal 110 within that implementation environment. It should be understood that this processing method can also be applied to other exemplary implementation environments and specifically executed by devices in other implementation environments. This embodiment does not limit the implementation environment to which this processing method is applicable.

[0041] like Figure 2 As shown, in an exemplary embodiment, the method for processing DDS messages includes at least steps S1 to S4, which are described in detail below:

[0042] S1, capture the corresponding data packets and filter out RTPS protocol data packets;

[0043] Please see Figure 4 , Figure 4 The flowchart illustrates a method for processing DDS messages in an exemplary embodiment of this application, showing a data packet capture process. In an exemplary embodiment of the present invention, step S1 involves capturing the corresponding data packet and filtering out RTPS protocol data packets, including steps S11 to S13:

[0044] S11. Obtain data packets from the specified network interface card;

[0045] In an exemplary embodiment of the present invention, a packet capture tool can be used to automatically acquire DDS communication data packets from the corresponding network card in real time. The packet capture tool can be libpcap (an open-source packet capture development kit (SDK)) or wincap (Windows Packet Capture is a free and public network access system under the Windows platform; this application does not impose specific restrictions on the packet capture tool). In other embodiments, the captured DDS data packets can also be offline data packets saved by Wireshark (an open-source packet capture tool with a visual interface) or tcpdump (a packet capture command under the Linux system).

[0046] S12. Filter out RTPS protocol data packets;

[0047] In this embodiment, the packet capture tool filters the captured data packets using the real-time RTPS protocol. The filtering method is the same as that described in the prior art and will not be elaborated here.

[0048] S13. Save RTPS protocol data packets.

[0049] In this embodiment, the RTPS protocol data packets filtered in step S12 can be stored on the user's host or stored separately on another storage device, and there is no limitation on this.

[0050] S2. Parse the RTPS protocol data packets and classify and store the parsed data.

[0051] Please see 5 and Figure 6 , Figure 5 This is a flowchart illustrating the overall process framework of packet parsing in a DDS message processing method, as shown in an exemplary embodiment of this application. Figure 6 The following is a flowchart illustrating the data packet parsing process in a DDS message processing method according to an exemplary embodiment of this application. In an exemplary embodiment of the present invention, step S2 involves parsing the RTPS protocol data packet and classifying and storing the parsed data, including steps S21 to S23:

[0052] S21. Parse RTPS protocol data packets.

[0053] In this step, the selected RTPS protocol packets are parsed according to the RTPS protocol. Each RTPS protocol packet contains an RTPS protocol header, RTPS protocol sub-message headers, and detailed sub-message content. RTPS protocol packets typically contain multiple types of sub-messages. The sub-message header contains an 8-bit flag indicating the type of different sub-messages. After obtaining the sub-message type, the sub-message is parsed according to its structure, and the parsed data is finally saved.

[0054] S22. Classify and store the parsed data.

[0055] Please see Figure 7 , Figure 7 for Figure 4 The flowchart of step S22 in the illustrated embodiment is shown in an exemplary embodiment. In an exemplary embodiment of the present invention, step S22 involves classifying and storing the parsed data, including steps S221 to S222:

[0056] S221. Obtain the identifiers of the participants and establish a classification strategy table based on the identifiers of the participants;

[0057] In this step, the globally unique identifier (GUID) of the participant is extracted from the Data(p) data packet during the SPDP phase. At the same time, the prefix value (prefix_GUID) of the corresponding globally unique identifier is obtained. Different participants are classified by identifying the prefix value of the globally unique identifier of the participants, and a classification strategy table is established.

[0058] S222. Obtain the subscriber identifier, publisher identifier, and topic name. Based on the classification strategy table, establish the correspondence between participants, subscribers, publishers, and topic names.

[0059] It should be noted that RTPS protocol data packets sent by the same publisher (writer) will all contain the same globally unique identifier prefix value (prefix_GUID) in their headers. Similarly, RTPS protocol data packets sent by the same subscriber (reader) will also contain the same globally unique identifier prefix value (prefix_GUID) in their headers. Subsequently, the source of the captured data packets can be classified based on the prefix value (prefix_GUID) of the globally unique identifier of each participant in the parsed RTPS protocol data packets. In this application, the source of the data packets mainly involves both subscribers (readers) and publishers (writers). In this embodiment, the classification method establishes a relationship table between the prefix value (prefix_GUID) of the globally unique identifier and the subscribers (readers) and publishers (writers), and stores the subsequently parsed subscriber (reader) and publisher (writer) information data in this relationship table, thereby achieving classified storage of data packet sources. In other embodiments, the classification method can also be any other applicable classification method in the prior art.

[0060] In this step, during the SEDP phase, the globally unique identifier (GUID) and topic name of the writer and reader are obtained from the subscriber (reader) data and the publisher (writer) data, respectively, and saved to the relationship table between the prefix value (prefix_GUID) of the globally unique identifier and the subscriber (reader) and publisher (writer) established in step S221. This establishes the correspondence between the writer and subscriber (reader) and the topic name (topic_name) and the participants.

[0061] S23. Obtain RTPS sub-message data and store the RTPS sub-message data according to the correspondence relationship.

[0062] The parsed data is saved according to the above correspondence, so that developers and users can quickly locate the relationship between entities at the problem point, making it easier to locate the specific location where the problem point occurs between different entities.

[0063] Please see Figure 8 , Figure 8 yes Figure 4The flowchart of step S23 in the illustrated embodiment is shown in an exemplary embodiment. In an exemplary embodiment of the present invention, step S23 involves acquiring RTPS sub-message data and classifying and storing the RTPS sub-message data according to the correspondence relationship, including steps S231 to S232:

[0064] S231. Use a sub-message parser to parse RTPS sub-messages;

[0065] Before parsing the RTPS sub-message content, it is necessary to first determine the RTPS sub-message content. This determination technique can be based on existing technology and will not be described in detail here. When it is determined that a certain RTPS sub-message content is of the data transmission type, the RTPS sub-message content is parsed by the corresponding parser, and each type of RTPS sub-message has a corresponding parser.

[0066] S232. Save the parsed RTPS sub-message content to the corresponding position in the relation table established in step S222.

[0067] In this step, based on the prefix value (prefix_GUID) of the globally unique identifier of the participant in the RTPS sub-message content, the corresponding publisher (writer) or subscriber (reader) in the relationship table is queried. The sent data is parsed and stored in the corresponding publisher (writer), and the received data is parsed and stored in the corresponding subscriber (reader). Because the relationship table already establishes the correspondence between participants, publishers, and subscribers, querying the prefix value (prefix_GUID) of the globally unique identifier of the participant in the RTPS sub-message content allows for quick location of the corresponding publisher (writer) or subscriber (reader). The RTPS sub-message content is then stored according to the correspondence in the relationship table under the corresponding publisher (writer) and subscriber (reader), thus achieving categorized storage of the transmitted data in the RTPS sub-message content.

[0068] S3. Deserialize the parsed data stored in categories;

[0069] Because DDS message transmission requires data serialization to convert the transmitted object into a string containing all the object's data information, the transmitted and received data stored in step S232 are both in string format. This step requires deserialization (the opposite of serialization, which is the process of converting binary data streams or text streams into easily processed and readable data structures) of both the transmitted and received data stored in step S232 to obtain the restored transmitted data. In this embodiment, the transmitted and received data are deserialized using CDR (a data serialization mechanism). During deserialization, the actual data structure can be directly derived from the IDL (Interface Description Language) file, thus ensuring the accuracy of the deserialized data.

[0070] Please see Figure 9 , Figure 9 yes Figure 2 The flowchart of step S3 in the illustrated embodiment is shown in one exemplary embodiment. In an exemplary embodiment of the present invention, step S3 involves deserializing the categorized and stored parsed data, including steps S31 to S36:

[0071] S31. Import the corresponding IDL file;

[0072] When different users use the above processing method to parse and process DDS data, they need to first import their corresponding IDL files into a pre-specified storage directory. Different users need to specify different storage directories for their respective IDL files.

[0073] S32. Generate Python code from the imported IDL file;

[0074] S33. Store the generated computer programming language (Python) code in the specified path;

[0075] The IDL file compiler generates Python code from the imported IDL file and stores it in the path specified by the corresponding IDL file.

[0076] S34. Obtain the names of different structures from the parsed data;

[0077] A structure is a collection of data that has the same or different data types; it is also called a data structure. Different structures have different names, and the content of the data can be obtained by reading the name of the structure within the data.

[0078] S35. Locate the Python code corresponding to different structure names in the path where the Python code is stored;

[0079] By using the corresponding Python programming language code for different structure names, the data content in the parsed data is converted into the corresponding Python programming language code.

[0080] S36. Call the deserialization interface to obtain the deserialized data.

[0081] The deserialization interface generated in the Python programming language code is called to deserialize the Python code corresponding to different structure names, resulting in deserialized data. The deserialized data is easier for users to process and read.

[0082] S4. Display the data after deserialization.

[0083] In this step, the deserialized data obtained in step S3 is displayed through the user interface (UI, which is the medium for interaction and information exchange between the system and the user, and realizes the conversion between the internal form of information and the form that can be accepted by humans).

[0084] Please see Figure 10 , Figure 10 This is an exemplary embodiment of the present application illustrating a tree-like relationship structure between entities in a classification strategy table. In an exemplary embodiment of the present invention, the correspondence between participants, writers, readers, and topic names included in the classification strategy table in step S2 is displayed in a tree-like structure on the user interface, and the data obtained in step S35 after deserialization is displayed at the corresponding positions in the tree-like structure. This setup allows developers and users to more intuitively see the topological relationships between entities on the user interface.

[0085] In an exemplary embodiment of the present invention, when displaying the tree-like relationship structure through a user interface, the method further includes: prominently displaying the names of topics with connection failures in the tree-like relationship structure. In this application, the connection failure can be any abnormal situation affecting the quality of communication data transmission, such as the receiver failing to receive the data, the sender failing to send it, or an error in the receiver's receiving time or the sender's sending time. The prominent display can be achieved through prominent color, prominent font, or dynamic reminders, or any display method that serves as a prominent identifier. Users can click to view the prominently displayed topic name to see its detailed content, such as SPDP (Simple Participant Discovery Protocol) or SEDP (Simple Endpoint Discovery Protocol), thereby troubleshooting at which step the connection failed and determining whether the problem lies with the writer or the reader.

[0086] In an exemplary embodiment of the present invention, the process of displaying the deserialized data further includes: listing the data of the same participant in the same data list, and viewing the specific data content of each participant by clicking on each data list. When displayed through a user interface, each data list can store the specific data information of the corresponding participant. Users can extract the data of participants of interest through the data list, and can also query the information sent by a specific publisher and the information received by the corresponding subscriber.

[0087] In an exemplary embodiment of the present invention, each participant's data list stores the times when the writer publishes information and the times when the reader subscribes to information for the same topic name. By calculating the time difference between the writer's publication time and the reader's subscription time, the time difference between the information sending time and the receiving time can be calculated. This allows for the assessment of the current network conditions and throughput, and also enables the detection of situations where a writer sends data but a reader does not receive it. This facilitates the timely detection and handling of anomalies during communication transmission.

[0088] Please see Figure 11 , Figure 11This is a block diagram of a DDS message processing apparatus illustrated in an exemplary embodiment of this application, including a capture module, a parsing module, a deserialization processing module, and a display module; the capture module is used to capture corresponding data packets and filter out RTPS protocol data packets; the parsing module is used to parse the RTPS protocol data packets and classify and store the parsed data; the deserialization processing module is used to deserialize the classified and stored parsed data; and the display module is used to display the deserialized data.

[0089] It should be noted that the DDS message processing methods and apparatuses provided in the above embodiments belong to the same concept, and the specific ways in which each module performs its operations have been described in detail in the method embodiments, and will not be repeated here. In practical applications, the DDS message processing apparatuses provided in the above embodiments can be assigned to different functional modules as needed, that is, the internal structure of the apparatus can be divided into different functional modules to complete all or part of the functions described above, and this is not a limitation.

[0090] Please see Figure 12 , Figure 12 This is a schematic diagram of a vehicle structure shown as an exemplary embodiment of this application. The vehicle includes: a memory, a processor, and a computer program stored in the memory and executable on the processor; when the processor executes the program, it implements the DDS message processing method provided in the above embodiment. Further, the vehicle also includes: a communication interface for communication between the memory and the processor; the memory stores the computer program executable on the processor, and may include high-speed RAM or non-volatile memory, such as at least one disk storage device. In this embodiment, if the memory 801, processor 802, and communication interface 803 are implemented independently, the communication interface 803, memory 801, and processor 802 can be interconnected via a bus to complete communication between them. The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be divided into address buses, data buses, control buses, etc. For ease of illustration, Figure 8The bus is represented by a single thick line, but this does not indicate that there is only one bus or one type of bus. In specific implementations, if the memory 801, processor 802, and communication interface 803 are integrated on a single chip, then the memory 801, processor 802, and communication interface 803 can communicate with each other through internal interfaces. The processor 802 may be a central processing unit (CPU), an application-specific integrated circuit (ASIC), or one or more integrated circuits configured to implement the embodiments of this application.

[0091] Embodiments of this application also provide a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the above-described method for processing DDS messages.

[0092] It should be noted that the computer-readable medium shown in the embodiments of this application can be a computer-readable signal medium or a computer-readable storage medium, or any combination of the two. A computer-readable storage medium can be, for example, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), flash memory, optical fiber, portable compact disc read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this application, a computer-readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, carrying a computer-readable computer program. Such propagated data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. Computer-readable signal media can also be any computer-readable medium other than computer-readable storage media, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The computer program contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to wireless, wired, etc., or any suitable combination thereof.

[0093] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. Each block in a flowchart or block diagram may represent a module, segment, or portion of code, which contains one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram or flowchart, and combinations of blocks in a block diagram or flowchart, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0094] The units described in the embodiments of this application can be implemented in software or hardware, and the described units can also be located in a processor. The names of these units do not necessarily limit the specific unit itself.

[0095] The DDS message processing method provided by this invention automatically captures Real-Time Publish-Subscribe Protocol (RTPS) data packets, classifies and stores the parsed data according to a classification strategy table, deserializes the parsed data, and displays the data. A tree-like relationship structure is used to display the correspondence between various entities on the user interface, allowing developers or users to intuitively see the data transmission relationships between different entities. This enables them to quickly locate the exact position of problems during DDS message data communication, thereby improving the troubleshooting speed in DDS communication transmission networks.

[0096] The above embodiments are merely illustrative of the principles and effects of the present invention and are not intended to limit the invention. Any person skilled in the art can modify or alter the above embodiments without departing from the spirit and scope of the present invention. Therefore, all equivalent modifications or alterations made by those skilled in the art without departing from the spirit and technical concept disclosed in the present invention should still be covered by the claims of the present invention.

Claims

1. A method for processing DDS messages, characterized in that, Includes the following steps: Capture the corresponding data packets and filter out RTPS protocol data packets; The RTPS protocol data packets are parsed, and the parsed data is classified and stored. Deserialization is performed on the parsed data stored in categories; Displays the data after deserialization; The process of classifying and storing the parsed data includes: Obtain the identifiers of the participants and build a classification strategy table based on the identifiers of the participants; Obtain the subscriber identifier, publisher identifier, and topic name; and establish the correspondence between participants, subscribers, publishers, and topic names based on the classification strategy table. Obtain RTPS sub-message data and store the RTPS sub-message data according to the correspondence relationship.

2. The processing method according to claim 1, characterized in that, The deserialization process for the categorized and stored parsed data includes: Import the corresponding IDL file; The imported IDL file will be converted into computer programming language code and stored in the specified path; Extract the names of different structures from the parsed data; Locate the computer programming language code corresponding to different structure names in the path where the computer programming language code is stored; Call the deserialization interface to obtain the deserialized data.

3. The processing method according to claim 1, characterized in that, The process of displaying the deserialized data includes: displaying the correspondence between participants, publishers, subscribers and topic names in the classification strategy table in a tree structure, and displaying the deserialized data in the tree structure accordingly.

4. The processing method according to claim 3, characterized in that, The step of displaying the correspondence between participants, publishers, subscribers and topic names in the classification strategy table in a tree structure includes: prominently displaying topic names with abnormal connections in the tree structure.

5. The processing method according to claim 1, characterized in that, The process of displaying the deserialized data also includes: listing the data of the same participant in the same data list, and viewing the specific data content of each participant by clicking on each of the data lists.

6. The processing method according to claim 5, characterized in that, The data list also stores the time when the publisher sends the data and the time when the corresponding subscriber receives the data.

7. A DDS message processing apparatus, characterized in that, include: The capture module is used to capture the corresponding data packets and filter out RTPS protocol data packets; The parsing module is used to parse the RTPS protocol data packets and classify and store the parsed data. The deserialization module is used to deserialize the parsed data stored in categories; The display module is used to display the data after deserialization. The process of classifying and storing the parsed data includes: Obtain the identifiers of the participants and build a classification strategy table based on the identifiers of the participants; Obtain the subscriber identifier, publisher identifier, and topic name; and establish the correspondence between participants, subscribers, publishers, and topic names based on the classification strategy table. Obtain RTPS sub-message data and store the RTPS sub-message data according to the correspondence relationship.

8. A vehicle, characterized in that, include: A memory, a processor, and a computer program stored in the memory and executable on the processor, the processor executing the program to implement the method for processing DDS messages as described in any one of claims 1 to 6.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that, The program is executed by the processor to implement the method for processing DDS messages as described in any one of claims 1 to 6.