Data verification method, data sending method, device, electronic equipment and medium

Abstract

The embodiment of the application discloses a data verification method, a data sending method, a device, an electronic device and a medium. The data verification method comprises the following steps: receiving a data packet from a target data space; analyzing the data packet to obtain a globally unique identifier (GUID), first verification data and service data; and verifying the service data according to the GUID and the first verification data to obtain a verification result. The embodiment of the application can verify the service data based on the GUID and the first verification data in the data packet. The GUID is a built-in feature in DDS, and no additional parameters such as DATAID need to be introduced, thereby solving the problem of redundancy between the introduction of additional parameters and the built-in features of DDS, and resources can be saved.

Description

Technical Field

[0001] This application relates to the field of communication technology, and in particular to a data verification method, a data transmission method, an apparatus, an electronic device, and a medium. Background Technology

[0002] In current in-vehicle SOA (Service-Oriented Architecture), the DDS (Data Distribution Service) communication protocol has become the main choice for inter-domain communication in vehicles due to its high efficiency, flexibility and real-time characteristics.

[0003] To meet functional safety requirements, failure detection is necessary for data transmitted via the DDS protocol. However, the DDS protocol itself does not define functional safety-related implementations. Therefore, implementations typically follow the AUTOSAR (Automotive Open System Architecture) E2E (End-to-End) specification. This specification introduces additional parameters, such as DATAID (data identifier) ​​and CRC (Cyclic redundancy check), to a certain extent ensuring the reliability and security of communication. However, existing technologies require the introduction of additional parameters, which are redundant with the built-in features of DDS, leading to resource waste. Summary of the Invention

[0004] This application provides a data verification method, a data transmission method, an apparatus, an electronic device, and a medium that do not require the introduction of additional parameters and can save resources.

[0005] To address the aforementioned problems, in a first aspect, embodiments of this application provide a data verification method applied at a receiving end, comprising:

[0006] Receive data packets from the target data space;

[0007] Parse the data packet to obtain the globally unique identifier (GUID), the first verification data, and the business data;

[0008] The business data is validated based on the GUID and the first validation data to obtain a validation result.

[0009] Secondly, embodiments of this application provide a data transmission method, applied at a sending end, comprising:

[0010] Obtain the GUID of the sending end;

[0011] Based on the GUID and the service data to be sent, determine the first verification data of the service data to be sent;

[0012] The GUID, the first verification data, and the service data to be sent are encapsulated into a data packet;

[0013] The data packet is published to the target data space.

[0014] Thirdly, embodiments of this application provide a data verification device applied at a receiving end, comprising:

[0015] The data packet receiving module is used to receive data packets from the target data space;

[0016] The data packet parsing module is used to parse the data packet to obtain the globally unique identifier (GUID), the first verification data, and the business data.

[0017] The data verification module is used to verify the business data based on the GUID and the first verification data, and obtain the verification result.

[0018] Fourthly, embodiments of this application provide a data transmission apparatus, applied at a transmitting end, comprising:

[0019] A GUID acquisition module is used to acquire the GUID of the sending end;

[0020] The first verification data determination module is used to determine the first verification data of the service data to be sent based on the GUID and the service data to be sent.

[0021] A data packet encapsulation module is used to encapsulate the GUID, the first verification data, and the service data to be sent into a data packet;

[0022] The data packet sending module is used to publish the data packet to the target data space.

[0023] Fifthly, embodiments of this application also provide an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the data verification method or data transmission method described in embodiments of this application.

[0024] Sixthly, embodiments of this application provide a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the steps of the data verification method or the data transmission method disclosed in embodiments of this application.

[0025] The data verification method, data transmission method, apparatus, electronic device, and medium provided in this application receive data packets from a target data space, parse the data packets to obtain GUID, first verification data, and service data, and verify the service data based on the GUID and first verification data to obtain a verification result. The service data can be verified based on the GUID and first verification data in the data packets. Since the GUID is a built-in feature in DDS, there is no need to introduce additional parameters such as DATAID, which solves the problem of redundancy between introducing additional parameters and the built-in features of DDS, and can save resources. Attached Figure Description

[0026] To more clearly illustrate the technical solutions of the embodiments of this application, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0027] Figure 1 This is a flowchart of a data verification method provided in an embodiment of this application;

[0028] Figure 2 This is a schematic diagram illustrating the composition of RTPS data packets in an embodiment of this application;

[0029] Figure 3 This is a flowchart of a data transmission method provided in an embodiment of this application;

[0030] Figure 4 This is an overall flowchart of the data sending method and data verification method in the embodiments of this application;

[0031] Figure 5 This is a schematic diagram of the structure of a data verification device provided in an embodiment of this application;

[0032] Figure 6 This is a schematic diagram of the structure of a data transmission device provided in an embodiment of this application;

[0033] Figure 7 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0034] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0035] Figure 1 This is a flowchart illustrating a data verification method provided in an embodiment of this application. This data verification method is applicable to in-vehicle data communication oriented towards SOA architecture, such as in-vehicle Ethernet communication. This data verification method is applied at the receiving end (i.e., the Reader side), such as... Figure 1 As shown, the method includes steps 110 to 130.

[0036] Step 110: Receive data packets from the target data space.

[0037] In one exemplary embodiment, the target data space is the global data space in DDS, such as Ethernet in vehicular Ethernet communication. DDS is a data-centric, topic-based subscription and publish communication middleware. Data in the target data space is stored and categorized by topic. Publishers (i.e., senders) can write data to the target data space, and subscribers (i.e., receivers) can read data from the target data space.

