MQTT-based modbus network system and data transmission method

Abstract

An MQTT-based Modbus network system and a data transmission method. The MQTT-based Modbus network system comprises: a plurality of master apparatuses, a plurality of slave apparatuses, master connectors connected to the plurality of master apparatuses by means of a Modbus protocol, slave connectors connected to the plurality of slave apparatuses by means of the Modbus protocol, and an MQTT mediator connected to the master connectors and the slave connectors by means of an MQTT protocol. The master connectors publish request information to the MQTT mediator on the basis of requests from the plurality of master apparatuses, and manage response information received for the request information. On the basis of an update status of sensing data from the plurality of slave apparatuses or on the basis of the request information from the master connectors, the slave connectors transfer the sensing data from the plurality of slave apparatuses by means of the MQTT mediator or respond to one or more of the plurality of master apparatuses.

Description

MQTT-based Modbus network system and data transmission method TECHNICAL FIELD

[0001] The present application relates to a Modbus network, in particular to a Modbus network implemented in combination with MQTT, and further relates to an MQTT-based Modbus network system and data transmission method. BACKGROUND

[0002] The existing Modbus network architecture mainly uses a gateway to obtain device data through a Modbus protocol, and then labels the data and drops it into a data hub.

[0003] A general Modbus network architecture can include a master device (e.g., a data collector) in a Modbus network, slave devices, and a remote server. The master device can connect multiple slave devices through the same or different protocols, and connect the remote server through TCP / IP.

[0004] When the master device transmits a request (first) to one of the slave devices, but does not receive a response within a timeout, the master device transmits a request (second) to the same slave device again. At this time, the slave device can send a response to the first request or a response to the second request. In the standard protocol of Modbus, only the data length is known, and the register address is not known, so when the master device receives the response, a data correspondence error can occur

[0005] In view of the above problems, Modbus protocol is generally only applied to near-end communication (i.e., the transmission of requests and responses only takes 10ms-500ms, and the timeout interval of two requests is about 1 second), and is difficult to be applied to an environment with a longer delay time (e.g., the Internet, the connection often exceeds 500ms or even 1 second). In addition, because the packets transmitted through the Modbus protocol are transmitted in clear code, if the Modbus protocol is applied to the Internet, the information security problem also needs to be considered.

[0006] SUMMARY

[0007] The present application provides an MQTT-based Modbus network system and data transmission method, which uses the characteristics of the MQTT protocol to cascade multiple Modbus networks, so that the Modbus protocol can be applied to the Internet with a longer delay time, and the security of the packet is improved.

[0008] In one embodiment, the MQTT-based Modbus network system comprises:

[0009] a plurality of first master devices, each of the first master devices is configured to issue a request;

[0010] a plurality of first slave devices, each of the first slave devices is configured to generate a sensing data;

[0011] an MQTT broker;

[0012] a first master connector connecting the plurality of first master devices via Modbus protocol and connecting the MQTT broker via MQTT protocol, the first master connector is configured to publish a request information to the MQTT broker according to the request of the plurality of first master devices, and manage a response information to the request information; and

[0013] a first slave connector connecting the plurality of first slave devices via Modbus protocol and connecting the MQTT broker via MQTT protocol, the slave connector is configured to:

[0014] transmit the sensing data of the plurality of first slave devices via the MQTT broker according to an update status of the sensing data of the plurality of first slave devices, or respond to one or more of the plurality of first master devices via the MQTT broker according to the request information of the first master connector.

[0015] In one embodiment, the data transmission method is applied to the network system, and comprises the following steps:

[0016] a) issuing a request by each of the plurality of first master devices, and generating a sensing data by each of the plurality of first slave devices;

[0017] b) publishing a request information to the MQTT broker by the first master connector based on the request of the plurality of first master devices;

[0018] c) transmitting the request information to the first slave connector by the MQTT broker; and

[0019] d) transmitting the sensing data of the plurality of first slave devices via the MQTT broker according to an update status of the sensing data of the plurality of first slave devices by the first slave connector, or responding to one or more of the plurality of first master devices via the MQTT broker according to the request information of the first master connector.

[0020] Compared with the related art, the application uses the MQTT adjuster, the master connector and the slave connector to concatenate the Modbus network through the MQTT protocol, and applies the custom MQTT topic structure, so that the Modbus protocol can be applied on the Internet network, thereby expanding the application range of the Modbus protocol. BRIEF DESCRIPTION OF DRAWINGS

[0021] Fig. 1 is a first embodiment of a connection diagram of a network system of the application;

[0022] Fig. 2 is a topic structure diagram of MQTT of the application;

[0023] Fig. 3 is a data transmission diagram in a bridge mode of the application;

[0024] Fig. 4 is a data transmission diagram in a tag mode of the application;

[0025] Fig. 5 is a first flowchart of a data transmission method of the application;

[0026] Fig. 6 is a timing diagram in the bridge mode of the application;

[0027] Fig. 7 is a second flowchart of a data transmission method of the application;

[0028] Fig. 8 is a third flowchart of a data transmission method of the application;

[0029] Fig. 9 is a second embodiment of a network connection diagram of the application.

[0030] REFERENCE SIGNS

[0031] 11: data collector

[0032] 12: device

[0033] 13: remote server

[0034] 21: master device

[0035] 211: first master device

[0036] 212: second master device

[0037] 213: third master device

[0038] 22: slave device

[0039] 3: master connector

[0040] 30: master cache

[0041] 4: slave connector

[0042] 40: slave cache

[0043] 5: MQTT regulator

[0044] 51: theme structure

