Test equipment monitoring method and system based on MQTT protocol

Abstract

The invention relates to the technical field of equipment monitoring, and provides a test equipment monitoring method and system based on an MQTT protocol, and the system comprises a server carrying an electronic test measurement control platform, a test node software terminal carrying test node software, and test equipment. In the test node software terminal, a protocol library is established to integrate multiple test equipment communication protocols, and each protocol is configured with a corresponding protocol interface; and according to the received command, intelligently calling a corresponding protocol interface by adopting a dynamic calling mechanism based on theme identification, and establishing connection with corresponding test equipment. Various test equipment communication protocols are integrated in test node software, a dynamic calling mechanism based on theme recognition is adopted, a protocol processing module is intelligently called to execute commands or acquire data, and seamless communication between different protocol equipment and a control platform is achieved.

Description

Technical Field

[0001] The present disclosure relates to the technical field related to equipment monitoring, and in particular, to a test equipment monitoring method and system based on the MQTT protocol. Background Art

[0002] The statements in this section merely provide background information related to the present disclosure and do not necessarily constitute prior art.

[0003] In the field of electronic test and measurement, test equipment is diversified and complex, and test equipment produced by different manufacturers use different communication protocols. In order to achieve unified control and management of these test equipment, an electronic test and measurement instrument control platform is usually developed, which can not only facilitate operators to remotely control test equipment and obtain relevant data, but also operate multiple test equipment at the same time.

[0004] The inventors found in their research that the current electronic test measurement control platform has the following technical problems in practical applications:

[0005] 1) Due to the particularity of the test and measurement field, in a test environment, different orders of operating different test equipment will lead to erroneous results. However, the current platform ignores the fact that different orders of operating test equipment may lead to different results. The instrument test platform issues operation instructions without caring about the order in which the commands reach the instrument, which will have an adverse impact on the entire test ecosystem. For example, when operating an oscilloscope and a signal generator, you need to operate the signal generator first, and then the oscilloscope can receive the electrical signal sent by the signal generator. However, due to different communication protocols and network congestion, the command issued first may reach the instrument later, thus causing errors.

[0006] 2) The development and maintenance costs of existing platforms are high, requiring professional technical support and a large amount of customized development, resulting in high system complexity. Due to differences in the communication protocols and communication data formats of test equipment instruments, each device needs to be adapted, resulting in problems with platform compatibility and consistency. For example, only a separate platform can be designed to control and monitor an oscilloscope, and it is impossible to communicate messages between multiple different instruments. If multiple test platforms want to communicate with the instrument, each platform needs to be connected to the instrument separately, and instrument data sharing and status monitoring cannot be achieved. Controlling communication between different instruments often requires professional technicians to operate, and it cannot be compatible with devices with different communication protocols at the same time. The system has poor compatibility and high development and maintenance costs. Summary of the invention

[0007] In order to solve the above problems, the present invention proposes a test equipment monitoring method and system based on the MQTT protocol, and sets a test node software terminal equipped with a node software, which serves as a middleware to process commands or data from the test equipment and the server. Through the set node software, a variety of test instrument communication protocols are unified, solving the problem of poor compatibility of multi-protocol equipment control platforms.

[0008] In order to achieve the above objectives, the present disclosure adopts the following technical solutions:

[0009] One or more embodiments provide a test equipment monitoring system based on the MQTT protocol, including a server equipped with an electronic test measurement control platform, a test node software terminal equipped with test node software, and a test equipment;

[0010] In the test node software terminal, a protocol library is established to integrate multiple test equipment communication protocols, and each protocol is configured with a corresponding protocol interface; according to the received command, a dynamic calling mechanism based on subject identification is adopted to intelligently call the corresponding protocol interface and establish a connection with the corresponding test equipment.

[0011] One or more embodiments provide a monitoring method based on the above-mentioned test equipment monitoring system based on the MQTT protocol, which is executed in a test node software terminal and includes the following steps:

