A message communication method and apparatus, an electronic device, and a storage medium

Abstract

The present disclosure relates to a message communication method and device, electronic equipment and storage medium. The message communication method comprises: obtaining first to-be-sent data from an application layer; in response to the first to-be-sent data needing to be protected, processing the first to-be-sent data to obtain second to-be-sent data carrying verification information; wherein the verification information is generated based on the first to-be-sent data; and instructing a message publisher to publish the second to-be-sent data so that a message subscriber obtains the second to-be-sent data.

Description

Technical Field

[0001] This disclosure relates to the field of vehicle communication technology, and in particular to a message communication method, apparatus, electronic device, and storage medium. Background Technology

[0002] Data Distribution Service (DDS) middleware is widely used in distributed systems and real-time data processing, and its publish-subscribe model provides an efficient way for various applications to exchange and communicate data. However, due to the open and distributed nature of DDS middleware, security issues exist during data transmission, such as data tampering, loss, and corruption. Currently, there is a lack of secure and efficient solutions for communication using the DDS protocol.

[0003] Therefore, how to use the DDS protocol for communication securely and efficiently is a technical problem that urgently needs to be solved. Summary of the Invention

[0004] To overcome the problems existing in related technologies, this disclosure provides a message communication method, apparatus, electronic device, and storage medium.

[0005] According to a first aspect of the present disclosure, a message communication method is provided, the method being applied to the middle layer of a vehicle's communication system, the middle layer of which deploys the DDS protocol, the method comprising: acquiring first data to be sent from an application layer; in response to the first data to be sent needing to be protected, processing the first data to be sent to obtain second data to be sent carrying verification information; wherein the verification information is generated based on the first data to be sent; and instructing a message publisher to publish the second data to be sent so that message subscribers can acquire the second data to be sent.

[0006] In some embodiments, processing the first data to be sent to obtain second data to be sent carrying verification information includes: calling an interface function to generate verification information for the first data to be sent; and obtaining the second data to be sent based on the first data to be sent and the verification information.

[0007] In some embodiments, the verification information is an E2E field; wherein, the E2E field includes at least the CRC checksum of the first data to be sent, the data identifier of the first data to be sent, the length of the second data to be sent, and a count value; generating the verification information of the first data to be sent includes: calling an E2E service to generate the E2E field based on the first data to be sent.

[0008] In some embodiments, the first data to be sent carries an identifier, and the response that the first data to be sent needs to be protected includes: obtaining a list of protected data identifiers based on the parsing result of parsing a pre-set target configuration file; wherein the list of protected data identifiers records the identifiers of data from the application layer that need to be protected; determining whether the first data to be sent needs to be protected by: performing a matching operation on the identifier of the first data to be sent with the identifier of each data in the list of protected data identifiers; and determining that the first data to be sent needs to be protected in response to the result of the matching operation being a first result.

[0009] According to a second aspect of the present disclosure, a message communication method is provided, the method being applied to the middle layer of a vehicle's communication system, the middle layer of which deploys the DDS protocol, the method comprising: acquiring first data to be received from a message publisher; in response to the first data to be received needing to be parsed, unpacking the first data to be received to obtain second data to be received and verification information generated based on the second data to be received; verifying the second data to be received according to the verification information; and in response to the verification result of the second data to be received being passed, sending the second data to be received to a target data receiver.

[0010] In some embodiments, the unpacking process of the first data to be received includes: calling an interface function to parse the second data to be received and the verification information from the first data to be received according to the encapsulation format of the first data to be received.

[0011] In some embodiments, the verification information is an E2E field; wherein, the E2E field includes at least the CRC checksum of the second data to be received, the data identifier of the second data to be received, the length of the first data to be received, and a count value; the step of parsing the second data to be received and the verification information from the first data to be received according to the encapsulation format of the first data to be received includes: using an E2E service to parse the first data to be received to obtain the second data to be received and an E2E field generated based on the second data to be received.

[0012] In some embodiments, responding to the need for the first data to be received to be parsed includes: obtaining a protected data identifier list based on the parsing result of parsing a pre-set target configuration file; wherein the protected data identifier list records the identifiers of data from the application layer that need to be protected; determining whether the first data to be received needs to be parsed by: performing a matching operation on the identifier of the first data to be received with the identifier of each data in the protected data identifier list; and determining that the first data to be received needs to be parsed in response to the result of the matching operation being a first result.

[0013] According to a third aspect of the present disclosure, a message communication apparatus is provided, the apparatus deploying the DDS protocol, the apparatus comprising: an acquisition module for acquiring first data to be sent from an application layer; a generation module for processing the first data to be sent in response to the need for protection of the first data to be sent, to obtain second data to be sent carrying verification information; wherein the verification information is generated based on the first data to be sent; and a sending module for instructing a message publisher to publish the second data to be sent so that message subscribers can acquire the second data to be sent.

[0014] According to a fourth aspect of the present disclosure, a message communication apparatus is provided, the apparatus deploying the DDS protocol, the apparatus comprising: an acquisition module for acquiring first data to be received from a message publisher; a processing module for unpacking the first data to be received in response to the need for parsing, to obtain second data to be received and verification information generated based on the second data to be received; a verification module for verifying the second data to be received according to the verification information; and a sending module for sending the second data to be received to a target data receiver in response to a successful verification result of the second data to be received.

[0015] According to a fifth aspect of the present disclosure, a vehicle is provided that stores a set of instructions, which are executed by the vehicle to implement the message communication method provided in the first aspect of the present disclosure.

