Interaction methods, devices, electronic equipment, and storage media of DDS gateways

Abstract

This application relates to the field of data communication technology, and particularly to an interaction method, apparatus, electronic device, and storage medium for a DDS gateway. The method includes: receiving a service request sent by a first microcontroller through a first DDS gateway deployed in a communication process of a first microprocessor for communicating with a first microcontroller; determining whether the service request meets a first preset forwarding condition based on a service identifier value and / or a notification class identifier value; if the service request meets the preset forwarding condition, forwarding the service request to a first microprocessor corresponding to the first microcontroller, determined from a plurality of microprocessors, and receiving a service response sent by the first microprocessor when executing the service request; and sending the service response to the first microcontroller when the service response meets a second preset forwarding condition. This solves the problem of insufficient MCU resources when both MCU and MPU chips simultaneously carry the DDS protocol, ensuring that the startup of each chip does not interfere with each other.

Description

Technical Field

[0001] This application relates to the field of data communication technology, and in particular to an interaction method, apparatus, electronic device and storage medium for a DDS gateway. Background Technology

[0002] With the development of intelligent and connected vehicles, the amount of data that needs to be carried in the vehicle network is gradually increasing. At this time, vehicle Ethernet, with its high bandwidth advantage, is being gradually used as the backbone network for vehicle communication. As users have higher and higher requirements for the diversity and richness of vehicle functions, distributed architecture SOA (Service-Oriented Architecture) has emerged. The use of SOA architecture on the basis of Ethernet cannot be separated from the support of middleware protocols. Data Distribution Service (DDS) protocol has gradually appeared in practical applications. It includes RPC (Remote Procedure Call) framework, QoS (Quality of Service) mechanism, domain partitioning, etc., which better enable SOA to be applied in vehicle networks.

[0003] In related technologies, OEMs have gradually adopted DDS as an in-vehicle communication middleware to decouple the connection between the controller application layer and the underlying transmission, promote SOA architecture design, and complete the Ethernet data transmission of the whole vehicle.

[0004] However, using the DDS protocol stack on an MCU (Microcontroller Unit) still has many limitations. For example, the limited RAM resources in the MCU mean that it cannot accommodate the resource consumption of proxy entities that are compatible with the MPU (Microprocessor Unit). This makes most OEMs unable or unwilling to deploy the DDS protocol stack on the MCU, and instead only deploy it on the MPU, resulting in a complex vehicle communication architecture and high communication latency. Summary of the Invention

[0005] This application provides an interaction method, device, electronic device, and storage medium for a DDS gateway to solve the problem of insufficient MCU resources, resulting in a complex vehicle communication architecture and high communication latency when both MCU and MPU chips are equipped with the DDS protocol. The DDS gateway is deployed in each MPU process that needs to communicate with the MCU, and the startup of each chip will not affect each other.

[0006] The first aspect of this application provides an interaction method for a DDS gateway, comprising the following steps: an in-vehicle network communication architecture based on Data Distribution Service (DDS) communication, the in-vehicle network communication architecture including multiple microcontrollers deployed in a first DDS communication area, multiple microprocessors deployed in a second DDS communication area, and multiple DDS gateways deployed in a communication process of the microprocessor for communicating with each microcontroller, wherein the method includes the following steps: receiving a service request sent by the first microcontroller through a first DDS gateway deployed in the communication process of a first microprocessor for communicating with the first microcontroller, wherein the first microcontroller is the processor corresponding to any function determined from the multiple microcontrollers when any function of the current vehicle is triggered. The device, wherein the service request is generated by any of the functions, and the service request includes a service identifier value and / or a notification class identifier value; based on the service identifier value and / or the notification class identifier value, it determines whether the service request meets a first preset forwarding condition, wherein the first preset forwarding condition is determined by the first microprocessor; and if the service request meets the preset forwarding condition, the service request is forwarded to a first microprocessor corresponding to the first microcontroller determined from the plurality of microprocessors, and a service response sent by the first microprocessor when executing the service request is received, and if the service response meets a second preset forwarding condition, the service response is sent to the first microcontroller, wherein the second preset forwarding condition is determined by the first microcontroller.

[0007] Based on the above technical means, this application can solve the problem that when both MCU and MPU chips are equipped with the DDS protocol, the MCU resources are insufficient, resulting in a complex vehicle communication architecture and high communication latency. The DDS gateway is deployed in each MPU process that needs to communicate with the MCU, and the startup of each chip will not affect each other.

[0008] Optionally, in some embodiments, the interaction method of the DDS gateway described above further includes: exchanging first communication data between the plurality of microcontrollers in the first DDS communication area via an in-vehicle Ethernet switch; and exchanging second communication data between the plurality of microprocessors in the second DDS communication area via an in-vehicle Ethernet switch.

[0009] Based on the above technical means, this application can better complete the SOA architecture design using the DDS protocol stack without increasing costs.

[0010] Optionally, in some embodiments, before deploying the plurality of microcontrollers in the first DDS communication area and the plurality of microprocessors in the second DDS communication area, the method further includes: determining the number of the plurality of microcontrollers and the number of the plurality of microprocessors to be deployed based on a preset deployment strategy, wherein the preset deployment strategy is:

[0011] N = (M total -M ower ) / M opposite side ;

[0012] Where N is the communicating peer, and M... total M is the memory resource allocated for the DDS protocol stack. ower M is the memory consumed by the MCU chip itself. opposite side This refers to the memory required by the peer in DDS communication.

[0013] Based on the above technical means, this application can solve the problem of insufficient MCU resources when both MCU and MPU chips are equipped with the DDS protocol.

[0014] Optionally, in some embodiments, before determining whether the service request meets the first preset forwarding condition based on the service identifier value and / or the notification class identifier value, the method further includes: receiving a first microcontroller globally unique identifier, a first microcontroller service request identifier value, and a first microcontroller notification class identifier value sent by the first microcontroller; receiving a first microprocessor globally unique identifier, a first microprocessor service request identifier value, and a first microprocessor notification class identifier value sent by the first microprocessor; and establishing a gateway forwarding routing table based on the first microcontroller globally unique identifier, the first microcontroller service request identifier value, the first microcontroller notification class identifier value, the first microprocessor globally unique identifier, the first microprocessor service request identifier value, and the first microprocessor notification class identifier value.