[0012] Get the command sent by the server;

[0013] After receiving the command, the command is first stored in the command queue. Based on the dynamic calling mechanism of MQTT protocol topic identification, the corresponding protocol interface is intelligently called according to the protocol identification information after command parsing, and a connection is established with the test device that executes the command.

[0014] The command queue and device mapping mechanism and multi-threading method are used to send the commands to the corresponding test devices in sequence in the queue order, so that the test devices perform corresponding operations after receiving the commands and return the data to the node software terminal;

[0015] The data returned by the test device is transmitted to the server through the corresponding MQTT protocol topic.

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

[0017] (1) The present disclosure unifies multiple test instrument communication protocols through the node software. In view of the inconsistent order of commands in the test instrument control, which may lead to device errors, the command queue and device mapping mechanism and multi-threading method are adopted to ensure the sequential execution of the same device commands and the efficiency of the platform operating different devices.

[0018] The MQTT protocol is used as the basis for message transmission, which enables different platforms to share and access device information by subscribing to topics. There is no need to repeatedly establish communication connections, which effectively saves network resources and improves communication efficiency.

[0019] The advantages of the present disclosure and the advantages of additional aspects will be described in detail in the following specific embodiments. BRIEF DESCRIPTION OF THE DRAWINGS

[0020] The accompanying drawings constituting a part of the present disclosure are used to provide a further understanding of the present disclosure. The exemplary embodiments of the present disclosure and the description thereof are used to explain the present disclosure but do not constitute a limitation of the present disclosure.

[0021] Figure 1 is a schematic diagram of a test equipment monitoring system based on the MQTT protocol according to Embodiment 1 of the present disclosure;

[0022] Figure 2 is a parsing flow chart of the data parsing module of Embodiment 1 of the present disclosure;

[0023] Figure 3 It is a data processing flow chart of the queue and multi-threaded calling module of embodiment 1 of the present disclosure. DETAILED DESCRIPTION

[0024] The present disclosure is further described below in conjunction with the accompanying drawings and embodiments.

[0025] It should be noted that the following detailed descriptions are exemplary and are intended to provide further explanation of the present disclosure. Unless otherwise specified, all technical and scientific terms used herein have the same meanings as those commonly understood by those skilled in the art to which the present disclosure belongs.

[0026] It should be noted that the terms used herein are only for describing specific embodiments and are not intended to limit exemplary embodiments according to the present disclosure. As used herein, unless the context clearly indicates otherwise, the singular form is also intended to include the plural form. In addition, it should be understood that when the terms "comprising" and / or "including" are used in this specification, it indicates the presence of features, steps, operations, devices, components and / or combinations thereof. It should be noted that, in the absence of conflict, the various embodiments in the present disclosure and the features in the embodiments can be combined with each other. The embodiments will be described in detail below in conjunction with the accompanying drawings.

[0027] Aiming at the many shortcomings of the current test and measurement equipment control platform, such as poor compatibility, high development and maintenance costs, and disordered commands, the present invention proposes a test instrument control and status monitoring method based on the MQTT protocol. The node software can intelligently select the communication protocol of the test equipment according to the command issued by the platform, thereby solving the problem of poor compatibility of the multi-protocol equipment control platform. The MQTT protocol is used for communication between the platform and the node software, and MQTT is a lightweight message transmission protocol. The communication between the platform and the node software terminal is controlled by the MQTT protocol, so that the operator can control the test instrument and obtain the results of the test instrument without professional knowledge of the test and measurement field, simplifying the operation process and reducing the professional requirements for the operator. Through the publish / subscribe mode, the status sharing and monitoring of the test equipment are realized, and multiple control platforms only need to subscribe to the same topic to receive messages from the node software. The device is disconnected from the node software terminal, the message format is wrong, the command is successfully issued, etc.; the node software can also quickly publish messages to a specific topic, thereby realizing multi-platform sharing of the device status, solving the problem of high system complexity. The command queue and device mapping mechanism and multi-threading method are adopted to realize asynchronous communication between different devices and the control platform and synchronous communication between the same device and the control platform, ensuring that different devices do not affect each other and the same devices operate in sequence, thus solving the problem of inconsistency between the platform command issuance and the device execution order. The following is an explanation with a specific embodiment.