[0016] According to a sixth aspect of the present disclosure, an electronic device is provided, comprising: a processor; a memory for storing executable instructions of the processor; the processor being configured to read the executable instructions from the memory and execute the instructions to implement the message communication method provided in the first and second aspects of the present disclosure.

[0017] According to a seventh aspect of the present disclosure, a computer-readable storage medium is provided that stores computer program instructions thereon, which, when executed by a processor, implement the steps of the message communication method provided in the first and second aspects of the present disclosure.

[0018] The technical solutions provided by the embodiments of this disclosure may include the following beneficial effects:

[0019] In the embodiments provided in this disclosure, first data to be sent is obtained from the application layer; in response to the need for protection of the first data to be sent, the first data to be sent is processed to obtain second data to be sent carrying verification information; wherein, the verification information is generated based on the first data to be sent; and the message publisher is instructed to publish the second data to be sent so that the message subscriber can obtain the second data to be sent. This allows for secure and efficient communication using the DDS protocol.

[0020] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and are not intended to limit this disclosure. Attached Figure Description

[0021] The accompanying drawings, which are incorporated in and form a part of this specification, illustrate embodiments consistent with this disclosure and, together with the description, serve to explain the principles of this disclosure.

[0022] Figure 1 This is a flowchart illustrating a message communication method according to an exemplary embodiment.

[0023] Figure 2 This is a flowchart illustrating a method for determining first data to be transmitted that needs to be protected, according to an exemplary embodiment.

[0024] Figure 3 This is a flowchart illustrating yet another message communication method according to an exemplary embodiment.

[0025] Figure 4 This is a flowchart illustrating a method for determining first data to be received that needs to be parsed, according to an exemplary embodiment.

[0026] Figure 5 This is a schematic diagram illustrating application layer communication via a DDS network according to an exemplary embodiment.

[0027] Figure 6 This is a block diagram illustrating a message communication device according to an exemplary embodiment.

[0028] Figure 7 This is a block diagram illustrating yet another message communication device according to an exemplary embodiment.

[0029] Figure 8This is a block diagram illustrating a vehicle according to an exemplary embodiment.

[0030] Figure 9 This is a block diagram illustrating an electronic device according to an exemplary embodiment. Detailed Implementation

[0031] The exemplary embodiments will now be described in detail with reference to the accompanying drawings.

[0032] It should be noted that the relevant embodiments and accompanying drawings are only for describing and illustrating exemplary embodiments provided by this disclosure, and not all embodiments of this disclosure, nor should this disclosure be understood to be limited to the relevant exemplary embodiments.

[0033] It should be noted that the terms "first," "second," etc., used in this disclosure are only used to distinguish different steps, devices, or modules. These terms do not represent any specific technical meaning, nor do they indicate any order or interdependence between them.

[0034] It should be noted that the terms “a,” “a plurality of,” and “at least one” used in this disclosure are illustrative rather than restrictive. Unless otherwise expressly indicated in the context, they should be understood as “one or more.”

[0035] It should be noted that the term "and / or" used in this disclosure is used to describe the relationship between related objects, and generally indicates that there are at least three relationships. For example, A and / or B can at least indicate: the existence of A alone, the existence of both A and B, and the existence of B alone.

[0036] It should be noted that the various steps described in the method embodiments of this disclosure may be performed in different orders and / or in parallel. Unless otherwise specified, the scope of this disclosure is not limited by the order in which the steps are described in the relevant embodiments.

[0037] It should be noted that all actions involving the acquisition of signals, information, or data in this disclosure are carried out in compliance with the relevant data protection laws and policies of the country where the location is situated, and with authorization from the owner of the relevant device.

[0038] Exemplary methods

[0039] Figure 1 This is a flowchart illustrating a message communication method according to an exemplary embodiment.

[0040] This message communication method is applied to the middle layer of a vehicle's communication system, which deploys the DDS protocol.

[0041] DDS is a data-centric middleware protocol that sits between the application layer and the operating system. DDS employs a publish / subscribe communication model for real-time, efficient data distribution. Furthermore, the DDS protocol provides rich QoS (Quality of Service) policies to meet the requirements of distributed real-time communication.

[0042] like Figure 1 As shown, the method includes the following steps.

[0043] In step S110, the first data to be sent from the application layer is obtained.

[0044] like Figure 5 As shown, the application layer can be any application connected to the DDS network. For example, the application layer can be the in-vehicle entertainment program A of car A, which has audio and video playback capabilities. As another example, a car's driving system has two ECUs (Electronic Control Units), ECU A and ECU B. Applications 1 and 3, located on the two ECUs respectively, communicate via the DDS network. Application 1 needs to transmit signals such as vehicle speed and accelerator pedal to application 3; therefore, application 1 is the application layer in this step (i.e., the sending application).

[0045] The first data to be sent is data that needs to be transmitted through the DDS network, such as brake signal data, steering signal data, audio and video data, battery signal data, etc.

[0046] In the specific implementation process, the first data to be sent from the application layer can be obtained in a variety of ways.

[0047] In step S120, in response to the need for protection of the first data to be sent, the first data to be sent is processed to obtain a second data to be sent carrying verification information; wherein, the verification information is generated based on the first data to be sent.

[0048] In practice, it can be determined in several ways whether the first piece of data to be sent needs to be protected. For example, it can be determined by the identifier carried by the first piece of data to be sent. Another example is by the type of application corresponding to the first piece of data to be sent (entertainment program or control program).