[0038] In one exemplary embodiment, the target data space can be Ethernet, and the receiving end can receive data packets from Ethernet based on the UDP (User Datagram Protocol) protocol stack. The data packets include service data of the target topic subscribed to by the receiving end.

[0039] In one exemplary embodiment, the data packet may be an RTPS (Real-Time Publish-Subscribe Protocol) data packet. RTPS is used to support data distribution and communication in distributed real-time systems. The RTPS protocol features real-time performance, reliability, distribution, and flexibility, and is often used in application scenarios requiring low latency and high throughput.

[0040] In an exemplary embodiment, before receiving data packets from the target data space, during the user configuration phase, E2E-related information needs to be configured in the configuration file, including whether to enable E2E verification configuration, timeout time, signal type (periodic or event-based), and transmission period.

[0041] Step 120: Parse the data packet to obtain the GUID, the first verification data, and the service data.

[0042] In one exemplary embodiment, a GUID (Globally Unique Identifier) ​​is an identifier in the DDS protocol that identifies the sender of a data packet and is used to characterize the source of the data packet.

[0043] In one exemplary embodiment, the first verification data is data calculated by the sending end for verifying the service data. The first verification data may include the length of the transmitted data and a first CRC (Cyclic Redundancy Check) value.

[0044] In one exemplary embodiment, the received data packet is parsed to obtain a GUID, first verification data, and service data. The data packet may also include a sequence number (SN), which can be obtained during data packet parsing. The SN is data in the DDS protocol that identifies the sequence number of the data packet.

[0045] In some embodiments of this application, parsing the data packet to obtain a GUID, first verification data, and service data includes: parsing the data packet to obtain an E2E sub-message and a data sub-message; parsing the E2E sub-message to obtain the first verification data; and parsing the data sub-message to obtain the GUID and the service data.

[0046] Figure 2 This is a schematic diagram illustrating the composition of RTPS data packets in an embodiment of this application, as shown below. Figure 2 As shown, a data packet can include an RTPS header, an E2E sub-message, and a data sub-message. The RTPS header includes the Magic (indicating that the data packet is an RTPS data packet), the Protocol Version, the vendor ID, and a GUID prefix. Figure 2 In this context, INFO_E2E indicates that the sub-message type is E2E sub-message. The E2E sub-message includes the first check data, namely the length of the transmitted data and the first CRC value. The E2E sub-message also includes flags and the length of the E2E sub-message header. Figure 2 The INFO_DATA header indicates that the sub-message type is a data sub-message. The data sub-message includes a write entity identifier (i.e., sender identifier), a read entity identifier (i.e., receiver identifier), a serial number (SN), and service data. The GUID prefix in the RTPS message header and the write entity identifier in the data sub-message together form the sender's GUID.

[0047] In one exemplary embodiment, parsing the data packet yields an RTPS message header, an E2E sub-message, and a data sub-message. Parsing the RTPS message header yields a GUID prefix. Parsing the E2E sub-message yields first checksum data, namely the length of the transmitted data and a first CRC value. Parsing the data sub-message yields a write entity identifier, a read entity identifier, a serial number (SN), and service data. The GUID prefix from the RTPS message header and the write entity identifier from the data sub-message are combined to form the sender's GUID.

[0048] By including E2E sub-messages and data sub-messages in data packets, the data packets can conform to the RTPS protocol, and different data can be carried through different sub-messages, thereby improving the comprehensiveness of the transmitted data and thus improving the comprehensiveness of data verification.

[0049] Step 130: Verify the business data based on the GUID and the first verification data to obtain the verification result.

[0050] In an exemplary embodiment, the source of business data can be verified based on the GUID, and the data length and integrity of the business data can be verified based on the first verification data to obtain the verification result.

[0051] In some embodiments of this application, the step of verifying the business data based on the GUID and the first verification data to obtain a verification result includes: determining second verification data of the business data based on the GUID and the business data; and determining the verification result of the business data based on the GUID, the first verification data, and the second verification data.

[0052] In one exemplary embodiment, the receiving end can recalculate the verification data based on the GUID and the service data to obtain second verification data. It then compares the first and second verification data. If they match, the verification data verification is successful; otherwise, it fails, indicating a potential data integrity issue. The GUID is compared with a pre-stored GUID from the sending end to determine if the data packet originates correctly. The verification result for the service data can include both the verification data verification result and the GUID verification result.

[0053] In an exemplary embodiment, the data packet may further include the data packet's SN. When the first verification data is calculated, the GUID, SN, and service data are considered simultaneously. In this case, when calculating the second verification data, the GUID, SN, and service data need to be calculated simultaneously to obtain the second verification data.

[0054] After determining the second verification data based on the GUID and business data, the verification result of the business data is determined based on the GUID, the first verification data, and the second verification data. This allows for accurate verification of the business data, ensuring that the data source is correct and the data is complete.

[0055] In some embodiments of this application, the second verification data includes a second CRC value and the length of the received data;

[0056] The step of determining the second verification data of the service data based on the GUID and the service data includes: determining the received data length of the service data; and determining the second CRC value based on the received data length, the GUID, and the service data.

[0057] In one exemplary embodiment, after parsing the obtained service data, the data length of the service data is calculated as the received data length. A CRC value is then calculated using the received data length, the GUID, and the service data as a second CRC value.

[0058] In one exemplary embodiment, when the data packet also includes the data packet's SN, the SN also needs to be included when calculating the second CRC. That is, the CRC value is calculated together with the received data length, GUID, SN and service data as the second CRC value.