[0045] 511: factory information

[0046] 512: network information

[0047] 513: mode information

[0048] 514: slave device identity information

[0049] 515: master device identity information

[0050] 516: sequence information

[0051] 6: monitoring connector

[0052] 61: management unit

[0053] S61-S64: transmission steps

[0054] S711-S718, S721-S728: transmission steps

[0055] S81-S86: transmission steps

[0056] S91-S95: transmission steps DETAILED DESCRIPTION

[0057] The present application discloses a Modbus network system based on MQTT (Message Queuing Telemetry Transport) (hereinafter referred to as network system in the specification), and a data transmission method used by the network system. The information content of the MQTT protocol is very simple, which is very suitable for being applied to Internet of Things (IoT) devices to help the Internet of Things devices transmit data to cloud servers for analysis, storage and use. The information of the MQTT protocol includes header, topic and payload, and the participants of the MQTT protocol include publisher as the information sender, broker as the information intermediary, and subscriber as the information receiver. The present application uses the characteristics of the MQTT protocol to overcome the shortcomings of the Modbus protocol, so that the Modbus protocol can be effectively applied to the Internet network with longer delay time, and the data security of the Modbus protocol is strengthened.

[0058] Referring to FIG. 1, a first embodiment of a connection diagram of a network system of the present application is shown. The network system of the present application comprises a plurality of master devices 21, a plurality of slave devices 22, at least one MQTT broker 5, at least one master connector 3, and at least one slave connector 4. The plurality of master devices 21 are master devices under Modbus protocol, such as data collectors, for issuing requests in a Modbus network. The plurality of slave devices 22 are slave devices under Modbus protocol, such as various sensors or programmable logic controllers (PLCs), for generating various sensing data or test data and responding to requests issued by one or more master devices 21.

[0059] The master connector 3 connects the plurality of master devices 21 through Modbus protocol, and the slave connector 4 connects the plurality of slave devices 22 through Modbus protocol. In other words, the master connector 3 and the slave connector 4 respectively communicate with Modbus devices through Modbus protocol to transmit requests and responses.

[0060] On the other hand, the master connector 3 and the slave connector 4 respectively connect the MQTT broker 5 through MQTT protocol, and can act as publishers and subscribers in MQTT protocol respectively according to current tasks. For example, when one of the plurality of master devices 21 issues a request to a target slave device, the master connector 3 generates request information in accordance with the request and publishes the request information to the MQTT broker 5, and the slave connector 4 connected to the target slave device can automatically obtain the request information from the MQTT broker 5. In this example, the request information published by the master connector 3 contains a specific topic, and the slave connector 4 subscribes to the topic. Therefore, the master connector 3 is a publisher in MQTT protocol, and the slave connector 4 is a subscriber in MQTT protocol.

[0061] For example, after the slave connector 4 inquires the target slave device according to the content of the request information and obtains the sensing data responded by the slave device, the slave connector 4 can generate response information according to the sensing data, and publish the response information to the MQTT broker 5. The master connector 3 can automatically obtain the response information from the MQTT broker 5, and manage the response information (e.g., reply to the master device 21 at an appropriate time point, or ignore the reply which has exceeded the time limit (in this case, the master device 21 has sent a new request)). In this example, the response information published by the slave connector 4 contains the same specific topic, and the master connector 3 subscribes to this topic. Therefore, the slave connector 4 is the publisher in the MQTT protocol, and the master connector 3 is the subscriber in the MQTT protocol.

[0062] In one embodiment, the user needs to set the connection parameters of the MQTT for the master connector 3, the slave connector 4 and the MQTT broker 5 when establishing the network system, for example, set the subscription topics of the master connector 3 and the slave connector 4. Then, the user sets the numbers of the master devices 21 and the slave devices 22, connects the master devices 21 to the master connector 3 and connects the slave devices 22 to the slave connector 4, thereby completing the basic configuration of the network system. In another embodiment, the user only needs to set the network group when establishing the network system, and other information is automatically brought in by the connectors (i.e., the master connector 3 and the slave connector 4). When there are multiple slave connectors 4, the white list or the black list of the slave connector 4 can be additionally set for each slave connector 4 to avoid receiving and processing unnecessary requests.

[0063] As shown in FIG. 1, the network system can include multiple slave connectors 4 (e.g., a first slave connector and a second slave connector), wherein the first slave connector connects one or more slave devices 22 (e.g., a first slave device), and the second slave connector connects one or more slave devices 22 (e.g., a second slave device). The first slave connector inquires the connected one or more first slave devices according to the received request and generates a response, but does not receive information sent by the second slave connector. Similarly, the second slave connector inquires the connected one or more second slave devices according to the received request and generates a response, but does not receive information sent by the first slave connector.

[0064] One of the technical features of the present application is that the master connector 3 can send request information to the slave connector 4 through two or more different modes (to be described later), and vice versa. Based on the different modes, the slave connector 4 can, after obtaining the request information: (1) transmit the sensing data of the plurality of slave devices 22 through the MQTT adjuster 5 according to the update status of the sensing data of the plurality of slave devices 22; or (2) directly respond to one or more of the plurality of master devices 21 that sent the request through the MQTT adjuster 5 according to the request information sent by the master connector 3. In the later paragraphs of this specification, the actions of the master connector 3 and the slave connector 4 in different modes will be further described.