[0049] For an example of determining whether the first piece of data to be sent needs to be protected, see [link to example]. Figure 2 The relevant content will not be repeated here.

[0050] In some embodiments, an interface function can be called to generate verification information for the first data to be sent; and the second data to be sent can be obtained based on the first data to be sent and the verification information.

[0051] In practice, the second data to be sent can be obtained from the first data to be sent and the verification information in various ways. As an example, the verification information and the first data to be sent can be concatenated to obtain the second data to be sent.

[0052] In the specific implementation process, verification information can be obtained in a variety of ways. For example, a cyclic redundancy check (CRC) check code of the first data to be sent can be generated and used as verification information.

[0053] In some embodiments, the verification information can be an E2E field, and an E2E service can be invoked to generate the E2E field corresponding to the first data to be sent based on the first data to be sent.

[0054] As an example only, the middleware layer of the vehicle's communication system provides interface functions that the application layer can call, passing the first data to be sent as a parameter. Within these interface functions, data can be processed according to... Figure 2 The method provided in the embodiment determines whether the first data to be sent needs to be protected. If it does not need to be protected, the first data to be sent can be returned to the application layer, which will then publish the first data to be sent based on the DCPS layer. If it needs to be protected, the interface function calls the E2E service to process the first data to be sent to obtain the second data to be sent, and returns the second data to be sent to the application layer, which will then publish the second data to be sent based on the DCPS layer.

[0055] E2E services are processes / threads or interface functions that can perform end-to-end (E2E) verification of data.

[0056] In practice, E2E services can be implemented by developers themselves or by using open-source programs with E2E security protection features, and are not limited by the description in this manual.

[0057] E2E is a protocol defined in the AUTOSAR specification for secure communication. It includes data security protection mechanisms such as CRC checksum algorithms and packet loss verification methods based on counter values. According to the AUTOSAR specification, E2E has a series of profiles, each with its own mechanisms, parameters, and data formats for data protection, offering high flexibility. Users can choose the configuration according to their actual needs.

[0058] As an example only, calling the E2E service and generating the E2E fields based on the first data to be sent includes the following data fields:

[0059] DataId: The data identifier for the first data to be sent, used to verify the identity of each transmitted data element. Its value can be any value within the 32-bit address space. The data ID is globally unique within the network of the communication system. When using E2E policing to protect messages (from COM calls), the receiving COM expects to receive only specific messages, which are verified by the E2E using the data ID.

[0060] Length: The length of the second data to be sent, 32 bits. The Length field was introduced to support variable-size lengths. This field includes the data to be protected (the first data to be sent) + E2E fields (CRC + counter + length + DataID).

[0061] Counter: A 32-bit counter used to protect the next data. It increments by 1 each time. A sends the counter value to B, and B can determine whether the data was received in time based on the received counter value. The initial value is 0. Each time E2E_P08Protect() is called, the counter increments by 1 until it reaches 0xFFFFFFFF.

[0062] CRC: Cyclic Redundancy Check, 32 bits, the remainder obtained after polynomial division of the first data to be sent.

[0063] In step S130, the message publisher is instructed to publish the second data to be sent so that the message subscribers can obtain the second data to be sent.

[0064] DDS mainly consists of two parts: the Data-Centric Publish-Subscribe (DCPS) layer and the Data Local Reconstruction Layer (DLRL). DCPS is used to handle data subscription and publishing, and the application layer uses this layer for data interaction.

[0065] DCPS consists of entities such as Domain, Participant, Publisher, Subscriber, DataWriter, DataReader, Topic, and Listener. The definitions of related technical terms are as follows:

[0066] (I) Domian

[0067] A domain is the basic structure of DDS, a communication plane identified by a unique DomainID. Only entities within the same domain can communicate (exchange data). Application entities from different domains cannot communicate.

[0068] (ii) Domian Participant

[0069] The DomainParticipant is the entry point for services. If an application wants to publish or subscribe to data, it must first obtain the DomainParticipant. Only after obtaining the DomainParticipant can it create, delete, or manage entities (e.g., Topic, Publisher, Subscriber, etc.).

[0070] (III) Publisher

[0071] Used to retrieve published data and publish it to the corresponding domain. A Publisher, as the publisher, can contain one or more DataWriters.

[0072] (iv) Subscriber

[0073] It receives data published by the Publisher and passes it to the corresponding upper-layer application entity. It must contain at least one DataReader.

[0074] (V) Topic

[0075] A Topic is mainly composed of Name and Type, and is used to represent the data to be transmitted over the network.

[0076] TopicName: is a string that uniquely identifies the domain;

[0077] TopicType: Data type definition. Each topic type can specify a corresponding key, which can be used to distinguish different instances of the same Topic.

[0078] (vi) DataWriter

[0079] If an upper-layer application needs to send data, it needs to use a DataWriter to write a specific Topic to an interface of a specified type. The DataWriter encodes the data and transmits it through a Publisher. A DataWriter must be bound to a Topic.

[0080] (vii) DataReader

[0081] The Subscriber retrieves data from the bound Topic through the DataReader and then passes it to the application. A DataReader can be bound to multiple Topics.

[0082] As an example only, at the DCPS layer, the following steps are performed to instruct the message publisher to publish the second piece of data to be sent:

[0083] 1. Obtain the participant information and QoS information configured by the user through the Participant Interface module and the QoS Module.