[0059] By using the second verification data, which includes the second CRC value and the length of the received data, the integrity and length of the business data can be verified simultaneously. Furthermore, by taking into account the length of the received data, the GUID, and the business data when calculating the second CRC value, the integrity of all data can be guaranteed.

[0060] In some embodiments of this application, the first verification data includes a first CRC value and the length of the transmitted data, and the verification result includes a GUID verification result, a CRC verification result, and a data length verification result;

[0061] The step of determining the verification result of the service data based on the GUID, the first verification data, and the second verification data includes: comparing the GUID with the pre-stored GUID of the sending end to obtain a GUID verification result; comparing the second CRC value with the first CRC value to obtain a CRC verification result; and comparing the length of the received data with the length of the sent data to obtain a data length verification result.

[0062] In one exemplary embodiment, the GUID of the sender that the receiver pre-stores may be the GUID of the sender that the receiver obtains when establishing a communication connection with the sender and stores it.

[0063] In one exemplary embodiment, the GUID in the data packet can be compared with the pre-stored GUID of the sender. If the GUID in the data packet matches the pre-stored GUID of the sender, the data source is correct; otherwise, the data source is incorrect. GUID verification ensures the correctness of the data source.

[0064] In one exemplary embodiment, the second CRC value and the first CRC value are compared to obtain a CRC check result. The CRC check result can be either a successful CRC check (i.e., the second CRC value matches the first CRC value, indicating that the data is complete) or a failed CRC check (i.e., the second CRC value does not match the first CRC value, indicating that the data is incomplete). CRC check ensures data integrity.

[0065] In one exemplary embodiment, the length of the received data is compared with the length of the sent data to obtain a data length verification result. The data length verification result can be either successful (i.e., the received data length matches the sent data length) or unsuccessful (i.e., the received data length does not match the sent data length). Data length verification ensures the consistency between the received and sent data lengths.

[0066] The data verification method provided in this application receives data packets from the target data space, parses the data packets to obtain GUID, first verification data, and business data, and verifies the business data based on the GUID and the first verification data to obtain the verification result. The business data can be verified based on the GUID and the first verification data in the data packets. Since the GUID is a built-in feature in DDS, there is no need to introduce additional parameters such as DATAID, which solves the problem of redundancy between introducing additional parameters and the built-in features of DDS and can save resources.

[0067] Based on the above technical solution, the method may further include: if the service data is a periodic signal, performing timeout verification on the data packet based on the validity period QoS (Quality of Service) of the Data Distribution Service (DDS), obtaining the timeout verification result, and updating the timer of the validity period QoS.

[0068] In one exemplary embodiment, QoS is a set of characteristics that control certain aspects of the behavior of DDS services. Deadline QoS defines the deadline or end date for data, that is, the validity period of data in the DDS system. Deadline QoS controls data transmission between DDS entities to ensure that data is transmitted and received within a specific timeframe.

[0069] In one exemplary embodiment, the QoS validity period corresponds to a timer used to record the length of time between the last time a data packet was received and the current time.

[0070] In one exemplary embodiment, the signal type of the business data is preset, and the signal type may include periodic signals or on-change signals.

[0071] In an exemplary embodiment, when the service data is a periodic signal, timeout verification can be performed on the data packet based on the validity period in the QoS (Quality of Service) period. Specifically, the timer for the QoS period begins counting from the last received data packet. If no new data packet is received within the validity period after the countdown expires, the timeout verification result is determined to be timed out. If a new data packet is received within the validity period after the countdown expires, the timeout verification result is determined to be not timed out. After determining the timeout verification result, the QoS period timer needs to be updated to ensure accurate timeout verification. The validity period can be the transmission period of the periodic signal.

[0072] The existing AUTOSAR E2E specification requires the introduction of an additional timer when performing timeout verification for periodic signals. However, the embodiments of this application can utilize the validity period (QoS) of the DDS to achieve timeout detection for periodic signals, thus avoiding the use of an additional timer.

[0073] Based on the above technical solution, the method may further include: if the service data is an event-type signal, then based on the received heartbeat message, perform node liveness verification based on the DDS's lifetime QoS, obtain the node liveness verification result, and update the lifetime QoS timer.

[0074] In one exemplary embodiment, Live-Line QoS (LIVELINESS QoS) is used to define how the activity or liveness status of a DDS entity is managed. LIVELINESS QoS parameters allow developers to control the monitoring and management of the activity of DDS entities to ensure timely data transmission and reception.

[0075] In one exemplary embodiment, the lifetime QoS corresponds to a timer used to record the length of time between the last time a heartbeat message was received and the current time.

[0076] In an exemplary embodiment, when the service data is an event-type signal, node liveness verification can be performed based on the liveness period in the QoS (Quality of Life) mechanism. Specifically, the timer for the QoS begins counting from the last received heartbeat message. If no new heartbeat message is received within the liveness period after the countdown expires, the liveness verification result is determined to be non-live. If a new heartbeat message is received within the valid period, the timeout verification result is determined to be live. After determining the liveness verification result, the QoS timer needs to be updated to ensure accurate liveness verification. The liveness period can be the configured period for the heartbeat message.

[0077] The existing AUTOSAR E2E specification cannot perform node liveness verification for event-type signals. However, the embodiments of this application can utilize the DDS's lifetime QoS to achieve timeout detection and node liveness status monitoring for event-type signals, thus ensuring the reliability of the communication channel.

[0078] Based on the above technical solution, the data packet also includes the data packet's serial number (SN).

