DDS and TSN automated integrated configuration system and method

Abstract

The present invention relates to a DDS and TSN automated integrated configuration system and method, comprising an application layer, a control layer, and a data layer. The application layer includes DDS publishers and subscribers, the control layer includes a DDS server and a TSN controller, and the data layer includes a TSN switch deployed in an end system and network on which the DDS application is deployed. The TSN controller establishes a connection with the DDS server, and the DDS server sends collected information to the TSN controller via the connection to request reserved time slots for network resources. The TSN controller outputs an L2 forwarding table, a gating list, and a publishing time that meet multicast transmission requirements through a routing scheduling algorithm. The L2 forwarding table and gating list are sent to the TSN switch for configuration, and the publishing time is returned to the DDS server as a response to the request. The DDS server dynamically configures the time when the publisher starts sending data. Compared with the prior art, the present invention effectively reduces the integration complexity of the two while ensuring the real-time transmission of DDS key task flows.

Description

Technical Field

[0001] The present invention relates to the field of communication technologies, and in particular to a DDS and TSN automated integrated configuration system and method. Background Art

[0002] Data Distribution Service (DDS) is a data-centric communication middleware that provides dynamic publish and subscribe functionality, facilitating efficient and scalable data distribution in distributed real-time systems. DDS supports multiple Quality of Service (QoS) policies, such as reliability, persistence, and real-time performance, to meet the needs of diverse application scenarios. These features make DDS an ideal choice for real-time data communication and distribution.

[0003] Time-Sensitive Networking (TSN), as an underlying network technology, provides mechanisms such as clock synchronization and traffic scheduling, effectively guaranteeing bandwidth and latency requirements for data transmission. Therefore, using TSN as the underlying transmission mechanism for DDS can provide deterministic data transmission for critical tasks in the system. DDS and TSN are two independent protocols proposed and maintained by different organizations. Integrating them to achieve real-time, reliable data communication currently presents the following challenges:

[0004] 1) The time-aware scheduling mechanism in TSN requires precise time windows to control message forwarding. Therefore, the timing of DDS data releases must be controlled to align with the TSN transmission window. However, standard DDS uses asynchronous transmission and lacks time awareness.

[0005] 2) DDS typically uses unicast to send data packets, with the destination MAC address in the packet being the MAC address of the subscriber's end system. TSN switches must parse the received data packets to obtain the IP address and port number in order to identify the DDS data stream. This approach reduces processing efficiency and hinders TSN's deterministic transmission of DDS packets.

[0006] 3) The TSN system needs to accurately obtain information about DDS deployment, traffic flow, and QoS to ensure that DDS messages are correctly processed at the data link layer to meet the needs of real-time data transmission. However, there is currently no mechanism for autonomous interaction between DDS and TSN, requiring manual configuration of both DDS and TSN.

[0007] 4) The integration of DDS and TSN lacks a method to automatically complete the entire process, from sensing transmission needs to calculating routing and scheduling, and finally configuring peer nodes and switches. Manual static configuration would be a huge workload and undermine the scalability of DDS, making it unable to meet transmission requirements under dynamic conditions. Summary of the Invention

[0008] The purpose of the present invention is to overcome the defects of the above-mentioned existing technologies and provide a DDS and TSN automated integrated configuration system and method. Through automated traffic sensing, calculation and configuration, it realizes integration with the TSN system before DDS releases data, effectively reducing the integration complexity of the two while ensuring the real-time transmission of DDS critical task streams.

[0009] The purpose of the present invention can be achieved by the following technical solutions:

[0010] According to a first aspect of the present invention, a DDS and TSN automated integrated configuration system is provided, comprising an application layer, a control layer, and a data layer. The application layer includes DDS publishers and subscribers, the control layer includes a DDS server as a centralized user configuration module and a TSN controller as a centralized network configuration module, and the data layer includes TSN switches deployed in end systems and networks on which DDS applications are deployed.