[0028] Example 1

[0029] In the technical solutions disclosed in one or more embodiments, Figures 1 to 3 As shown, a test equipment monitoring system based on the MQTT protocol is provided, including a server equipped with an electronic test measurement control platform, a test node software terminal equipped with a test node software, and a test device; the test node software terminal communicates with the server through the MQTT protocol;

[0030] Test equipment, including various test equipment, as controlled nodes, receiving messages from the server through node software and returning corresponding data;

[0031] The server, as a control node, is configured to execute the issuance of commands and receive data from the test equipment. It communicates with the node software terminal through the MQTT protocol;

[0032] The test node software terminal, as a middleware, is configured to process commands or data from the test device and the server.

[0033] In a feasible technical solution, a protocol library is established in the test node software terminal to integrate multiple test equipment communication protocols, and each protocol is configured with a corresponding protocol interface; when the test node software terminal receives a message from the server, a dynamic calling mechanism based on subject identification is adopted to intelligently call the corresponding protocol interface execution command to establish a connection with the corresponding test equipment, thereby realizing seamless communication between different protocol devices and the control platform.

[0034] A further technical solution is that the test node software terminal adopts a publish / subscribe mode, and the server subscribes to a topic; the test node software terminal publishes a message to the corresponding server according to the topic subscription information;

[0035] Through the above solution, multiple servers can share and monitor the device status in real time by subscribing to the topics sent by the node software. Different servers can use the topic subscription of the node software to publish control commands to achieve cross-platform device control.

[0036] In order to solve the impact of command sequence on operation results, command queue and device mapping mechanism and multi-threading method are adopted to realize asynchronous communication between different devices and control platform and synchronous communication between the same device and control platform, so as to improve communication efficiency.

[0037] The method of this embodiment overcomes the problems of difficult processing of heterogeneous data and poor compatibility caused by the diversity of test equipment and protocol differences, realizes the unification of control interfaces, improves communication efficiency, reduces system complexity and development costs, and can be widely used in distributed automatic test systems.

[0038] The implementation scheme in the test node software terminal is described in detail below;

[0039] In some embodiments, the test node software terminal includes a data parsing module, an MQTT communication module, a dynamic protocol calling module, an event reporting module, and a queue and multi-thread calling module;

[0040] The MQTT communication module is configured to establish a communication connection between the test node software terminal and the server based on the MQTT communication protocol to realize data transmission;

[0041] The data parsing module is configured to extract messages from the data received from the test device; perform standardization processing on the data from the server to obtain parsed information;

[0042] The dynamic protocol calling module is configured to intelligently select and call a matching protocol interface according to the protocol identification information in the parsed information and the set instrument communication protocol library;

[0043] An event reporting module is configured to report errors or abnormal information during data processing or communication;

[0044] The queue and multi-threaded call module is configured to set different threads for test devices with different protocols, set command queues for the same test device, and execute commands between different test devices in sequence according to the definition of the message;

[0045] In some embodiments, the MQTT communication module is configured to perform topic subscription, topic publishing, and response topic;

[0046] When the MQTT communication module receives data from the event reporting module or after data parsing is successful, the node software sends a subscription message to the server through the topic subscribed by the server. At this time, any server that subscribes to the topic can receive the message from the node software, thereby realizing the data and status sharing of the device. When the node software receives a message from the server, it returns the received message to the server through the MQTT response topic. When the server receives the message, it indicates that the server and the node software have successfully established a connection. The server can publish commands through the topic, and the node software performs the corresponding operation after receiving the command.

[0047] In some embodiments, the data parsing module flow chart is as follows Figure 2 As shown, the steps are as follows:

[0048] 1-1) Data preparation: Get messages from the server or test device;

[0049] 1-2) Data analysis: Determine whether the data is from the server or the test device based on the message type. If it is data from the test device, execute step 1.4); if it is data from the server, execute step 1.3); if the data is wrong or the message is invalid, report the event.

[0050] 1-3) Message extraction: According to the type information carried in the message data obtained from the server, determine whether this command is an add command or a command to be issued. If it is an add command, call the protocol dynamic call module according to the address information and protocol information carried in the message. If it is a command to be issued, issue the command according to the connection information stored in the node software for the first connection to the corresponding test device;

[0051] A specific implementation scheme is that the dynamic call module sets a handle set. When the test device successfully connects to the test node software terminal for the first time, the dynamic call module stores the handle and address of the test device in a Map. When the next command is issued, the message is sent to the test device directly through the handle, which solves the problem of needing to re-establish the connection every time a command is issued; the connection information stored in the first connection in step 3) is the handle stored in the Map.

[0052] Among them, Map refers to a data structure.

[0053] 1-4) Data standardization: standardize the received messages according to the standard format;

[0054] Taking the connection command as an example, when the node software receives a message from the device, it indicates that the test device has been successfully connected and returned a message. At this time, the Status in the message sent by the node software to the server should be connected. If the received data is garbled or invalid data, the data will be sent to the event reporting module for event reporting.

[0055] In some embodiments, the dynamic calling module is configured to call the corresponding protocol interface according to the protocol information parsed by the data parsing module;

[0056] Specifically, a protocol interface library is maintained in the dynamic call module, and the protocol interface library sets a protocol interface for each protocol; when the communication protocol of the test equipment is changed or a new communication protocol is added, the corresponding protocol interface is added to the protocol interface library.

[0057] The dynamic calling module extracts the protocol identification information according to the address and command sent by the data parsing module, automatically matches the corresponding protocol, and selects and calls the protocol interface that matches the protocol;

[0058] In some embodiments, the event reporting module is configured to report errors and abnormal events in the process of data transmission and data processing.

[0059] Specifically, event reporting can be implemented through the publish / subscribe mode of the MQTT protocol. The server pre-subscribes to the event reporting topic. When problems such as disconnection or data anomalies occur, the event reporting module will locate the place where the error occurred and return the error to the server. The server can promptly troubleshoot the error based on the problem reported in the event.

[0060] In some embodiments, the queue and multi-threaded calling module is configured to set different threads for test devices with different protocols, set a command queue for the same test device, and through the definition of messages, the command sequence execution between different devices can also be realized. The queue and multi-threaded calling module flow chart is as follows Figure 3 , the specific implementation steps are as follows:

[0061] 2-1) Command acquisition: Receive the parsed command. If the current command is not a device adding command, execute step 2-3; otherwise, if the current command is a device adding command, execute step 2-2;

[0062] 2-2) Start a thread: Start an additional thread for the current command, and set a command queue for the corresponding test device A to store commands related to the test device; if the test device A already exists in the connected device list, an event is reported.

[0063] 2-3) Command queue: If the current command involves multiple test devices and needs to be executed in sequence, the current command is stored in the multi-device command queue. If the current command only involves a single device, the command enters the command queue opened for the device.

[0064] Among them, the multi-device command queue and the single-device command queue corresponding to a single device are specifically set queues. The multi-device command queue is used to store commands that need to be executed by multiple test devices; the single-device command queue is used to store commands that need to be executed by a corresponding single test device;

[0065] 2-3) Command dequeue: Commands are executed in sequence. When a command is successfully executed, it is dequeued until the command is completed. Multi-threaded command execution is adopted, and single-device command queues of different devices are executed simultaneously.

[0066] This embodiment is arranged that due to multithreading, single device command queues of different devices can be executed simultaneously to improve guarantee efficiency.