[0079] After verifying the business data based on the GUID and the first verification data to obtain the verification result, the method further includes: storing the business data and the verification result in a cache; and upon receiving a business data read request, verifying the SN corresponding to each business data in the cache to obtain the SN verification result.

[0080] In one exemplary embodiment, after verifying the service data, the service data and the corresponding verification result are stored in the cache of the sending end (i.e., the reader side), awaiting user retrieval. While caching the service data and verification result, it is also possible to determine whether data is lost based on the serial number (SN) of each data packet. If data is lost, and the topic corresponding to the service data is configured with reliable QoS (retransmission mechanism), a retransmission request will be sent to the peer. If it is determined based on the SN of each data packet that the cached service data is out of order, the service data in the cache can be reordered based on the SN of each data packet.

[0081] In an exemplary embodiment, it is checked whether the data packet in the cache is the first frame data packet. If it is the first frame data packet, no SN value verification is performed. If the data packet is not the first frame data packet, SN value verification is required, that is, the difference between the SN of the current data packet and the previous frame data packet is calculated. If the difference is the target value (e.g., 1), it means that the current data packet and the previous frame data packet are in the correct order and there is no out-of-order or packet loss. If the SNs corresponding to each service data in the cache are sequentially increasing and the difference between each two adjacent data packets is the target value, it means that there are no duplicate, out-of-order or packet loss errors in the service data in the cache, that is, the SN verification result is a successful verification. If the serial numbers (SNs) corresponding to each service data in the cache are not sequentially increasing, or if the difference between any two adjacent data packets is not always the target value, then the data in the cache contains duplicate, out-of-order, or lost packets errors, meaning the SN verification result is a failed verification. Additionally, if the SNs of each service data in the cache are the same, then the service data in the cache contains duplicate errors. If the SNs corresponding to each service data in the cache are increasing, but the difference between any two adjacent data packets is not always the target value, then the service data in the cache contains lost packets errors. If the SNs of each service data in the cache are not increasing, meaning the difference between the SNs of any two adjacent data packets can be positive or negative, then the service data in the cache contains out-of-order errors.

[0082] By fully considering the impact of retransmission and reordering on the order of data packets under the Reliable QoS mechanism of DDS, and ensuring that SN verification is performed only after Reliable QoS processing and when a service data read request is received, misjudgments caused by out-of-order delivery or packet loss can be avoided. Moreover, by using the SN of the DDS protocol to replace redundant parameters such as the Rolling Counter in the AUTOSAR E2E specification, the design is simplified and resource waste can be reduced.

[0083] Based on the above technical solution, after storing the business data and the verification result in the cache, the method further includes: in response to the business party's business data reading request, sending the business data and the verification result to the business party.

[0084] In an exemplary embodiment, after receiving a business data read request and verifying the SN corresponding to each business data in the cache, the business data and each verification result (including GUID verification result, CRC verification result, data length verification result, timeout verification result or node liveness verification result, and SN verification result) can be sent to the business party. If the verification fails, the verification result will include the error status, which facilitates the business party to take the next step.

[0085] Based on the above technical solution, before receiving data packets in the target data space, it may further include: during the endpoint discovery phase, establishing a communication connection with the sending end when both the sending end and the receiving end have enabled E2E verification configuration.

[0086] In an exemplary embodiment, during the EDP (Endpoint Discovery Protocol) Match phase, it is necessary to verify whether both communicating parties have enabled E2E verification configuration. Only when both parties have enabled E2E verification configuration can a successful match be established and a communication connection established. When verifying whether the sending end has enabled E2E verification configuration, the receiving end can determine whether the sending end has enabled E2E verification configuration based on the configuration attribute information sent by the sending end.

[0087] By utilizing the matching mechanism in the DDS endpoint discovery phase, the E2E configurations of both communicating parties are verified to ensure that both parties have enabled the E2E function, thus avoiding misjudgments and security vulnerabilities caused by one party not enabling the E2E verification configuration.

[0088] Figure 3 This is a flowchart illustrating a data transmission method provided in an embodiment of this application. This data transmission method is applicable to in-vehicle data communication oriented towards SOA architecture, such as in-vehicle Ethernet communication. This data transmission method is applied at the sending end (i.e., the Reader side), such as... Figure 3 As shown, the method includes steps 310 to 340.

[0089] Step 310: Obtain the GUID of the sending end.

[0090] In one exemplary embodiment, the GUID is an identifier in the DDS protocol that identifies the sender of a data packet and is used to characterize the source of the data packet.

[0091] In one exemplary embodiment, the sending end obtains its own GUID.

[0092] In an exemplary embodiment, before communicating with the receiving end, during the user configuration phase, E2E-related information needs to be configured in the configuration file, including whether to enable E2E verification configuration, timeout time, signal type (periodic or event-based), and transmission period.

[0093] Step 320: Determine the first verification data of the service data to be sent based on the GUID and the service data to be sent.

[0094] In one exemplary embodiment, the first verification data is data calculated by the sending end for verifying the service data. The first verification data may include the length of the transmitted data and a first CRC value.

[0095] In an exemplary embodiment, the sending end may calculate verification data based on the GUID and the service data, which shall be used as the first verification data.

[0096] In an exemplary embodiment, when calculating the first verification data, the SN of the data packet to be sent may also be included in the calculation, that is, the GUID, the SN of the data packet to be sent, and the service data to be sent are calculated simultaneously to obtain the first verification data.

[0097] In some embodiments of this application, the first verification data includes a first CRC value and the length of the transmitted data;