[0011] The TSN controller establishes a connection with the DDS server, and the DDS server sends the collected information to the TSN controller through the connection to request a reserved transmission time slot of network resources;

[0012] The TSN controller outputs an L2 forwarding table, a gating list, and a publishing schedule that meet multicast transmission requirements through a routing scheduling algorithm. The L2 forwarding table and the gating list are sent to the TSN switch for configuration, and the publishing schedule is sent back to the DDS server as a response to the request. The DDS server dynamically configures the time when the publisher starts sending data.

[0013] The TSN switch is used to forward the multicast DDS message according to the locally configured L2 forwarding table and gating list.

[0014] According to a second aspect of the present invention, a method for automated integrated configuration of DDS and TSN is provided, applying the above-mentioned system, the method comprising:

[0015] After the DDS server discovers a new topic, it assigns it a dedicated multicast locator for subsequent data transmission;

[0016] The DDS server extracts the DDS stream information from the discovery message sent by the DDS client and sends the DDS stream information to the TSN controller to request dynamic configuration;

[0017] After receiving the request from the DDS server, the TSN controller generates TSN flow information based on the global network topology information and DDS flow information, and inputs the TSN flow information into the routing scheduling algorithm. The routing scheduling algorithm outputs the L2 forwarding table for TSN path control, the gating list, and the publishing schedule for the DDS publisher to start sending data. The publishing schedule is then transmitted to the DDS server as a reply, and the L2 forwarding table and gating list are sent to the TSN switch.

[0018] After receiving the reply from the TSN controller, the DDS server extracts the sending time of each topic and forwards the sending time to the corresponding DDS publisher via a discovery message;

[0019] After receiving the discovery message with the publishing start time set from the DDS server, the DDS publisher completes the publishing configuration of the local publishing time and enters the waiting state. It starts to send data periodically after the configured time arrives.

[0020] After receiving the configuration message containing the YANG model, the TSN switch completes the dynamic configuration of the local L2 forwarding table and gating list based on the extracted configuration information.

[0021] Preferably, based on the client-server discovery mode, the discovery mechanism of DDS is used to collect user-network interface implementation information, and calculate the forwarding path and the reserved transmission time slot on the path.

[0022] Preferably, after discovering a new topic, the DDS server automatically allocates a dedicated multicast IP address for each topic through a multicast address translation mechanism. The multicast IP address is automatically converted into a multicast MAC address according to the IP to MAC conversion rule when passing through the network card.

[0023] Preferably, during the subsequent data transmission process, the TSN switch uses VLAN tags and multicast MAC addresses to identify the DDS data stream, thereby completing the forwarding and scheduling of Ethernet frames carrying mission-critical data;

[0024] The VLAN tag in the Ethernet frame includes the VLAN ID set by the DDS user through VLANQoS and the transmission priority information of the TransportPriorityQoS setting topic.

[0025] Preferably, the DDS server extracts DDS stream information including unicast locator information of DDS publishers and subscribers, and QoS information that can represent DDS stream attributes and transmission requirements from the discovery message sent by the DDS client, maps the extracted structural stream information into a DDS stream information structure, and sends it to the TSN controller.

[0026] Preferably, the QoS information that can represent the DDS flow attributes and transmission requirements is encapsulated in the parameter list of the outgoing message;

[0027] The QoS information that can represent the DDS flow attributes and transmission requirements includes the publisher's data publishing cycle, data transmission priority, data payload size, the earliest time the data is sent in a cycle, the latest time the data is sent in a cycle, the jitter between the actual time the data is sent and the specified time, the time when the publisher starts sending data, the VLAN used when the data is transmitted, and the maximum delay allowed from data sending to data receiving.

[0028] Preferably, after receiving the publishing schedule, the DDS server indexes the discovery message data of the corresponding publisher in the discovery database according to its topic, and fills the publishing time in the received json file into the member corresponding to the time when the publisher starts sending data in the discovery message, and then sends the discovery message back to the corresponding publisher to configure the start publishing time.