[0065] In the present application, the master connector 3 connects the plurality of master devices 21 through the Modbus protocol, and the master devices 21 send requests directly to the master connector 3. Therefore, the master connector 3, relative to the master devices 21, is similar to the role of a slave device in a Modbus network, can receive the requests sent by the master devices 21 and respond to the requests. Similarly, the slave connector 4 connects the plurality of slave devices 22 through the Modbus protocol, and the slave devices 22 receive requests from the slave connector 4 and directly respond to the corresponding data of the request to the slave connector 4. Therefore, the slave connector 4, relative to the slave devices 22, is similar to the role of a master device in a Modbus network, can make requests to the slave devices 22 and receive response data from the slave devices 22. And, after receiving the request information issued by the master connector 3, the slave connector 4 can first schedule a plurality of request information, or schedule a plurality of requests in a request information, and transmit the request to the corresponding slave device 22 according to the content of the topic of the request information (to be described later), and receive the sensing data responded by the slave device 22.

[0066] As mentioned above, the master devices 21 send requests based on the Modbus protocol, and the slave devices 22 respond to sensing data based on the Modbus protocol. In the present application, the master connector 3, the slave connector 4 and the MQTT adjuster 5 are provided in the network system to connect a plurality of Modbus networks through the MQTT protocol, so that the problem that the Modbus protocol cannot handle longer transmission delays and cannot associate requests and responses is solved by defining topics in the MQTT protocol. It is worth mentioning that the MQTT protocol itself supports encryption of packets, so it can further solve the security problem that the Modbus protocol uses clear transmission.

[0067] Please refer to FIG. 1 and FIG. 2, wherein FIG. 2 is a schematic diagram of the topic structure of the MQTT of the present application.

[0068] As described above, the information transmitted by MQTT includes a header, a topic, and content, where the content is, for example, a request issued by the master device 21 or sensing data responded by the slave device 22. Based on the MQTT protocol, the request information published by the master connector 3 includes a specified topic (e.g., a first topic). If the slave connector 4 subscribes to the first topic from the MQTT broker 5, the slave connector 4 can automatically obtain the request information from the MQTT broker 5 when the master connector 3 publishes the request information including the first topic to the MQTT broker 5. Conversely, the slave connector 4 can generate and publish response information to the MQTT broker 5 according to the sensing data responded by the slave device 22, and the response information can also include a specified topic (e.g., a second topic). If the master connector 3 subscribes to the second topic from the MQTT broker 5, the master connector 3 can automatically obtain the response information from the MQTT broker 5 when the slave connector 4 publishes the response information including the second topic to the MQTT broker 5.

[0069] In an embodiment, the name of the topic is a string encoded by UTF-8. In this application, the topic structure 51 used by the MQTT protocol includes at least network group information, mode information (Mode) 513, slave device identity information (Slave ID) 514, and master device information. The network group information (including plant information (Plant) 511 and network information (Network) 512) describes the network location (e.g., the plant and network area) where the transmitted information is located, the mode information 513 describes the transmission mode of the information, the slave device identity information 514 describes the ID of the target slave device, and the master device information (including master device identity information (Master ID) 515 and sequence information (Sequence ID) 516) describes the information of the source master device, including the ID of the master device 21 issuing the request and the processing sequence of the request.

[0070] In an embodiment, the slave device identity information 514 is preset to use the station ID in the Modbus RTU, and the slave connector 4 can learn or set the station ID of one or more slave devices 22 connected thereto. For example, when there are two slave connectors 4 in the network system, it is possible that both of the slave connectors 4 have the same slave device 22 with the same station ID due to a setting error. In this case, masking can be performed by setting a white list or a black list. In addition, the slave connector 4 can ignore the request from the master connector 3 for a non-existent slave device 22.

[0071] It is worth mentioning that the topic subscribed by the master connector 3 can mainly include the network group and the sub-group thereof, while the topic subscribed by the slave connector 4 can mainly include the specific device and the sub-group thereof (i.e. one slave connector 4 does not need to receive the information published by other slave connectors 4). However, in other embodiments, the topic subscribed by the slave connector 4 can also include the network group and the sub-group thereof, and the information published by other slave connectors 4 can be filtered out through filtering means. Since the present application supports multi-mode operation, it is necessary to distinguish the mode. In other words, the topics subscribed by the master connector 3 and the slave connector 4 can be optimized according to the actual settings, so as to avoid receiving unnecessary information.

[0072] It is worth mentioning that the MQTT protocol supports the device to subscribe to multiple topics at the same time. Therefore, in one embodiment, the master connector 3 and the slave connector 4 can subscribe to one or more topics, respectively.

[0073] In the present application, one MQTT adjuster 5 can connect multiple master connectors 3 (e.g. a first master connector and a second master connector) and multiple slave connectors 4 (e.g. a first slave connector and a second slave connector) at the same time, and the request information sent by the master connector 3 and the response information sent by the slave connector 4 both contain topics. Through the network group information in the topic structure 51, the slave device identity information 514 and the master device information, each slave device 22 can know which master device 21 sends the request, and each master device 21 can also know which request the current received response corresponds to. In this way, the present application can use the MQTT protocol to connect multiple Modbus networks, and make the Modbus protocol applicable to the Internet network with longer delay time.

[0074] In one embodiment, in the topic structure 51 defined in the present application, the mode information 513 can include a bridge mode (Bridge) and a tag mode (Tag), wherein the bridge mode is applied to request the sensing data of the slave devices 22 belonging to the frequently changing quantity (i.e. frequently changed), and the tag mode is applied to request the sensing data of the slave devices 22 belonging to the rarely changing quantity (i.e. rarely changed), but not limited thereto.

