Message collection method and device, electronic equipment and computer readable medium

Abstract

Embodiments of the present application disclose a message collection method and device, electronic equipment and a computer readable medium. The embodiments of the method include: obtaining a DDS message collection configuration file for a target electronic control unit, the DDS message collection configuration file including message collection configuration information for at least one topic; determining a target topic in the at least one topic based on the message collection configuration information, collecting a target DDS message under the target topic; and storing the target DDS message. The embodiments expand the applicable scenarios of DDS message collection, and reduce the cost of the vehicle end.

Description

Technical Field

[0001] This application relates to the field of computer technology, specifically to message acquisition methods, apparatus, electronic devices, and computer-readable media. Background Technology

[0002] Data Distribution Service (DDS) is a communication middleware with advantages such as high reliability and high throughput, and it has been increasingly adopted by the automotive industry. In DDS, publishers release data through topics, which are then encapsulated into DDS messages and sent to the network. Subscribers receive these DDS messages by subscribing to the topic. In the automotive field, vehicle ECUs (Electronic Control Units) interact via DDS, typically requiring the collection of DDS messages for subsequent data analysis and testing.

[0003] In existing technologies, it is typically necessary to connect the PC (Personal Computer) to the vehicle via a network cable, and configure a gateway in the vehicle to support communication between the PC and the vehicle's ECU. Specialized DDS message acquisition software is then used on the PC to collect and store DDS messages. This method does not support remote DDS message acquisition, limits application scenarios, has poor flexibility, and requires an onboard gateway, increasing the cost on the vehicle side. Summary of the Invention

[0004] This application provides a message acquisition method, apparatus, electronic device, and computer-readable medium, which expands the applicable scenarios of DDS message acquisition, improves the flexibility of DDS message acquisition, and reduces the cost of vehicle-side data acquisition.

[0005] In a first aspect, embodiments of this application provide a message acquisition method applied to a target electronic control unit (ECU) in a vehicle. The target ECU interacts with other ECUs in the vehicle via a Data Distribution Service (DDS). The method includes: obtaining a DDS message acquisition configuration file for the target ECU, the DDS message acquisition configuration file including message acquisition configuration information for at least one topic; determining a target topic among the at least one topics based on the message acquisition configuration information, and acquiring a target DDS message corresponding to the target topic; and storing the target DDS message.

[0006] Secondly, embodiments of this application provide a message acquisition device applied to a target electronic control unit (ECU) in a vehicle. The target ECU interacts with other ECUs in the vehicle via a Data Distribution Service (DDS). The device includes: an acquisition unit for acquiring a DDS message acquisition configuration file for the target ECU, the DDS message acquisition configuration file including message acquisition configuration information for at least one topic; an acquisition unit for determining a target topic among the at least one topics based on the message acquisition configuration information, and acquiring the target DDS message corresponding to the target topic; and a storage unit for storing the target DDS message.

[0007] Thirdly, embodiments of this application provide an electronic device, including: one or more processors; and a storage device having one or more programs stored thereon, wherein when the one or more programs are executed by the one or more processors, the one or more processors implement the method as described in any embodiment of the first aspect.

[0008] Fourthly, embodiments of this application provide a computer-readable medium having a computer program stored thereon that, when executed by a processor, implements the method as described in any embodiment of the first aspect.

[0009] In this embodiment, the target electronic control unit (ECU) in the vehicle first acquires a DDS message acquisition configuration file for that ECU. The DDS message acquisition configuration file includes message acquisition configuration information for at least one topic. Then, based on the message acquisition configuration information, a target topic within the at least one topic is determined, and target DDS messages under that target topic are acquired. Finally, the acquired target DDS messages are stored. In this process, on the one hand, by acquiring the DDS message acquisition configuration file for the target ECU, the target ECU can complete the acquisition and storage of DDS messages without relying on a wired connection between the vehicle and the PC, enabling DDS message acquisition in all scenarios and expanding the applicable scenarios for DDS message acquisition. Simultaneously, no gateway configuration is required on the vehicle, reducing vehicle-side costs. On the other hand, because a specific DDS message acquisition configuration file is set for the target ECU, and corresponding message acquisition configuration information is set for different topics, the target ECU can perform customized DDS message acquisition for different topics, achieving on-demand DDS message acquisition and improving the flexibility of DDS message acquisition. Attached Figure Description

[0010] Other features, objects, and advantages of this application will become more apparent from the following detailed description of non-limiting embodiments with reference to the accompanying drawings:

[0011] Figure 1 This is a schematic diagram of the DDS communication principle of the message acquisition method of this application;

[0012] Figure 2 This is a flowchart of one embodiment of the message acquisition method of this application;

[0013] Figure 3 This is a schematic diagram of the structure of the target DDS message in the message acquisition method of this application;

[0014] Figure 4 This is a schematic diagram of the structure of the rewritten message of the message acquisition method of this application;

[0015] Figure 5 This is a schematic diagram of the data packet structure of the message acquisition method of this application;