[0029] Preferably, the TSN controller stores the L2 forwarding table and the gating list as a YANG model, and transmits them to the TSN switch in XML format via a TCP / IP connection;

[0030] The YANG model of the L2 forwarding table includes the index number, destination MAC address, source port, VLAN ID, and destination port information required to configure an item in the routing table;

[0031] The YANG model of the gate list includes the ports required to configure the time-aware shaper on the TSN switch and the index, duration, and gated switch status information of each GCL on the port.

[0032] Preferably, the method further includes: explicitly controlling the forwarding behavior of multicast frames when passing through the TSN switch through a multicast spanning tree, wherein the multicast tree takes the node where the publisher is located as the root node, passes through the internal nodes representing the TSN switch in the middle, and finally reaches the leaf nodes where all subscribers are located; the TSN controller calculates a multicast tree that meets the requirements through a routing scheduling algorithm, and then converts the multicast tree into a configuration of an L2 forwarding table and sends it to the TSN switch.

[0033] Compared with the prior art, the present invention has the following beneficial effects:

[0034] 1) Based on a software-defined networking model, this paper proposes a system and method for automatic integration and configuration of DDS and TSN, which can be used in various scenarios such as the Internet and industry. This architecture can realize automatic DDS traffic perception, forwarding and scheduling calculation, and TSN system configuration before DDS transmits data, solving the problems of low efficiency, poor flexibility, and complex configuration of manual integration of DDS and TSN.

[0035] 2) The present invention uses a centralized client-server discovery model and a DDS server as a centralized user configuration module to automatically collect DDS transmission demand information. This automatic collection mechanism fully utilizes the dynamic discovery mechanism of DDS itself. The DDS server can extract DDS traffic information by parsing the received discovery messages, eliminating the need to develop a dedicated user-network interaction protocol and avoiding a significant increase in the amount of protocol stack code.

[0036] 3) The present invention solves the problem of TSN system's difficulty in identifying DDS data streams by using a multicast mechanism to transmit DDS data. TSN can identify DDS data streams only by relying on VLAN and dedicated multicast MAC addresses in the data link layer, effectively reducing the difficulty of integration.

[0037] 4) The present invention makes full use of the extensible feature of parameter list members in RTPS messages, and expresses traffic attributes and transmission requirements to the DDS server by defining a series of DDS QoS policies and encapsulating them into the parameter list in the discovery message during the discovery message construction phase.

[0038] 5) The present invention implements dynamic configuration of TSN switches by sending messages containing YANG model configuration information, ensuring the reliability and efficiency of the configuration process and solving the problem of complex manual configuration.

[0039] 6) The present invention realizes dynamic interaction between DDS and TSN by establishing a request-response mechanism between the DDS server and the TSN controller, integrating the two independent protocols into one.

[0040] 7) The present invention adopts the time-aware publishing mechanism of the DDS publisher, and solves the problem of aligning the DDS issuance time with the scheduling time window reserved in TSN by controlling the publishing time. BRIEF DESCRIPTION OF THE DRAWINGS

[0041] Figure 1 Configuring an architecture for automated integration of DDS and TSN based on software-defined networking;

[0042] Figure 2 Flowchart for automating the integration of DDS and TSN;

[0043] Figure 3 Schematic diagram of DDS stream identification and conversion mechanism;

[0044] Figure 4 This is a diagram of DDS flow information collection based on discovery messages;

[0045] Figure 5 This is a diagram of the interaction between the DDS Server and the TSN controller;

[0046] Figure 6 Schematic diagram of the multicast spanning tree;

[0047] Figure 7 YANG model for configuring L2 forwarding table;

[0048] Figure 8 To configure the gate list YANG model;

[0049] Figure 9 Configure the flow chart for DDS publishing moments. DETAILED DESCRIPTION