[0075] Please refer to FIG. 3 for the data transmission diagram of the present application in the bridge mode. Specifically, when the mode information 513 in the topic of an information is the bridge mode, the master connector 3, the slave connector 4 and the MQTT adjuster 5 will transmit data according to the mode shown in FIG. 3.

[0076] In the embodiment of FIG. 3, the MQTT broker 5 connects multiple master connectors 3, one of which (e.g., the first master connector) connects the first master device 211 and the second master device 212, and another of which (e.g., the second master connector) connects the third master device 213. The MQTT broker 5 also connects one slave connector 4, which connects the slave device 22 and has an ID of 5. As shown in FIG. 3, the first master device 211 issues a request, and the master connector 3 generates corresponding request information according to the request. The request information conforms to the MQTT protocol and includes a header, a topic, and content. The topic is, for example, “Plant A / Net 1 / Bridge / 5 / master 1 / 1234”, i.e., the network group information of the topic is the first network of Plant A, the mode information 513 is the bridge mode, the slave device identity information 514 is ID: 5, the master device identity information 515 is the first master device 211, and the sequence information 516 is 1234.

[0077] In the embodiment of FIG. 3, both the master connector 3 and the slave connector 4 subscribe to the above-mentioned topic, so when the master connector 3 generates the request information according to the request of the first master device 211 and publishes the request information to the MQTT broker 5 as a publisher, the slave connector 4 can automatically obtain the request information from the MQTT broker 5 as a subscriber. After receiving the request information, the slave connector 4 can schedule the request information (e.g., the slave connector 4 can subscribe to multiple topics and receive multiple request information at the same time, so it needs to schedule multiple request information), and request sensing data from the corresponding slave device 22 (i.e., the slave device 22 with ID 5) according to the content of the request information.

[0078] When the slave connector 4 obtains the corresponding sensing data from the slave device 22 with ID 5, the slave connector can generate response information and publish the response information to the MQTT broker 5 as a publisher. At this time, since the content of the topic to which the master connector 3 subscribes includes the network group information of the slave device 22 and the slave device identity information 514, the master connector 3 can automatically obtain the response information from the MQTT broker 5 as a subscriber. Thus, the master connector 3 can respond to the request of the first master device 211 based on the sensing data in the response information.

[0079] As described above, the MQTT broker 5 can connect multiple master connectors 3 at the same time. Since the topics subscribed by each master connector 3 can be different, different master connectors 3 can receive different push notifications when the MQTT broker 5 publishes information.

[0080] The application can concatenate multiple Modbus networks through the MQTT protocol, which can be located at different endpoints, such as a branch in Asia and a branch in the United States. Although the delay time of the Internet network does not affect the association of the request and response through the definition of the topic, if the number of packets transmitted is too large, the delay of the Internet network can be as high as several seconds, and the real-time transmission of data through the bridge mode will waste a lot of unnecessary time. Therefore, for some types of data (such as sensing data belonging to small momentum), the network system of the application can use the tag mode for batch update.

[0081] Referring to FIG. 4, it is a schematic diagram of data transmission in the tag mode of the application.

[0082] In the embodiment of FIG. 4, the master connector 3 has a master cache 30, and the slave connector 4 has a slave cache 40. If the mode information 513 in the topic of the request information is the tag mode, the slave connector 4 will update the slave cache 40 according to the sensing data after requesting the sensing data from the corresponding slave device (such as ID 5) 22 according to the request information. Moreover, the slave connector 4 will periodically check the content of the slave cache 40 to determine whether the data of the slave cache 40 has changed. In the application, the slave connector 4 will generate and publish the response information to the MQTT regulator 5 based on the update status of multiple sensing data in the slave cache 40 when it is checked that the data of the slave cache 40 has changed. The master connector 3 subscribed to this topic can batch update the content of the master cache 30 based on the content of the response information after receiving the response information. Moreover, the master connector 3 will directly respond to the requests of multiple master devices 21 with the corresponding data in the master cache 30 when the requests of multiple master devices 21 are received and the sensing data corresponding to the requests exist in the master cache 30.

[0083] The Modbus protocol is based on position information when making requests and responses. Specifically, the master device 21 can request the data of a certain position of a certain slave device 22, and when the slave device 22 receives the request, it can respond to the sensing data of this position to the master device 21. For different types of slave devices 22, the data at the requested position can be large momentum data or small momentum data. The tag mode is suitable for small momentum data, and the bridge mode is suitable for large momentum data, but not limited thereto.

[0084] In an embodiment, the master connector 3 and the slave connector 4 can agree on the locations to be requested through communication, and then the master connector 3 can set the master cache 30 based on the locations, and the slave connector 4 can set the slave cache 40 based on the locations. After the locations are set, the slave connector 4 can perform local monitoring on the slave device 22 (i.e., without continuously performing handshake with the MQTT broker 5 and / or the master connector 3), continuously read the values at the locations from the slave device 22, and update the slave cache 40. In this embodiment, the slave connector 4 only generates and publishes the response information based on the update status of the sensing data in the slave cache 40 when the data in the slave cache 40 changes after the update, to perform batch update on the master cache 30 of the master connector 3.

[0085] In the tag mode, the master connector 3 does not need to immediately generate and publish the request information as long as the corresponding data in the master cache 30 exists. Also, the sensing data of the slave device 22 can remain unchanged, and thus the slave connector 4 does not need to immediately generate and publish the response information after requesting the sensing data from the slave device 22 each time. In this way, the network system of the present application can effectively reduce the transmission amount of packets, save the handshake time, and thus improve the transmission efficiency.