[0015] Based on the above technical means, this application can realize the adaptive function of the DDS gateway, so that the gateway will not need to be upgraded or updated due to external communication devices or data volume.

[0016] Optionally, in some embodiments, before determining whether the service request meets the first preset forwarding condition based on the service identifier value and / or the notification class identifier value, the method further includes: receiving a newly added microcontroller globally unique identifier, a newly added microcontroller service request identifier value, and a newly added microcontroller notification class identifier value sent by the newly added microcontroller; receiving a newly added microprocessor globally unique identifier, a newly added microprocessor service request identifier value, and a newly added microprocessor notification class identifier value sent by the newly added microprocessor; and updating the gateway forwarding routing table based on the newly added microcontroller globally unique identifier, the newly added microcontroller service request identifier value, the newly added microcontroller notification class identifier value, the newly added microprocessor globally unique identifier, the newly added microprocessor service request identifier value, and the newly added microprocessor notification class identifier value.

[0017] Based on the above technical means, this application can realize the adaptive function of the DDS gateway, so that the gateway will not need to be upgraded or updated due to external communication devices or data volume.

[0018] A second aspect of this application provides an interaction device for a DDS gateway, based on a vehicle network communication architecture using Data Distribution Service (DDS) communication. The vehicle network communication architecture includes multiple microcontrollers deployed in a first DDS communication area, multiple microprocessors deployed in a second DDS communication area, and multiple DDS gateways deployed in communication processes of the microprocessors for communicating with each microcontroller. The device includes a receiving module for receiving a service request sent by the first microcontroller through a first DDS gateway deployed in the communication process of the first microprocessor for communicating with the first microcontroller. The first microcontroller is a processor determined from the multiple microcontrollers corresponding to any function triggered in the current vehicle. The service request... The service request is generated by any of the functions, and includes a service identifier value and / or a notification class identifier value; a judgment module is used to determine whether the service request meets a first preset forwarding condition based on the service identifier value and / or the notification class identifier value, wherein the first preset forwarding condition is determined by the first microprocessor; and a sending module is used to forward the service request to a first microprocessor corresponding to the first microcontroller determined from the plurality of microprocessors when the service request meets the preset forwarding condition, and to receive a service response sent by the first microprocessor when executing the service request, and to send the service response to the first microcontroller when the service response meets a second preset forwarding condition, wherein the second preset forwarding condition is determined by the first microcontroller.

[0019] Optionally, in some embodiments, the interaction device of the DDS gateway described above further includes: a first data exchange unit, used for exchanging first communication data between the plurality of microcontrollers in the first DDS communication area via an in-vehicle Ethernet switch; and a second data exchange unit, used for exchanging second communication data between the plurality of microprocessors in the second DDS communication area via an in-vehicle Ethernet switch.

[0020] Optionally, in some embodiments, before deploying the plurality of microcontrollers in the first DDS communication area and the plurality of microprocessors in the second DDS communication area, the interaction device of the DDS gateway further includes: a determining unit, configured to determine the number of deployed microcontrollers and the number of deployed microprocessors based on a preset deployment strategy, wherein the preset deployment strategy is:

[0021] N = (M total -M ower ) / M opposite side ;

[0022] Where N is the communicating peer, and M... total M is the memory resource allocated for the DDS protocol stack. ower M is the memory consumed by the MCU chip itself. opposite side This refers to the memory required by the peer in DDS communication.

[0023] Optionally, in some embodiments, before determining whether the service request meets the first preset forwarding condition based on the service identifier value and / or the notification class identifier value, the determining module is further configured to: receive a first microcontroller globally unique identifier, a first microcontroller service request identifier value, and a first microcontroller notification class identifier value sent by the first microcontroller; receive a first microprocessor globally unique identifier, a first microprocessor service request identifier value, and a first microprocessor notification class identifier value sent by the first microprocessor; and establish a gateway forwarding routing table based on the first microcontroller globally unique identifier, the first microcontroller service request identifier value, the first microcontroller notification class identifier value, the first microprocessor globally unique identifier, the first microprocessor service request identifier value, and the first microprocessor notification class identifier value.

[0024] Optionally, in some embodiments, before determining whether the service request meets the first preset forwarding condition based on the service identifier value and / or the notification class identifier value, the determining module is further configured to: receive a newly added microcontroller globally unique identifier, a newly added microcontroller service request identifier value, and a newly added microcontroller notification class identifier value sent by the newly added microcontroller; receive a newly added microprocessor globally unique identifier, a newly added microprocessor service request identifier value, and a newly added microprocessor notification class identifier value sent by the newly added microprocessor; and update the gateway forwarding routing table based on the newly added microcontroller globally unique identifier, the newly added microcontroller service request identifier value, the newly added microcontroller notification class identifier value, the newly added microprocessor globally unique identifier, the newly added microprocessor service request identifier value, and the newly added microprocessor notification class identifier value.

[0025] A third aspect of this application provides an electronic device, including: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the interaction method of the DDS gateway as described in the above embodiments.

[0026] A fourth aspect of this application provides a computer-readable storage medium having a computer program stored thereon, which is executed by a processor to implement the interaction method of the DDS gateway as described in the above embodiments.

[0027] Therefore, by pre-deploying a DDS gateway, service requests from the microprocessor and microcontroller are received and filtered. The gateway determines whether a service request meets a first preset forwarding condition; if so, it is forwarded; otherwise, it is discarded. It then determines whether the service request meets a second preset forwarding condition; if so, it is forwarded; otherwise, it is discarded. This solves the problem of insufficient MCU resources, leading to a complex vehicle communication architecture and high communication latency when both MCU and MPU chips simultaneously carry the DDS protocol. The DDS gateway is deployed within each MPU process that needs to communicate with the MCU, ensuring that the startup of each chip does not interfere with each other.

[0028] Additional aspects and advantages of this application will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of this application. Attached Figure Description

[0029] The above and / or additional aspects and advantages of this application will become apparent and readily understood from the following description of the embodiments taken in conjunction with the accompanying drawings, wherein:

[0030] Figure 1 This is a flowchart of the interaction method of the DDS gateway provided according to the embodiments of this application;