[0016] Figure 6 This is a schematic diagram of the system structure to which the message acquisition method of this application applies;

[0017] Figure 7 This is a schematic diagram of the structure of one embodiment of the message acquisition device of this application;

[0018] Figure 8 This is a schematic diagram of the structure of an electronic device used to implement the embodiments of this application. Detailed Implementation

[0019] All actions involving the acquisition of signals, information, or data in this application are carried out in accordance with the relevant data protection laws and policies of the country where the application is located, and with the authorization of the owner of the relevant device.

[0020] The present application will now be described in further detail with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the invention and not intended to limit it. Furthermore, it should be noted that, for ease of description, only the parts relevant to the invention are shown in the accompanying drawings.

[0021] It should be noted that, unless otherwise specified, the embodiments and features described in this application can be combined with each other. This application will now be described in detail with reference to the accompanying drawings and embodiments.

[0022] For ease of understanding, some aspects involved in the embodiments of this application will be explained first:

[0023] DDS (Data Distribution Service) is a high-performance, low-latency distributed data exchange middleware widely used in real-time and embedded systems, such as autonomous driving, aerospace, industrial automation, and military applications. It supports efficient transmission and sharing of real-time data by providing a flexible data distribution mechanism.

[0024] For the principles of DDS communication, please refer to [link / reference]. Figure 1 Specifically, it includes:

[0025] A participant represents an application or device that participates in DDS data exchange. Each participant can contain multiple publishers and subscribers.

[0026] The Publisher is responsible for creating and managing DataWriters, which publish data to specified topics. Each Publisher can manage one or more DataWriters.

[0027] Subscriber: Responsible for creating and managing DataReaders, which receive data from specified topics. Each subscriber can manage one or more DataReaders.

[0028] A topic defines the type and structure of data, serves as the logical channel for data exchange, and is the link between publishers and subscribers. Publishers and subscribers use topics to match and exchange data.

[0029] DataWriter: Responsible for encapsulating data belonging to a specific topic into DDS messages and sending them over the network. A data writer can only be associated with one topic, but a topic can be associated with multiple data writers, and these data writers can be managed by different publishers.

[0030] DataReader: Responsible for receiving DDS messages related to a specific topic from the network and extracting the data. A data reader can only be associated with one topic, but a topic can be associated with multiple data readers, which can be managed by different subscribers.

[0031] DDS Message: A DDS message is a data unit transmitted in a DDS system. It encapsulates the data content of the topic and also contains some additional information for transmission control and management.

[0032] In the field of autonomous driving, vehicles are equipped with ECUs (Electronic Control Units). An ECU is an embedded system used to control one or more electrical systems in a vehicle. It is often referred to as the "brain" of the car, receiving input signals from sensors, processing these signals, and sending control commands to actuators to control various functions of the vehicle.

[0033] Each ECU in the vehicle can act as a participant, exchanging data with each other via DDS. Typically, DDS message acquisition is required during this process for DDS message playback. DDS message acquisition refers to capturing and recording data packets during DDS communication for subsequent analysis and processing. DDS message playback refers to resending the acquired DDS messages back to the network for testing, verification, or simulation scenarios.

[0034] In existing technologies, it is typically necessary to connect the PC (Personal Computer) to the vehicle via a network cable, and configure a gateway in the vehicle to support communication between the PC and the vehicle's ECU. Specialized DDS message acquisition software is then used on the PC to collect and store DDS messages. This method does not support remote DDS message acquisition, limits application scenarios, has poor flexibility, and requires an onboard gateway, increasing the cost on the vehicle side.

[0035] This application provides a message acquisition method that can solve the above problems.

[0036] Please refer to Figure 2 This document illustrates the flow of one embodiment of the message acquisition method according to this application. The message acquisition method can be applied to a target electronic control unit (ECU) in a vehicle, which interacts with other ECUs in the vehicle via a Data Distribution System (DDS). The target ECU can be any ECU in the vehicle. The message acquisition method of this application is executed by the target ECU.

[0037] The message collection method includes the following steps:

[0038] Step 201: Obtain the DDS message acquisition configuration file for the target electronic control unit. The DDS message acquisition configuration file includes message acquisition configuration information for at least one topic.

[0039] In this embodiment, the target electronic control unit (ECU) can obtain its own DDS message acquisition configuration file. For example, the DDS message acquisition configuration file can be transmitted from a PC to the vehicle via a wireless connection, and then obtained by the target ECU. Alternatively, the PC can pre-upload the configuration file to the cloud, and then the cloud can distribute it to the vehicle for the target ECU to obtain.

[0040] In this embodiment, the DDS message acquisition configuration file may include message acquisition configuration information for at least one topic. The at least one topic may be a topic associated with the target electronic control unit (ECU), specifically including topics subscribed to and published by the target ECU. For each topic, the corresponding message acquisition configuration information can be used to indicate the acquisition configuration for DDS messages under that topic, such as whether to perform DDS message acquisition, the type of DDS messages acquired, and the acquisition method.