[0086] Referring to FIG. 5, a first flowchart of the data transmission method of the present application is shown. FIG. 5 shows the specific flow of the data transmission method of the present application, and the data transmission method is mainly applied to the network system shown in FIG. 1, the topic structure 51 shown in FIG. 2, the bridge mode shown in FIG. 3, and the tag mode shown in FIG. 4.

[0087] As shown in FIG. 5, when the network system of the present application is used, one or more of the plurality of master devices 21 in the network system can issue a request, and one or more of the plurality of slave devices 22 can generate sensing data due to normal operation (step S61). The master connector 3 connects the plurality of master devices 21 and receives the request issued by the master device 21 through the Modbus protocol (e.g., RS485 or TCP / IP). At this time, the master connector 3 generates the request information based on the request, and publishes the request information to the MQTT broker 5 as an MQTT publisher (step S62).

[0088] In the present application, the MQTT broker 5 transmits the request information published by the master connector 3 to the slave connector 4 (step S63). Specifically, the request information contains a specific topic, and the slave connector 4 subscribes to the specific topic from the MQTT broker 5. Therefore, when the master connector 3 publishes the request information containing the specific topic to the MQTT broker 5, the slave connector 4 can automatically obtain the request information from the MQTT broker 5.

[0089] When receiving the request information from the connector 4, the request information is scheduled, and the corresponding slave device 22 is inquired according to the content of the request information, and the sensing data responded by the slave device 22 is obtained. Based on the mode information 513 in the current topic being the bridge mode or the tag mode, the connector 4 transmits the sensing data of the plurality of slave devices 22 through the MQTT adjuster 5 according to the update state of the sensing data of the plurality of slave devices 22 (in the tag mode), or directly responds to one or more of the plurality of master devices 21 through the MQTT adjuster 5 according to the request information of the master connector 3 (in the bridge mode) (step S64). In other words, in the bridge mode, the connector 4 inquires the slave device 22 according to each request information and publishes the corresponding response information immediately; in the tag mode, the connector 4 only records the update state of the sensing data of the slave device 22 through the slave cache 40, and updates the master cache 30 of the master connector 3 in batches based on the update state.

[0090] Please refer to FIG. 6, which is the timing diagram of the application in the bridge mode. FIG. 6 discloses the data transmission timing of the network system in the bridge mode when the first master device 211 and the second master device 212 respectively send requests to the slave device 22.

[0091] As shown in FIG. 6, the first master device 211 first sends a request 1 to the master connector 3 (step S711). The master connector 3 generates first request information based on the request 1 and publishes the first request information to the MQTT adjuster 5 (step S712), wherein the first request information includes a first topic, network group information of the first topic records a network group where the slave device 22 is located, mode information 513 records the bridge mode, slave device identity information 514 records the ID of the slave device 22, master device identity information 515 records the ID of the first master device 211, and sequence information 516 records the order of the first master device 211 sending the request 1. Moreover, the content of the first request information is the request 1.

[0092] In this embodiment, the connector 4 subscribes to the first topic, so it can automatically obtain the first request information from the MQTT adjuster 5 (step S713). The connector 4 schedules the first request information (for example, the connector 4 receives the first request information, the second request information, the third request information, etc. at the same time), and inquires the corresponding slave device 22 according to the schedule (for example, queries the ID recorded in the slave device identity information 514) (step S714). Moreover, the slave device 22 generates a response 1 to the connector 4 (step S715).

[0093] The slave connector 4 generates and publishes first response information to the MQTT broker 5 based on the response 1 from the slave device 22 (step S716), wherein the first response information can also contain the first topic. The master connector 3 subscribes to the first topic, thus the master connector 3 can automatically obtain the first response information from the MQTT broker 5 (step S717). Then, the master connector 3 responds to the first master device 211 which sent the request 1 according to the content of the first response information (step S718).

[0094] Similarly, the second master device 212 sends a request 2 to the master connector 3 (step S721). The time when the first master device 211 sends the request 1 and the time when the second master device 212 sends the request 2 are not limited to those shown in FIG. 6. After receiving the request 2, the master connector 3 generates second request information based on the request 2 and publishes the second request information to the MQTT broker 5 (step S722), wherein the second request information contains a second topic, the network group information of the second topic records the network group where the slave device 22 is located, the mode information 513 records the bridge mode, the slave device identity information 514 records the ID of the slave device 22, the master device identity information 515 records the ID of the second master device 212, and the sequence information 516 records the sequence of the request 2 sent by the second master device 212. Moreover, the content of the second request information is the request 2. According to the definition of the topic, the slave device 22 will not be confused when responding to the request 1 and the request 2.

[0095] In this embodiment, the slave connector 4 subscribes to both the first topic and the second topic, thus the slave connector 4 can automatically obtain the second request information from the MQTT broker 5 (step S723). Then, the slave connector 4 schedules the second request information and inquires the slave device 22 according to the schedule (step S724). Moreover, the slave device 22 generates a response 2 to the slave connector 4 (step S725).

[0096] The slave connector 4 generates and publishes second response information to the MQTT broker 5 based on the response 2 from the slave device 22 (step S726), wherein the second response information can also contain the second topic. The master connector 3 subscribes to both the first topic and the second topic, thus the master connector 3 can automatically obtain the second response information from the MQTT broker 5 (step S727). Then, the master connector 3 responds to the second master device 212 which sent the request 2 according to the content of the second response information (step S728).

[0097] Please refer to FIG. 7, which is a second flowchart of the data transmission method of the present application. FIG. 7 discloses the steps related to how the master connector 3 processes and responds to the requests of multiple master devices 21 in the tag mode. Similarly, the method of FIG. 7 is applied to the network system shown in FIG. 1 and the topic structure 51 shown in FIG. 2.