[0031] Figure 2This is a schematic diagram of a vehicle network architecture based on a DDS gateway according to an embodiment of this application;

[0032] Figure 3 This is a schematic diagram illustrating the deployment of a DDS gateway according to an embodiment of this application;

[0033] Figure 4 This is a flowchart illustrating the filtering and forwarding condition learning process of a DDS gateway according to an embodiment of this application.

[0034] Figure 5 This is a schematic diagram illustrating the interactive behavior of a DDS gateway provided according to an embodiment of this application;

[0035] Figure 6 This is a block diagram of an interaction device for a DDS gateway provided according to an embodiment of this application;

[0036] Figure 7 This is a schematic diagram of an electronic device provided according to an embodiment of this application.

[0037] Explanation of reference numerals in the attached diagram: 10 - Interaction device of DDS gateway, 100 - Receive module, 200 - Judgment module, and 300 - Transmitting module. Detailed Implementation

[0038] The embodiments of this application are described in detail below. Examples of these embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and intended to explain this application, and should not be construed as limiting this application.

[0039] Before introducing the interaction method of the DDS gateway in the embodiments of this application, let's first introduce the DDS interaction method in related technologies.

[0040] DDS (Data Distribution Service) is a next-generation distributed real-time communication middleware protocol. It adopts a publish / subscribe architecture, emphasizes data as the core, and provides rich QoS (Quality of Service) policies to ensure real-time, efficient, and flexible data distribution, meeting the needs of various distributed real-time communication applications.

[0041] In terms of data transmission, DDS has 22 standard QoS types and some custom QoS types. By using QoS appropriately, even when using UDP at the transport layer, it can also achieve mechanisms such as retransmission of lost data and receiving acknowledgment responses, thus making up for the shortcomings of reliable data transmission which can only be carried out using TCP.

[0042] Regarding the confirmation of the status of the communicating parties, each entity in the DDS protocol stack has an automatic keep-alive and liveness declaration mechanism, so that the communicating parties can know the life cycle and liveness of the other party in real time and take timely action.

[0043] The related technology discloses a vehicle electronic and electrical system based on DDS, in which data communication between terminal nodes, switches and central controllers all adopts a communication method based on DDS data bus.

[0044] However, the related technologies do not consider that vehicle safety control generally uses MCU chips, and the resource capabilities of sensor and actuator chips may not be sufficient to support the DDS protocol stack. Furthermore, these technologies are incompatible with the requirements of low controller cost, stable control functions, and security, making them unsuitable for current automotive development needs. Additionally, they fail to address the fact that during the service discovery phase of the DDS protocol stack, the local end stores the proxy entity of the peer, thus increasing memory consumption on the communication end. Given the limited resources of the MCU, it cannot accommodate the resource consumption caused by the proxy entity matched with the MPU communication. Simultaneously integrating the DDS protocol into both MCU and MPU chips presents significant challenges.

[0045] To address the aforementioned issues, this application provides an interaction method for a DDS gateway. In this method, a DDS gateway is pre-deployed. Service requests from the microprocessor and microcontroller are received and filtered. The method determines whether the service request meets a first preset forwarding condition; if so, it is forwarded; otherwise, it is discarded. The method then determines whether the service request meets a second preset forwarding condition; if so, it is forwarded; otherwise, it is discarded. This solves the problem of insufficient MCU resources, leading to a complex vehicle communication architecture and high communication latency when both the MCU and MPU chips simultaneously carry the DDS protocol. The DDS gateway is deployed within each MPU process that needs to communicate with the MCU, ensuring that the startup of each chip does not interfere with each other.

[0046] Specifically, Figure 1 This is a flowchart illustrating an interaction method for a DDS gateway provided in an embodiment of this application.

[0047] In this embodiment, the interaction method of the DDS gateway is based on the vehicle network communication architecture of the Data Distribution Service (DDS) communication. The vehicle network communication architecture includes multiple microcontrollers deployed in a first DDS communication area, multiple microprocessors deployed in a second DDS communication area, and multiple DDS gateways deployed in the communication process of the microprocessors for communicating with each microcontroller.

[0048] The in-vehicle network communication architecture of DDS communication can include: DDS communication area A, DDS communication area B, and an in-vehicle Ethernet switch. DDS communication area A contains an in-vehicle Ethernet communication terminal equipped with an MCU chip, DDS communication area B contains an in-vehicle Ethernet communication terminal equipped with an MPU chip, and the in-vehicle Ethernet switch is responsible for Ethernet data exchange between the various chips. This is the simplest communication model, and may involve multiple communication domains. In actual design, this can be extended based on specific needs.

[0049] Specifically, such as Figure 2 As shown, Figure 2 This is a schematic diagram of a vehicle network architecture based on a DDS gateway according to an embodiment of this application. The communication architecture includes, but is not limited to, ring networks, tree networks, or other types of communication network architectures. A simplest communication model is described here. For example, in this embodiment, multiple microprocessors may include MPU1, MPU2, and MPU3, and multiple microcontrollers may include MCU1, MCU2, and MCU3. In actual design, extensions can be made based on specific needs. The system includes an Ethernet communication terminal equipped with an MCU chip, an Ethernet communication terminal equipped with an MPU chip, and a vehicle Ethernet switch.

[0050] In the communication system of this application embodiment, it is necessary to isolate different communication domains by assigning different domainIDs. The characteristics of the method are as follows:

[0051] S201: Represents the DDS communication domain equipped with MCU chips. The number of peers each MCU chip can communicate with within this domain needs to be calculated based on memory resources, thus determining the total number of MCU chips in this communication domain. The calculation formula is as follows:

[0052] N = (M total -M ower ) / M opposite side ;

[0053] Where N represents the peer that can communicate;

[0054] M total : Represents the memory resources allocated by the system to the DDS protocol stack;

[0055] M ower : Represents the memory consumed by the MCU chip itself, including the memory required by the DDS protocol stack, the memory required by the DDS communication entity, etc.;

[0056] M opposite side: Represents the memory required by the peer in DDS communication, including the memory consumed by the peer participants, writer, reader and other proxy entity information that needs to be loaded into the MCU chip.