[0050] The following will clearly and completely describe the technical solutions in the embodiments of the present invention in conjunction with the accompanying drawings. Obviously, the described embodiments are part of the embodiments of the present invention, not all of them. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making creative efforts should fall within the scope of protection of the present invention.

[0051] Example

[0052] This embodiment proposes a DDS and TSN automated integrated configuration system based on a centralized software-defined network model. Figure 1 The system consists of three parts: the application layer, the control layer, and the data layer. The application layer includes the DDS publisher and subscriber, the control layer includes the centralized user configuration module and the centralized network configuration module, and the data layer includes the end systems where the DDS application is deployed and the TSN switches in the network.

[0053] The functions of each part of the architecture are as follows:

[0054] The DDS Client application is responsible for publishing and subscribing to user data. It needs to periodically send discovery messages containing its own information to the DDS Server and receive discovery messages from the DDS Server.

[0055] As a centralized user configuration module, DDS Server is responsible for the interaction between DDS and TSN systems. It completes the three major functions of multicast transmission address conversion, traffic information collection and release time configuration by collecting, processing and forwarding discovery messages.

[0056] As a centralized network configuration module, the TSN controller is responsible for routing and scheduling calculations. Based on the calculation results, it generates the L2 forwarding table, gating list, and release schedule. It also completes the configuration of DDS through the northbound interface in the form of sending messages and completes the configuration of TSN switches through the southbound interface.

[0057] The TSN switch is responsible for forwarding and processing multicast DDS messages according to the locally configured L2 forwarding table and gating list to meet the DDS requirement for bounded latency.

[0058] Next, based on the above-mentioned DDS and TSN automatic integration configuration architecture, this embodiment provides a method for DDS and TSN automatic integration configuration, such as Figure 2 Shown, including:

[0059] S1. After discovering a new topic, the DDS Server assigns it a dedicated multicast locator for subsequent data transmission. DDS publishers use the multicast address specified in this multicast locator to send data, and DDS subscribers listen for data at this multicast address. The purpose of multicast address conversion is to decouple the destination MAC address in the DDS data packet from the MAC address of the subscriber's end system. The TSN system can identify DDS flows based on the destination MAC address in the message, enabling path control and scheduling.

[0060] Figure 3 Schematic diagram of the DDS stream identification conversion mechanism.

[0061] When critical DDS data is encapsulated into frames and transmitted over the Layer 2 network, TSN must be able to identify these flows with deterministic transmission requirements before it can perform path control and real-time scheduling. To enable TSN to efficiently identify DDS streams, the present invention uses a DDS multicast mechanism to convert DDS streams so that they can be identified. The present invention uses a combination of the VLAN tag and the multicast MAC address in the Ethernet frame to identify DDS data streams under different topics.

[0062] DDS users can set VLAN tags using VLANQoS to set the VLAN ID and the topic's transmission priority using TransportPriorityQoS. They also need to pre-configure the host's network interface card's priority mapping rules. When DDS data is sent through the network interface card, the configured VLAN ID is automatically added, and the transmission priority in TransportPriorityQoS is mapped to the VLAN PCP field based on the priority mapping rules.

[0063] The addition of multicast MAC addresses is the core of the DDS stream identification mechanism, and it requires the cooperation of the DDS Server to complete. DDS adopts unicast mode for data transmission by default, and the destination IP and MAC address in the DDS message are the IP and MAC address of the host network card where the subscriber is located. However, this destination address that is tightly coupled with the network card cannot uniquely identify a certain DDS data stream, and the unicast transmission mode will lead to a decrease in efficiency under one-to-many conditions. For this reason, the present invention uses a DDS multicast transmission mechanism. The DDS Server will automatically assign a dedicated multicast IP address to each Topic. When passing through the network card, the multicast IP address will be automatically converted to a multicast MAC address according to the IP to MAC conversion rules. In this way, the TSN switch can identify the DDS stream based solely on the information at the data link layer, without the need for higher-level message parsing.