[0098] First, the master connector 3 and the slave connector 4 need to complete the coordination setting and establish the corresponding cache (i.e., the master cache 30 and the slave cache 40) inside. Then, as shown in FIG. 7, the master device 21 sends a request to the master connector 3 (step S81). After receiving the request, the master connector 3 judges whether the corresponding data of the request exists in the master cache 30 (step S82), that is, the master connector 3 judges whether the request has been issued and the response from the slave connector 4 has been received. In this embodiment, after obtaining the response information issued by the slave connector 4 through subscription, the master connector 3 records the data (such as the sensing data of the target slave device) in the response information in the master cache 30. Therefore, when the corresponding data of the request issued by the master device 21 exists in the master cache 30, the master connector 3 does not issue the request information, but directly responds to the request of one or more master devices 21 according to the corresponding data in the master cache 30 (step S83).

[0099] It is worth mentioning that the master cache 30 and the slave cache 40 are not necessarily the same. Specifically, because the slave connector 4 can receive requests from different master devices 21 (in the bridge mode) or different master connectors 3 (in the tag mode), the required range can be different. In an embodiment, for the same slave connector 4, the content of the slave cache 40 should at least completely cover the content of the master cache 30 of the corresponding master connector 3.

[0100] If it is judged in step S82 that the corresponding data of the request does not exist in the master cache 30, it means that the master connector 3 has not issued the request information for this request. At this time, the master connector 3 generates and issues the request information based on the request of the master device 21 in a manner similar to the above-mentioned bridge mode (step S84). After the slave connector 4 inquires the corresponding slave device 22 based on the content of the request information and obtains the response sensing data, it can generate and issue the response information. At this time, the master connector 3 can automatically obtain the response information from the MQTT regulator 5 (step S85), and after the master connector 3 analyzes the response information, the content of the response information (such as the sensing data responded by the slave device 22) is written into the master cache 30 (step S86). Therefore, the master connector 3 can directly respond to the master device 21 that issued the request according to the content of the master cache 30 (step S83).

[0101] The bridge mode and the tag mode are used simultaneously in the step S84. For example, a request (e.g. request A) of the master connector 3 can include two request ranges of B and C or three request ranges of B, C and D, wherein the request range C belongs to the cache content of the master cache 30. At this time, if the master connector 3 issues the request A and receives a response, the cache data of C in the master cache 30 can be updated. Moreover, if the request A is within the cache range of the master cache 30, the master connector 3 can directly use the cache data in the master cache 30 to respond without issuing the request A again.

[0102] According to the above technical means, the master connector 3 does not need to issue a request to the MQTT broker 5 as long as the corresponding data exists in the master cache 30, and the efficiency of data transmission can be effectively improved.

[0103] Referring to FIG. 8, a third flowchart of the data transmission method of the present application is shown. FIG. 8 discloses the steps of how the slave connector 4 monitors the slave devices 22 locally and updates the master connector 3 in batches in the tag mode. Similarly, the method of FIG. 8 is applied to the network system of FIG. 1 and the topic structure 51 of FIG. 2.

[0104] As described above, the master connector 3 and the slave connector 4 need to complete the cooperative setting and establish the corresponding caches (i.e. the master cache 30 and the slave cache 40) internally. As described above, the tag mode is mainly applied to the sensing data of the slave devices 22 with low momentum, so that the slave connector 4 can know which data of which position of the slave devices 22 the master connector 3 wants to request after the master cache 30 and the slave cache 40 are established and set. Therefore, the plurality of storage positions in the slave cache 40 can correspond to the plurality of storage positions in the master cache 30.

[0105] As shown in FIG. 8, after receiving the request information issued by the master connector 3, the slave connector 4 requests the sensing data from the target slave device (step S91). After receiving the sensing data responded by the slave device 22, the slave connector 4 updates the sensing data in the corresponding position of the slave cache 40 (step S92).

[0106] Next, the slave connector 4 determines whether all of the slave devices 22 associated with the request have been interrogated (step S93). If not, the slave connector 4 performs steps S91 and S92 again. After all of the slave devices 22 associated with the request have been interrogated, the slave connector 4 determines whether the data in the slave cache 40 has changed (step S94). The determination can be performed once (i.e., a request issued via the bridge mode has occurred and the request covers the cache range of the slave cache 40) or periodically (i.e., the slave connector 4 periodically monitors the cache content of the slave cache 40), without limitation. In one embodiment, the slave connector 4 requests the sensed data of a specific location of the slave devices 22 and writes to a specific location in the slave cache 40. Before writing, the slave connector 4 compares the data on both sides to determine whether they are the same. If so, the data is not written to the slave cache 40 again. If not, the data is written to the slave cache 40 and a flag is set to indicate that the data has changed.

[0107] If the data in the slave cache 40 has changed, it means that the sensed data of the slave devices 22 has changed and there is a need to respond to the requesting master device 21. Therefore, upon determining that the data in the slave cache 40 has changed, the slave connector 4 generates the response information based on the update status (i.e., the changed portion) of the sensed data in the slave cache 40 and publishes the response information to the MQTT broker 5. The master cache 30 of the master connector 3 is then updated in batch by the MQTT broker 5 (step S95). Specifically, after the slave connector 4 publishes the response information, the master connector 3 automatically obtains the response information from the MQTT broker 5. The master connector 3 then updates the data in the master cache 30 in batch according to the content of the response information. After the master cache 30 is updated, the master connector 3 responds to the request of one or more master devices 21 according to the data in the updated master cache 30.