[0067] This embodiment provides an integrated and unified management method for test equipment communication. The MQTT protocol is used to implement transparent command control and status monitoring of single or multiple devices on multiple platforms. Middleware services are provided for multi-protocol devices to achieve convenient, efficient and standardized data conversion. A method for simplifying the system architecture of the automatic test instrument control platform is provided to reduce development costs and operating resource consumption.

[0068] By setting up a unified interface software in the test node software terminal, different test equipment communication protocols can be integrated, reducing the diversity and professional technical requirements required for the system to connect to various instruments and equipment; using the MQTTT protocol as the basic architecture for message transmission, an efficient and flexible message subscription and publishing mechanism across platforms and devices is implemented. This key feature allows multiple platforms to share and obtain device information by simply subscribing to the same topic, without having to establish independent communication connections for each device or platform, greatly simplifying the system structure and communication process;

[0069] The node software acts as an intermediary between the instrument and the platform, responsible for converting and adapting the communication protocols of different devices, so that various devices can interact with the upper-level platform through the MQTT protocol. Regardless of the underlying protocol used by the device, commands can be issued and status responses can be responded to in a unified manner.

[0070] Example 2

[0071] Based on Example 1, this embodiment provides a monitoring method for a test equipment monitoring system based on the MQTT protocol, which is executed in a test node software terminal, such as Figure 1 As shown, the following steps are included:

[0072] Step 1: The node software terminal obtains the command sent by the server;

[0073] Step 2: After receiving the command, the node software terminal first stores the command in the command queue. Based on the dynamic calling mechanism of MQTT protocol topic identification, the corresponding protocol interface is intelligently called according to the protocol identification information after command parsing, and a connection is established with the test device that executes the command.

[0074] Step 3: The node software terminal uses a command queue and device mapping mechanism and a multi-threading method to send commands to the corresponding test devices in sequence according to the queue order, so that the test devices perform corresponding operations after receiving the commands and return data to the node software terminal;

[0075] Step 4: The node software terminal transmits the data returned by the test device to the server through the corresponding MQTT protocol topic;

[0076] In this embodiment, a dynamic calling mechanism is used to intelligently call the corresponding protocol interface, thereby overcoming the problems of difficult processing of heterogeneous data and poor compatibility caused by the diversity of test equipment and protocol differences. Through the protocol interface software, the protocol interface can be configured and used without understanding the underlying complex communication protocols and technical details, allowing users to operate through standardized APIs, hiding the specific implementation mechanism, making the system easier to use, port and maintain.

[0077] In addition, for the situation where the order of commands in the test instrument control is inconsistent and causes device errors, the command queue and device mapping mechanism and multi-threading method are adopted to ensure the sequential execution of the same device commands and the efficiency of the platform operating different devices. The MQTT protocol is used as the basis for message transmission, which enables different platforms to share and access device information by subscribing to topics, without the need to repeatedly establish communication connections, effectively saving network resources and improving communication efficiency.

[0078] Furthermore, before step 1, it also includes the step of adding a device, that is, when the system starts running, the server sends a command to add a device to the test node software terminal through the MQTT protocol. After receiving the command, the node software first determines whether the current device is connected. If it is connected, the event is reported through the event reporting module to inform the server that the device is connected. If it is not connected, the node software parses the command after receiving the command, obtains the communication protocol of the device to be added by parsing the command, and establishes a connection with the test device according to the matched protocol configuration protocol interface.

[0079] After the connection is established, the server can issue commands, and the node software terminal executes steps 1 to 4 to remotely monitor the test equipment.

[0080] Furthermore, when the node software terminal sends a connection to the test device and an error occurs, such as a connection failure or a command in the wrong format is sent when sending a command, the node software sends a specified error to the server through the topic of the MQTT event report generated by the event reporting module; so that after the server receives the error message, it can check the test device according to the error content.

[0081] In order to realize the monitoring of test equipment using different communication protocols, a series of communication protocols are also defined in this embodiment. The standardized communication protocols can facilitate the parsing of messages by the node software;

