A standardized test method for metro equipment iot interface

Abstract

The application discloses a standardized test method for a metro equipment internet-of-things interface, and belongs to the technical field of rail transit. The standardized test method for the metro equipment internet-of-things interface comprises steps of group preparation, group test, exception handling and report printing. In the group preparation step, a clustering analysis method is used to divide internet-of-things interface detection items into several groups. In the group test step, the detection items are tested in turn in units of groups. In the exception handling step, log records are called to provide users with analysis and troubleshooting. In the report printing step, a standardized detection report for the internet-of-things interface is automatically generated. The method has the advantages of significantly reducing the detection workload of the metro equipment internet-of-things interface, compressing the detection time and improving the standardized test efficiency of the internet-of-things interface.

Description

Technical Field

[0001] This invention relates to the field of rail transit technology, specifically to a standardized testing method for IoT interfaces of subway equipment. Background Technology

[0002] With the continuous development of new-generation information technology, the urban rail transit industry is ushering in a development opportunity for digital transformation and upgrading. Cities such as Shanghai and Suzhou have taken the lead in launching research on digital base technology, creating a data-integrated and shared rail transit station infrastructure platform based on the latest Internet of Things (IoT) platform technology. This reshapes the traditional hierarchical architecture of station electromechanical systems into a flat architecture digital operation system, eliminating intermediate monitoring systems. Station electromechanical equipment is directly connected to the station's digital base via IoT interfaces, thereby simplifying system hierarchy, reducing construction costs, breaking down professional data barriers, and improving equipment operation and maintenance efficiency.

[0003] To this end, Shanghai Metro officially released the "Guiding Opinions on the Construction of Rail Transit Electromechanical Systems Based on Cloud Platform and Internet of Things Technology," a standardized technical document for the construction of Shanghai's urban rail transit network. This document proposes an IoT interface standard based on the MQTT protocol and clarifies that subsequent new line construction and existing line renovation projects will adopt a digital operation system (digital base) technical solution. Against this backdrop, the need for standardized testing and certification of IoT interfaces for metro station electromechanical equipment has emerged.

[0004] A typical subway station includes over 3,000 sets of electromechanical equipment across 15 major categories and 125 subcategories, such as ventilation and air conditioning, water supply and drainage, power and lighting, and elevators and escalators. This involves nearly 100 equipment manufacturers, whose IoT interfaces vary significantly. Incomplete compatibility and even incompatibility exist when these devices are connected to the station's digital base station, impacting equipment integration efficiency and subway construction progress. Conducting standardized testing and certification of IoT interfaces is an effective way to ensure that equipment from different manufacturers and of different types can be connected to the station's digital base station in a standardized and efficient manner.

[0005] The "Guiding Opinions on the Construction of Rail Transit Electromechanical Systems Based on Cloud Platform and Internet of Things Technology" clarifies six application topics (Topics) of the MQTT protocol application layer messages, including device attribute reporting, setting device attributes, and calling device services. It also specifies 21 testing items in four major categories for IoT interface testing, including protocol testing, functional testing, disturbance testing, and security testing, as shown in Table 1.

[0006] Table 1. List of Standardized Testing Items for IoT Interfaces of Electromechanical Equipment in Subway Stations

[0007] In the table, CONNECT, CONNACK, PUBLISH, PUBACK, SUBSCRIBE, SUBACK, UNSUBSCRIBE, UNSUBACK, PINGREQ, and PINGRESP are control message types specified by the MQTT protocol.

[0008] The traditional IoT interface testing process involves testing and verifying 21 test items sequentially, which is labor-intensive and time-consuming. This makes it difficult to meet the actual needs of numerous equipment manufacturers for testing, the time requirements for on-site quality spot checks during subway construction, and the high-quality development requirements for improving quality and efficiency in the subway industry.

[0009] The technical problem this invention aims to solve is to overcome the shortcomings of traditional IoT interface testing methods, which are labor-intensive and time-consuming. It proposes a group testing method to improve the efficiency of standardized IoT interface testing, better meet the actual needs of IoT testing and certification of station electromechanical equipment, and better support the digital transformation and high-quality development of the subway industry. Summary of the Invention

[0010] In view of the shortcomings of the existing technology, the purpose of this invention is to provide a standardized testing method for IoT interfaces of subway equipment to solve the problems mentioned in the background.