[0084] 2. The Discovery Module, through the RTPS process and with the support of SPDP and SEDP, is responsible for discovering participants and confirming data readers. Once the two endpoints corresponding to the participants and data readers have discovered each other, the Subscriber Module and Publisher Module can be used to subscribe to and send data.

[0085] 3. The Publish Module takes the second data to be sent as a sample and sends it to the Deserialize / Serialize Module according to the Topic type. The Serialize Module then converts the sample into binary data and sends it to the Writer Module.

[0086] 4. The Writer Module performs unified scheduling and processing, and determines whether the serialized sample is sent synchronously or asynchronously. Finally, the Writer Module sends the data to the WHC Module.

[0087] 5. The WHC Module acts as a cache to retransmit messages in case of data loss.

[0088] 6. The Queue Service Module is responsible for sending data to the RTPS Process Module, thereby publishing the second batch of data to be sent to the domain.

[0089] In the embodiments provided in this disclosure, in response to the need for protection of the first data to be sent, the first data to be sent is processed to obtain a second data to be sent carrying verification information. Based on the DCPS layer, the message publisher is instructed to publish the second data to be sent so that the message subscriber can obtain the second data to be sent. Since the second data to be sent published to the domain by the message publisher carries verification information, a secure transmission channel can be established between the message publisher and the message subscriber, effectively ensuring the security of data transmitted based on the DDS protocol. Adding verification information to the first data to be sent before transmission results in lower communication costs and computational overhead, effectively maintaining the real-time performance of DDS protocol data transmission.

[0090] In the embodiments provided in this disclosure, verification information for the first data to be sent is generated by calling an interface function; and the second data to be sent is obtained based on the first data to be sent and the verification information. This eliminates the need to modify the DDS source code, achieving isolation between secure data processing and protocol processing, and allows for the selection of different data protection methods according to different application scenarios.

[0091] Figure 2 A flowchart illustrating a method for determining first data to be transmitted that needs to be protected, according to an exemplary embodiment.

[0092] In step S210, the identifier of the first data to be sent is matched with the identifier of each data in the list of protected data identifiers.

[0093] In the specific implementation process, the first data to be sent carries an identifier.

[0094] The protected data identifier list records the identifiers of data from the application layer that need to be protected. In some embodiments, the protected data identifier list can be obtained based on the parsing results of a pre-set target configuration file.

[0095] In practice, the list of protected data identifiers can be obtained in various ways. As an example, users can confirm which data requires security protection (e.g., brake signal data, turn signal data) and which does not (e.g., audio / video data). This information is then communicated to SOACore.Databus via a configuration file to obtain the list of protected data identifiers.

[0096] In step S220, in response to the result of the matching operation being the first result, it is determined that the first data to be sent needs to be protected.

[0097] As an example only, the identifier of the first data to be sent can be matched with the identifier of each data in the protection data identifier list. If there is an identifier in the protection data identifier list that is the same as the identifier of the first data to be sent, the result of the matching operation is determined to be the first result; if there is no identifier in the protection data identifier list that is the same as the identifier of the first data to be sent, the result of the matching operation is determined to be the second result.

[0098] If the result of the matching operation is the first result, it is determined that the first data to be sent needs to be protected.

[0099] In the embodiments provided in this disclosure, a list of protected data identifiers is obtained based on the parsing results of a pre-set target configuration file; a matching operation is performed on the identifier of the first data to be sent and the identifier of each data in the list of protected data identifiers; in response to the result of the matching operation being a first result, it is determined that the first data to be sent needs to be protected. Thus, data can be selectively protected according to the user's wishes, ensuring the security of important data transmission without consuming excessive communication resources.

[0100] Figure 3 This is a flowchart illustrating yet another message communication method according to an exemplary embodiment.

[0101] This message communication method is applied to the middle layer of the vehicle's communication system, which deploys the DDS protocol.

[0102] like Figure 3 As shown, the method includes the following steps.

[0103] In step S310, the first data to be received from the message publisher is obtained.

[0104] The first type of data to be received is data that needs to be transmitted through the DDS network, such as brake signal data, steering signal data, audio and video data, battery signal data, etc.

[0105] In practice, message subscribers can retrieve the first data to be received from the message publisher by topic from the domain.

[0106] For a detailed description of message subscribers, domains, and message publishers, please refer to the relevant content in step S130, which will not be repeated here.

[0107] As an example only, in the DCPS layer, the following steps are performed to obtain the first data to be received from the message publisher.

[0108] 1. Obtain the participant information and QoS information configured by the customer through the Participant Interface module and the QoS Module.

[0109] 2. The Discovery Module invokes the RTPS process, discovering participants and confirming data senders with the support of SPDP and SEDP. Once the two endpoints have discovered each other, they can use the Subscriber module and Publisher Module to subscribe to and send data.

[0110] 3. After receiving a message, the RTPS Process Module processes it through the Unicast Module / Multicast Module and then transfers it to the RHC Module for storage.

[0111] 4. When the RHC Module receives data, it calls the Deserialize / Serialize Module to convert the binary data into the corresponding sample data and sends it to the Reader Module. The Reader Module then distributes the data (the first data to be received) to the Subscriber Module.

[0112] In step S320, in response to the need to parse the first data to be received, the first data to be received is unpacked to obtain the second data to be received and the verification information generated based on the second data to be received.

[0113] In practice, it can be determined in several ways whether the first data to be received needs to be parsed. For example, it can be determined by the identifier carried by the first data to be received. Another example is by the type of application corresponding to the first data to be received (entertainment program or control program).