[0041] As an example, the message collection configuration information may include a collection identifier. The collection identifier indicates whether DDS messages under this topic should be collected. The collection identifier may include at least one of the following: "OFF" or "ON". Wherein, "OFF" indicates that DDS messages under this topic do not need to be collected; "ON" indicates that DDS messages under this topic need to be collected.

[0042] As another example, the message acquisition configuration information may include an acquisition type identifier. The acquisition type identifier may include, but is not limited to, at least one of the following: "OFF", "On_WithAllWriter&Reader", "On_OnlyWriter", "On_OnlyOneWriter", and "On_OnlyReader". The meanings of the above acquisition type identifiers are as follows:

[0043] "OFF" indicates that DDS messages under this topic do not need to be collected.

[0044] "On_WithAllWriter&Reader" indicates that all DDS messages written by all data writers and read by all data readers under this topic need to be collected. It's understandable that a topic can be associated with multiple data writers located in different electronic control units (ECUs). Each data writer can generate DDS messages corresponding to that topic; therefore, a topic can have multiple data writers, and the DDS messages written by all data writers under that topic can originate from multiple ECUs. The same applies to data readers, which will not be elaborated upon here.

[0045] "On_OnlyWriter" indicates that all DDS messages written by all data writers under this topic need to be collected, while all DDS messages read by all data readers under this topic do not need to be collected.

[0046] "On_OnlyOneWriter" indicates that each DDS message written by each data writer under this topic is collected only once, and that DDS messages read by all data readers under this topic do not need to be collected.

[0047] "On_OnlyReader" indicates that DDS messages written by all data writers under this topic do not need to be collected, while DDS messages read by all data readers under this topic need to be collected.

[0048] It is understandable that the DDS message acquisition configuration file, in addition to including message acquisition configuration information for at least one topic, may also include the identifier of the target electronic control unit (ECU) and the identifiers of each of the aforementioned topics. The identifier of the target ECU may include, but is not limited to, the name of the target ECU. By configuring the identifier of the target ECU, the DDS message acquisition configuration file can be selectively acquired by the target ECU. The identifier of a topic can be the name or code of the topic. By configuring the identifier of a topic, message acquisition configuration can be tailored to different topics, achieving on-demand acquisition.

[0049] By setting up a DDS message acquisition configuration file for the target electronic control unit and setting up corresponding message acquisition configuration information for different topics, the target electronic control unit can perform customized DDS message acquisition for different topics, realizing on-demand acquisition of DDS messages and improving the flexibility of DDS message acquisition.

[0050] Step 202: Based on the message collection configuration information, determine at least one target topic in the topic, and collect the target DDS messages under the target topic.

[0051] In this embodiment, since the message collection configuration information for each topic indicates whether to collect DDS messages under that topic, a target topic among the at least one of the aforementioned topics can be determined based on the message collection configuration information. The target topic can be one or more of the aforementioned topics for DDS message collection. After determining the target topic, target DDS messages under the target topic are filtered and collected. The target DDS message is the message to be collected from the messages encapsulating data under the target topic.

[0052] As an example, the message collection configuration information may include a collection identifier. The collection identifier indicates whether DDS messages under this topic should be collected. The collection identifier may include at least one of the following: "OFF" or "ON". If the message collection configuration information for a certain topic includes the collection identifier "ON", then that topic can be identified as the target topic, i.e., the topic for which DDS message collection is required. Based on this, DDS messages in the target topic can be collected as target DDS messages.

[0053] As another example, the message acquisition configuration information may include an acquisition type identifier. The acquisition type identifier may include, but is not limited to, at least one of the following: "OFF", "On_WithAllWriter&Reader", "On_OnlyWriter", "On_OnlyOneWriter", and "On_OnlyReader". If the message acquisition configuration information for a specific topic contains any one of these acquisition type identifiers, then that topic can be identified as the target topic, i.e., the topic for which DDS message acquisition is required. Based on this, for a specific target topic, the target DDS message to be acquired within that target topic can be determined based on the acquisition type indicated by the acquisition type identifier corresponding to that target topic, and then that DDS message can be acquired.

[0054] Step 203: Store the target DDS message.

[0055] In this embodiment, the collected target DDS messages can be directly summarized and stored, or the collected target DDS messages can be post-processed and the processing results stored; no specific limitation is made here. For example, one or more of the following processes can be performed: filtering, target information extraction, message packet assembly, compression, etc.

[0056] Based on this, a customized parsing tool can be configured on the vehicle side to parse and display the target DDS message, enabling DDS message analysis without relying on a PC.