[0057] The above formula is used to calculate the number of DDS peers that each chip can communicate with, as well as the number of entities such as topics and writers that it can carry. The MCU chips that need to communicate with each other are divided into a DDS communication domain. The domainID can take a value within the range defined by the standard. For example, if domainID=1, all MCU chips in this communication domain can communicate directly through an Ethernet switch. Chips in other communication domains cannot communicate directly. For example, MCU1 and MCU2 can communicate normally, but MCU1 and MPU1 cannot communicate and can only exchange data through a DDS gateway.

[0058] S202: Represents the DDS communication domain equipped with MPU chips. The calculation method is the same as in S201. The number of MPU peers that can communicate is calculated. The MPU chips that need to communicate with each other are divided into a DDS communication domain. The domainID can take values ​​within the range defined by the standard. For example, if domainID=2, all chips in this communication domain can communicate directly, while chips in other communication domains cannot communicate directly.

[0059] S203: Represents the Ethernet data exchange center. The controllers in S201 can exchange data through the S203 switch, and the controllers in S202 can exchange data through the S203 switch. S201 and S202 are connected via Ethernet and both use the DDS protocol stack as the communication middleware.

[0060] Furthermore, such as Figure 3 As shown, Figure 3 This diagram illustrates the deployment of a DDS gateway based on the interaction method of the DDS gateway according to this application. Its deployment characteristics need to consider the following:

[0061] It should be noted that DDS gateway deployment mainly involves two parts: the design principles for DDS gateway deployment location and the communication behavior requirements of the DDS gateway. Regarding the design principles for DDS gateway deployment location, considerations must be given to communication latency, single point of failure of the gateway, differences in gateway function startup due to chip startup differences, and differences between high-end and low-end vehicle configurations. This is to avoid functional and architectural problems and unpredictable risks arising from the introduction of the DDS gateway. As for the communication behavior requirements of the deployed DDS gateway, firstly, the DDS gateway only needs to handle communication between the MCU and MPU; that is, when the MCU needs to communicate with the MPU or vice versa, this communication data is forwarded through the DDS gateway. When the DDS gateway interacts with other processes in the MPU chip, communication can only be conducted through the local loopback network. The introduction of the DDS gateway should not lead to increased network bandwidth or data storms.

[0062] S301: In the initial design phase, collect communication data of the entire vehicle and analyze the data communication paths. Generally, there are data communication between MCU chips, data communication between MCU chips and MPU chips, data communication between MPU chips, and data communication between processes within the MPU chip.

[0063] S302: Gateway deployment principle. Gateway deployment needs to meet the requirements of communication transmission latency. The forwarding latency brought by the gateway needs to be considered. Therefore, in this embodiment, MCUs still communicate directly with each other, and MPUs also communicate directly with each other. When an MPU needs to communicate with an MCU, a DDS gateway needs to be deployed in one process of this MPU chip. This allows the MCU to be in a communication domain, which can both allow the MCU to communicate directly and reduce the latency caused by the introduction of the gateway, and also meet the problem of limited MCU resources.

[0064] Gateway deployment needs to avoid the risk of single point of failure. When one gateway fails, it should not affect the communication between other MPUs and the MCU. Therefore, the gateway needs to be deployed in each MPU process that needs to communicate with the MCU. Even if one of the gateways carrying an MPU fails, it will only affect the communication between that MPU and the MCU, and will not affect the communication between other MPUs and the MCU. This can avoid the whole vehicle carrying a single gateway, which would cause all forwarded data to fail after the gateway fails, resulting in the failure of the whole vehicle function.

[0065] Gateway deployment needs to accommodate communication latency caused by differences in chip startup. Generally, MCUs start up faster and MPUs start up slower, and the startup times of each MPU / MCU also differ. If the gateway is deployed on a slow-starting chip, it will affect the communication between other fast-starting MPUs and the MCU because the gateway is deployed on a slow-starting MPU. Therefore, the DDS gateway is deployed in the process of each MPU that needs to communicate with the MCU, so that the startup of each chip will not affect each other.

[0066] The gateway deployment needs to meet the requirements of the vehicle's high and low configurations. The difference between high and low configuration chips should not cause communication abnormalities between the MCU and MPU. Therefore, the DDS gateway is deployed in each MPU process that needs to communicate with the MCU. The presence or absence of each chip will not affect each other.

[0067] S303: Gateway implementation requirements analysis. When the MCU chip needs to communicate with the MPU chip, a DDS gateway needs to be deployed in the process of this MPU chip. Since the MCU communication domain and the MPU communication domain are isolated by domain division, the DDS gateway needs to be in both communication domains at the same time and establish connections with the communication entities in both communication domains. The gateway only needs to complete the data forwarding when the data communicates between the MCU and the MPU.

[0068] S304: System communication rule design. First, the DDS gateway completes the data communication forwarding between the MCU and MPU. That is, when the MCU needs to communicate with the MPU or the MPU needs to communicate with the MCU, this communication data is forwarded through the DDS gateway. When the DDS gateway interacts with other processes in the MPU chip, it can only communicate through the local loopback network. Second, for direct communication between MCUs, the DDS gateway does not forward data sent from MCU to MCU; for direct communication between MPUs, the DDS gateway does not forward data sent from MPU to MPU, nor does it forward data for communication between MPU processes.

[0069] like Figure 1 As shown, the interaction method of this DDS gateway includes the following steps:

[0070] In step S101, a service request sent by the first microcontroller is received through a first DDS gateway deployed in the communication process of the first microprocessor used to communicate with the first microcontroller. The first microcontroller is the processor corresponding to any function determined from multiple microcontrollers when any function of the current vehicle is triggered. The service request is generated by any function and includes a service identifier value and / or a notification class identifier value.

[0071] The service identifier value can include both service request identifier and service response identifier. The service request identifier value is primarily designed for the gateway to automatically learn the filtering and forwarding conditions for service request data. First, each controller needs to ensure the uniqueness of the assigned service identifier value; for example, the service identifier value can be defined as serviceNum = x++. Second, the transmission of the service identifier value is divided into two phases. In the service discovery phase, it is transmitted through topic data or user data, mainly for the DDS gateway to learn the data conditions that can be forwarded. In the data transmission phase, it is transmitted through the payload field of the data sub-message. The specific transmission rules can be defined by the user; the DDS gateway mainly uses this to determine whether the data meets the forwarding conditions and can be forwarded.