[0114] For an example of determining whether the first data to be received needs to be parsed, see [link to example]. Figure 4 The relevant content will not be repeated here.

[0115] In some embodiments, an interface function can be called to parse the second data to be received and the verification information from the first data to be received, based on the encapsulation format of the first data to be received.

[0116] In some embodiments, the verification information is an E2E field. The E2E service can be used to parse the first data to be received to obtain the second data to be received and the E2E field generated based on the second data to be received.

[0117] For a detailed description of the E2E field and E2E service, please refer to the relevant content in step S120, which will not be repeated here.

[0118] As an example only, the verification information includes: the CRC checksum of the second data to be received, the data identifier of the second data to be received, the length of the first data to be received, and the count value. Based on the length of each of the above data fields, each data field can be parsed sequentially starting from the beginning of the first data to be received.

[0119] In step S330, the second data to be received is verified based on the verification information.

[0120] As an example only, regarding the E2E field in step S120, the E2E service can verify the second data to be received based on the verification information through the following steps:

[0121] (1) When the data receiving end is waiting to receive new data, it is in the STATUS NONEWDATA state. When the second data to be received and the E2E field generated based on the second data to be received appear, it proceeds to step (2).

[0122] (2) After receiving the second data to be received, the receiving end calls the CRC algorithm to calculate the CRC value of the second data to be received and compares it with the CRC in the received E2E field. If they are different, the data status is determined to be STATUS_ERROR; if they are the same, proceed to step (3).

[0123] (3) The receiving end identifies the data by reading the DataID in the received E2E field, obtains relevant information about the data based on the configuration information of this DataID for subsequent logical judgment, and configures a timer. If the DataID is not in the configuration information, the data status is determined to be STATUS ERROR. If the DataID is in the configuration information, the DataID timer is cleared to 0, and the process proceeds to step (4).

[0124] (4) The receiving end parses the length of the second data to be received and compares it with the length of the DataID configuration information. If they are not equal, the data status is determined to be STATUS ERROR. If they are equal, proceed to step (5).

[0125] (5) The receiving end calculates DeltaCounter, subtracts the Counter value of the DataID received last time from the receiving end from the Counter value of the DataID currently received, and proceeds to step (6).

[0126] (6) If DeltaCounter is greater than or equal to 0 and less than the configured MaxDeltaCounter (DeltaCounter tolerance range, configurable), proceed to step (7); otherwise, determine the data status as STATUSWRONGSEOUENCE (DeltaCounter exceeds tolerance range).

[0127] (7) If DeltaCounter is greater than 0, proceed to step (8); otherwise, DeltaCounter is equal to 0, and the data status is determined to be STATUS REPEATED.

[0128] (8) If DeltaCounter equals 1, determine the data status as E2E PO8STATUS OK; otherwise, determine the data status as STATUS OKSOMELOST.

[0129] In step S340, in response to the verification result of the second data to be received being passed, the second data to be received is sent to the target data receiver.

[0130] The target data receiver can be any application that has subscribed to the second data to be received and has accessed the DDS network. As an example only, in step S110, application 3 is used (see example 3). Figure 5 () can be the target recipient in this step.

[0131] In practical implementation, after the message subscriber receives the first data to be received, it can notify the target receiver that data is available through a listener or conditional trigger. The target receiver can then call the interface function provided by the communication middleware layer. Within this interface function, it can utilize... Figure 4 The method provided in the embodiment determines whether the first data to be received needs to be parsed. If the first data to be received needs to be parsed, the interface function is used to unpack the first data to be received and return the second data to be received that has passed the verification to the target receiver. If the first data to be received does not need to be parsed, the interface function directly returns the first data to be received to the target receiver.

[0132] In the embodiments provided in this disclosure, first data to be received from a message publisher is obtained; in response to the need to parse the first data to be received, the first data to be received is unpacked to obtain second data to be received and verification information generated based on the second data to be received; the second data to be received is verified according to the verification information; in response to the verification result of the second data to be received being passed, the second data to be received is sent to the target data receiver. Therefore, the second data to be received published by the message publisher to the domain can be verified to ensure that no data security issues such as tampering, loss, or damage occur during the transmission of the second data to be received. This allows the establishment of a secure transmission channel between the message publisher and the message subscriber, effectively ensuring the security of data transmitted based on the DDS protocol.

[0133] Figure 4 This is a flowchart illustrating a method for determining first data to be received that needs to be parsed, according to an exemplary embodiment.

[0134] In step S410, the identifier of the first data to be received is matched with the identifier of each data in the list of protected data identifiers.

[0135] In practice, the first data to be received carries an identifier. The protected data identifier list records the identifiers of the data from the application layer that need to be parsed. In some embodiments, the protected data identifier list can be obtained based on the parsing results of a pre-set target configuration file. As an example only, the user can confirm which data needs security protection (e.g., brake signal data, turn signal data, etc.) and which data does not need security protection (e.g., audio and video data, etc.), and then convey this information to SOACore.Databus via a configuration file to obtain the protected data identifier list.

[0136] In step S420, in response to the result of the matching operation being the first result, it is determined that the first data to be received needs to be parsed.

[0137] As an example only, the identifier of the first data to be received can be matched with the identifier of each data in the protection data identifier list. If there is an identifier in the protection data identifier list that is the same as the identifier of the first data to be received, the result of the matching operation is determined to be the first result; if there is no identifier in the protection data identifier list that is the same as the identifier of the first data to be received, the result of the matching operation is determined to be the second result.