[0108] With the above technical means, the slave connector 4 can continuously monitor one or more slave devices 22 associated with the request and only publish the response information when the sensed data of the one or more slave devices 22 has changed. In this way, the efficiency of data transmission can be effectively improved.

[0109] Referring to FIG. 9, a second embodiment of the network connection of the present application is shown. In the embodiment of FIG. 9, in addition to the master connector 3, the slave connector 4, and the MQTT broker 5, the network system further includes a monitoring connector 6. As shown in FIG. 9, the monitoring connector 6 is connected to the MQTT broker 5 via the MQTT protocol and can subscribe to all topics of the MQTT broker 5.

[0110] In this embodiment, the monitoring connector 6 does not involve any request and response on the Modbus network, but is used to enable the management unit 61 of the backend to continuously monitor and view all data streams on the network. Therefore, the monitoring connector 6 can subscribe to all topics of the MQTT broker 5, that is, the monitoring connector 6 can receive all MQTT information published to the MQTT broker 5.

[0111] In other embodiments, the network system can include multiple monitoring connectors 6, each of which monitors different data. For example, a first monitoring connector can subscribe to a topic with the plant information 511 being “Plant A” and the network information 512 being “Net 1”, so that all information transmitted in the first network is automatically delivered to the first monitoring connector after being published. For another example, a second monitoring connector can subscribe to a topic with the plant information 511 being “Plant A” and the network information being “Net 2”, so that all information transmitted in the second network is automatically delivered to the second monitoring connector after being published. For another example, a third monitoring connector can subscribe to a topic with the slave device identity information 514 being “10”, so that all information related to the slave device 22 with ID 10 is automatically delivered to the third monitoring connector after being published, and so on.

[0112] In this embodiment, the monitoring connector 6 only receives information, but does not involve sending a request and responding to a request. Therefore, the monitoring connector 6 can also be used to generate a network topology, that is, to depict which networks (such as Net 1, Net 2, Net 3, etc.) are covered by the entire network system, which devices (master device 21 and slave device 22) are included in these networks, and which devices are currently performing handshake, etc. Therefore, it is beneficial for the management unit 61 of the backend to evaluate and optimize the entire network system.

[0113] In an embodiment of the present application, the master connector 3, the slave connector 4 and the monitoring connector 6 are independent electronic devices internally configured with hardware units such as processors, memories, connection ports and network connection interfaces. Through the processors and memories, the master connector 3, the slave connector 4 and the monitoring connector 6 can execute the data transmission method of the present application; through the connection ports, the master connector 3, the slave connector 4 and the monitoring connector 6 can connect the master device 21 or the slave device 22 via a wired manner (such as RS485); through the network connection interfaces, the master connector 3, the slave connector 4 and the monitoring connector 6 can connect the master device 21, the slave device 22 and the MQTT broker 5 via a wireless manner (such as TCP / IP).

[0114] In another embodiment, the master connector 3, the slave connector 4 and the monitoring connector 6 can also be implemented in software and installed on an existing hardware device (such as a router, a gateway, a master device or a slave device) in the network system. The hardware device is connected to the MQTT broker 5 through Ethernet, and connected to the master device 21 or the slave device 22 through RS485 or TCP / IP. Furthermore, the hardware device can also be a large device (such as a server) internally configured with a plurality of master devices 21 or a plurality of slave devices 22. When the hardware device is installed with the software, it can actively serve the plurality of master devices 21 or the plurality of slave devices 22 as the master connector 3 or the slave connector 4. It is worth mentioning that if the master connector 3 and the slave connector 4 of the present application are implemented using software, the user can directly set the data positions of the frequently changed data and the less changed data of the target slave device in the software. In this way, when the software is used as the master connector 3 and the slave connector 4, it can automatically determine whether the bridge mode should be used to immediately inquire and respond or the tag mode should be used to perform batch update when the data is changed according to the data positions indicated in the request.

[0115] Through the network system and the data transmission method of the present application, even if the master device and the slave device in the Modbus network communicate on the Internet network with a long delay time, the master device's request and the slave device's response can still be associated by the topic in the MQTT protocol, without causing confusion. Therefore, the application range of the Modbus network can be effectively expanded.

Claims

1. A MQTT-based Modbus network system, comprising: a plurality of first master devices, each of the first master devices being configured to issue a request; a plurality of first slave devices, each of the first slave devices being configured to generate sensing data; a MQTT adjuster; a first master connector connecting the plurality of first master devices through a Modbus protocol and connecting the MQTT adjuster through a MQTT protocol, the first master connector being configured to publish request information to the MQTT adjuster according to the requests of the plurality of first master devices and to manage response information to the request information; and a first slave connector connecting the plurality of first slave devices through a Modbus protocol and connecting the MQTT adjuster through a MQTT protocol, the first slave connector being configured to: transmit the sensing data of the plurality of first slave devices through the MQTT adjuster according to an update state of the sensing data of the plurality of first slave devices; or respond to one or more of the plurality of first master devices according to the request information of the first master connector. 2.The MQTT-based Modbus network system of claim 1, wherein the request information comprises a topic, and a topic structure used by the MQTT protocol comprises at least network group information, mode information, slave device identity information, master device identity information, and sequence information. 3.The MQTT-based Modbus network system of claim 2, wherein the mode information comprises a bridge mode and a tag mode. 4.The MQTT-based Modbus network system of claim 3, wherein the bridge mode is applied to request the sensing data of the plurality of first slave devices belonging to a high motion amount, and the tag mode is applied to request the sensing data of the plurality of first slave devices belonging to a low motion amount. 5.The MQTT-based Modbus network system of claim 3, wherein the first slave connector subscribes to the topic from the MQTT adjuster, and when the first master connector publishes the request information comprising the topic to the MQTT adjuster, the first slave connector automatically obtains the request information from the MQTT adjuster. ​ 6. The MQTT-based Modbus network system of claim 3, wherein when the pattern information in the topic is the bridge pattern, the first slave connector schedules the request information after receiving the request information, requests the sensing data from the corresponding first slave device according to the content of the request information, and generates response information based on the sensing data and publishes to the MQTT broker, wherein the specific topic to which the first master connector subscribes to the MQTT broker includes the network group information and the slave device identity information of the first slave device, so that the first master connector automatically obtains the response information from the MQTT broker after the first slave connector publishes the response information, and the request of one or more first master devices is responded according to the data in the response information.