[0072] The service response identifier value is primarily designed for the gateway to automatically learn the filtering and forwarding conditions of service response data. First, the service response identifier value can use the GUID (Globally Unique Identifier) ​​carried in the service request data. The specific GUID used can be defined according to your needs; it's not mandatory, as long as the gateway can forward it. Second, the service response identifier value is transmitted during the data transmission phase through the payload field of the data sub-message. Specific transmission rules can be defined by yourself.

[0073] Notification class identifiers can be assigned unique identifiers, just like service request identifiers. For example, they can be defined as NotifNum. Data notification class identifier transmission is divided into two phases: in the service discovery phase, it is transmitted through topic data or user data, etc., and in the data transmission phase, it is transmitted through the payload field of the data sub-message. The specific transmission rules can be defined by the user.

[0074] In step S102, based on the service identifier value and / or notification class identifier value, it is determined whether the service request meets the first preset forwarding condition, wherein the first preset forwarding condition is determined by the first microprocessor.

[0075] Specifically, when the MCU sends a request message with serviceNum=1 as a client, the gateway determines whether the request should be forwarded based on the previously recorded serviceNum sent by the MPU. If serviceNum=1, the first preset forwarding condition is met. When the MCU sends notification data NotifNum=1.1, the gateway determines whether the request should be forwarded based on the previously recorded NotifNum. If NotifNum=1.1, the first preset condition is met.

[0076] Optionally, in some embodiments, before determining whether a service request meets the first preset forwarding condition based on the service identifier value and / or notification class identifier value, the method further includes: receiving a first microcontroller globally unique identifier, a first microcontroller service request identifier value, and a first microcontroller notification class identifier value sent by a first microcontroller; receiving a first microprocessor globally unique identifier, a first microprocessor service request identifier value, and a first microprocessor notification class identifier value sent by a first microprocessor; and establishing a gateway forwarding routing table based on the first microcontroller globally unique identifier, the first microcontroller service request identifier value, the first microcontroller notification class identifier value, the first microprocessor globally unique identifier, the first microprocessor service request identifier value, and the first microprocessor notification class identifier value.

[0077] Optionally, in some embodiments, before determining whether a service request meets the first preset forwarding condition based on the service identifier value and / or notification class identifier value, the method further includes: receiving a newly added microcontroller globally unique identifier, a newly added microcontroller service request identifier value, and a newly added microcontroller notification class identifier value sent by the newly added microcontroller; receiving a newly added microprocessor globally unique identifier, a newly added microprocessor service request identifier value, and a newly added microprocessor notification class identifier value sent by the newly added microprocessor; and updating the gateway forwarding routing table based on the newly added microcontroller globally unique identifier, the newly added microcontroller service request identifier value, the newly added microcontroller notification class identifier value, the newly added microprocessor globally unique identifier, the newly added microprocessor service request identifier value, and the newly added microprocessor notification class identifier value.

[0078] It should be noted that data filtering can be performed before determining whether a service request meets the first preset forwarding condition based on the service identifier value and / or notification identifier value. During the service discovery phase, each entity endpoint sends its own GUID, the serviceNum of the services it can provide, and the NotifNum of the services it needs. At this time, the gateway records these three pieces of information. The GUID is mainly used to identify the entity that communicates with the GW and is used to filter service response data; the serviceNum is mainly used to identify the service and is used to filter service request data; and the NotifNum is mainly used to identify notification data and is used to filter notification data. At the same time, depending on the different startup times of each component, any discovery behavior performed after startup needs to update the filtering conditions in a timely manner.

[0079] Specifically, such as Figure 4 As shown, Figure 4 This is a flowchart illustrating the filtering and forwarding condition learning process of a DDS gateway according to an embodiment of this application.

[0080] S401: After system startup, according to the characteristics of the DDS communication protocol, the domain participant discovery phase will be triggered immediately. During the domain participant discovery phase, any participant with the same domainID can establish a connection. Therefore, the MCU chip and the gateway, and the gateway and the MPU chip can communicate and establish a connection, while creating proxy entity information for the peer. Since the MCU chip and the MPU chip are not in the same domain, they cannot establish a connection. MCU chips in the same domain can perform service discovery and establish a connection with each other. MPU chips in the same domain can also perform service discovery and establish a connection with each other.

[0081] S402: During the endpoint discovery phase, according to the standard protocol, the DDS entities in the MCU chip and MPU chip will send their own GUIDs to the gateway. At the same time, the MCU chip and MPU chip need to send their own service request identifier value and notification class identifier value to the gateway through topic data. The gateway needs to record this information as the gateway forwarding routing table.

[0082] S403: When a controller starts up slowly, or a controller is added midway, and these controllers meet the requirements for the gateway to forward data, the gateway also needs to learn this part of the content so that it can forward this type of data normally later; that is, if it is an MCU chip, the chip needs to communicate with the MPU chip, or if it is an MPU chip, the chip needs to communicate with the MCU chip.

[0083] S404: This content is the same as S401. Newly added or later started controllers complete the domain participant discovery phase with the existing communication system;

[0084] S405: This content is the same as S402. Newly added or later started controllers complete the endpoint discovery phase with the existing communication system;

[0085] S406: Information related to newly added or subsequently started controllers is recorded by the gateway and used as a condition for subsequent data forwarding.

[0086] In step S103, if the service request meets the preset forwarding conditions, the service request is forwarded to the first microprocessor corresponding to the first microcontroller determined from multiple microprocessors, and the service response sent by the first microprocessor when executing the service request is received. When the service response meets the second preset forwarding conditions, the service response is sent to the first microcontroller, wherein the second preset forwarding conditions are determined by the first microcontroller.

[0087] Specifically, when the MCU sends a request message with serviceNum=1 as a client, the gateway determines whether the request should be forwarded based on the previously recorded serviceNum sent by the MPU. If serviceNum=1, it is forwarded; otherwise, it is discarded. After receiving the request, the MPU sends a response message carrying the GUID=0x11111 of the client MCU. The gateway determines whether forwarding is required based on the previously recorded GUID sent by the MCU. If GUID=0x11111, it is forwarded; otherwise, it is discarded.