[0064] S2. After receiving the discovery message sent by the DDS Client, the DDS Server extracts the Unicast locator information of the DDS publisher and subscriber, as well as the QoS information that can represent the DDS stream attributes and transmission requirements, and maps this information into the DDS stream information structure. The DDS stream information collection based on the discovery message is shown as follows: Figure 4 shown.

[0065] When using TSN, in order to achieve deterministic transmission of critical data streams, it is necessary to reserve a suitable forwarding path and the transmission time slot on the path through calculation before transmission. Therefore, before configuring the TSN system, it is necessary to collect information such as the associated Topic, source node, destination node, cycle, VLAN ID, priority, load size, offset and jitter, maximum allowed delay, multicast transmission address, etc. of the DDS data stream. The present invention adopts the Client-Server (client-server) discovery mode and innovatively uses the DDS Server as the CUC, so that the discovery mechanism of DDS can be used as the user-network interface in the centralized configuration model to achieve the purpose of information collection.

[0066] The following QoS parameters are defined for DDS users to set application layer data attributes and transmission requirements:

[0067] (1) Deadline QoS

[0068] Parameter Id Parameter members Parameter length Parameter meaning 0x0023 period 8 bytes Indicates the period during which the publisher publishes data

[0069] (2)TransportPriorityQoS

[0070] Parameter Id Parameter members Parameter length Parameter meaning 0x0049 priority 8 bytes Indicates the priority of data during transmission

[0071] (3)PayloadQoS

[0072] Parameter Id Parameter members Parameter length Parameter meaning 0x8007 payload 8 bytes Indicates the payload size of the data

[0073] (4)TimeAwareQoS

[0074]

[0075] (5) VLAN QoS

[0076] Parameter Id Parameter members Parameter length Parameter meaning 0x8009 id 4 bytes Indicates the VLAN used when transmitting data

[0077] (5)LatencyBudgetQoS

[0078]

[0079] The QoS described above will be encapsulated into the ParameterList part of the discovery message during the discovery phase of the DDS Client. After receiving the discovery message about the DataWriter, the DDS Server's EDPPUBListener will deserialize and extract the WriterProxyData from it, which contains the associated topic, the IP address of the host where it is located, and various QoS. EDPPUBListener will use the topic as an index, store the unicast locator in the source IP, and then map the various QoS of the DataWriter to various attributes of the stream and store them in the DDSStreamInfo. EDPSUBListener is responsible for collecting the IP address of the host where the DataReader is located and adding it to the destination IP. In addition, because the multicast transmission mechanism is used, the allocated multicast address also needs to be stored.

[0080] After obtaining the DDS stream information, S3 and DDS Server store them in a json format file and send the json file to the TSN controller via TCP / IP connection to request dynamic configuration. Figure 5 Figure 2 shows the interaction between the DDS Server and the TSN controller.

[0081] S4. After receiving the request from the DDS Server, the TSN controller generates TSN stream information based on the global network topology and DDS stream information, and then inputs the TSN stream into the routing and scheduling algorithms. If the scheduling is successful, the routing algorithm will output the L2 forwarding table for TSN path control, and the scheduling algorithm will output the gating list and the schedule for the DDS publisher to start sending data. The TSN controller will transmit the publishing schedule to the DDS Server in the form of a JSON file via the TCP / IP connection previously established with the DDS Server in response. For the L2 forwarding table and gating list, the TSN controller stores them as YANG models and transmits them to the TSN switch in the form of XML via the TCP / IP connection.

[0082] During the TSN stream generation process, the TSN controller needs to map the source IP address and destination IP address in the DDS stream information to nodes in the network based on the network topology information.