[0138] If the result of the matching operation is the first result, then the first data to be received needs to be parsed.

[0139] In the embodiments provided in this disclosure, a matching operation is performed on the identifier of the first data to be received and the identifier of each data in the list of protected data identifiers; in response to the result of the matching operation being a first result, it is determined that the first data to be received needs to be parsed. Therefore, it can be determined whether the received first data to be received needs to be parsed, thereby enabling selective security protection of the data according to the user's wishes, ensuring the security of important data transmission without consuming excessive communication resources.

[0140] Exemplary device

[0141] Figure 6 This is a block diagram illustrating a message communication device according to an exemplary embodiment. (Refer to...) Figure 6 The device 600 includes an acquisition module 610, a generation module 620, and a transmission module 630.

[0142] The acquisition module 610 is used to acquire the first data to be sent from the application layer.

[0143] The generation module 620 is used to process the first data to be sent in response to the need for protection of the first data to be sent, to obtain a second data to be sent carrying verification information; wherein the verification information is generated based on the first data to be sent.

[0144] The sending module 630 is used, based on the DCPS layer, to instruct the message publisher to publish the second data to be sent, so that the message subscriber can obtain the second data to be sent.

[0145] In some embodiments, processing the first data to be sent to obtain second data to be sent carrying verification information includes: calling an interface function to generate verification information for the first data to be sent; and obtaining the second data to be sent based on the first data to be sent and the verification information.

[0146] In some embodiments, the verification information is an E2E field; wherein, the E2E field includes at least the CRC checksum of the first data to be sent, the data identifier of the first data to be sent, the length of the second data to be sent, and a count value; generating the verification information of the first data to be sent includes: calling an E2E service to generate the E2E field based on the first data to be sent.

[0147] In some embodiments, the first data to be sent carries an identifier, and the response that the first data to be sent needs to be protected includes: obtaining a list of protected data identifiers based on the parsing result of parsing a pre-set target configuration file; wherein the list of protected data identifiers records the identifiers of data from the application layer that need to be protected; determining whether the first data to be sent needs to be protected by: performing a matching operation on the identifier of the first data to be sent with the identifier of each data in the list of protected data identifiers; and determining that the first data to be sent needs to be protected in response to the result of the matching operation being a first result.

[0148] In the embodiments of the above-mentioned message communication device, the specific processing of each module and the technical effects it brings can be referred to the relevant descriptions in the corresponding method embodiments, which will not be repeated here.

[0149] Figure 7 This is a block diagram of another message communication device according to an exemplary embodiment. (Refer to...) Figure 7 The device 700 includes an acquisition module 710, a processing module 720, a verification module 730, and a sending module 740.

[0150] The acquisition module 710 is used to acquire the first data to be received from the message publisher.

[0151] The processing module 720 is used to depacketize the first data to be received in response to the need for the first data to be received to be parsed, and obtain the second data to be received and the verification information generated based on the second data to be received.

[0152] The verification module 730 is used to verify the second data to be received based on the verification information.

[0153] The sending module 740 is used to send the second data to be received to the target data receiver in response to the verification result of the second data to be received being passed.

[0154] In some embodiments, the unpacking process of the first data to be received includes: calling an interface function to parse the second data to be received and the verification information from the first data to be received according to the encapsulation format of the first data to be received.

[0155] In some embodiments, the verification information is an E2E field; wherein, the E2E field includes at least the CRC checksum of the second data to be received, the data identifier of the second data to be received, the length of the first data to be received, and a count value; the step of parsing the second data to be received and the verification information from the first data to be received according to the encapsulation format of the first data to be received includes: using an E2E service to parse the first data to be received to obtain the second data to be received and an E2E field generated based on the second data to be received.

[0156] In some embodiments, responding to the need for the first data to be received to be parsed includes: obtaining a protected data identifier list based on the parsing result of parsing a pre-set target configuration file; wherein the protected data identifier list records the identifiers of data from the application layer that need to be protected; determining whether the first data to be received needs to be parsed by: performing a matching operation on the identifier of the first data to be received with the identifier of each data in the protected data identifier list; and determining that the first data to be received needs to be parsed in response to the result of the matching operation being a first result.

[0157] In the embodiments of the above-mentioned message communication device, the specific processing of each module and the technical effects it brings can be referred to the relevant descriptions in the corresponding method embodiments, which will not be repeated here.

[0158] Exemplary vehicle

[0159] Figure 8 This is a block diagram illustrating a vehicle 800 according to an exemplary embodiment. The vehicle 800 may be a gasoline vehicle, a hybrid vehicle, an electric vehicle, a fuel cell vehicle, or other types of vehicles.

[0160] Reference Figure 8 The vehicle 800 may include multiple subsystems, such as a drive system 810, a control system 820, a sensing system 830, a communication system 840, an information display system 850, and a computing processing system 860. The vehicle 800 may also include more or fewer subsystems, and each subsystem may include multiple components, which will not be described in detail here.

[0161] The drive system 810 includes components that provide power to the vehicle 800. These include, for example, an engine, an energy source, and a transmission.

[0162] The control system 820 includes components that provide control for the vehicle 800. These include, for example, vehicle control, cockpit equipment control, and driver assistance control.

[0163] The perception system 830 includes components that provide the vehicle 800 with perception of its surroundings. These include, for example, a vehicle positioning system, a laser sensor, a voice sensor, an ultrasonic sensor, and camera equipment.