[0088] When the MCU sends notification data (NotifNum = 1.1), the gateway determines whether the request should be forwarded based on the previously recorded NotifNum. If NotifNum = 1.1, it forwards the request; otherwise, it discards it. Upon receiving the request, the MPU sends a response message carrying the client MCU's GUID = 0x11111. The gateway then determines whether forwarding is necessary based on the previously recorded GUID sent by the MCU. If the GUID = 0x11111, it forwards the message; otherwise, it discards it.

[0089] Optionally, in some embodiments, before deploying multiple microcontrollers in the first DDS communication area and multiple microprocessors in the second DDS communication area, the method further includes: determining the number of multiple microcontrollers and the number of multiple microprocessors to be deployed based on a preset deployment strategy, wherein the preset deployment strategy is:

[0090] N = (M total -M ower ) / M opposite side ;

[0091] Where N represents the peer that can communicate, Mtotal represents the memory resources allocated by the system to the DDS protocol stack, Mower represents the memory consumed by the MCU chip itself, and Mopposite side represents the memory required by the peer that communicates with DDS.

[0092] The above formula can be used to calculate the number of DDS peers that each chip can communicate with, as well as the number of entities such as topics and writers that it can carry.

[0093] To enable those skilled in the art to further understand the interaction method of the DDS gateway in the embodiments of this application, the following detailed description is provided in conjunction with specific embodiments.

[0094] like Figure 5 As shown, Figure 5 This application presents an interaction method for a DDS gateway according to an embodiment of the present application.

[0095] S501: When a certain function of the vehicle is triggered, the MCU chip sends a related service request, such as volume control adjustment. The MCU chip is responsible for the volume control switch, and the vehicle system is responsible for volume adjustment. At this time, the MCU chip receives a volume increase request from the user, and then the MCU chip will send a volume increase service request.

[0096] S502: After receiving a request from the MCU chip, the gateway determines whether the received data serviceNUM matches the data provided by the MPU collected earlier. If it does, the data is forwarded; otherwise, it is discarded.

[0097] S503: In S403, if the conditions are met in a certain DDS gateway, the request will be forwarded. After the process in the MPU receives the request, it will determine whether the service is provided by itself. If it is, the request will be executed; otherwise, it will be discarded.

[0098] S504: After receiving the request, the process in the MPU sends the response for the service. The gateway receives the response and determines whether the GUID in the data sub-message is a relevant entity on the MCU side. If it is, it forwards the request; otherwise, it discards the request. If the conditions are met in a certain DDS gateway, the response will be forwarded. After receiving the response, the MCU determines whether it is a valid entity.

[0099] According to the DDS gateway interaction method proposed in this application, the DDS gateway is pre-deployed. It receives service requests from the microprocessor and microcontroller, filters these requests, and determines whether each request meets a first preset forwarding condition. If the request meets the condition, it is forwarded; otherwise, it is discarded. The method then determines whether the request meets a second preset forwarding condition; if the condition is met, it is forwarded; otherwise, it is discarded. This solves the problem of insufficient MCU resources, leading to a complex vehicle communication architecture and high communication latency when both MCU and MPU chips simultaneously carry the DDS protocol. The DDS gateway is deployed in each MPU process that needs to communicate with the MCU, ensuring that the startup of each chip does not interfere with each other.

[0100] Next, the interactive device of the DDS gateway according to the embodiments of this application is described with reference to the accompanying drawings.

[0101] Figure 6 This is a block diagram of the interaction device of the DDS gateway according to an embodiment of this application.

[0102] like Figure 6As shown, the interaction device 10 of the DDS gateway is based on the vehicle network communication architecture of the Data Distribution Service (DDS) communication. The vehicle network communication architecture includes multiple microcontrollers deployed in the first DDS communication area, multiple microprocessors deployed in the second DDS communication area, and multiple DDS gateways deployed in the communication process of the microprocessors for communicating with each microcontroller. The device includes a receiving module 100, a judging module 200, and a sending module 300.

[0103] The receiving module 100 is configured to receive a service request sent by the first microcontroller through a first DDS gateway deployed in the communication process of the first microprocessor used to communicate with the first microcontroller. The first microcontroller is the processor corresponding to any function determined from multiple microcontrollers when any function of the current vehicle is triggered. The service request is generated by any function and includes a service identifier value and / or a notification class identifier value. The judging module 200 is configured to judge whether the service request meets a first preset forwarding condition based on the service identifier value and / or the notification class identifier value. The first preset forwarding condition is determined by the first microprocessor. The sending module 300, when the service request meets the preset forwarding condition, forwards the service request to the first microprocessor corresponding to the first microcontroller determined from multiple microprocessors, receives the service response sent by the first microprocessor when executing the service request, and sends the service response to the first microcontroller when the service response meets a second preset forwarding condition. The second preset forwarding condition is determined by the first microcontroller.

[0104] Optionally, in some embodiments, the interaction device 10 of the DDS gateway described above further includes: a first data exchange unit, used for exchanging first communication data between multiple microcontrollers in a first DDS communication area via an in-vehicle Ethernet switch; and a second data exchange unit, used for exchanging second communication data between multiple microprocessors in a second DDS communication area via an in-vehicle Ethernet switch.

[0105] Optionally, in some embodiments, before deploying multiple microcontrollers in the first DDS communication area and multiple microprocessors in the second DDS communication area, the interaction device 10 of the DDS gateway further includes: a determining unit, configured to determine the number of multiple microcontrollers and the number of multiple microprocessors deployed based on a preset deployment strategy, wherein the preset deployment strategy is:

[0106] N = (M total -M ower ) / M opposite side ;

[0107] Where N represents the peer that can communicate, Mtotal represents the memory resources allocated by the system to the DDS protocol stack, Mower represents the memory consumed by the MCU chip itself, and Mopposite side represents the memory required by the peer that communicates with DDS.

[0108] Optionally, in some embodiments, before determining whether a service request meets the first preset forwarding condition based on the service identifier value and / or notification class identifier value, the determination module 200 is further configured to: receive a first microcontroller globally unique identifier, a first microcontroller service request identifier value, and a first microcontroller notification class identifier value sent by the first microcontroller; receive a first microprocessor globally unique identifier, a first microprocessor service request identifier value, and a first microprocessor notification class identifier value sent by the first microprocessor; and establish a gateway forwarding routing table based on the first microcontroller globally unique identifier, the first microcontroller service request identifier value, the first microcontroller notification class identifier value, the first microprocessor globally unique identifier, the first microprocessor service request identifier value, and the first microprocessor notification class identifier value.