[0057] The method provided in the above embodiments of this application involves the target electronic control unit (ECU) in a vehicle first acquiring a DDS message acquisition configuration file for that ECU. The DDS message acquisition configuration file includes message acquisition configuration information for at least one topic. Then, based on the message acquisition configuration information, a target topic within the at least one topic is determined, and target DDS messages under that target topic are acquired. Finally, the acquired target DDS messages are stored. In this process, on the one hand, by acquiring the DDS message acquisition configuration file for the target ECU, the target ECU can complete the acquisition and storage of DDS messages without relying on a wired connection between the vehicle and the PC, enabling DDS message acquisition in all scenarios and expanding the applicable scenarios for DDS message acquisition. Simultaneously, no gateway configuration is required on the vehicle, reducing vehicle-side costs. On the other hand, since a specific DDS message acquisition configuration file is set for the target ECU, and corresponding message acquisition configuration information is set for different topics, the target ECU can perform customized DDS message acquisition for different topics, achieving on-demand DDS message acquisition and improving the flexibility of DDS message acquisition.

[0058] In some optional embodiments, step 203 above may further include the following sub-steps:

[0059] Sub-step 2031: Extract target information from the target DDS message.

[0060] Specifically, target information refers to a portion of the target DDS message, which may include the data to be analyzed and other important information. The specific details can be specified by technical personnel as needed, and are not limited here. By extracting target information, only the portion of the target DDS message supporting data analysis can be retained, thereby reducing subsequent storage overhead. It also reduces bandwidth consumption when uploading the collected results to the cloud.

[0061] Sub-step 2032: Summarize the target information according to a preset format to obtain the rewritten message corresponding to the target DDS message.

[0062] Here, the preset format can be customized by technical personnel, and no specific limitations are imposed. For example, the target information can be concatenated according to a preset order to obtain the rewritten message corresponding to the target DDS message. As another example, after concatenating the target information, timestamps, message lengths, and other information can be added at set locations to obtain the rewritten message corresponding to the target DDS message. No specific limitations are imposed here.

[0063] Sub-step 2033: Assemble the obtained rewritten messages into packets to obtain data packets.

[0064] Here, packetizing the rewritten message refers to encapsulating it into a data packet suitable for network transmission according to a certain format. The main purpose of packetization is to transmit data efficiently and reliably. The format of the packetized data can be defined by technical personnel and is not specifically limited here.

[0065] Sub-step 2034: Compress the data packets to obtain the DDS message acquisition result file.

[0066] Compressing data packets can further reduce data storage and transmission overhead.

[0067] Sub-step 2035: Store the DDS message acquisition result file.

[0068] Based on this, a customized parsing tool can be configured on the vehicle side to parse and display the DDS message acquisition result files, enabling DDS message analysis without relying on a PC.

[0069] By sequentially extracting target information, rewriting messages, assembling messages, and compressing data packets, the storage and transmission overhead of data can be reduced to the greatest extent, thereby reducing resource consumption and lowering equipment costs.

[0070] In some alternative embodiments, see Figure 3 The target DDS message includes the Media Access Control Header (MAC Header), Internet Protocol Header (IP Header), User Datagram Protocol Header (UDP Header), DDS Header, DDS Payload, and Frame Check Sequence (FCS).

[0071] Based on this, sub-step 2031 above can be further executed according to the following steps:

[0072] The first step is to extract the source Internet Protocol address (which can be referred to as the source IP address) and the destination Internet Protocol address (which can be referred to as the destination IP address) from the Internet Protocol header (i.e., the IP header).

[0073] The second step is to extract the DDS protocol version number, data sequence number, and target subject identifier from the DDS protocol header.

[0074] The third step is to extract the DDS payload from the target DDS message.

[0075] The fourth step is to summarize the source IP address, destination IP address, DDS protocol version number, data sequence number, target topic identifier, and DDS payload to obtain the target information.

[0076] The MAC header is the header of the data link layer, used to encapsulate data packets from the network layer and ensure that data can be transmitted correctly in the physical network. The MAC header can occupy 14 bytes.

[0077] The IP header is the network layer header used to encapsulate transport layer data, ensuring that data can be correctly routed across the internet. The IP header occupies 20 bytes. It consists of non-IP address information, the source IP address, and the destination IP address. The non-IP address information includes, but is not limited to, the version number, IP header length, and IP header checksum. This non-IP address information occupies 12 bytes. The source and destination IP addresses each occupy 4 bytes. Since the source and destination IP addresses indicate the sender and receiver of the data, respectively, they can be extracted as part of the destination information.

[0078] The UDP header is the transport layer header used to encapsulate application layer data and provide connectionless data transmission services. The UDP header can occupy 8 bytes.

[0079] The DDS Header is the application layer header used to encapsulate DDS protocol-related data, ensuring correct data transmission within the DDS system. The UDP Header occupies 20 bytes. It may include the DDS protocol identifier, DDS protocol version number, data sequence number, and destination topic identifier. In practice, data from a single topic may be sent multiple times, each with a corresponding sequence number. The DDS protocol version number occupies 1 byte, the data sequence number occupies 2 bytes, and the destination topic identifier occupies 4 bytes. The DDS protocol version number indicates the DDS protocol version, the data sequence number uniquely identifies the data being transmitted, and the destination topic identifier uniquely identifies the source topic of the data encapsulated in the target DDS message. Therefore, the DDS protocol version number, data sequence number, and destination topic identifier can be extracted as part of the target information.