[0098] The step of determining the first verification data of the service data to be sent based on the GUID and the service data to be sent includes: determining the transmission data length of the service data to be sent; and determining the first CRC value based on the transmission data length, the GUID, and the service data to be sent.

[0099] In one exemplary embodiment, the first CRC value is used for data integrity verification, and the transmitted data length is used for data length verification.

[0100] In an exemplary embodiment, the length of the data to be sent is calculated, and a CRC value is calculated based on the length of the data to be sent, the GUID of the sending end, and the data to be sent, which is used as the first CRC value. The length of the data to be sent and the first CRC value are used together as the first verification data.

[0101] In an exemplary embodiment, when calculating the first CRC value, the SN of the data packet to be sent may also be included in the calculation. That is, the CRC calculation is performed on the length of the data to be sent, the GUID, the SN of the data packet to be sent, and the service data to be sent at the same time to obtain the first CRC value.

[0102] By including both the transmitted data length and the first CRC value in the first verification data, the receiving end can easily perform data length verification and data integrity verification. Moreover, when calculating the first CRC value, the transmitted data length, GUID, and the business data to be transmitted are considered simultaneously, which can ensure that all data is fully verified when performing integrity verification.

[0103] Step 330: Encapsulate the GUID, the first verification data, and the service data to be sent into a data packet.

[0104] In one exemplary embodiment, the GUID, first verification data, and service data to be sent can be encapsulated into a data packet in accordance with the RTPS protocol.

[0105] In some embodiments of this application, encapsulating the GUID, the first verification data, and the service data to be sent into a data packet includes: generating an E2E sub-message including the first verification data; generating a data sub-message including the GUID and the service data to be sent; and encapsulating the E2E sub-message and the data sub-message into a data packet.

[0106] like Figure 2 As shown, a data packet can include an RTPS header, an E2E sub-message, and a data sub-message. The RTPS header includes the Magic (indicating that the data packet is an RTPS data packet), the Protocol Version, the vendor ID, and a GUID prefix. Figure 2 In this context, INFO_E2E indicates that the sub-message type is E2E sub-message. The E2E sub-message includes the first check data, namely the length of the transmitted data and the first CRC value. The E2E sub-message also includes flags and the length of the E2E sub-message header. Figure 2 The INFO_DATA header indicates that the sub-message type is a data sub-message. The data sub-message includes a write entity identifier (i.e., sender identifier), a read entity identifier (i.e., receiver identifier), a serial number (SN), and service data. The GUID prefix in the RTPS message header and the write entity identifier in the data sub-message together form the sender's GUID.

[0107] In one exemplary embodiment, such as Figure 2 As shown, according to the RTPS protocol, the first checksum data can be grouped into an E2E sub-message, that is, the length of the data to be sent and the first CRC value can be grouped into an E2E sub-message. The GUID and the service data to be sent can be grouped into a data sub-message, and the SN of the data packet to be sent can also be included in the data sub-message. According to the RTPS protocol, the E2E sub-message and the data sub-message are then converted into a data packet. For example... Figure 2 As shown, the data packet also includes an RTPS message header, which includes a GUID prefix. The data sub-message includes a write entity identifier. The GUID prefix and the write entity identifier together form the sender's GUID.

[0108] By including E2E sub-messages and data sub-messages in data packets, the data packets can conform to the RTPS protocol, and different data can be carried through different sub-messages, thereby improving the comprehensiveness of the transmitted data and thus improving the comprehensiveness of data verification.

[0109] Step 340: Publish the data packet to the target data space.

[0110] In one exemplary embodiment, the target data space is the global data space in DDS, such as Ethernet in vehicular Ethernet communication. DDS is a data-centric, topic-based subscription and publish communication middleware. Data in the target data space is stored and categorized by topic. Publishers (i.e., senders) can write data to the target data space, and subscribers (i.e., receivers) can read data from the target data space.

[0111] In one exemplary embodiment, the target data space can be Ethernet, and the sending end can publish data packets to Ethernet based on the UDP (User Datagram Protocol) protocol stack. The service data to be published in the data packets is the service data of the target topic.

[0112] The data transmission method provided in this application obtains the GUID of the sending end, determines the first verification data based on the GUID and the service data to be sent, encapsulates the GUID, the first verification data and the service data to be sent into a data packet, and publishes the data packet to the target data space. This facilitates the receiving end to verify the service data based on the GUID and the first verification data in the data packet. Since the GUID is a built-in feature of DDS, there is no need to introduce additional parameters such as DATAID, which solves the problem of redundancy between introducing additional parameters and the built-in features of DDS, and can save resources.

[0113] Based on the above technical solution, the method may further include: if the service data to be sent is an event-type signal, then a heartbeat message is sent to the target data space according to the configured period.

[0114] In one exemplary embodiment, the configuration period is the heartbeat message sending period configured by the user during the user configuration phase.

[0115] In an exemplary embodiment, the signal type of the business data is preset, that is, configured by the user during the user configuration phase. The signal type may include periodic signals or event-type signals.

[0116] In an exemplary embodiment, when the service data to be sent is an event-type signal, the sending end sends heartbeat messages to the target data space according to the configured period, so that the receiving end can perform node survival verification on the sending end based on the life-to-life QoS according to the periodically sent heartbeat messages.

[0117] The existing AUTOSAR E2E specification cannot perform node liveness verification for event-type signals. However, the embodiments of this application, for event-type signals, send heartbeat messages by the sending end according to the configured period. This allows the receiving end to use the DDS's lifespan QoS to perform timeout detection and node liveness status monitoring based on the heartbeat messages, thus ensuring the reliability of the communication channel.