[0109] Optionally, in some embodiments, before determining whether a service request meets the first preset forwarding condition based on the service identifier value and / or notification class identifier value, the determination module 200 is further configured to: receive a newly added microcontroller globally unique identifier, a newly added microcontroller service request identifier value, and a newly added microcontroller notification class identifier value sent by the newly added microcontroller; receive a newly added microprocessor globally unique identifier, a newly added microprocessor service request identifier value, and a newly added microprocessor notification class identifier value sent by the newly added microprocessor; and update the gateway forwarding routing table based on the newly added microcontroller globally unique identifier, the newly added microcontroller service request identifier value, the newly added microcontroller notification class identifier value, the newly added microprocessor globally unique identifier, the newly added microprocessor service request identifier value, and the newly added microprocessor notification class identifier value.

[0110] It should be noted that the foregoing explanation of the interaction method embodiment of the DDS gateway also applies to the interaction device of the DDS gateway in this embodiment, and will not be repeated here.

[0111] The interaction device for the DDS gateway proposed in this application pre-deploys the DDS gateway, receives service requests from the microprocessor and microcontroller, filters the service requests, determines whether the service request meets a first preset forwarding condition (forwarding if it meets the condition, otherwise discarding it), and determines whether the service request meets a second preset forwarding condition (forwarding if it meets the condition, otherwise discarding it). This solves the problem of insufficient MCU resources leading to a complex vehicle communication architecture and high communication latency when both MCU and MPU chips simultaneously carry the DDS protocol. The DDS gateway is deployed in each MPU process that needs to communicate with the MCU, and the startup of each chip does not affect each other.

[0112] Figure 7 A schematic diagram of the structure of an electronic device provided in an embodiment of this application. The electronic device may include:

[0113] The memory 701, the processor 702, and the computer program stored on the memory 701 and executable on the processor 702.

[0114] When the processor 702 executes the program, it implements the interaction method of the DDS gateway provided in the above embodiments.

[0115] Furthermore, electronic devices also include:

[0116] Communication interface 703 is used for communication between memory 701 and processor 702.

[0117] The memory 701 is used to store computer programs that can run on the processor 702.

[0118] The memory 701 may include high-speed RAM (Random Access Memory) memory, and may also include non-volatile memory, such as at least one disk storage.

[0119] If the memory 701, processor 702, and communication interface 703 are implemented independently, then the communication interface 703, memory 701, and processor 702 can be interconnected via a bus to complete communication between them. The bus can be an ISA (Industry Standard Architecture) bus, a PCI (Peripheral Component Interconnect) bus, or an EISA (Extended Industry Standard Architecture) bus, etc. The bus can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 7 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0120] Optionally, in a specific implementation, if the memory 701, processor 702, and communication interface 703 are integrated on a single chip, then the memory 701, processor 702, and communication interface 703 can communicate with each other through an internal interface.

[0121] The processor 702 may be a CPU (Central Processing Unit), an ASIC (Application Specific Integrated Circuit), or one or more integrated circuits configured to implement the embodiments of this application.

[0122] This application also provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the above-described interaction method of the DDS gateway.

[0123] In the description of this specification, the references to terms such as "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of this application. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification, as well as the features of different embodiments or examples.

[0124] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one of that feature. In the description of this application, "N" means at least two, such as two, three, etc., unless otherwise explicitly specified.

[0125] Any process or method described in the flowchart or otherwise herein can be understood as representing a module, segment, or portion of code comprising one or more N executable instructions for implementing custom logic functions or processes, and the scope of the preferred embodiments of this application includes additional implementations in which functions may be performed not in the order shown or discussed, including substantially simultaneously or in reverse order depending on the functions involved, as should be understood by those skilled in the art to which embodiments of this application pertain.

[0126] It should be understood that the various parts of this application can be implemented using hardware, software, firmware, or a combination thereof. In the above embodiments, the N steps or methods can be implemented using software or firmware stored in memory and executed by a suitable instruction execution system. For example, if implemented in hardware, as in another embodiment, it can be implemented using any one or a combination of the following techniques known in the art: discrete logic circuits having logic gates for implementing logical functions on data signals, application-specific integrated circuits (ASICs) having suitable combinational logic gates, programmable gate arrays (FPGAs), field-programmable gate arrays (FPGAs), etc.

[0127] Those skilled in the art will understand that all or part of the steps of the methods in the above embodiments can be implemented by a program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, the program includes one or a combination of the steps of the method embodiments.

[0128] Although embodiments of this application have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting this application. Those skilled in the art can make changes, modifications, substitutions and variations to the above embodiments within the scope of this application.

Claims

1. An interaction method of a DDS gateway, characterized in that, A vehicle network communication architecture based on data distribution service (DDS) communication, the vehicle network communication architecture comprising a plurality of microcontrollers deployed in a first DDS communication area, a plurality of microprocessors deployed in a second DDS communication area, and a plurality of DDS gateways deployed in a communication process of the microprocessors for communication with each microcontroller, wherein the method comprises the following steps: receiving, by a first DDS gateway deployed in a communication process of a first microprocessor for communication with a first microcontroller, a service request sent by the first microcontroller, wherein the first microcontroller is a processor corresponding to any function of a current vehicle determined from the plurality of microcontrollers when the any function is triggered, the service request is generated by the any function, and the service request comprises a service identification value and / or a notification class identification value; determining whether the service request meets a first preset forwarding condition based on the service identification value and / or the notification class identification value, wherein the first preset forwarding condition is determined by the first microprocessor; and if the service request meets the preset forwarding condition, forwarding the service request to a first microprocessor corresponding to the first microcontroller determined from the plurality of microprocessors, receiving a service response sent by the first microprocessor when the first microprocessor executes the service request, and sending the service response to the first microcontroller when the service response meets a second preset forwarding condition, wherein the second preset forwarding condition is determined by the first microcontroller; before deploying the plurality of microcontrollers in the first DDS communication area and deploying the plurality of microprocessors in the second DDS communication area, the method further comprises: determining the number of the plurality of microcontrollers and the number of the plurality of microprocessors based on a preset deployment strategy, wherein the preset deployment strategy is: N = (M total -M ower ) / M opposite side ; Wherein, N is the opposite end of communication, M total Memory resources allocated for the DDS protocol stack, M ower Memory consumed by the MCU chip itself, M opposite side Memory required by the opposite end of DDS communication.