[0080] The DDS Payload is the application layer data portion, containing the actual data to be transmitted. The data in the DDS Payload is the final data to be detected; therefore, the content of the DDS Payload can be extracted as partial target information.

[0081] FCS is a 4-byte sequence located at the end of an Ethernet frame, used to check for errors in the data.

[0082] It should be noted that the structure of the target DDS message and the number of bytes occupied by each item in the target DDS message are not limited to the above description, and other settings can be made as needed.

[0083] By extracting the target information of the target DDS packet in the above manner, only the protocol version number, data sequence number, source IP address, destination IP address, target subject identifier, and DDS payload of the target DDS packet can be retained. The entire contents of MAC Header, UDP Header, FCS, and parts of IP Header and DDS Header are deleted. Based on this, the rewritten packet is generated, which can greatly reduce the total number of bytes while retaining the target information, thereby reducing storage and traffic overhead.

[0084] In some optional embodiments, based on the above embodiments, sub-step 2032 can be further performed according to the following steps:

[0085] The first step is to obtain the timestamp of the target DDS message. The timestamp is used to indicate the generation time of the target DDS message.

[0086] The second step is to determine the length of the target information.

[0087] Specifically, the target information includes the source IP address, destination IP address, DDS protocol version number, data sequence number, target subject identifier, and DDS payload. Adding the number of bytes occupied by these items to the actual number of bytes occupied by the DDS payload yields the length of the target information.

[0088] The third step is to concatenate the timestamp, the length of the target information, and the target information according to a preset format to obtain the rewritten message corresponding to the target DDS message.

[0089] Specifically, see Figure 4 The rewritten message can be obtained by concatenating the following elements in the order of timestamp, target information length, DDS protocol version number, data sequence number, source IP address, destination IP address, target subject identifier, and DDS payload. The timestamp can occupy 6 bytes, and the target information length can occupy 3 bytes.

[0090] It should be noted that the structure of the rewritten message and the number of bytes occupied by each item in the rewritten message are not limited to the above description, and other settings can be made as needed.

[0091] By generating the rewritten message corresponding to the target DDS message through the above process, the total number of bytes in the rewritten message can be greatly reduced while retaining the target information, thereby reducing storage and bandwidth overhead.

[0092] In some optional embodiments, sub-step 2033 above may be further performed according to the following steps:

[0093] The first step is to group the rewritten messages to obtain at least one group of messages.

[0094] Specifically, grouping rules can be set as needed, without specific limitations. For example, rewritten messages corresponding to the same topic can be grouped together. As another example, target topics can be grouped to obtain multiple topic groups, each containing a set number of target topics, allowing rewritten messages corresponding to the same topic group to be grouped together. As yet another example, grouping can be performed by combining target topics and message length, ensuring that the total length of each group of messages is less than a set threshold. These will not be elaborated upon further here.

[0095] The second step is to concatenate each group of messages in the above-mentioned at least one group of messages to obtain a concatenated message.

[0096] The third step is to determine the total length of the concatenated message. Here, the total length of the concatenated message is the sum of the lengths of each message in the group.

[0097] The fourth step involves concatenating the preset start flag, total length, concatenated message, checksum of the concatenated message group, and preset end flag to obtain a data packet.

[0098] Specifically, the structure of the data packet can be found in [reference needed]. Figure 5 The start flag indicates the beginning of a concatenated message and can be set to a fixed value, such as 0xAA55. The start flag occupies 2 bytes. The checksum is a method used to check data integrity and accuracy. It generates a checksum by summing all bytes or bits in a data block. This checksum is usually appended to the data to verify at the receiving end whether the data has been modified or corrupted during transmission. The checksum occupies 1 byte. The end flag indicates the end of a concatenated message and can be set to a fixed value, such as 0x7B. The start flag occupies 1 byte.

[0099] By assembling the rewritten messages obtained through the above process, data storage and transmission can be carried out efficiently and reliably.

[0100] In some optional embodiments, after performing step 204, the following step may also be performed: uploading the DDS message acquisition result file to the cloud.

[0101] In practical applications, servers and databases can be deployed in the cloud. The vehicle and cloud can communicate wirelessly. When a DDS message acquisition result file is generated, it can be uploaded to the cloud in real time, ensuring that both the vehicle and cloud store the DDS message acquisition result file. Technicians can download the DDS message acquisition result file from the cloud via PC or view it directly on the vehicle, improving the convenience and flexibility of DDS message playback and analysis.

[0102] In some optional embodiments, after performing step 203, the following step may also be performed: upon receiving a message readback instruction from the PC, the target DDS message is uploaded to the cloud, so that the PC can download the target DDS message from the cloud. Thus, the PC can parse and display the target DDS message using the configured DDS message parsing tool, enabling DDS message analysis on the PC.

[0103] The readback instruction may include, but is not limited to, at least one of the following: the vehicle's VIN (Vehicle Identification Number), time period information, the identifier of the subject to be read back, and the storage address of the target DDS message to be read back. The VIN is also known as the vehicle identification number. The time period information refers to the generation time of the original DDS message to be read back.