[0011] To achieve the above objectives, this invention proposes a standardized testing method for IoT interfaces of subway equipment, comprising the following steps: S1. Group Preparation: Prepare the IoT interface testing project group, including the following sub-steps: S11. Classification of Testing Items: Based on the MQTT protocol communication connection process and device data subscription / publishing process, IoT interface testing items are divided into general testing items and special testing items. The general testing items refer to the pre-testing items related to the MQTT protocol control message format that are necessarily involved in the MQTT protocol communication connection and device data subscription / publishing process, including testing items for CONNECT / CONNACK messages, PUBLISH / PUBACK messages, SUBSCRIBE / SUBACK messages, UNSUBSCRIBE / UNSUBACK messages, PINGREQ / PINGRESP messages, etc. The specific testing items refer to specific functional testing items, including testing items for data communication functions, control functions, and anti-disturbance functions; S12. Testing Item Clusters: Based on the principle that the required testing environment and testing parameters are basically the same, cluster analysis is performed on the special testing items to form several special testing item clusters, including data communication function clusters, control function clusters, anti-disturbance function clusters, etc. S2. Group Testing: The dedicated testing items are tested sequentially in groups, including the following sub-steps: S21. Prepare test data: Prepare the corresponding test environment and test parameters for each group in advance, and at the same time establish a table of the affiliation between each group and each test item, and clear the test qualification mark of each test item. S22, Responding to User Selection: Display the group test operation interface, and automatically switch to the test environment corresponding to the selected group and load the corresponding test parameters according to the group selected by the user; S23: Start group test: First, establish a communication connection and interact with the device under test according to the MQTT protocol communication connection process and device data subscription / publishing process. Then, apply test parameters at regular intervals and record the early communication connection messages, data subscription / publishing messages and device response messages after the test parameters are applied. S24. Analyze message logic: Compare with the MQTT protocol specification, analyze and determine whether the message format and content of the messages recorded in sub-step S23 are compliant. This includes the following sub-steps: S241. Preliminary Preparation: Analyze the testing requirements of each testing item from the MQTT protocol level, and describe the testing requirement characteristics of each testing item using five parameters: message type, subject type, inspection type, content type, and group to which it belongs, forming a requirement characteristic table containing all testing items. Among them, the message type is the control message type specified by the MQTT protocol, the subject type is the MQTT protocol application layer subject, the inspection type includes formal inspection and content inspection, and the content type includes header inspection and payload inspection. S242, Message Matching: Read the recorded messages sequentially, extract the message type and topic type of the current message; then traverse the requirement feature table, match the detection items of the group, message type and topic type and the detection qualification flag of the detection item is zero. If the match is successful, mark the detection item and jump to the compliance analysis step S243; otherwise, continue to analyze the next message. S243. Compliance Analysis: If the inspection type of this test item is a formal inspection, compare whether the header format and payload format of the current message are consistent with the MQTT protocol specification. If they are consistent, set the test qualification mark of this test item; if they are inconsistent, first record the abnormality type and abnormal message content, and then jump to S242. If the inspection type of the test item is content inspection, then further determine the content type of the test item; if the content type of the test item is header inspection, then analyze whether the header content of the current message is consistent with the MQTT protocol specification. If it is consistent, then set the test qualification flag of the test item; if it is inconsistent, then first record the abnormal type and abnormal message content, and then jump to S242. If the content type of the detection item is load detection, analyze whether the load content of the current message is consistent with the MQTT protocol specification. If it is consistent, set the detection pass flag of the detection item; if it is inconsistent, first record the abnormal type and abnormal message content, and then jump to S242. S25. Determine the group status: Determine whether the test qualification mark of each group's test item is set. If all are set, the test of the group is determined to be passed; otherwise, the test of the group is determined to be failed. S26. Display test results: Refresh the group test operation interface and use different colors to display the test status of each group and its corresponding test items. For groups that have passed the test, the test operation button is grayed out; for test items with non-compliant records, the corresponding log analysis button is displayed; if all group tests have passed, the user is prompted that the test has passed and after user confirmation, the process jumps to step S4. S27. Select subsequent operation: Wait for user operation. If the user selects the group test operation button, proceed to sub-step S22; if the user selects the log analysis button, proceed to step S3. S3. Exception Handling: Retrieve log records and display the context, exception type, and captured exception message content of the exception message for users to analyze and troubleshoot the problem; S4. Report Printing: Automatically generate an IoT interface standardization test report, including the following sub-steps: S41. Prepare template: Prepare a standardized IoT interface test report template in advance; S42. Organize attachments: Automatically read the message records of each group test, organize the format and use them as attachments to the test report; S43. Generate Report: Based on the testing time of each group, the test qualification marks of each test item, the attachments compiled in S42, and the pre-entered list of test personnel, automatically generate the IoT interface standardization test report.