[0118] Based on the above technical solution, before obtaining the GUID of the sending end, the method further includes: during the endpoint discovery phase, establishing a communication connection with the receiving end when both the sending end and the receiving end have enabled E2E verification configuration.

[0119] In one exemplary embodiment, during the EDP Match phase, it is necessary to verify whether both communicating parties have enabled E2E verification configuration. Only when both parties have enabled E2E verification configuration can a successful match be established and a communication connection established. When verifying whether the receiving end has enabled E2E verification configuration, the sending end can determine whether the receiving end has enabled E2E verification configuration based on the configuration attribute information sent by the receiving end.

[0120] By utilizing the matching mechanism in the DDS endpoint discovery phase, the E2E configurations of both communicating parties are verified to ensure that both parties have enabled the E2E function, thus avoiding misjudgments and security vulnerabilities caused by one party not enabling the E2E verification configuration.

[0121] Figure 4 This is an overall flowchart of the data sending method and data verification method in the embodiments of this application, as shown below. Figure 4As shown, after receiving the service data generated by Application 1, the writer obtains the GUID, calculates the data length, calculates the CRC value (first CRC value), assembles an E2E sub-message, assembles a data sub-message, synthesizes an RTPS data packet, and sends the data packet to the Ethernet based on the UDP protocol stack. The reader receives the data packet from the Ethernet based on the UDP protocol stack, parses the data sub-message, parses the E2E sub-message, verifies the data length, verifies the GUID, verifies the CRC, performs data timeout verification or node liveness verification according to the signal type, and puts the verified service data and verification results into the cache. The data in the cache can be processed for reliable QoS, such as requesting data retransmission. When receiving a service data read request from Application 2, the reader performs SN verification on the data in the cache, and after verification, sends the service data and all verification results to Application 2. If the sending end detects a verification error in the verification results (including data length verification result, GUID verification result, CRC verification result, timeout verification result, or node liveness verification result) after verifying the data packet, it will notify the BSW (Basic Software) of the error status. The BSW will then count the errors and return the error count to the business party (Application 2).

[0122] Figure 4 The specific execution process of each step can be referred to the above embodiments, and will not be repeated here.

[0123] This application utilizes the SN and GUID of the DDS protocol to replace redundant parameters such as RollingCounter and DATA ID in the AUTOSAR E2E specification, simplifying the design and reducing resource waste. Based on the signal type (Period or OnChange), it automatically selects Deadline QoS or Liveliness QoS for timeout detection, improving the flexibility and efficiency of timeout detection and reducing resource waste. For periodic signals, using DDS's Deadline QoS for timeout detection avoids the need for additional timers. For event-type signals, using DDS's Liveliness QoS enables timeout detection and node liveness monitoring, ensuring the reliability of the communication channel. The matching mechanism in the DDS endpoint discovery phase verifies the E2E configuration of both communicating parties, ensuring that both parties have E2E functionality enabled, avoiding misjudgments and security vulnerabilities caused by one end's lack of configuration, and improving communication reliability and security. Under DDS's Reliable QoS mechanism, the impact of retransmission and reordering on data packet order is fully considered, ensuring that SN verification is performed after QoS processing, avoiding misjudgments due to out-of-order delivery or packet loss, and improving the accuracy of data verification.

[0124] By leveraging DDS's Deadline QoS and Liveliness QoS for timeout detection, no additional timer is required, improving the real-time performance of the functional safety mechanism while reducing system resource consumption. This application's embodiments are based on the native features of the DDS protocol, are compatible with existing DDS implementations, and possess good scalability, making them suitable for various automotive SOA architectures and facilitating promotion and application. By integrating the built-in features of the DDS protocol (such as SN, GUID, Deadline QoS, Liveliness QoS, etc.), the communication mechanism is optimized, eliminating the need for the AUTOSAR E2E specification. This ensures functional safety while improving communication efficiency and reducing communication latency and packet loss rate.

[0125] Figure 5 This is a schematic diagram of a data verification device provided in an embodiment of this application. This data verification device is applied at the receiving end, such as... Figure 5 As shown, the device includes:

[0126] The data packet receiving module 510 is used to receive data packets from the target data space;

[0127] The data packet parsing module 520 is used to parse the data packet to obtain a globally unique identifier (GUID), first verification data, and business data.

[0128] The data verification module 530 is used to verify the business data based on the GUID and the first verification data, and obtain the verification result.

[0129] Optionally, the data verification module includes:

[0130] The second verification data determination unit is used to determine the second verification data of the business data based on the GUID and the business data.

[0131] The verification unit is used to determine the verification result of the business data based on the GUID, the first verification data, and the second verification data.

[0132] Optionally, the second verification data includes a second cyclic redundancy check (CRC) value and the length of the received data;

[0133] The second verification data determination unit is specifically used for:

[0134] The step of determining the second verification data of the business data based on the GUID and the business data includes:

[0135] Determine the length of the received business data;

[0136] The second CRC value is determined based on the received data length, the GUID, and the service data.

[0137] Optionally, the first verification data includes a first CRC value and the length of the transmitted data, and the verification result includes a GUID verification result, a CRC verification result, and a data length verification result;

[0138] The verification unit is specifically used for:

[0139] The GUID is compared with the pre-stored GUID of the sender to obtain the GUID verification result;

[0140] The second CRC value is compared with the first CRC value to obtain the CRC check result;