[0104] By uploading the target DDS message to the cloud upon receiving a message readback command from the PC, on-demand transmission of the target DDS message is achieved, reducing traffic overhead during transmission.

[0105] Understandably, if the acquisition results are stored in the form of DDS message acquisition result files, then after executing sub-step 2035, the following steps can also be performed: upon receiving a message readback command from the PC, the DDS message acquisition result file is uploaded to the cloud, allowing the PC to download the DDS message acquisition result file from the cloud and parse it to obtain the target DDS message. In this case, the PC is configured with a customized parsing tool, which can parse and display the DDS message acquisition result file, enabling DDS message analysis on the PC. By uploading the DDS message acquisition result file to the cloud upon receiving a message readback command from the PC, on-demand transmission of the DDS message acquisition result file can be achieved, further reducing the traffic overhead during transmission.

[0106] In some optional embodiments, after executing sub-step 2035, the following steps may also be performed: detecting the vehicle's operating status; and uploading the target DDS message to the cloud when the vehicle's operating status meets the target conditions. The target conditions can be set as needed and are not specifically limited here. For example, when the vehicle's operating status is in a fault state, the target DDS message can be uploaded to the cloud; or, when the vehicle is in an emergency braking state, the target DDS message can be uploaded to the cloud, etc.

[0107] The target electronic control unit can detect the vehicle's operating status based on received data or signals. For example, the vehicle's battery status can be detected by analyzing data collected by voltage, temperature, and current sensors within the battery pack. The target electronic control unit can communicate with the sensors via a CAN (Controller Area Network) bus to acquire sensor data or signals transmitted by the sensors.

[0108] By combining the vehicle's operating status to control the timing of target DDS message uploads, on-demand transmission of target DDS messages can be achieved, reducing traffic overhead during transmission.

[0109] Understandably, if the acquisition results are stored in the form of DDS message acquisition result files, then after executing sub-step 2035, the following steps can also be performed: detect the vehicle's operating status; when the vehicle's operating status meets the target conditions, upload the DDS message acquisition result file to the cloud. By controlling the upload timing of the DDS message acquisition result file in conjunction with the vehicle's operating status, on-demand transmission of the DDS message acquisition result file can be achieved, further reducing the traffic overhead during transmission.

[0110] In combination with the above embodiments, Figure 6 A schematic diagram of a system to which the message acquisition method of this application is applicable is shown. See also Figure 6 As shown, the system may include a vehicle-side terminal, a cloud-based terminal, and a PC-based terminal. The cloud-based terminal may have the function of storing DDS message acquisition result files and DDS message acquisition configuration files. The vehicle-side terminal may be configured with a target electronic control unit, which may contain multiple functional modules to realize DDS message acquisition configuration and the functions of DDS message acquisition, modification, packetization, compression, storage, uploading, and playback. The PC-based terminal may also include multiple functional modules to perform DDS message acquisition configuration file push, DDS message acquisition result file playback, and storage functions. Different functional modules can interact with each other; see [reference needed]. Figure 6 As indicated by the arrows in the image, further details will not be provided here.

[0111] Further reference Figure 7As an implementation of the methods shown in the above figures, this application provides an embodiment of a message acquisition device, which is similar to... Figure 1 Corresponding to the method embodiment shown, the device can be specifically applied to a target electronic control unit in a vehicle, which interacts with other electronic control units in the vehicle through a data distribution service (DDS).

[0112] like Figure 7 As shown, the message acquisition device of this embodiment includes: an acquisition unit 701, used to acquire a DDS message acquisition configuration file for the target electronic control unit, the DDS message acquisition configuration file including message acquisition configuration information for at least one topic; an acquisition unit 702, used to determine a target topic among the at least one topics based on the message acquisition configuration information, and acquire target DDS messages under the target topic; and a storage unit 703, used to store the target DDS messages.

[0113] In some optional implementations of this embodiment, the storage unit 703 is further configured to: extract target information from the target DDS message; summarize the target information according to a preset format to obtain a rewritten message corresponding to the target DDS message; assemble the obtained rewritten message into a packet to obtain a data packet; compress the data packet to obtain a DDS message acquisition result file; and store the DDS message acquisition result file.

[0114] In some optional implementations of this embodiment, the target DDS message includes a Media Access Control header, an Internet Protocol header, a User Datagram Protocol header, a DDS protocol header, a DDS payload, and a frame check sequence number; the storage unit 703 is further configured to: extract the source Internet Protocol address and the destination Internet Protocol address from the Internet Protocol header; extract the DDS protocol version number, the data sequence number, and the identifier of the target topic from the DDS protocol header; extract the DDS payload from the target DDS message; and summarize the source Internet Protocol address, the destination Internet Protocol address, the DDS protocol version number, the data sequence number, the identifier of the target topic, and the DDS payload to obtain target information.

[0115] In some optional implementations of this embodiment, the storage unit 703 is further configured to: obtain the timestamp of the target DDS message, the timestamp being used to indicate the generation time of the target DDS message; determine the length of the target information; and concatenate the timestamp, the length of the target information, and the target information according to a preset format to obtain the rewritten message corresponding to the target DDS message.