[0083] In order to solve the forwarding problem of multicast streams, this embodiment explicitly controls the forwarding behavior of multicast frames when they pass through switches by building a multicast spanning tree. Figure 6 As shown in the figure, a multicast tree consists of several nodes, each of which stores its parent and child nodes, forming a linked tree structure. The multicast tree begins with the publisher's node as the root, passes through internal nodes representing switches, and ultimately reaches the leaves where all subscribers reside. The TSN controller's routing algorithm calculates a multicast tree that meets the requirements. It then converts this multicast tree into an L2 forwarding table configuration and sends it to the switch. This allows packets to enter the switch through one port and be transmitted from the switch through one or more ports configured in the forwarding table.

[0084] like Figure 7 As shown in Figure 1, the YANG model of the L2 forwarding table contains the index number, destination MAC address, source port, VLAN ID, and destination port information required to configure an entry in the routing table.

[0085] like Figure 8 As shown in Figure 2, the YANG model of the gate list contains the ports required to configure the time-aware shaper on the TSN switch, as well as the index, duration, and gated on / off status information of each GCL on the port.

[0086] S5. After receiving the response from the TSN controller, the DDS Server extracts the sending time of each Topic and forwards the time to the corresponding DDS publisher through a discovery message, thereby completing the time configuration for the DDS publisher to start sending data.

[0087] After receiving the configuration about the publishing time, the DDS Server will index the discovery message data of the corresponding publisher in the DiscoveryDatabase according to its Topic, and fill the publishing time in the received JSON file into the scheduled transmit offset member of TimeAwareQoS in the discovery message. Then, it will send the discovery message back to the corresponding publisher to configure its start publishing time.

[0088] S6. After receiving the discovery message with the publishing start time set from the DDS Server, the DDS publisher completes the publishing configuration of the local publishing time and enters the waiting state. It starts to send data periodically after the configured time arrives.

[0089] like Figure 9 As shown, upon receiving a discovery message, the publisher filters the GUID in the discovery message. If it matches the local GUID, the publisher proceeds to configure the publishing time. The publisher's PubListener calls the on_transmit_offset_configuration() method, sets the firstConfigurated_ flag, and extracts the scheduled transmit offset from the TimeAwareQoS to set the start_point_.

[0090] This embodiment adds a conditional judgment before the publisher sends data to realize the time perception capability of the DDS publisher. If the firstConfigurated_ flag is true and the current time is greater than the start_point_, the publisher will start sending data.

[0091] After receiving the configuration message containing the YANG model, the S7 and TSN switches extract the configuration information from it and complete the dynamic configuration of the local L2 forwarding table and gating list.

[0092] S8. At this point, the entire automatic integration and configuration of DDS and TSN before data transmission is completed. The DDS publisher will start sending data periodically at the required time, and the messages entering TSN will be forwarded and scheduled according to the pre-configuration to ensure that DDS data reaches the DDS subscriber in real time.

[0093] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in the present invention, and such modifications or substitutions are intended to be within the scope of protection of the present invention. Therefore, the scope of protection of the present invention shall be subject to the scope of protection of the claims.

Claims