[0164] The communication system 840 includes components that provide communication connectivity for the vehicle 800. These may include, for example, mobile communication networks (e.g., 3G, 4G, 5G networks), WiFi, Bluetooth, and vehicle-to-everything (V2X) connectivity.

[0165] The information display system 850 includes components that provide various information displays for the vehicle 800. These include, for example, vehicle information displays, navigation information displays, and entertainment information displays.

[0166] The computing processing system 860 includes components that provide data computing and processing capabilities for the vehicle 800. The computing processing system 860 may include at least one processor 861 and a memory 862. The processor 861 can execute instructions stored in the memory 862.

[0167] The processor 861 can be any conventional processor, such as a commercially available CPU. The processor may also include, for example, a Graphics Processing Unit (GPU), a Field Programmable Gate Array (FPGA), a System on Chip (SOC), an Application Specific Integrated Circuit (ASIC), or a combination thereof.

[0168] The memory 862 can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk or optical disk.

[0169] In this embodiment of the present disclosure, a set of instructions is stored in the memory 862, and the processor 861 can execute the set of instructions to implement all or part of the steps of the message communication method described in any of the exemplary embodiments above.

[0170] Exemplary electronic devices

[0171] Figure 9 This is a block diagram illustrating an electronic device 900 according to an exemplary embodiment. The electronic device 900 may be a vehicle controller, an in-vehicle terminal, an in-vehicle computer, or other types of electronic devices.

[0172] Reference Figure 9 The electronic device 900 may include at least one processor 910 and a memory 920. The processor 910 can execute instructions stored in the memory 920. The processor 910 is communicatively connected to the memory 920 via a data bus. In addition to the memory 920, the processor 910 can also be communicatively connected to an input device 930, an output device 940, and a communication device 950 via the data bus.

[0173] Processor 910 can be any conventional processor, such as a commercially available CPU. Processors may also include graphics processing units (GPUs), field-programmable gate arrays (FPGAs), systems-on-chips (SoCs), application-specific integrated circuits (ASICs), or combinations thereof.

[0174] The memory 920 can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk or optical disk.

[0175] In this embodiment of the present disclosure, the memory 920 stores executable instructions, and the processor 910 can read the executable instructions from the memory 920 and execute the instructions to implement all or part of the steps of the message communication method described in any of the exemplary embodiments above.

[0176] Exemplary computer-readable storage media

[0177] In addition to the methods and apparatus described above, exemplary embodiments of this disclosure may also be a computer program product or a computer-readable storage medium storing the computer program product. The computer product includes computer program instructions that can be executed by a processor to perform all or part of the steps described in any of the methods in the exemplary embodiments described above.

[0178] The computer program product can be written in any combination of one or more programming languages ​​to perform the operations of the embodiments of this application. The programming languages ​​include object-oriented programming languages ​​such as Java and C++, as well as conventional procedural programming languages ​​such as C or similar languages, and scripting languages ​​(e.g., Python). The program code can be executed entirely on the user's computing device, partially on the user's device, as a standalone software package, partially on the user's computing device and partially on a remote computing device, or entirely on a remote computing device or server.

[0179] The computer-readable storage medium may be any combination of one or more readable media. A readable medium may be a readable signal medium or a readable storage medium. A readable storage medium may be, for example, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of readable storage media include: static random access memory (SRAM) having one or more electrically connected wires, electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk or optical disk, or any suitable combination thereof.

[0180] Other embodiments of this disclosure will readily occur to those skilled in the art upon consideration of the specification and practice of this disclosure. This application is intended to cover any variations, uses, or adaptations of this disclosure that follow the general principles of this disclosure and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this disclosure are indicated by the appended claims.

[0181] It should be understood that this disclosure is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this disclosure is limited only by the appended claims.

Claims

1. A message communication method, characterized in that, The method is applied to the middle layer of a vehicle's communication system, wherein the middle layer of the vehicle's communication system deploys the DDS protocol, and the method includes: Obtain the first data to be sent from the application layer; In response to the need for protection of the first data to be sent, the first data to be sent is processed to obtain a second data to be sent carrying verification information; wherein, the verification information is generated based on the first data to be sent. Based on the DCPS layer, the message publisher is instructed to publish the second data to be sent so that the message subscribers can obtain the second data to be sent; The first data to be sent carries an identifier, and the response that the first data to be sent needs to be protected includes: The method for determining whether the first data to be sent needs to be protected is as follows: A matching operation is performed on the identifier of the first data to be sent and the identifier of each data in the protected data identifier list, wherein the protected data identifier list records the identifiers of data from the application layer that need to be protected. In response to the result of the matching operation being a first result, it is determined that the first data to be sent needs to be protected.

2. The message communication method according to claim 1, characterized in that, The step of processing the first data to be sent to obtain the second data to be sent carrying verification information includes: Call the interface function to generate verification information for the first data to be sent; and The second data to be sent is obtained based on the first data to be sent and the verification information.

3. The message communication method according to claim 2, characterized in that, The verification information is an E2E field; wherein, the E2E field includes at least the CRC checksum of the first data to be sent, the data identifier of the first data to be sent, the length of the second data to be sent, and a count value; The verification information for generating the first data to be sent includes: Invoke the E2E service to generate the E2E field based on the first data to be sent.

4. The message communication method according to claim 1, characterized in that, The method further includes: Based on the parsing results of the pre-set target configuration file, a list of protected data identifiers is obtained.