[0116] In some optional implementations of this embodiment, the storage unit 703 is further configured to: group the obtained rewritten messages to obtain at least one group of messages; for each group of messages in the at least one group of messages, perform the following steps: concatenate the group of messages to obtain a concatenated message; determine the total length of the concatenated message; and concatenate a preset start flag, the total length, the concatenated message, the checksum of the group of messages, and a preset end flag to obtain a data packet.

[0117] In some optional implementations of this embodiment, the device further includes a first uploading unit, configured to: upload the target DDS message to the cloud upon receiving a message readback instruction sent by a personal computer (PC), so that the PC can download the target DDS message from the cloud.

[0118] In some optional implementations of this embodiment, the device further includes a second uploading unit, configured to: detect the vehicle operating status; and upload the target DDS message to the cloud when the vehicle operating status meets the target conditions.

[0119] The apparatus provided in the above embodiments of this application first obtains a DDS message acquisition configuration file for the target electronic control unit (ECU). The DDS message acquisition configuration file includes message acquisition configuration information for at least one topic. Then, based on the message acquisition configuration information, a target topic within the at least one topic is determined, and target DDS messages under the target topic are acquired. Finally, the acquired target DDS messages are stored. In the above process, on the one hand, by obtaining the DDS message acquisition configuration file for the target ECU, the target ECU can complete the acquisition and storage of DDS messages without relying on a wired connection between the vehicle and the PC, enabling DDS message acquisition in all scenarios and expanding the applicable scenarios of DDS message acquisition. At the same time, there is no need to configure a gateway on the vehicle, reducing vehicle-side costs. On the other hand, since a specific DDS message acquisition configuration file is set for the target ECU, and corresponding message acquisition configuration information is set for different topics, the target ECU can perform customized DDS message acquisition for different topics, realizing on-demand acquisition of DDS messages and improving the flexibility of DDS message acquisition.

[0120] The following is for reference. Figure 8 It shows a schematic diagram of the structure of an electronic device used to implement some embodiments of this application. Figure 8 The electronic device shown is merely an example and should not be construed as limiting the functionality and scope of the embodiments of this application.

[0121] like Figure 8As shown, the electronic device may include a processing unit (e.g., a central processing unit, a graphics processing unit, etc.) 801, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 802 or a program loaded from a storage device 808 into a random access memory (RAM) 803. The RAM 803 also stores various programs and data required for the operation of the electronic device 800. The processing unit 801, ROM 802, and RAM 803 are interconnected via a bus 804. An input / output (I / O) interface 805 is also connected to the bus 804.

[0122] Typically, the following devices can be connected to I / O interface 805: input devices 806 including, for example, touchscreens, touchpads, keyboards, mice, cameras, microphones, accelerometers, gyroscopes, etc.; output devices 807 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 808 including, for example, disks, hard disks, etc.; and communication devices 809. Communication device 809 allows electronic device 800 to communicate wirelessly or wiredly with other devices to exchange data. Although Figure 8 An electronic device 800 with various devices is shown; however, it should be understood that it is not required to implement or possess all of the devices shown. More or fewer devices may be implemented or possessed alternatively. Figure 8 Each box shown can represent a device or multiple devices as needed.

[0123] In particular, according to some embodiments of this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, some embodiments of this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device 809, or installed from a storage device 808, or installed from a ROM 802. When the computer program is executed by the processing device 801, it performs the functions defined in the methods of some embodiments of this application.

[0124] It should be noted that the computer-readable medium described in some embodiments of this application may be a computer-readable signal medium or a computer-readable storage medium, or any combination thereof. A computer-readable storage medium may be, for example,—but not limited to—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 or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In some embodiments of this application, a computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. In some embodiments of this application, a computer-readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A computer-readable signal medium can be any computer-readable medium other than a computer-readable storage medium, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to: wires, optical fibers, RF (radio frequency), etc., or any suitable combination thereof.

[0125] In some implementations, clients and servers can communicate using any currently known or future-developed network protocol such as HTTP (Hypertext Transfer Protocol) and can interconnect with digital data communication (e.g., communication networks) of any form or medium. Examples of communication networks include local area networks (“LANs”), wide area networks (“WANs”), the Internet (e.g., the Internet of Things), and end-to-end networks (e.g., ad hoc end-to-end networks), as well as any currently known or future-developed networks.

[0126] The aforementioned computer-readable medium may be included in the aforementioned electronic device; or it may exist independently and not assembled into the electronic device. The aforementioned computer-readable medium carries one or more programs that, when executed by the electronic device, cause the electronic device to: acquire a DDS message acquisition configuration file for a target electronic control unit, the DDS message acquisition configuration file including message acquisition configuration information for at least one topic; based on the message acquisition configuration information, determine a target topic within the at least one topic, acquire target DDS messages under the target topic, and store the target DDS messages.