[0082] A feasible technical solution is that the test node software terminal embeds an instrument communication protocol library, and the instrument communication protocol library is used to store different communication protocol standards adopted by various test equipment.

[0083] The communication protocol is set in the test node software terminal, and the test equipment sends and receives data through the corresponding interface without knowing the underlying protocol details. Therefore, when the communication protocol of the test equipment needs to be updated or optimized, it is only necessary to update the corresponding protocol library content at the node software level without causing any operational impact on the top-level users who directly use the software, thereby ensuring a smooth transition of the system upgrade process and continuity of user use.

[0084] Step 1: When the node software receives a message sent by the server, the message is first processed by the built-in professional message parsing module; the specific message parsing process is as follows: Figure 2 As shown, the following steps are included:

[0085] 1-1) Get messages from the server or test device;

[0086] 1-2) Determine whether the message type is from the server or the test device. If it is from the test device, execute step 1.4); if it is from the server, execute step 1.3); if the data is wrong or the message is invalid, report the event.

[0087] 1-3) According to the type information carried in the message data obtained from the server, determine whether this command is an add command or a command to be issued. If it is an add command, call the protocol dynamic call module according to the address information and protocol information carried in the message. If it is a command to be issued, issue the command according to the connection information stored in the node software for the first connection to the corresponding test device;

[0088] A specific implementation scheme is that the dynamic call module sets a handle set. When the test device successfully connects to the test node software terminal for the first time, the dynamic call module stores the handle and address of the test device in a Map. When the next command is issued, the message is sent to the test device directly through the handle, which solves the problem of needing to re-establish the connection every time a command is issued; the connection information stored in the first connection in step 3) is the handle stored in the Map.

[0089] Among them, Map refers to a data structure.

[0090] Data standardization: standardize the received messages according to the standard format;

[0091] The standardized data has a fixed format and content. Taking the connection command as an example, when the node software receives a message from the device, it indicates that the test device has been successfully connected and returned a message. At this time, the Status in the message sent by the node software to the server should be connected. If the received data is garbled or invalid data, the data will be sent to the event reporting module for event reporting.

[0092] Furthermore, if any error occurs during the parsing process, the preset subject event reporting mechanism will be automatically triggered, and the error information will be reported through the event reporting module, ensuring that the problem is fed back and resolved in a timely manner.

[0093] When the message is parsed successfully, the protocol is dynamically called according to the protocol identification information in the parsing result, and the protocol interface that fully matches it is intelligently selected and called, including the following steps:

[0094] Step 21: Create a protocol interface library, in which a protocol interface is set for each protocol;

[0095] Step 22: extract the protocol identification information according to the address and command obtained by data analysis, search the protocol interface library in turn, automatically match the corresponding protocol, select and call the protocol interface that matches the protocol;

[0096] Furthermore, when the communication protocol of the test equipment is changed or a new communication protocol is added, a corresponding protocol interface is added to the protocol interface library to implement the updating of the protocol interface library;

[0097] In the above scheme, through this dynamic calling process, it can be ensured that various instruments and equipment can accurately perform corresponding control or data interaction tasks.

[0098] A specific solution, the multi-threaded method is specifically a multi-threaded concurrent processing strategy. For different test device addresses, independent threads are established, each thread is set up with a separate command queue, and multiple threads are executed in parallel to ensure the synchronization and consistency of concurrent operations.

[0099] In this embodiment, a command queue is constructed, and a mapping relationship between threads, command queues, and test devices is realized during the multi-threaded setting process; and multi-threaded parallel execution can greatly improve execution efficiency;

[0100] Optionally, the commands are stored in the command queue in the order issued by the server, and then the commands are executed in the corresponding order and then removed from the queue;

[0101] During the command issuance phase, no matter how complex the command sequence from the server is, the node software can ensure that each command enters the pre-set command queue in strict accordance with the order of receipt, effectively preventing the disorder of command execution order caused by network delays or other emergencies.