1. A DDS and TSN automated integration configuration method, characterized in that: An automated integrated configuration system using DDS and TSN, comprising an application layer, a control layer, and a data layer. The application layer includes DDS publishers and subscribers, the control layer includes a DDS server as a centralized user configuration module and a TSN controller as a centralized network configuration module, and the data layer includes TSN switches deployed in end systems and networks on which DDS applications are deployed. The method comprises: After discovering a new topic, the DDS server assigns it a dedicated multicast locator for subsequent data transmission. Through the multicast address translation mechanism, a dedicated multicast IP address is automatically assigned to each topic. This multicast IP address is automatically converted to a multicast MAC address according to the IP-to-MAC conversion rules when passing through the network card. During the subsequent data transmission process, the TSN switch uses VLAN tags and multicast MAC addresses to identify the DDS data stream, thereby completing the forwarding and scheduling of Ethernet frames carrying mission-critical data. The VLAN tag in the Ethernet frame includes the VLAN ID set by the DDS user through VLANQoS and the transmission priority information of the topic set by TransportPriorityQoS. The DDS server extracts DDS flow information from the discovery message sent by the DDS client and sends it to the TSN controller to request dynamic configuration and reserved transmission time slots for network resources. The DDS flow information includes unicast locator information for the DDS publisher and subscriber, as well as QoS information that can represent DDS flow attributes and transmission requirements. The dynamic configuration is the L2 forwarding table and gating list on the TSN switch, as well as the configuration of the publishing start time on the DDS publisher. After receiving the request from the DDS server, the TSN controller generates TSN flow information based on the global network topology information and DDS flow information, and inputs the TSN flow information into the routing scheduling algorithm. The routing scheduling algorithm outputs the L2 forwarding table for TSN path control, the gating list, and the publishing schedule for the DDS publisher to start sending data. The publishing schedule is then transmitted to the DDS server as a reply, and the L2 forwarding table and gating list are sent to the TSN switch. After receiving the reply from the TSN controller, the DDS server extracts the start publishing time of each topic and forwards the start publishing time to the corresponding DDS publisher via a discovery message; After receiving the discovery message with the publishing start time set from the DDS server, the DDS publisher completes the publishing configuration of the local publishing time and enters the waiting state. It starts to send data periodically after the configured time arrives. After receiving the configuration message containing the YANG model, the TSN switch completes the dynamic configuration of the local L2 forwarding table and gating list based on the extracted configuration information.

2. The method according to claim 1, characterized in that Based on the client-server discovery model, the DDS discovery mechanism is used as the user-network interface to automatically collect DDS stream transmission information and calculate the forwarding path and the reserved transmission time slot on the path.

3. The method according to claim 1, characterized in that The DDS server extracts DDS stream information from the discovery message sent by the DDS client, including the unicast locator information of the DDS publisher and subscriber, and QoS information that can represent the DDS stream attributes and transmission requirements. After mapping the extracted structured stream information into a DDS stream information structure, it sends it to the TSN controller.

4. The method according to claim 3, characterized in that During the discovery phase of the DDS client, QoS information that represents the DDS flow attributes and transmission requirements is encapsulated into the parameter list of the discovery message. The QoS information that can represent the DDS flow attributes and transmission requirements includes the publisher's data publishing cycle, data transmission priority, data payload size, the earliest time the data is sent in a cycle, the latest time the data is sent in a cycle, the jitter between the actual time the data is sent and the specified time, the time when the publisher starts sending data, the VLAN used when the data is transmitted, and the maximum delay allowed from data sending to data receiving.

5. The method according to claim 4, characterized in that After receiving the publishing schedule, the DDS server indexes the discovery message data of the corresponding publisher in the discovery database according to its topic, and fills the publishing time in the received json file into the member corresponding to the time when the publisher starts sending data in the discovery message, and then sends the discovery message back to the corresponding publisher to configure the start publishing time.

6. The method according to claim 1, characterized in that The TSN controller stores the L2 forwarding table and gating table as a YANG model and transmits it to the TSN switch via a TCP / IP connection in XML format. The YANG model of the L2 forwarding table includes the index number, destination MAC address, source port, VLAN ID, and destination port information of an item in the configuration routing table; The YANG model of the gate list includes the port for configuring the time-aware shaper on the TSN switch and the index, duration, and gated switch status information of each GCL on the port.

7. The method according to claim 1, characterized in that The method also includes: explicitly controlling the forwarding behavior of multicast frames when passing through the TSN switch through a multicast tree, wherein the multicast tree has the node where the publisher is located as the root node, passes through the internal nodes representing the TSN switch in the middle, and finally reaches the leaf nodes where all subscribers are located; the TSN controller calculates a multicast tree that meets the requirements through a routing scheduling algorithm, and then converts the multicast tree into a configuration of an L2 forwarding table and sends it to the TSN switch.

Images