[0012] In summary, the embodiments of the present invention have the following beneficial effects compared with the prior art: This invention provides an automated interface testing method characterized by group testing, which effectively improves the efficiency of IoT interface standardization testing, reduces the personnel input of testing units, meets the time requirements of on-site quality spot checks in subway stations, and better supports the digital transformation and development of the rail transit industry.

[0013] To more clearly illustrate the features and effects of the present invention, the present invention will be described in detail below with reference to the accompanying drawings and specific embodiments. Attached Figure Description

[0014] Figure 1 This is a schematic diagram of a standardized testing process for the IoT interface of subway equipment, as an embodiment of the invention.

[0015] Figure 2 This is a schematic diagram of the message compliance analysis process in a standardized testing method for IoT interfaces of subway equipment, as described in an embodiment of the invention. Detailed Implementation

[0016] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the invention.

[0017] The following describes the specific implementation of the present invention in detail, using the 21 detection items in the Shanghai Metro IoT interface standard as background and specific embodiments.

[0018] In one embodiment of the present invention, see Figure 1 The aforementioned standardized testing method for IoT interfaces of subway equipment includes the following steps: S1. Group Preparation: Prepare the IoT interface testing project group, including the following sub-steps: S11. Classification of Testing Items: Based on the MQTT protocol communication connection process and device data subscription / publishing process, 21 different types of IoT interface testing items are divided into general testing items and special testing items. The general testing items refer to the pre-testing items related to the MQTT protocol control message format that are necessarily involved in the MQTT protocol communication connection and device data subscription / publishing process. These include 10 testing items for CONNECT / CONNACK messages, PUBLISH / PUBACK messages, SUBSCRIBE / SUBACK messages, UNSUBSCRIBE / UNSUBACK messages, PINGREQ / PINGRESP messages, etc. The special testing items refer to specific functional testing items, including the remaining 12 testing items such as data communication function, control function, and anti-disturbance function; S12. Testing Item Clusters: Based on the principle that the required testing environment and testing parameters are basically the same, cluster analysis is performed on the dedicated testing items to form several dedicated testing item clusters, including data communication function clusters, control function clusters, and anti-disturbance function clusters. Specifically, six testing items, including device authentication, device attribute reporting, device event reporting, sub-device online, sub-device offline, and communication mechanism testing, are included in the data communication function cluster; two testing items, including setting device attributes and calling device services, are included in the control function cluster; two testing items, including control message disturbance and message data disturbance, are included in anti-disturbance function cluster 1; one testing item, including transmission network disturbance, is included in anti-disturbance function cluster 2; and one testing item, including communication equipment disturbance, is included in anti-disturbance function cluster 3. Thus, the above 12 dedicated testing items are divided into 5 clusters. S2. Group Testing: The dedicated testing items are tested sequentially in groups, including the following sub-steps: S21. Prepare test data: Prepare the corresponding test environment and test parameters for each group in advance, and at the same time establish a table of the affiliation between each group and each test item, and clear the test qualification mark of each test item. S22. Responding to User Selection: Display the group testing operation interface, where users can select the group to be tested as needed; based on the group selected by the user, automatically switch to the test environment corresponding to the selected group and load the corresponding test parameters; S23: Start group test: First, establish a communication connection and interact with the device under test according to the MQTT protocol communication connection process and device data subscription / publishing process. Then, apply test parameters at regular intervals and record the general messages such as the initial communication connection, data subscription, and data publication, as well as the device response messages after the test parameters are applied. S24. Analyze message logic: In accordance with the MQTT protocol specification, analyze and judge whether the message format and message content of the messages recorded in sub-step S23 are compliant; if compliant, set the corresponding test item's test qualification flag; if non-compliant, record the exception type and exception message content. S25. Determine the group status: Determine whether the test qualification mark of each group's test item is set. If all are set, the test of the group is determined to be passed; otherwise, the test of the group is determined to be failed. S26. Display Test Results: Refresh the group test operation interface, using different colors to display the test status of each group and its associated test items. For groups that pass the test, their test operation buttons are grayed out; for groups that fail the test, their test operation buttons are displayed normally, allowing users to operate them; for test items with non-compliant records, the corresponding log analysis button is displayed; the 10 general test items are treated as special groups, and their test status is also displayed synchronously in the group test operation interface; if all group tests have passed, the user is prompted that the test has passed, and after user confirmation, the process proceeds to step S4. S27. Select subsequent operation: Wait for user operation. If the user selects the group test operation button, proceed to sub-step S22; if the user selects the log analysis button, proceed to step S3. S3. Exception Handling: Retrieve log records and display the context, exception type, and captured exception message content of the exception message for users to analyze and troubleshoot the problem; S4. Report Printing: Automatically generate an IoT interface standardization test report, including the following sub-steps: S41. Prepare template: Prepare a standardized IoT interface test report template in advance; S42. Organize attachments: Automatically read the message records of each group test, organize the format and use them as attachments to the test report; S43. Generate Report: Based on the testing time of each group, the test qualification marks of each test item, the attachments compiled in S42, and the pre-entered list of test personnel, automatically generate the IoT interface standardization test report.