7. The MQTT-based Modbus network system of claim 3, wherein when the pattern information in the topic is the tag pattern, the first slave connector requests the sensing data from the corresponding first slave device according to the request information, updates the slave cache of the first slave connector according to the sensing data, and the first slave connector is configured to generate the response information based on the update status of the sensing data in the slave cache when it is determined that the data in the slave cache has changed and publish to the MQTT broker to update the master cache of the first master connector in batches, wherein the request of the plurality of first master devices is responded according to the data in the master cache.

8. The MQTT-based Modbus network system of claim 4, further comprising a monitoring connector connected to the MQTT broker through the MQTT protocol, wherein the monitoring connector subscribes to all topics of the MQTT broker.

9. The MQTT-based Modbus network system of claim 1, further comprising: a plurality of second master devices, each of which is configured to issue a second request; and a second master connector connected to the plurality of second master devices through the Modbus protocol and connected to the MQTT broker through the MQTT protocol, wherein the second master connector is configured to publish second request information to the MQTT broker according to the second request of the plurality of second master devices and manage second response information to the second request information.

10. A data transmission method applied to a network system composed of an MQTT broker, a first master connector, and a first slave connector, wherein the MQTT broker is connected to the first master connector and the first slave connector through the MQTT protocol, the first master connector is connected to a plurality of first master devices through the Modbus protocol, the first slave connector is connected to a plurality of first slave devices through the Modbus protocol, and the data transmission method comprises: step a) issuing a request by each of the plurality of first master devices and generating sensing data by each of the plurality of first slave devices; ​ ​ ​ ​ Step b) issuing request information by the first master connector to the MQTT broker based on the requests of the plurality of first slave devices; Step c) transmitting the request information by the MQTT broker to the first slave connector; and Step d) transmitting the sensing data of the plurality of first slave devices by the first slave connector through the MQTT broker according to the update status of the sensing data of the plurality of first slave devices, or responding to one or more of the plurality of first master devices through the MQTT broker according to the request information of the first master connector.

11. The data transmission method of claim 10, wherein the request information comprises a topic, and a topic structure used by the MQTT protocol comprises at least network group information, mode information, slave device identity information, master device identity information, and sequence information, wherein the mode information comprises a bridge mode and a tag mode.

12. The data transmission method of claim 11, wherein the first slave connector subscribes to the topic from the MQTT broker, and the step c) is automatically obtaining the request information by the first slave connector from the MQTT broker when the first master connector issues the request information comprising the topic to the MQTT broker.

13. The data transmission method of claim 11, wherein when the mode information in the topic is the bridge mode, the step d) comprises: Step d11) scheduling the request information by the first slave connector, and requesting the sensing data from the corresponding first slave device according to the content of the request information; Step d12) generating response information by the first slave connector based on the sensing data and issuing to the MQTT broker; Step d13) automatically obtaining the response information by the first master connector from the MQTT broker after the first slave connector issues the response information, wherein a specific topic to which the first master connector subscribes from the MQTT broker comprises the network group information and the slave device identity information of the first slave device; and Step d14) responding to the request of one or more first master devices according to the data in the response information by the first master connector.

14. The data transmission method of claim 11, wherein when the mode information in the topic is the tag mode, the step d) comprises: Step d21) requesting the sensing data from the corresponding first slave device according to the request information by the first slave connector; Step d22) updating a slave cache of the first slave connector according to the sensing data by the first slave connector. ​ Step d23) judging whether the data of the slave cache has changed by the first slave connector, wherein the first slave connector judges whether the data of the slave cache has changed when the request issued through the bridge mode occurs and the request covers the cache range of the slave cache, or the first slave connector periodically monitors the cache content of the slave cache to judge whether the data of the slave cache has changed; and Step d24) when judging that the data of the slave cache has changed, generating response information based on the update status of the sensing data in the slave cache by the first slave connector and publishing to the MQTT regulator; Wherein, the first master connector receives the response information from the MQTT regulator to update the master cache of the first master connector in batches, and responds to the request of one or more first master devices according to the data in the master cache.

15. The data transmission method of claim 14, wherein when the pattern information in the topic is the tag pattern, the step a) further comprises: Step a1) judging whether the corresponding data of the request exists in the master cache by the first master connector; Step a2) when the corresponding data of the request exists in the master cache, directly responding to the request of one or more first master devices according to the corresponding data in the master cache by the first master connector; and Step a3) when the corresponding data of the request does not exist in the master cache, executing the steps b) to d).

16. The data transmission method of claim 11, wherein the network system further comprises a monitoring connector connected with the MQTT regulator through the MQTT protocol, and the monitoring connector subscribes to all topics of the MQTT regulator.

Images