[0127] Computer program code for performing operations of some embodiments of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++; and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network, or it can be connected to an external computer (e.g., via the Internet using an Internet service provider), including local area networks (LANs) or wide area networks (WANs).

[0128] 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. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing 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 the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, 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.

[0129] The units described in some embodiments of this application can be implemented in software or hardware. The described units can also be housed in a processor; for example, a processor may be described as including a first determining unit, a second determining unit, a selecting unit, and a third determining unit. The names of these units do not necessarily limit the specific unit itself.

[0130] The functions described above in this document can be performed, at least in part, by one or more hardware logic components. For example, exemplary types of hardware logic components that can be used, without limitation, include: Field Programmable Gate Arrays (FPGAs), Application-Specific Integrated Circuits (ASICs), Application Standard Products (ASSPs), System-on-Chip (SoCs), Complex Programmable Logic Devices (CPLDs), and so on.

[0131] The above description is merely a selection of preferred embodiments of this application and an explanation of the technical principles employed. Those skilled in the art should understand that the scope of the invention involved in the embodiments of this application is not limited to technical solutions formed by specific combinations of the above-described technical features, but should also cover other technical solutions formed by arbitrary combinations of the above-described technical features or their equivalents without departing from the above-described inventive concept. For example, technical solutions formed by substituting the above-described features with (but not limited to) technical features with similar functions disclosed in the embodiments of this application.

Claims

1. A message acquisition method, characterized in that, A target electronic control unit (ECU) applied in a vehicle, the target ECU interacting with other ECUs in the vehicle via a data distribution service (DDS), the method comprising: Obtain the DDS message acquisition configuration file for the target electronic control unit, wherein the DDS message acquisition configuration file includes message acquisition configuration information for at least one topic; Based on the message collection configuration information, a target topic among the at least one topics is determined, and target DDS messages under the target topic are collected; Store the target DDS message.

2. The method according to claim 1, characterized in that, The storage of the target DDS message includes: Extract target information from the target DDS message; The target information is summarized according to a preset format to obtain the rewritten message corresponding to the target DDS message; The rewritten messages are then assembled into packets to obtain data packets; The data packets are compressed to obtain a DDS message acquisition result file; Store the DDS message acquisition result file.

3. The method according to claim 2, characterized in that, The target DDS message includes a Media Access Control header, an Internet Protocol header, a User Datagram Protocol header, a DDS protocol header, a DDS payload, and a frame check sequence. Extracting target information from the target DDS message includes: Extract the source Internet Protocol address and destination Internet Protocol address from the Internet Protocol header; Extract the DDS protocol version number, data sequence number, and the identifier of the target topic from the DDS protocol header; Extract the DDS payload from the target DDS message; The target information is obtained by summarizing the source Internet Protocol address, the destination Internet Protocol address, the DDS protocol version number, the data sequence number, the target topic identifier, and the DDS payload.

4. The method according to claim 2 or 3, characterized in that, The step of summarizing the target information according to a preset format to obtain the rewritten message corresponding to the target DDS message includes: Obtain the timestamp of the target DDS message, the timestamp being used to indicate the generation time of the target DDS message; Determine the length of the target information; The timestamp, the length of the target information, and the target information are concatenated according to a preset format to obtain the rewritten message corresponding to the target DDS message.

5. The method according to any one of claims 2-4, characterized in that, The step of assembling the obtained rewritten messages into packets to obtain data packets includes: The rewritten messages are grouped to obtain at least one group of messages; For each of the at least one group of messages, perform the following steps: The group of messages is concatenated to obtain the concatenated message; Determine the total length of the spliced ​​message; The preset start flag, the total length, the concatenated message, the checksum of the group of messages, and the preset end flag are concatenated to obtain a data packet.

6. The method according to any one of claims 1-5, characterized in that, After storing the target DDS message, the method further includes: Upon receiving a message readback instruction from a personal computer (PC), the target DDS message is uploaded to the cloud so that the PC can download the target DDS message from the cloud.

7. The method according to any one of claims 1-5, characterized in that, After storing the target DDS message, the method further includes: Detect the vehicle's operating status; When the vehicle's operating status meets the target conditions, the target DDS message is uploaded to the cloud.

8. A message acquisition device, characterized in that, A target electronic control unit (ECU) applied in a vehicle, the target ECU interacting with other ECUs in the vehicle via a data distribution service (DDS), the device comprising: The acquisition unit is used to acquire a DDS message acquisition configuration file for the target electronic control unit, wherein the DDS message acquisition configuration file includes message acquisition configuration information for at least one topic; The acquisition unit is used to determine the target topic among the at least one topics based on the message acquisition configuration information, and to acquire the target DDS message under the target topic; A storage unit is used to store the target DDS message.

9. An electronic device, characterized in that, include: One or more processors; Storage device, on which one or more programs are stored, When the one or more programs are executed by the one or more processors, the one or more processors implement the method as described in any one of claims 1-7.

10. A computer-readable medium having a computer program stored thereon, characterized in that, When the program is executed by the processor, it implements the method as described in any one of claims 1-7.

Images