[0019] In one embodiment of the present invention, see Figure 2 The sub-step S24 of the standardized testing method for IoT interfaces of subway equipment further includes a message compliance analysis method, comprising the following sub-steps: S241. Preliminary Preparation: Analyze the testing requirements of each testing item from the MQTT protocol level, and use five parameters such as message type, subject type, inspection type, content type, and group to describe the testing requirement characteristics of each testing item, forming a requirement characteristic table containing all testing items; among them, the message type is the control message type specified by the MQTT protocol, which in this embodiment includes CONNECT (1), CONNACK (2), PUBLISH (30), PUBACK (4), SUBSCRIBE (8), SUBACK (9), UNSUBSCRIBE (1), UNSUBSCRIBE (2), UNSUBSCRIBE (30), UNSUBSCRIBE (4), UNSUBSCRIBE (5), UNSUBSCRIBE (6), UNSUBSCRIBE (7), UNSUBSCRIBE (8), UNSUBSCRIBE (9), UNSUBSCRIBE (1 ... There are 10 types, including CK (11), PINGREQ (12), and PINGRESP (13); the topic type is the MQTT protocol application layer topic, which includes 6 types in this embodiment, such as device attribute reporting (1), setting device attributes (2), calling device services (3), device event reporting (4), sub-device going online (5), and sub-device going offline (6); the inspection type includes formal inspection and content inspection; the content type includes header inspection and payload inspection; here, the header and payload directly refer to the terminology of the MQTT protocol; the requirement feature table of the detection items in this embodiment is shown in Table 2; Table 2. Characteristics of Testing Requirements for Standardized Testing Items of IoT Interfaces for Electromechanical Equipment in Subway Stations

[0020] S242, Message Matching: Read the recorded messages sequentially and extract the message type and topic type of the current message; then traverse the requirement feature table, match the detection items of the group, message type and topic type, and the detection qualification flag of the detection item is zero. If the match is successful, mark the detection item and jump to the compliance analysis step S243; otherwise, continue to analyze the next message. It should be noted that for parameters not defined in the requirement feature table, such as the group and topic type of general detection items, these undefined parameters are ignored during matching. S243. Compliance Analysis: If the inspection type of this test item is a formal inspection, compare whether the header format and payload format of the current message are consistent with the MQTT protocol specification. If they are consistent, set the test qualification mark of this test item; if they are inconsistent, first record the abnormality type and abnormal message content, and then jump to S242. If the inspection type of the test item is content inspection, then further determine the content type of the test item; if the content type of the test item is header inspection, then analyze whether the header content of the current message is consistent with the MQTT protocol specification. If it is consistent, then set the test qualification flag of the test item; if it is inconsistent, then first record the abnormal type and abnormal message content, and then jump to S242. If the content type of the detection item is load detection, analyze whether the load content of the current message is consistent with the MQTT protocol specification. If it is consistent, set the detection pass flag of the detection item; if it is inconsistent, first record the abnormal type and abnormal message content, and then jump to S242. As can be seen, users only need to perform 5 tests on the 5 groups of dedicated testing items to complete the entire IoT interface standardization testing process, without having to consider the testing of 10 general testing items. The test analysis of the general testing items is already embedded in the testing process of the dedicated testing items. Compared with the traditional method that requires organizing 21 tests for 21 testing items, this invention can significantly reduce the workload of IoT interface testing, shorten the testing time, and improve the efficiency of standardized testing of IoT interfaces for subway equipment.

Claims

1. A standardized testing method for IoT interfaces of subway equipment, characterized in that, Includes the following steps: S1. Group Preparation: Prepare the IoT interface testing project group, including the following sub-steps: S11. Classification of Testing Items: Based on the MQTT protocol communication connection process and device data subscription / publishing process, IoT interface testing items are divided into general testing items and special testing items. The general testing items refer to the pre-testing items related to the MQTT protocol control message format that are necessarily involved in the MQTT protocol communication connection and device data subscription / publishing process, including testing items for CONNECT / CONNACK messages, PUBLISH / PUBACK messages, SUBSCRIBE / SUBACK messages, UNSUBSCRIBE / UNSUBACK messages, PINGREQ / PINGRESP messages, etc. The specific testing items refer to specific functional testing items, including testing items for data communication functions, control functions, and anti-disturbance functions; S12. Testing Item Clusters: Based on the principle that the required testing environment and testing parameters are basically the same, cluster analysis is performed on the special testing items to form several special testing item clusters, including data communication function clusters, control function clusters, anti-disturbance function clusters, etc. S2. Group Testing: The dedicated testing items are tested sequentially in groups, including the following sub-steps: S21. Prepare test data: Prepare the corresponding test environment and test parameters for each group in advance, and at the same time establish a table of the affiliation between each group and each test item, and clear the test qualification mark of each test item. S22, Responding to User Selection: Display the group test operation interface, and automatically switch to the test environment corresponding to the selected group and load the corresponding test parameters according to the group selected by the user; S23: Start group test: First, establish a communication connection and interact with the device under test according to the MQTT protocol communication connection process and device data subscription / publishing process. Then, apply test parameters at regular intervals and record the early communication connection messages, data subscription / publishing messages and device response messages after the test parameters are applied. S24. Analyze message logic: Compare with the MQTT protocol specification, analyze and determine whether the message format and content of the messages recorded in sub-step S23 are compliant. This includes the following sub-steps: S241. Preliminary Preparation: Analyze the testing requirements of each testing item from the MQTT protocol level, and describe the testing requirement characteristics of each testing item using five parameters: message type, subject type, inspection type, content type, and group to which it belongs, forming a requirement characteristic table containing all testing items. Among them, the message type is the control message type specified by the MQTT protocol, the subject type is the MQTT protocol application layer subject, the inspection type includes formal inspection and content inspection, and the content type includes header inspection and payload inspection. S242, Message Matching: Read the recorded messages sequentially, extract the message type and topic type of the current message; then traverse the requirement feature table, match the detection items of the group, message type and topic type and the detection qualification flag of the detection item is zero. If the match is successful, mark the detection item and jump to the compliance analysis step S243; otherwise, continue to analyze the next message. S243. Compliance Analysis: If the inspection type of this test item is a formal inspection, compare whether the header format and payload format of the current message are consistent with the MQTT protocol specification. If they are consistent, set the test qualification mark of this test item; if they are inconsistent, first record the abnormality type and abnormal message content, and then jump to S242. If the inspection type of the test item is content inspection, then further determine the content type of the test item; if the content type of the test item is header inspection, then analyze whether the header content of the current message is consistent with the MQTT protocol specification. If it is consistent, then set the test qualification flag of the test item; if it is inconsistent, then first record the abnormal type and abnormal message content, and then jump to S242. If the content type of the detection item is load detection, analyze whether the load content of the current message is consistent with the MQTT protocol specification. If it is consistent, set the detection pass flag of the detection item; if it is inconsistent, first record the abnormal type and abnormal message content, and then jump to S242. S25. Determine the group status: Determine whether the test qualification mark of each group's test item is set. If all are set, the test of the group is determined to be passed; otherwise, the test of the group is determined to be failed. S26. Display test results: Refresh the group test operation interface and use different colors to display the test status of each group and its corresponding test items. For groups that have passed the test, the test operation button is grayed out; for test items with non-compliant records, the corresponding log analysis button is displayed; if all group tests have passed, the user is prompted that the test has passed and after user confirmation, the process jumps to step S4. S27. Select subsequent operation: Wait for user operation. If the user selects the group test operation button, proceed to sub-step S22; if the user selects the log analysis button, proceed to step S3. S3. Exception Handling: Retrieve log records and display the context, exception type, and captured exception message content of the exception message for users to analyze and troubleshoot the problem; S4. Report Printing: Automatically generate an IoT interface standardization test report, including the following sub-steps: S41. Prepare template: Prepare a standardized IoT interface test report template in advance; S42. Organize attachments: Automatically read the message records of each group test, organize the format and use them as attachments to the test report; S43. Generate Report: Based on the testing time of each group, the test qualification marks of each test item, the attachments compiled in S42, and the pre-entered list of test personnel, automatically generate the IoT interface standardization test report.

Images