[0141] The length of the received data is compared with the length of the sent data to obtain the data length verification result.

[0142] Optionally, the packet parsing module is specifically used for:

[0143] Parse the data packet to obtain E2E sub-messages and data sub-messages;

[0144] Parse the E2E sub-message to obtain the first verification data;

[0145] Parse the data sub-message to obtain the GUID and the business data.

[0146] Optionally, the device further includes:

[0147] The timeout verification module is used to perform timeout verification on the data packet based on the validity period QoS of the Data Distribution Service (DDS) if the service data is a periodic signal, obtain the timeout verification result, and update the timer of the validity period QoS.

[0148] Optionally, the device further includes:

[0149] The liveness verification module is used to perform node liveness verification based on the received heartbeat message and the QoS of the DDS if the service data is an event-type signal, obtain the node liveness verification result, and update the timer of the QoS.

[0150] Optionally, the data packet may also include the data packet's serial number (SN).

[0151] The device further includes:

[0152] The caching module is used to store the business data and the verification result in the cache;

[0153] The SN verification module is used to verify the SN corresponding to each piece of business data in the cache when a business data read request is received, and to obtain the SN verification result.

[0154] Optionally, the device further includes:

[0155] The data sending module is used to respond to the business data reading request from the business party and send the business data and verification result to the business party.

[0156] Optionally, the device further includes:

[0157] The E2E configuration verification module is used to establish a communication connection with the sending end during the endpoint discovery phase, provided that both the sending end and the E2E verification configuration are enabled.

[0158] The data verification device provided in this application embodiment is used to implement the steps of the data verification method described in this application embodiment. The specific implementation of each module of the device is described in the corresponding steps, and will not be repeated here.

[0159] The data verification device provided in this application receives data packets from the target data space, parses the data packets to obtain GUID, first verification data, and business data, and verifies the business data based on the GUID and the first verification data to obtain the verification result. It can verify the business data based on the GUID and the first verification data in the data packets. Since the GUID is a built-in feature in DDS, there is no need to introduce additional parameters such as DATAID, which solves the problem of redundancy between introducing additional parameters and the built-in features of DDS and can save resources.

[0160] Figure 6 This is a schematic diagram of a data transmission device provided in an embodiment of this application. This data transmission device is applied at the transmitting end, such as... Figure 6 As shown, the device includes:

[0161] The GUID acquisition module 610 is used to acquire the GUID of the sending end;

[0162] The first verification data determination module 620 is used to determine the first verification data of the service data to be sent based on the GUID and the service data to be sent.

[0163] The data packet encapsulation module 630 is used to encapsulate the GUID, the first verification data, and the service data to be sent into a data packet;

[0164] The data packet sending module 640 is used to publish the data packet to the target data space.

[0165] Optionally, the first verification data includes a first CRC value and the length of the transmitted data;

[0166] The first verification data determination module is specifically used for:

[0167] Determine the length of the data to be sent for the service data to be sent;

[0168] The first CRC value is determined based on the length of the transmitted data, the GUID, and the service data to be transmitted.

[0169] Optionally, the data packet encapsulation module is specifically used for:

[0170] Generate an E2E sub-message that includes the first verification data;

[0171] Generate a data sub-message that includes the GUID and the service data to be sent;

[0172] The E2E sub-message and the data sub-message are encapsulated into a data packet.

[0173] Optionally, the device further includes:

[0174] The heartbeat message sending module is used to send heartbeat messages to the target data space according to the configured period if the service data to be sent is an event-type signal.

[0175] Optionally, the device further includes:

[0176] The E2E configuration verification module is used to establish a communication connection with the receiving end during the endpoint discovery phase, provided that both the module and the receiving end have enabled E2E verification configuration.

[0177] The data transmission apparatus provided in this application embodiment is used to implement the steps of the data transmission method described in this application embodiment. The specific implementation of each module of the apparatus is described in the corresponding steps, and will not be repeated here.

[0178] The data transmission apparatus provided in this application obtains the GUID of the sending end, determines the first verification data based on the GUID and the service data to be transmitted, encapsulates the GUID, the first verification data and the service data to be transmitted into a data packet, and publishes the data packet to the target data space. This facilitates the receiving end to verify the service data based on the GUID and the first verification data in the data packet. Since the GUID is a built-in feature of DDS, there is no need to introduce additional parameters such as DATAID, which solves the problem of redundancy between introducing additional parameters and the built-in features of DDS, and can save resources.

[0179] Figure 7 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application, such as... Figure 7 As shown, the electronic device 700 may include one or more processors 710 and one or more memories 720 connected to the processors 710. The electronic device 700 may also include an input interface 730 and an output interface 740 for communicating with another device or system. Program code executed by the processor 710 may be stored in the memory 720.

[0180] The processor 710 in the electronic device 700 calls the program code stored in the memory 720 to execute the data verification method or data transmission method described in the above embodiments.

[0181] This application also provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the steps of the data verification method or data transmission method as described in this application.

[0182] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the data verification method or data transmission method as described in this application.

[0183] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For the apparatus embodiments, since they are fundamentally similar to the method embodiments, the description is relatively simple; relevant parts can be referred to the descriptions in the method embodiments.

[0184] The data verification method, data transmission method, apparatus, electronic device, and medium provided in the embodiments of this application have been described in detail above. Specific examples have been used to illustrate the principles and implementation methods of this application. The description of the above embodiments is only for the purpose of helping to understand the method and core ideas of this application. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this application. Therefore, the content of this specification should not be construed as a limitation of this application.