2. The method of claim 1, wherein, the method further comprises: performing first communication data exchange between the plurality of microcontrollers in the first DDS communication area through a vehicle Ethernet switch; performing second communication data exchange between the plurality of microprocessors in the second DDS communication area through the vehicle Ethernet switch.

3. The method of claim 1, wherein, before determining whether the service request meets the first preset forwarding condition based on the service identification value and / or the notification class identification value, the method further comprises: receiving a first microcontroller globally unique identifier, a first microcontroller service request identification value, and a first microcontroller notification class identification value sent by the first microcontroller; receiving a first microprocessor globally unique identifier, a first microprocessor service request identification value, and a first microprocessor notification class identification value sent by the first microprocessor; establishing a gateway forwarding routing table according to the first microcontroller globally unique identifier, the first microcontroller service request identification value, the first microcontroller notification class identification value, the first microprocessor globally unique identifier, the first microprocessor service request identification value, and the first microprocessor notification class identification value.

4. The method of claim 3, wherein, Before judging whether the service request meets the first preset forwarding condition based on the service identification value and / or the notification class identification value, the method further comprises: receiving a newly-added microcontroller global unique identifier, a newly-added microcontroller service request identification value and a newly-added microcontroller notification class identification value sent by a newly-added microcontroller; receiving a newly-added microprocessor global unique identifier, a newly-added microprocessor service request identification value and a newly-added microprocessor notification class identification value sent by a newly-added microprocessor; updating the gateway forwarding routing table based on the newly-added microcontroller global unique identifier, the newly-added microcontroller service request identification value, the newly-added microcontroller notification class identification value, the newly-added microprocessor global unique identifier, the newly-added microprocessor service request identification value and the newly-added microprocessor notification class identification value.

5. An interaction device of a DDS gateway, characterized in that, A vehicle-mounted network communication architecture based on data distribution service (DDS) communication, the vehicle-mounted network communication architecture comprising a plurality of microcontrollers deployed in a first DDS communication area, a plurality of microprocessors deployed in a second DDS communication area, and a plurality of DDS gateways deployed in a communication process of a microprocessor for communication with each microcontroller, wherein the apparatus comprises: a receiving module configured to receive a service request sent by a first microcontroller through a first DDS gateway deployed in a communication process of a first microprocessor for communication with the first microcontroller, wherein the first microcontroller is a processor corresponding to any function of a current vehicle determined from the plurality of microcontrollers when the any function is triggered, the service request is generated by the any function, and the service request comprises a service identification value and / or a notification class identification value; a judging module configured to judge whether the service request meets a first preset forwarding condition based on the service identification value and / or the notification class identification value, wherein the first preset forwarding condition is determined by the first microprocessor; and a sending module configured to, when the service request meets the preset forwarding condition, forward the service request to a first microprocessor corresponding to the first microcontroller determined from the plurality of microprocessors, receive a service response sent by the first microprocessor when the first microprocessor executes the service request, and when the service response meets a second preset forwarding condition, send the service response to the first microcontroller, wherein the second preset forwarding condition is determined by the first microcontroller. Before deploying the plurality of microcontrollers in the first DDS communication area and deploying the plurality of microprocessors in the second DDS communication area, the interaction apparatus of the DDS gateway further comprises: a determining unit configured to determine the number of the plurality of microcontrollers and the number of the plurality of microprocessors based on a preset deployment strategy, wherein the preset deployment strategy is: N = (M total -M ower ) / M opposite side ; Wherein, N is the opposite end of communication, M total Memory resources allocated for the DDS protocol stack, M ower Memory consumed by the MCU chip itself, M opposite side Memory required by the opposite end of DDS communication.

6. The apparatus of claim 5, wherein, further comprising: a first data exchange unit configured to perform first communication data exchange between the plurality of microcontrollers in the first DDS communication area through a vehicle-mounted Ethernet switch; and a second data exchange unit configured to perform second communication data exchange between the plurality of microprocessors in the second DDS communication area through a vehicle-mounted Ethernet switch. A second data exchange unit is configured to exchange second communication data between the plurality of microprocessors in the second DDS communication area through the vehicle-mounted Ethernet switch.

7. The apparatus of claim 5, wherein, Before determining whether the service request meets the first preset forwarding condition based on the service identification value and / or the notification class identification value, the determining module is further configured to: receive a first microcontroller globally unique identifier, a first microcontroller service request identification value and a first microcontroller notification class identification value sent by the first microcontroller; receive a first microprocessor globally unique identifier, a first microprocessor service request identification value and a first microprocessor notification class identification value sent by the first microprocessor; establish a gateway forwarding routing table according to the first microcontroller globally unique identifier, the first microcontroller service request identification value, the first microcontroller notification class identification value, the first microprocessor globally unique identifier, the first microprocessor service request identification value and the first microprocessor notification class identification value.

8. The apparatus of claim 7, wherein, Before determining whether the service request meets the first preset forwarding condition based on the service identification value and / or the notification class identification value, the determining module is further configured to: receive a first microcontroller globally unique identifier, a first microcontroller service request identification value and a first microcontroller notification class identification value sent by the first microcontroller; receive a first microprocessor globally unique identifier, a first microprocessor service request identification value and a first microprocessor notification class identification value sent by the first microprocessor; update the gateway forwarding routing table based on the new microcontroller globally unique identifier, the new microcontroller service request identification value, the new microcontroller notification class identification value, the new microprocessor globally unique identifier, the new microprocessor service request identification value and the new microprocessor notification class identification value.

9. An electronic device, comprising: comprising: a memory, a processor and a computer program stored in the memory and executable on the processor, the processor executing the program to implement the interaction method of the DDS gateway according to any one of claims 1-4.

10. A computer-readable storage medium having stored thereon a computer program, characterized in that, The program is executed by the processor to implement the interaction method of the DDS gateway according to any one of claims 1-4.

Images