[0102] In step 3, the command queue and device mapping mechanism and multi-threading method are used, specifically:

[0103] 2-1) Command acquisition: Receive the parsed command. If the current command is not a device adding command, execute step 2-3; otherwise, if the current command is a device adding command, execute step 2-2;

[0104] 2-2) Open thread: Open an additional thread for the current command, and set a command queue for the corresponding test device A to store commands related to the test device;

[0105] Optionally, if the test device A already exists in the connected device list, an event is reported.

[0106] 2-3) Command queue: If the current command involves multiple test devices and needs to be executed in sequence, the current command is stored in the multi-device command queue. If the current command only involves a single device, the command enters the command queue opened for the corresponding device.

[0107] Among them, the multi-device command queue and the single-device command queue corresponding to a single device are specifically set queues. The multi-device command queue is used to store commands that need to be executed by multiple test devices; the single-device command queue is used to store commands that need to be executed by a corresponding single test device;

[0108] 2-3) Command dequeue: Commands are executed in sequence. When a command is successfully executed, it is dequeued until the command is completed. Multi-threaded command execution is adopted, and single-device command queues of different devices are executed simultaneously.

[0109] When the command is correctly issued to the target test device, the test device will execute the instruction and feedback the operation results to the node software terminal in real time. After receiving the operation results of the device, the node software terminal will package the results according to the predefined message format standard and send them back to the server through the network, realizing the closed-loop control of the entire test process and complete information interaction records. Figure 1 This is the workflow diagram of the node software terminal.

[0110] The above description is only a preferred embodiment of the present disclosure and is not intended to limit the present disclosure. For those skilled in the art, the present disclosure may have various modifications and variations. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present disclosure shall be included in the protection scope of the present disclosure.

[0111] Although the above describes the specific implementation methods of the present disclosure in conjunction with the accompanying drawings, it is not intended to limit the scope of protection of the present disclosure. Technical personnel in the relevant field should understand that on the basis of the technical solution of the present disclosure, various modifications or variations that can be made by those skilled in the art without creative work are still within the scope of protection of the present disclosure.

Claims

1. A test equipment monitoring system based on the MQTT protocol, characterized by: It includes a server equipped with an electronic test measurement control platform, a test node software terminal equipped with test node software, and test equipment; In the test node software terminal, a protocol library is established to integrate multiple test equipment communication protocols, and each protocol is configured with a corresponding protocol interface; according to the received command, a dynamic calling mechanism based on subject identification is adopted to intelligently call the corresponding protocol interface and establish a connection with the corresponding test equipment.

2. The test equipment monitoring system based on the MQTT protocol as claimed in claim 1, characterized in that: The test node software terminal adopts the publish / subscribe mode, the server subscribes to the topic; the test node software terminal publishes messages to the corresponding server according to the topic subscription information.

3. The test equipment monitoring system based on the MQTT protocol as claimed in claim 1, characterized in that: The test node software terminal includes a data parsing module configured to extract messages from data received from the test device; perform standardization processing on the data from the server to obtain parsed information; The data parsing module is configured to perform the following steps: Get messages from the server or test device; Determine whether the message type is from the server or the test device; Messages are extracted from the data from the server, and based on the type information carried in the message data obtained from the server, it is determined whether the command is an add command or a command to be issued. If it is an add command, the protocol dynamic call module is called based on the address information and protocol information carried in the message. If it is a command to be issued, the command is issued based on the connection information stored in the node software for the first connection to the corresponding test device; Data from test equipment is normalized and regulated according to standard formats.

4. The test equipment monitoring system based on the MQTT protocol as claimed in claim 3, characterized in that: The connection information stored in the test device corresponding to the first connection is: in the set handle set, the handle set by the corresponding test device when the connection is established for the first time.