[0185] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented by means of software plus necessary general-purpose hardware platforms, and of course, it can also be implemented by hardware. Based on this understanding, the above technical solutions, in essence or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in the various embodiments or some parts of the embodiments.

Claims

1. A data verification method, characterized in that, Applied to the receiving end, including: Receive data packets from the target data space; Parse the data packet to obtain the globally unique identifier (GUID), the first verification data, and the business data; The business data is validated based on the GUID and the first validation data to obtain a validation result.

2. The method according to claim 1, characterized in that, The step of verifying the business data based on the GUID and the first verification data to obtain a verification result includes: Based on the GUID and the business data, determine the second verification data of the business data; The verification result of the business data is determined based on the GUID, the first verification data, and the second verification data.

3. The method according to claim 2, characterized in that, The second verification data includes the second cyclic redundancy check (CRC) value and the length of the received data; The step of determining the second verification data of the business data based on the GUID and the business data includes: Determine the length of the received business data; The second CRC value is determined based on the received data length, the GUID, and the service data.

4. The method according to claim 3, characterized in that, The first verification data includes a first CRC value and the length of the transmitted data, and the verification result includes a GUID verification result, a CRC verification result, and a data length verification result; Determining the verification result of the business data based on the GUID, the first verification data, and the second verification data includes: The GUID is compared with the pre-stored GUID of the sender to obtain the GUID verification result; The second CRC value is compared with the first CRC value to obtain the CRC check result; The length of the received data is compared with the length of the sent data to obtain the data length verification result.

5. The method according to any one of claims 1-4, characterized in that, Parse the data packet to obtain the GUID, first verification data, and business data, including: Parse the data packet to obtain E2E sub-messages and data sub-messages; Parse the E2E sub-message to obtain the first verification data; Parse the data sub-message to obtain the GUID and the business data.

6. The method according to any one of claims 1-5, characterized in that, Also includes: If the service data is a periodic signal, the data packet is timed out based on the validity period QoS of the Data Distribution Service (DDS), the timeout result is obtained, and the timer of the validity period QoS is updated.

7. The method according to any one of claims 1-5, characterized in that, Also includes: If the service data is an event-type signal, then based on the received heartbeat message, node liveness verification is performed based on the DDS's lifetime QoS to obtain the node liveness verification result, and the lifetime QoS timer is updated.

8. The method according to any one of claims 1-7, characterized in that, The data packet also includes the data packet's sequence number (SN); After verifying the business data based on the GUID and the first verification data to obtain the verification result, the method further includes: Store the business data and the verification result in a cache; When a business data read request is received, the SN corresponding to each business data in the cache is verified to obtain the SN verification result.

9. The method according to claim 8, characterized in that, After storing the business data and the verification result in the cache, the method further includes: In response to a business data read request from a business party, the business data and verification results are sent to the business party.

10. The method according to any one of claims 1-9, characterized in that, Before receiving data packets from the target data space, the method further includes: During the endpoint discovery phase, a communication connection is established between the endpoint and the sending end, provided that both the endpoint and the sending end have enabled E2E verification configuration.

11. A data transmission method, characterized in that, Applied to the sending end, including: Obtain the GUID of the sending end; Based on the GUID and the service data to be sent, determine the first verification data of the service data to be sent; The GUID, the first verification data, and the service data to be sent are encapsulated into a data packet; The data packet is published to the target data space.

12. The method according to claim 11, characterized in that, The first verification data includes a first CRC value and the length of the transmitted data; The step of determining the first verification data of the service data to be sent based on the GUID and the service data to be sent includes: Determine the length of the data to be sent for the service data to be sent; The first CRC value is determined based on the length of the transmitted data, the GUID, and the service data to be transmitted.

13. The method according to claim 11 or 12, characterized in that, The step of encapsulating the GUID, the first verification data, and the service data to be sent into a data packet includes: Generate an E2E sub-message that includes the first verification data; Generate a data sub-message that includes the GUID and the service data to be sent; The E2E sub-message and the data sub-message are encapsulated into a data packet.

14. The method according to any one of claims 11-13, characterized in that, Also includes: If the service data to be sent is an event-type signal, then the heartbeat message will be sent to the target data space according to the configured period.

15. The method according to any one of claims 11-14, characterized in that, Before obtaining the GUID of the sending end, the process also includes: During the endpoint discovery phase, a communication connection is established between the endpoint and the receiving end, provided that both the endpoint and the receiving end have enabled E2E verification configuration.

16. A data verification device, characterized in that, Applied to the receiving end, including: The data packet receiving module is used to receive data packets from the target data space; The data packet parsing module is used to parse the data packet to obtain the globally unique identifier (GUID), the first verification data, and the business data. The data verification module is used to verify the business data based on the GUID and the first verification data, and obtain the verification result.

17. A data transmission device, characterized in that, Applied to the sending end, including: A GUID acquisition module is used to acquire the GUID of the sending end; The first verification data determination module is used to determine the first verification data of the service data to be sent based on the GUID and the service data to be sent. A data packet encapsulation module is used to encapsulate the GUID, the first verification data, and the service data to be sent into a data packet; The data packet sending module is used to publish the data packet to the target data space.

18. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the data verification method according to any one of claims 1 to 10 or the data transmission method according to any one of claims 11 to 15.

19. A computer-readable storage medium having a computer program stored thereon, characterized in that, When executed by a processor, the program implements the steps of the data verification method according to any one of claims 1 to 10 or the steps of the data transmission method according to any one of claims 11 to 15.

Images