5. A message communication method, characterized in that, The method is applied to the middle layer of a vehicle's communication system, wherein the middle layer of the vehicle's communication system deploys the DDS protocol, and the method includes: Retrieve the first data to be received from the message publisher; In response to the need to parse the first data to be received, the first data to be received is unpacked to obtain the second data to be received and the verification information generated based on the second data to be received. The second data to be received is verified based on the verification information. In response to the verification result of the second data to be received being passed, the second data to be received is sent to the target data receiver; The response that the first data to be received needs to be parsed includes: The method used to determine whether the first data to be received needs to be parsed is as follows: A matching operation is performed on the identifier of the first data to be received and the identifier of each data in the protected data identifier list, wherein the protected data identifier list records the identifiers of data from the application layer that need to be protected. In response to the result of the matching operation being a first result, it is determined that the first data to be received needs to be parsed.

6. The message communication method according to claim 5, characterized in that, The unpacking process for the first data to be received includes: The interface function is called to parse the second data to be received and the verification information from the first data to be received, according to the encapsulation format of the first data to be received.

7. The message communication method according to claim 6, characterized in that, The verification information is an E2E field; wherein, the E2E field includes at least the CRC checksum of the second data to be received, the data identifier of the second data to be received, the length of the first data to be received, and a count value; The step of parsing the second data to be received and the verification information from the first data to be received according to the encapsulation format of the first data to be received includes: Using E2E services, the first data to be received is parsed to obtain the second data to be received and an E2E field generated based on the second data to be received.

8. The message communication method according to claim 5, characterized in that, The method further includes: Based on the parsing results of the pre-set target configuration file, a list of protected data identifiers is obtained.

9. A message communication device, characterized in that, The device deploys the DDS protocol, and the device includes: The acquisition module is used to acquire the first data to be sent from the application layer; A generation module is configured to process the first data to be sent in response to the need for protection of the first data to be sent, to obtain a second data to be sent carrying verification information; wherein the verification information is generated based on the first data to be sent, the first data to be sent carries an identifier, and the response to the need for protection of the first data to be sent includes: The method for determining whether the first data to be sent needs to be protected is as follows: A matching operation is performed on the identifier of the first data to be sent and the identifier of each data in the protected data identifier list, wherein the protected data identifier list records the identifiers of data from the application layer that need to be protected. In response to the result of the matching operation being a first result, it is determined that the first data to be sent needs to be protected; The sending module, based on the DCPS layer, instructs the message publisher to publish the second data to be sent, so that the message subscribers can obtain the second data to be sent.

10. The message communication device according to claim 9, characterized in that, The step of processing the first data to be sent to obtain the second data to be sent carrying verification information includes: Call the interface function to generate verification information for the first data to be sent; and The second data to be sent is obtained based on the first data to be sent and the verification information.

11. The message communication device according to claim 10, characterized in that, The verification information is an E2E field; wherein, the E2E field includes at least the CRC checksum of the first data to be sent, the data identifier of the first data to be sent, the length of the second data to be sent, and a count value; The verification information for generating the first data to be sent includes: Invoke the E2E service to generate the E2E field based on the first data to be sent.

12. The message communication device according to claim 9, characterized in that, The generation module is also used for: Based on the parsing results of the pre-set target configuration file, a list of protected data identifiers is obtained.

13. A message communication device, characterized in that, The device deploys the DDS protocol, and the device includes: The acquisition module is used to acquire the first data to be received from the message publisher; The processing module is configured to, in response to the need for parsing the first data to be received, depacketize the first data to be received to obtain second data to be received and verification information generated based on the second data to be received; the response to the need for parsing the first data to be received includes: The method used to determine whether the first data to be received needs to be parsed is as follows: A matching operation is performed on the identifier of the first data to be received and the identifier of each data in the protected data identifier list, wherein the protected data identifier list records the identifiers of data from the application layer that need to be protected. In response to the result of the matching operation being a first result, it is determined that the first data to be received needs to be parsed; The verification module is used to verify the second data to be received based on the verification information. The sending module is used to send the second data to be received to the target data receiver in response to the verification result of the second data to be received being passed.

14. The message communication device according to claim 13, characterized in that, The unpacking process for the first data to be received includes: The interface function is called to parse the second data to be received and the verification information from the first data to be received, according to the encapsulation format of the first data to be received.

15. The message communication device according to claim 14, characterized in that, The verification information is an E2E field; wherein, the E2E field includes at least the CRC checksum of the second data to be received, the data identifier of the second data to be received, the length of the first data to be received, and a count value; The step of parsing the second data to be received and the verification information from the first data to be received according to the encapsulation format of the first data to be received includes: Using E2E services, the first data to be received is parsed to obtain the second data to be received and an E2E field generated based on the second data to be received.

16. The message communication device according to claim 13, characterized in that, The processing module is also used for: Based on the parsing results of the pre-set target configuration file, a list of protected data identifiers is obtained.

17. An electronic device, characterized in that, include: processor; Memory used to store the processor's executable instructions; The processor is configured to read the executable instructions from the memory and execute the instructions to implement the message communication method according to any one of claims 1-8.

18. A computer-readable storage medium having computer program instructions stored thereon, characterized in that, When the program instructions are executed by the processor, they implement the steps of the message communication method according to any one of claims 1-8.

19. A vehicle, characterized in that, A set of instructions is stored, which is executed by the vehicle to implement the message communication method according to any one of claims 1-8.

Images