5. The test equipment monitoring system based on the MQTT protocol as claimed in claim 3, characterized in that: The test node software terminal also includes a dynamic calling module configured to call the corresponding protocol interface according to the protocol information parsed by the data parsing module; The protocol interface library is maintained in the dynamic call module, and a protocol interface is set for each protocol in the protocol interface library; when the communication protocol of the test equipment is changed or a new communication protocol is added, the corresponding protocol interface is added to the protocol interface library; The dynamic calling module extracts the protocol identification information according to the address and command sent by the data parsing module, automatically matches the corresponding protocol, and selects and calls the protocol interface that matches the protocol.

6. The test equipment monitoring system based on the MQTT protocol as claimed in claim 3, characterized in that: The test node software terminal also includes an event reporting module, which is configured to report errors and abnormal events in the process of data transmission and data processing.

7. The test equipment monitoring system based on the MQTT protocol as claimed in claim 3, characterized in that: The test node software terminal also includes a queue and multi-threaded call module, which is configured to set different threads for test devices of different protocols, set a command queue for the same test device, and realize the sequential execution of commands between different devices through the definition of messages; Alternatively, the test node software terminal also includes an MQTT communication module, which is configured to establish a communication connection between the test node software terminal and the server based on the MQTT communication protocol to achieve data transmission.

8. A monitoring method for a test equipment monitoring system based on the MQTT protocol according to any one of claims 1 to 7, executed in a test node software terminal, characterized in that: The steps include: Get the command sent by the server; After receiving the command, the command is first stored in the command queue. Based on the dynamic calling mechanism of MQTT protocol topic identification, the corresponding protocol interface is intelligently called according to the protocol identification information after command parsing, and a connection is established with the test device that executes the command. The command queue and device mapping mechanism and multi-threading method are used to send the commands to the corresponding test devices in sequence in the queue order, so that the test devices perform corresponding operations after receiving the commands and return the data to the node software terminal; The data returned by the test device is transmitted to the server through the corresponding MQTT protocol topic.

9. The monitoring method according to claim 8, characterized in that: The message parsing process includes the following steps: Get messages from the server or test device; Determine whether the message type is from the server or the test device; Messages are extracted from the data from the server, and based on the type information carried in the message data obtained from the server, it is determined whether the command is an add command or a command to be issued. If it is an add command, the protocol dynamic call module is called based on the address information and protocol information carried in the message. If it is a command to be issued, the command is issued based on the connection information stored in the node software for the first connection to the corresponding test device; Data from test equipment is normalized and regulated according to standard formats.

10. The monitoring method according to claim 8, characterized in that: Intelligently calling the corresponding protocol interface according to the protocol identification information after command parsing includes the following steps: Creating a protocol interface library, wherein a protocol interface is set for each protocol in the protocol interface library; According to the address and command obtained by data analysis, the protocol identification information is extracted, the protocols in the protocol interface library are searched in turn, the corresponding protocols are automatically matched, and the protocol interface matching the protocol is selected and called; Alternatively, the multi-thread method is specifically a multi-thread concurrent processing strategy, in which independent threads are established for different test device addresses, a separate command queue is set for each thread, and multiple threads are executed in parallel; The command queue and device mapping mechanism and multi-threading method are adopted, including the following steps: Receive the parsed command; If the current command is to start a thread for adding a device command, an additional thread is started for the current command, and a command queue is set for the corresponding test device A to store commands related to the test device; If the current command is not a device add command, the execution command is put into the queue; if the current command involves multiple test devices and needs to be executed in sequence, the current command is stored in the multi-device command queue; if the current command only involves a single device, the command enters the command queue opened for the corresponding device; Commands are executed in sequence. When a command is successfully executed, it is removed from the queue until the command is completed. Multi-threaded command execution is adopted, and single-device command queues of different devices are executed simultaneously. Among them, the multi-device command queue is used to store commands that need to be executed by multiple test devices; the single-device command queue is used to store commands that need to be executed by a corresponding single test device.

Images