Dotting test method, device, equipment, medium and product

Abstract

The invention discloses a dotting test method and device, equipment, a medium and a product, and the method comprises the steps: obtaining a dotting test request for a tested equipment cluster, and calling a pre-stored standard equipment description file according to the dotting test request, determining test parameter information of the tested equipment according to a standard equipment description file and the dotting test request; based on an idle state of a data transmission module between the tested equipment cluster and the tested equipment cluster, performing a concurrent dotting test on each tested equipment in the tested equipment cluster according to the test parameter information to obtain a dotting test result; and generating a health portrait corresponding to the equipment model of the tested equipment according to the dotting test result, analyzing the health portrait and the test result, and generating a corresponding equipment maintenance suggestion. According to the technical characteristics, the test efficiency is improved, and the operation complexity is reduced.

Description

Technical Field

[0001] This invention relates to the field of terminal equipment testing technology, and in particular to a dot-matrix testing method, apparatus, equipment, medium, and product. Background Technology

[0002] In the industrial sector, point-based testing of addressable remote sensor high-speed transducer protocol (HART) smart devices is crucial for ensuring device reliability, but its communication speed is relatively slow.

[0003] Existing technologies employ a serial approach for multi-device point testing, requiring manual interpretation of the complex HART protocol device description language to determine the communication and parsing rules for the test data. However, this approach suffers from the following drawbacks: serial testing is inefficient, multi-device testing is time-consuming, and defining test data rules is cumbersome and difficult to implement. Summary of the Invention

[0004] This invention provides a dot-marking test method, apparatus, equipment, medium, and product, which improves testing efficiency and reduces operational complexity.

[0005] In a first aspect, embodiments of this disclosure provide a dot-marking test method, including:

[0006] Obtain a point-tracking test request for the cluster of devices under test, call a pre-stored standard device description file according to the point-tracking test request, and determine the test parameter information of the devices under test according to the standard device description file and the point-tracking test request;

[0007] Based on the idle state of the data transmission module between the device under test cluster and the device under test cluster, concurrent point-marking tests are performed on each device under test in the device under test cluster according to the test parameter information to obtain point-marking test results.

[0008] Based on the test results, a health profile and test result analysis corresponding to the device model of the tested device are generated, and corresponding device maintenance suggestions are generated.

[0009] Secondly, embodiments of this disclosure provide a dot-marking test apparatus, comprising:

[0010] The test information determination module is used to obtain a point-marking test request for the cluster of devices under test, call a pre-stored standard device description file according to the point-marking test request, and determine the test parameter information of the devices under test according to the standard device description file and the point-marking test request.

[0011] The dot-matrix test module is used to perform concurrent dot-matrix tests on each device under test in the device under test cluster based on the idle state of the data transmission module between the device under test and the cluster of devices under test and according to the test parameter information, so as to obtain the dot-matrix test results.

[0012] The test evaluation module is used to generate a health profile and test result analysis corresponding to the equipment model of the tested equipment based on the point test results, and to generate corresponding equipment maintenance suggestions.

[0013] Thirdly, embodiments of this disclosure provide an electronic device, including:

[0014] At least one processor; and

[0015] A memory that is communicatively connected to at least one processor; wherein,

[0016] The memory stores a computer program that can be executed by at least one processor, such that the at least one processor can perform a dot-marking test method provided in the first aspect embodiment described above.

[0017] Fourthly, embodiments of this disclosure provide a computer-readable storage medium storing computer instructions that, when executed by a processor, implement the dot-marking test method provided in the first aspect of the embodiments described above.

[0018] Fifthly, this disclosure provides a computer program product, which includes a computer program that, when executed by a processor, implements a dot-marking test method provided in the first aspect of the embodiment.

[0019] The technical solution of this invention involves obtaining a point-tracking test request for a cluster of devices under test (DUTs), calling a pre-stored standard device description file based on the point-tracking test request, and determining the test parameter information of the DUTs based on the standard device description file and the point-tracking test request. Based on the idle state of the data transmission module between the DUTs and the cluster, concurrent point-tracking tests are performed on each DUT in the cluster according to the test parameter information to obtain point-tracking test results. Based on the point-tracking test results, a health profile and test result analysis corresponding to the device model of the DUTs are generated, and corresponding device maintenance suggestions are generated. These technical features directly and automatically extract test parameters through standardized files, simplifying rule definition steps, reducing operational difficulty, achieving accurate adaptation of test parameters, and ensuring test effectiveness. Performing concurrent point-tracking tests on multiple devices based on the idle state of the data transmission module improves test efficiency and resource utilization, shortens test time, and extends the value of testing to operation and maintenance.

[0020] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of the present invention, nor is it intended to limit the scope of the invention. Other features of the invention will become readily apparent from the following description. Attached Figure Description

[0021] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0022] Figure 1 This is a flowchart of a dot-marking test method provided in an embodiment of the present invention;

[0023] Figure 2 This is a schematic diagram of the structure of a dot-marking test device provided in an embodiment of the present invention;

[0024] Figure 3 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention. Detailed Implementation

[0025] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.

[0026] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0027] In one embodiment, Figure 1This is a flowchart of a dot-marking test method provided by an embodiment of the present invention. This embodiment is applicable to situations where multiple devices perform dot-marking tests concurrently. The method can be executed by a dot-marking test device, which can be implemented in hardware and / or software.

[0028] This method is executed by the host computer of the Distributed Control System (DCS). The DCS system interacts with the field device under test through the host computer and data transmission (Input / Output, I / O) modules.

[0029] like Figure 1 As shown, the method includes:

[0030] S101. Obtain the point-marking test request for the cluster of devices under test, call the pre-stored standard device description file according to the point-marking test request, and determine the test parameter information of the devices under test according to the standard device description file and the point-marking test request.

[0031] In this embodiment, the device under test (DUT) cluster can be understood as a collection of multiple industrial intelligent devices (DUTs) that need to undergo point-based testing, including devices of different types and models. Each DUT is a test object for point-based testing. Point-based testing is a process of giving an intelligent device an input value, obtaining its output value, and comparing whether the results match. A point-based test request can be understood as an instruction carrier that triggers the test process, containing dynamic configuration information such as the test object (each DUT within the DUT cluster, represented by device model and device serial number) and test requirements (number of test points, allowable error range, test priority).

[0032] A standard device description file (DD file) is a file containing the inherent attributes of a device, written in the Electronic Device Description Language (EDDL) and conforming to the Field Device Integration (FDI) Foundation specifications. Developed by the device manufacturer for a specific model of intelligent device, it serves as the core basis for standardized communication between the DCS system and the device. This file is strongly bound to the device manufacturer, model, and version, ensuring its uniqueness. The system can accurately match and retrieve the unique standard device description file based on the device's manufacturer, model, and version. It can be parsed by the Electronic Device Description Engine (EDD Engine) interpreter to extract device attributes. The EDD Engine interpreter is the software engine in the host system that interprets and executes the device description file. The standard device description file includes basic device identity information (such as manufacturer identifier, device model, device version number), device communication protocol attribute information (such as protocol type, version number, and rules for the composition of communication data packets), and device interaction command attribute information (such as a list of data items that the device can read and write, and the name, length, and data type of each data item, as well as the command number of each interaction data packet and the definition of the data content of each command's request and response data packets).

[0033] For analog output (AO) devices, their readable and writable data items typically include multiple parameters such as temperature, pressure, and valve position. It is necessary to explicitly specify specific data items as the core output values ​​(i.e., valve position parameters) based on the device's user manual. After this configuration is completed, the system will associate the device model with the variable identifiers of the corresponding valve position parameters and store this information in the database. For known device models, the above configuration information will be pre-entered into the database before the software leaves the factory, achieving one-time configuration and permanent reuse. Subsequent testing of this model of AO device will not require repeated configuration of the valve position parameters. Simultaneously, parsing the standard device description file can clarify the communication protocol details corresponding to the AO device's valve position parameters, providing a direct basis for the encapsulation and generation of communication data packets during testing, ensuring accurate interaction of valve position-related commands.

[0034] Test parameter information can be understood as a set of parameters that can be directly used for test execution after integrating the fixed attributes of the standard device description file and the dynamic requirements of the point test request. These parameters include communication parameters (command number, address), test parameters (current value, percentage value, number of test points), and judgment parameters (error allowable range).

[0035] Specifically, upon receiving a test request for the cluster of devices under test, the system first retrieves the standard device description file corresponding to the specified device model from the database. This standard device description file has been pre-parsed by the EDD Engine interpreter, and the extracted basic device information, communication protocol rules, and interactive command definitions have been converted into XML strings and persistently stored in the database, eliminating the need for repeated parsing. From the parsed data stored in the database, immutable characteristic attributes such as device manufacturer identification, communication protocol type and version, interactive command number, and data packet composition rules are extracted. From the test request, dynamically configurable requirements such as the number of test points, target values ​​for each test point, and error judgment thresholds are extracted. Finally, the two types of parameters are integrated according to preset rules, and parameter compliance is verified (e.g., whether the command number matches the device protocol and whether the test value conforms to the data packet format requirements). After successful verification, structured test parameter information is generated.

[0036] S102. Based on the idle state of the data transmission module between the device under test cluster and the device under test cluster, perform concurrent point-marking tests on each device under test in the device under test cluster according to the test parameter information, and obtain the point-marking test results.

[0037] In this embodiment, the data transmission module is the hardware / software interaction unit in the DCS system that connects the host computer and the device under test (DUT). It is preferably an I / O module, compatible with different fieldbus protocols such as HART / Profibus / FF, and has the functions of sending test data packets and receiving device feedback data. Its working states include idle and busy. The idle state can be understood as the state where the data transmission module is not performing any test tasks and can immediately respond to new test commands. The test results can be understood as a set of judgments for one or more test points of the DUT, including the pass / fail conclusion for each test point, test process data (test data packet response delay, test time, actual valve position value convergence process value), error type and frequency, etc.

[0038] Specifically, the system first divides the cluster of devices under test (DUTs) into at least one test queue. It then iterates through each DUT in the queue, matching the corresponding data transmission module to the communication address and protocol type of each DUT. The system monitors the module's operational status in real time. If the module is busy, the DUT remains in the corresponding test queue; if the module is idle, the DUT is removed from the queue. The system then retrieves the corresponding test parameters, encapsulates a test data packet adapted to the device type according to the data packet format defined in the standard device description file, and sends it to the DUT through the data transmission module. Next, it performs corresponding data reading and comparison judgments for different DUT types. For example, for type 1 devices, it reads process variable values ​​and compares them with current test values; for type 2 devices, it reads the actual valve position value and compares it with percentage test values. Understandably, the system simultaneously executes the above process for DUTs corresponding to other idle modules, achieving parallel testing of multiple devices. After all devices are tested, the system summarizes the test point judgment results, process data, and error information for each device to form a complete point-based test result.

[0039] S103. Based on the test results, generate a health profile and test result analysis corresponding to the equipment model of the tested equipment, and generate corresponding equipment maintenance suggestions.

[0040] In this embodiment, the health profile corresponding to a device model is constructed based on the test results of multiple devices of the same model. Through cluster analysis of process data (response latency, convergence time), calculation of the overall failure rate, and identification of potential failure modes, an overall health status model of the device model is built, intuitively reflecting the common performance baseline and degradation trend of the model. Test result analysis involves analyzing test data for a single device or a cluster of devices of the same model, including comparative analysis of single device performance with historical data, performance difference analysis between devices of the same model, and analysis of the distribution patterns of error types. Device maintenance recommendations are personalized operation and maintenance strategies generated based on the health profile and test result analysis, including fault location recommendations, performance optimization recommendations, and recommendations for preventative maintenance timing.

[0041] Specifically, the test results are first categorized and processed. For a cluster of devices of the same model, test point conclusions, process data, and error information are extracted from all devices to calculate the overall failure rate of that model. Cluster analysis of process data such as response delay and convergence time is used to establish a baseline health profile for that model. Simultaneously, for individual devices under test, the current test data is compared with historical stored data to analyze performance trends. Combined with the health profile, potential failure modes (such as response speed degradation or unstable output) are identified. Based on these analyses, a multi-dimensional test result analysis report is generated, including a summary of common problems at the model level and the location of individual problems for each device. Finally, targeted equipment maintenance recommendations are output based on the analysis report. For example, for valve positioners with significantly increased response delay, it is recommended to check the air source or valve stem friction; for the second type of equipment with prolonged output value convergence time, the risk of control parameter drift is highlighted, achieving closed-loop management from test data to maintenance decisions.

[0042] This invention provides a point-based testing method, comprising: acquiring a point-based testing request for a cluster of devices under test; calling a pre-stored standard device description file according to the point-based testing request; determining test parameter information of the devices under test based on the standard device description file and the point-based testing request; performing concurrent point-based testing on each device under test in the cluster based on the idle state of the data transmission module between the device under test and the cluster of devices under test, and obtaining point-based testing results; generating a health profile and test result analysis corresponding to the device model of the devices under test based on the point-based testing results, and generating corresponding device maintenance suggestions. The above technical solution directly extracts test parameters automatically through standardized files, simplifies rule definition steps, reduces operational difficulty, achieves accurate adaptation of test parameters, and ensures test effectiveness; performs concurrent point-based testing on multiple devices based on the idle state of the data transmission module, improving test efficiency and resource utilization, and shortening test time; and extends the value of testing to operation and maintenance.

[0043] Optionally, the method, prior to S101, further includes:

[0044] a1. Obtain standard device description files for different device models. For each standard device description file, call the interpreter to parse the standard device description file to obtain device description information. The device description information includes at least the device's basic identity information, device communication protocol attribute information, and device interaction command attribute information.

[0045] In this embodiment, the interpreter is an EDD Engine, a tool for parsing standard device description files in EDDL format. Device description information can be understood as structured data obtained after the interpreter parses the standard device description file, including at least basic device identity information, device communication protocol attribute information, and device interaction command attribute information. Specifically, the basic device identity information is used to uniquely identify the device under test, including inherent attributes such as manufacturer identifier, device model, and device version number; the device communication protocol attribute information is the communication rules information between the device and the DCS system, including protocol type, version number, and communication data packet composition rules; and the device interaction command attribute information is the instruction and data interaction format information supported by the device, including the interaction data packet command number and the definition of the request and response data packet content.

[0046] Specifically, the system first obtains standard device description files corresponding to different device models in batches. For each file, it calls the EDDEngine interpreter to perform parsing operations. During the parsing process, it extracts basic device identity information, device communication protocol attribute information, and device interaction command attribute information from the standard device description files in sequence. It integrates the three types of information into structured device description information, completing the conversion from EDDL language to system-recognizable data.

[0047] b1. Convert the device description information into a set format, and associate and store the standard device description file and the device description information in the set format in the database.

[0048] In this embodiment, the format setting can be understood as a standardized data format that facilitates system storage, retrieval, and retrieval, such as an XML format string.

[0049] Specifically, the parsed device description information is converted into an XML format string, and a relationship is established between the standard device description file and the XML format device description information in the database. Both are then persistently stored in the database to avoid repeatedly parsing the file during each subsequent test, thus significantly improving the efficiency of test parameter retrieval.

[0050] c1. Import the system configuration of the current system, determine the communication address of each device under test based on the system configuration, and the mapping data points of the input and output data of each device under test in the current system, configure the read and write permissions of the mapping data points, and associate the communication address, mapping data points and the read and write permissions of the mapping data points with the standard device description file corresponding to the device model of the device under test, and store them in the database.

[0051] In this embodiment, system configuration can be understood as the field configuration data of the DCS system, including the physical deployment information of the device under test, communication link configuration, data interaction rules, etc. Mapped data points are the corresponding identifiers of the input / output data of the device under test in the DCS system, used to enable the DCS system to read and write data to the device; read and write permissions are the operation permissions configured for the mapped data points, determining whether the DCS system can perform read and write actions on the data points.

[0052] Specifically, the system configuration data of the current DCS system is imported. Based on the configuration information, the physical communication address of each device under test is matched. Simultaneously, the corresponding mapping data points for the device's input / output data in the system are determined. Read and write permissions are configured for each mapping data point according to testing requirements (e.g., write permissions are required for writing test parameters, and read permissions are required for reading device feedback data). The communication address, mapping data point, and read / write permissions for the mapping data point are stored in the database. An association link is established between the communication address, mapping data point, read / write permissions, device model, and standard device description file, providing a precise configuration basis for subsequent concurrent test command issuance and data interaction.

[0053] Optionally, based on the idle state of the data transmission module between the device under test (DUT) cluster and the DUT cluster, concurrent point-based testing is performed on each DUT in the DUT cluster according to the test parameter information to obtain the point-based test results, including:

[0054] a2. Divide all devices under test in the device cluster into at least one test queue, and traverse each test queue.

[0055] In this embodiment, the test queue can be understood as a collection of devices under test waiting to be tested. All devices under test in the device under test cluster can be divided into one or more queues according to different rules such as device type, test priority, and number of devices, so as to achieve orderly scheduling of test tasks.

[0056] Specifically, the cluster of devices to be tested is first divided into one or more test queues according to preset rules, and each device under test in each test queue is traversed.

[0057] b2. For each device under test in the test queue, determine whether the data transmission module corresponding to the device under test is idle based on the communication address of the device under test.

[0058] In this embodiment, the communication address can be understood as the unique communication identifier address of the device under test in the DCS system.

[0059] Each data transmission module can connect to multiple devices under test through different serial ports. However, at any given time, only one device under test corresponding to the serial port of each data transmission module can perform the point-marking test. Therefore, the status of the data transmission module needs to be checked before performing the point-marking test.

[0060] Specifically, for each device under test (DUT) encountered, the corresponding data transmission module is matched based on its communication address. All serial ports under that data transmission module are scanned in real time to determine if any are already occupied. If a busy serial port is found, the data transmission module is determined to be in an unschedulable busy state, and the DUT must continue waiting in the test queue. If no busy serial port is found, the data transmission module is determined to be idle and can respond to the test requests from the DUT.

[0061] c2. If the data transmission module corresponding to the device under test is in an idle state, remove the device under test from the test queue, and perform point testing on the device under test based on the device type and test parameter information to obtain the point testing results.

[0062] In this embodiment, the device type is a category classified according to the working principle and testing logic of the device. Different types of devices correspond to different testing parameters and procedures.

[0063] Specifically, if the data transmission module corresponding to a device is detected to be idle, the device is first removed from the test queue to avoid repeated scheduling. Then, based on the device type, the test parameter information adapted to the device type generated by S101 is retrieved, a test data packet conforming to the device communication protocol is encapsulated, and sent to the device under test through the idle data transmission module. Finally, test actions such as data reading and comparison are performed to complete the point-marking test of the device and generate the corresponding point-marking test results. At the same time, the above scheduling logic is continuously executed on other devices in the test queue to achieve concurrent testing of multiple devices.

[0064] Furthermore, based on the device type of the device under test, a point-marking test is performed on the device under test according to the test parameter information to obtain the point-marking test results, including:

[0065] a3. If the device under test is a type 1 device under test, a test data packet is generated based on the fixed communication command number, the current test value of at least one test point and the communication address of the device under test in the test parameter information, and the test data packet is sent to the device under test through the data transmission module.

[0066] In this embodiment, the first type of device under test (DUT) is an analog input (AI) type DUT, which is an industrial intelligent device that uses a current signal (e.g., 4-20mA) as the core testing and feedback carrier. It requires point-based testing and judgment based on the current test value. The fixed communication command number is an inherent and unchangeable interaction instruction identifier parsed from the standard device description file, used to specify the function type of the test instruction and ensure that the device can recognize and respond to the test request. The current test value is a preset target current parameter for the first type of device. The test data packet is a standardized data unit that integrates the fixed communication command number, current test value, communication address, and other information, following the device communication protocol format.

[0067] Specifically, if the device under test is a Type I device, the test parameter information generated by S101 is first called to extract the fixed communication command number, the current test value of at least one test point, and the communication address of the device. The above information is integrated and encapsulated into a test data packet according to the data packet format specified by the device communication protocol (such as HART). Finally, the test data packet is sent to the target device under test through the data transmission module of the allocated serial port to trigger the device to execute the corresponding test action.

[0068] b3. Read the process variable values ​​of the corresponding mapped data points of the device under test in the current system at the preset frequency, compare the process variable values ​​with the current test values ​​of the corresponding test points one by one, and determine the result of each test point based on the comparison results and the preset error allowable range.

[0069] In this embodiment, the preset frequency is a fixed time interval for the DCS system to read data from the device feedback. The process variable (PV) value is the actual operating current data fed back by the first type of device after receiving the test data packet. The preset error allowable range is a threshold standard for determining whether the test point is qualified.

[0070] Specifically, according to a preset frequency, the process variable value PV (i.e., actual current value) fed back from the corresponding mapped data point of the device in the current DCS system is continuously read; for each test point, the collected process variable value is compared with the preset current test value one by one, and the difference between the two is calculated; if the difference is within the preset error allowable range, the test point is judged to be qualified; if the difference exceeds the preset error allowable range, the test point is judged to be unqualified.

[0071] c3. Summarize the test results of all test points, generate the test results of the device under test, and record the test process data and error type information. The test process data should include at least the response delay of the test data packet and the total test time of each device under test. The error type information should include at least the error type and the frequency of error type occurrence.

[0072] In this embodiment, the test process data is the operation and maintenance analysis data generated during the test execution process, which includes at least the test data packet response delay and the total test time; the error type information is the data on the classification and frequency of anomalies that occur during the test, which includes at least the error type and the frequency of error type occurrence.

[0073] Specifically, the pass / fail judgment results of all test points are summarized to form a complete point-based test result for the first type of tested device; at the same time, test process data and error type information are recorded synchronously. Among them, the test process data should at least include the delay time from the issuance of the test data packet to the receipt of the first response, and the total time taken for the device to complete the judgment of all test points from the issuance of the command. The error type information should at least classify and record the types of anomalies that occurred during the test (such as communication timeout, data anomaly) and the frequency of occurrence of each type of anomaly; finally, the point-based test results, process data, and error information are stored together to provide data support for the subsequent generation of health profiles.

[0074] For example, for AI-type HART devices: ① The input to the AI ​​device is a current value, specified by the user as 4-20mA. In the industrial control industry, tests are typically conducted at 3 or 5 points, divided into 3 points (4mA, 12mA, and 20mA). ② According to the standard DD document and HART protocol, the fixed communication command number for AI-type HART devices is 40. The current value is written into the data packet, which puts the device into a fixed current mode. ③ The data packet containing the current value is directly transmitted point-to-point to the intelligent device through the DCS system. ④ Every 500ms, the DCS tag number PV value corresponding to the device's output value is read from the DCS system. This value is compared with the input current, with an error margin of ±1%. If the comparison result is within the error range, the test point is considered to have passed; otherwise, the reading is retried for 3 seconds. If all three comparisons fail, the test point is considered to have failed. ⑤ The above process is repeated according to the number of test points until all test points are completed, and the test results are displayed. ⑥ The test results are recorded in the database for easy retrieval later.

[0075] Furthermore, based on the device type of the device under test, a point-marking test is performed on the device under test according to the test parameter information to obtain the point-marking test results, including:

[0076] a4. If the device under test is a type II device under test, a test data packet is generated based on the percentage test value of at least one test point, the valve position variable identifier, and the communication address of the device under test in the test parameter information. The test data packet is then sent to the device under test through the data transmission module.

[0077] In this embodiment, the second type of device under test (DUT) is an analog output (AO) type DUT, which is an industrial intelligent device with parameters such as valve position opening as the core test object. Performance judgment needs to be completed based on percentage test values ​​and actual valve position feedback. The percentage test value can be understood as a preset target control value for the controlled parameters such as valve position, representing the expected operating state of the device in percentage form (e.g., valve position opening 50%). The valve position variable identifier can be understood as identification information parsed from the standard device description file, used to uniquely identify the valve position parameters of the DUT. The test data packet can be understood as a standardized data unit that integrates percentage test values, valve position variable identifiers, communication addresses, and other information, following the device communication protocol format, and is used to issue control commands to the second type of device.

[0078] Specifically, if the device under test is of type AO, the test parameter information generated by S101 is retrieved first, and the percentage test value, valve position variable identifier, and communication address of at least one test point are extracted. The above information is integrated and encapsulated into a test data packet according to the data packet format specified by the communication protocol adapted to the device (such as HART or Profibus). The test data packet is sent to the target device under test through the data transmission module of the allocated serial port, triggering the device to perform valve position adjustment.

[0079] b4. Write at least one percentage test value to the corresponding mapped data point of the device under test in the current system according to the test data packet, read the actual valve position value of the device under test at a preset frequency, compare the actual valve position value with the percentage test value of the corresponding test point one by one, and determine the result of each test point according to the comparison result and the preset error allowable range.

[0080] In this embodiment, the actual valve position value can be understood as the actual valve opening value fed back by the device under test after receiving the test data packet and performing the action.

[0081] Specifically, according to the instructions in the test data packet, a percentage test value is written to the corresponding mapped data point of the device in the DCS system; simultaneously, the actual valve position value fed back by the device under test is continuously read at a preset frequency, and the valve position data at the final stable state is recorded. Real-time data during the valve position adjustment process is collected synchronously to form the convergence process value of the actual valve position value. For each test point, the final stable actual valve position value is compared with the preset percentage test value one by one, and the difference between the two is calculated; if the difference is within the preset error allowable range, the test point is judged to be qualified; if the difference exceeds the preset error allowable range, the test point is judged to be unqualified.

[0082] c4. Summarize the test results of all test points, generate the test results of the device under test, and record the test process data and error type information. The test process data should include at least the response delay of the test data packet, the total test time of each device under test, and the convergence process value of the actual valve position. The error type information should include the error type and the frequency of error type occurrence.

[0083] In this embodiment, the convergence process value of the actual valve position is the set of real-time valve position data at different time points during the process of adjusting the valve position from the current state to the target state. The preset frequency is a fixed time interval at which the system reads the actual valve position value.

[0084] Specifically, the pass / fail judgment results of all test points are summarized to form a complete point-based test result for this type of tested equipment. Simultaneously, test process data and error type information are recorded. The test process data includes at least the response delay from the issuance of the test data packet to the receipt of the first valve position feedback, the total time taken for the equipment to complete all test point judgments from the issuance of the command, and the convergence process value of the actual valve position. Error type information is categorized and recorded, recording the types of anomalies that occurred during the test (such as valve position adjustment timeout, abnormal data feedback), and the frequency of each anomaly. Finally, the point-based test results, process data, and error information are stored together to provide data support for subsequent equipment health profile generation and maintenance recommendation output.

[0085] For example, for an AO type HART device: ① The input to the AO device is written to a specific tag number through the DCS system. This value is then input to the smart device via the IO module. Generally, tests are performed at 3 or 5 points, divided into percentages, with the input value being a decimal representation of the percentage. ② Based on the master variables configured for this device model, a request data packet is formed and sent to the smart device. The response data packet from the smart device is obtained and parsed to retrieve its value. ③ The value of the AO device is a changing process, slowly approaching the input value. The device's master variables are read every 3 seconds, and compared to the input value for an error of ±1%. If the master variables are equal to the input value for 3 consecutive times, the test point is considered passed. If the master variable value remains unchanged for 3 consecutive times, or if the master variable is still not equal to the input value after a 5-minute timeout, the test point is considered a failure. ④ The above process is repeated based on the number of test points until all test points are completed, and the test results are displayed. ⑤ The test results are recorded in the database for later retrieval.

[0086] Optionally, based on the test results, a health profile and test result analysis corresponding to the equipment model of the tested equipment can be generated, and corresponding equipment maintenance suggestions can be generated, including:

[0087] a5. For the same model of devices under test in the device under test cluster, calculate the overall failure rate of each device model based on the point test results, and perform cluster analysis on the test process data to generate a health profile of each device model of device under test.

[0088] In this embodiment, the same model of device under test can refer to industrial intelligent devices with completely identical manufacturer identification, device model, and version number. The standard device description files for devices of the same model are identical, and the list of readable and writable data items, as well as the names, lengths, data types, and other attributes of each data item, are unified. The overall failure rate can be understood as the proportion of devices failing the test within a cluster of devices of the same model out of the total number of devices tested for that model. The health profile can be understood as a device status model constructed based on the overall failure rate and cluster analysis results of devices of the same model, used to reflect the performance baseline, degradation trend, and common failure risks of that model of device.

[0089] Specifically, the tested equipment cluster is first categorized by model. For each model, the number of non-compliant devices is counted based on the results of the point-based test, and the overall failure rate of that model is calculated. Simultaneously, test process data (response delay, total point-based test time, valve position convergence process value, etc.) of all devices of that model are extracted, and cluster analysis is performed to group devices with similar data characteristics into one category, identifying common performance characteristics of that model (such as a common problem of long response delay for a certain model). Finally, combining the overall failure rate and the cluster analysis results, a health profile of that model is constructed, presenting the model-level performance benchmark and failure distribution pattern.

[0090] b5. Based on the health profile and test process data, identify the potential failure modes of the tested equipment corresponding to the equipment model, and store the standard equipment description file associated with the potential failure modes and equipment models in the database.

[0091] In this embodiment, potential failure modes are the types of failures and causes that are prone to occur in this model of equipment, identified from the health profile (such as excessive response delay or valve position adjustment error), which serve as the basis for developing preventive maintenance strategies.

[0092] Specifically, based on the generated health profile and combined with the standard equipment description file for this model of equipment (such as the list of readable and writable data items defined in the file and the name, length, data type, and other attributes of each data item), potential fault modes of this model of equipment are identified. For example, if cluster analysis shows that the valve position convergence process values ​​of a certain model of AO equipment generally exceed the standard range, and the length and type of the corresponding data items do not match the test instructions, then "abnormal valve position adjustment parameter configuration" is determined to be a potential fault mode of this model of equipment. The identified potential fault modes are associated with the standard equipment description file of this model of equipment and stored in the database to provide a reference for the subsequent testing and maintenance of the same model of equipment.

[0093] c5. For each device under test, compare the test process data of the device under test, determine the performance change trend of the device under test, and generate corresponding personalized equipment maintenance suggestions.

[0094] In this embodiment, the performance change trend is the result of comparing the data from the current test with historical test data for a single device under test, used to determine the direction of performance degradation or optimization. Personalized device maintenance recommendations are targeted operation and maintenance guidance strategies generated based on the performance change trend of a single device and potential fault modes at the model level.

[0095] Specifically, for each device under test in the cluster, its historical test data is retrieved, and the current data is compared with the historical data to analyze the performance change trend of the device. For example, if the response latency of a device increases by 30% compared with the historical average, it is determined that its performance has degraded. Finally, combined with the potential failure modes of the device model and its own performance change trend, personalized device maintenance suggestions are generated. For example, for devices with degraded response latency, it is recommended to check the communication link or calibrate the device parameters; for devices with excessive valve position adjustment, it is recommended to maintain the actuator and rematch the data item parameters.

[0096] Optionally, the method further includes:

[0097] a6. For each second type of device under test, monitor the actual value change of the valve position. If the actual value change of the valve position indicates that there is abnormal behavior, terminate the point test of the device under test and generate an error warning message.

[0098] In this embodiment, the actual valve position value change status can be understood as the real-time change characteristics of the actual valve position value over time after the second type of tested device receives the percentage test value command, including the rate of change, fluctuation range, and whether abnormal behaviors such as jumps / stagnation occur. Abnormal behavior refers to unexpected states that occur during the change of the actual valve position value, such as no valve position response, jumps exceeding the normal range, and excessively large value fluctuations. Error warning information is an alarm prompt generated for abnormal valve position behavior, including information such as the time of abnormality occurrence, device identifier, and abnormality type.

[0099] Specifically, for each Type II tested device, after issuing the percentage test value command, the actual valve position value is read in real time from the mapped data points based on the valve position data item name, length, and data type defined in the standard device description file, and its change status is continuously monitored. If abnormal behavior such as no valve position response, value jumps exceeding the normal range, or failure to approach the target value for an extended period is detected, the point-tracking test for that device is immediately terminated to prevent the fault from escalating, and an error warning message containing the abnormal device identifier, abnormal type, and occurrence time is generated and simultaneously pushed to the operation and maintenance terminal.

[0100] b6. If the actual valve position value change indicates that there is no abnormal behavior, after completing the point test of the device under test, generate a convergence curve based on the actual valve position value of different test points. Based on the fluctuation amplitude and convergence time of the convergence curve, determine whether the dynamic response characteristics of the device under test meet expectations. If not, combine the historical test data of the device under test to determine the equipment performance degradation trend and generate degradation warning information.

[0101] In this embodiment, the convergence curve is a curve plotted with time on the horizontal axis and the actual valve position value on the vertical axis, intuitively reflecting the entire process of adjusting the valve position from the initial state to the target percentage test value. The fluctuation amplitude is the maximum difference between the actual valve position value and the steady-state value during the convergence curve's approach to the target value, used to reflect the stability of the device's valve position adjustment. The convergence time is the total time from issuing the test command to the actual valve position value stabilizing within the preset error allowable range, used to reflect the response speed of the device's valve position adjustment. The dynamic response characteristic is the ability of the device to transition the valve position parameters from the initial state to a stable state after receiving the control command, determined by both the fluctuation amplitude and the convergence time. Historical test data can be understood as the data set generated by the device under test in previous executions of similar test tasks before this point-based test, including historical point-based test results, historical test process data (response delay, total time, valve position convergence process value, etc.), historical error type information, etc. Historical test data is stored in the database in association with the device model and unique device identifier (device serial number). Equipment performance degradation trends are determined by comparing the dynamic response characteristic data from this test with historical data to identify patterns in equipment performance changes, such as gradually increasing convergence time and continuously increasing fluctuation amplitude, reflecting signs of equipment aging or impending failure. Degradation warning information is a preventative alert generated based on performance degradation trends, including degradation parameters, degradation level, and recommended maintenance measures.

[0102] Specifically, if the actual valve position value changes without abnormalities, after completing the point-by-point tests at all test points, the system plots a convergence curve based on the collected valve position value data throughout the process. The system extracts the fluctuation amplitude and convergence time of the curve and compares it with the performance baseline derived from the health profile of this model of equipment to determine whether the dynamic response characteristics meet expectations. If the fluctuation amplitude exceeds the standard or the convergence time is too long, the system further retrieves historical test data for the equipment, compares and analyzes the changing patterns of the dynamic response indicators, and determines the trend of equipment performance degradation (e.g., a 20% increase in convergence time compared to the previous test indicates response speed degradation). Finally, a degradation warning message is generated, determining the degradation parameters, the degree of degradation, and targeted maintenance recommendations (e.g., cleaning the valve stem, calibrating the positioner), achieving closed-loop management from testing process monitoring to preventative maintenance.

[0103] Optionally, the method further includes:

[0104] a7. If the test end conditions are met, send a stop current mode command to the device under test. The test end conditions include test completion, test failure, and receiving a terminate test command through the operation interface.

[0105] In this embodiment, the test termination condition can be understood as the judgment condition that triggers the termination of the test process, including test completion (all test points of the device under test have been executed and data acquisition has been completed), test failure (an unrecoverable anomaly occurs during the test, such as communication interruption or device unresponsiveness), and receiving a termination test command (a stop command actively issued by the user through the operation interface). The stop current mode command is an interactive instruction defined based on the standard device description file of the device under test. It is a standardized control instruction used to instruct the device under test to exit the test state and restore to the normal operation mode. Its command number and request / response data packet format are derived from the device interactive instruction attribute information. The operation interface is the human-machine interaction entry point provided by the DCS system, which supports users to manually trigger the test termination operation.

[0106] Specifically, the system continuously monitors the operating status during testing, determining in real time whether the preset test termination conditions are met. This includes situations where the device under test (DUT) completes all test point marking, data acquisition, and result determination; or where a fault occurs during testing, such as device unresponsiveness or data anomalies, preventing further testing; or where a manual termination command is received from the user via the operation interface. The system then retrieves the standard device description file corresponding to the DUT, extracting a list of readable and writable data items and their names, lengths, data types, and other attribute information. Based on this information, it matches the command identifier corresponding to the current mode and encapsulates the stop command data packet according to the format specified in the device communication protocol. This forms a stop current mode command, which is then sent to the DUT via the data transmission module, instructing the device to exit the test mode and resume normal operation, thus preventing the device from being in a prolonged testing state and affecting on-site production.

[0107] In one embodiment, Figure 2 This is a schematic diagram of the structure of a dot-marking test device provided in an embodiment of the present invention. Figure 2 As shown, the device includes:

[0108] The test information determination module 21 is used to obtain a point-marking test request for the cluster of devices under test, call a pre-stored standard device description file according to the point-marking test request, and determine the test parameter information of the device under test according to the standard device description file and the point-marking test request.

[0109] The dot-mapping test module 22 is used to perform concurrent dot-mapping tests on each device under test in the device under test cluster based on the idle state of the data transmission module between the device under test cluster and the device under test cluster, according to the test parameter information, and obtain the dot-mapping test results.

[0110] The test evaluation module 23 is used to generate a health profile and test result analysis corresponding to the equipment model of the tested equipment based on the point test results, and to generate corresponding equipment maintenance suggestions.

[0111] The dot-marking testing device used in this technical solution improves testing efficiency and reduces operational complexity.

[0112] Optionally, the device further includes a file pre-storage module, specifically used for:

[0113] Obtain standard device description files for different device models. For each standard device description file, call the interpreter to parse the standard device description file to obtain device description information. The device description information includes at least basic device identity information, device communication protocol attribute information, and device interaction command attribute information.

[0114] The device description information is converted into a set format, and the standard device description file and the device description information in the set format are associated and stored in the database.

[0115] Import the system configuration of the current system, determine the communication address of each device under test and the mapping data point of the input and output data of each device under test in the current system based on the system configuration, configure the read and write permissions of the mapping data point, and associate the communication address, mapping data point and the read and write permissions of the mapping data point with the standard device description file corresponding to the device model of the device under test and store it in the database.

[0116] Optionally, the dot-marking test module 22 includes:

[0117] The test queue partitioning unit is used to partition all devices under test in the device under test cluster into at least one test queue and traverse each test queue.

[0118] The idle state determination unit is used to determine whether the data transmission module corresponding to each device under test in the test queue is in an idle state based on the communication address of the device under test.

[0119] The dot-mapping test unit is used to remove the device under test from the test queue if the data transmission module corresponding to the device under test is in an idle state, and to perform dot-mapping tests on the device under test based on the device type of the device under test and the test parameter information to obtain the dot-mapping test results.

[0120] Optionally, the dot-marking test unit is specifically used for:

[0121] If the device under test is a first type of device under test, a test data packet is generated based on the fixed communication command number, the current test value of at least one test point and the communication address of the device under test in the test parameter information, and the test data packet is sent to the device under test through the data transmission module.

[0122] Read the process variable values ​​of the corresponding mapped data points of the device under test in the current system at a preset frequency, compare the process variable values ​​with the current test values ​​of the corresponding test points one by one, and determine the result of each test point based on the comparison results and the preset error allowable range.

[0123] Summarize the test results of all test points to generate the test results of the device under test, and record the test process data and error type information. The test process data includes at least the response delay of the test data packet and the total test time of each device under test. The error type information includes at least the error type and the frequency of error type occurrence.

[0124] Optionally, the dot-marking test unit is specifically used for:

[0125] If the device under test is a second type of device under test, a test data packet is generated based on the percentage test value of at least one test point in the test parameter information, the valve position variable identifier and the communication address of the device under test, and the test data packet is sent to the device under test through the data transmission module.

[0126] According to the test data packet, write at least one percentage test value to the corresponding mapped data point of the device under test in the current system, read the actual valve position value of the device under test at a preset frequency, compare the actual valve position value with the percentage test value of the corresponding test point one by one, and determine the result of each test point according to the comparison result and the preset error allowable range.

[0127] The test results of all test points are summarized to generate the test results of the device under test, and the test process data and error type information are recorded. The test process data includes at least the response delay of the test data packet, the total test time of each device under test, and the convergence process value of the actual value of the valve position. The error type information includes the error type and the frequency of error type generation.

[0128] Optionally, the test evaluation module 23 is specifically used for:

[0129] For the same model of devices under test in the device cluster, the overall failure rate of each device model is calculated based on the point test results, and cluster analysis is performed on the test process data to generate a health profile of each device model.

[0130] Based on the health profile and the test process data, identify the potential fault modes of the tested equipment of the corresponding equipment model, and store the potential fault modes in the database in association with the standard equipment description file of the equipment model.

[0131] For each device under test, the test process data of the device under test is compared to determine the performance change trend of the device under test, and corresponding personalized equipment maintenance suggestions are generated.

[0132] Optionally, the device further includes a device early warning module, specifically used for:

[0133] For each second type of device under test, monitor the actual value change of the valve position of the device under test. If the actual value change of the valve position indicates that there is abnormal behavior, terminate the point test of the device under test and generate an error warning message.

[0134] If the change in the actual valve position indicates that there is no abnormal behavior, after completing the point test of the device under test, a convergence curve is generated based on the actual valve position values ​​of different test points. Based on the fluctuation amplitude and convergence time of the convergence curve, it is determined whether the dynamic response characteristics of the device under test meet expectations. If they do not meet expectations, the device performance degradation trend is determined by combining the historical test data of the device under test, and degradation warning information is generated.

[0135] Optionally, the device further includes a test termination module, specifically used for:

[0136] If the test termination conditions are met, a stop current mode command is sent to the device under test. The test termination conditions include test completion, test failure, or receiving a terminate test command through the operation interface.

[0137] The dot-marking test device provided in the embodiments of the present invention can execute the dot-marking test method provided in any embodiment of the present invention, and has the corresponding functional modules and beneficial effects of the execution method.

[0138] In one embodiment, Figure 3 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention. For example... Figure 3The diagram illustrates a schematic representation of an electronic device 10 that can be used to implement embodiments of the present invention. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices (e.g., helmets, glasses, watches, etc.), and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the invention described and / or claimed herein.

[0139] like Figure 3 As shown, the electronic device 10 includes at least one processor 11 and a memory, such as a read-only memory (ROM) 12 or a random access memory (RAM) 13, communicatively connected to the at least one processor 11. The memory stores computer programs executable by the at least one processor. The processor 11 can perform various appropriate actions and processes based on the computer program stored in the ROM 12 or loaded into the RAM 13 from storage unit 18. The RAM 13 can also store various programs and data required for the operation of the electronic device 10. The processor 11, ROM 12, and RAM 13 are interconnected via a bus 14. An input / output (I / O) interface 15 is also connected to the bus 14.

[0140] Multiple components in electronic device 10 are connected to I / O interface 15, including: input unit 16, such as keyboard, mouse, etc.; output unit 17, such as various types of displays, speakers, etc.; storage unit 18, such as disk, optical disk, etc.; and communication unit 19, such as network card, modem, wireless transceiver, etc. Communication unit 19 allows electronic device 10 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0141] Processor 11 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of processor 11 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various processors running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. Processor 11 performs the various methods and processes described above, such as the dot-mapping test method.

[0142] In some embodiments, the dot-matrix testing method may be implemented as a computer program tangibly contained in a computer-readable storage medium, such as storage unit 18. In some embodiments, part or all of the computer program may be loaded and / or installed on electronic device 10 via ROM 12 and / or communication unit 19. When the computer program is loaded into RAM 13 and executed by processor 11, one or more steps of the dot-matrix testing method described above may be performed. Alternatively, in other embodiments, processor 11 may be configured to perform the dot-matrix testing method by any other suitable means (e.g., by means of firmware).

[0143] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), payload-programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0144] Computer programs used to implement the methods of the present invention may be written in any combination of one or more programming languages. These computer programs may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device, such that when executed by the processor, the computer programs cause the functions / operations specified in the flowcharts and / or block diagrams to be performed. The computer programs may be executed entirely on a machine, partially on a machine, or as a standalone software package, partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0145] In the context of this invention, a computer-readable storage medium can be a tangible medium that may contain or store a computer program for use by or in conjunction with an instruction execution system, apparatus, or device. A computer-readable storage medium may include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination thereof. Alternatively, a computer-readable storage medium may be a machine-readable signal medium. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0146] To provide interaction with a user, the systems and techniques described herein can be implemented on an electronic device having: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user; and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the electronic device. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0147] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as data servers), or middleware components (e.g., application servers), or frontend components (e.g., user computers with graphical user interfaces or web browsers through which users can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., communication networks). Examples of communication networks include local area networks (LANs), wide area networks (WANs), blockchain networks, and the Internet.

[0148] A computing system can include clients and servers. Clients and servers are generally located far apart and typically interact through communication networks. The client-server relationship is created by computer programs running on the respective computers and having a client-server relationship with each other. The server can be a cloud server, also known as a cloud computing server or cloud host, which is a hosting product within the cloud computing service system to address the shortcomings of traditional physical hosts and VPS services, such as high management difficulty and weak business scalability.

[0149] This invention also provides a computer program product, including a computer program that, when executed by a processor, can implement the dot-mapping test method provided in any embodiment of this application.

[0150] In the implementation of the computer program product, computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof. Programming languages ​​include object-oriented programming languages ​​such as Java, Smalltalk, and C++, as well as conventional procedural programming languages ​​such as C or similar languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0151] It should be understood that the various forms of processes shown above can be used, with steps reordered, added, or deleted. For example, the steps described in this invention can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution of this invention can be achieved, and this is not limited herein.

[0152] The specific embodiments described above do not constitute a limitation on the scope of protection of this invention. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this invention should be included within the scope of protection of this invention.

Claims

1. A dot-marking test method, characterized in that, include: Obtain a point-tracking test request for the cluster of devices under test, call a pre-stored standard device description file according to the point-tracking test request, and determine the test parameter information of the devices under test according to the standard device description file and the point-tracking test request; Based on the idle state of the data transmission module between the device under test cluster and the device under test cluster, concurrent point-marking tests are performed on each device under test in the device under test cluster according to the test parameter information to obtain point-marking test results. Based on the test results, a health profile and test result analysis corresponding to the device model of the tested device are generated, and corresponding device maintenance suggestions are generated.

2. The method according to claim 1, characterized in that, Also includes: Obtain standard device description files for different device models. For each standard device description file, call the interpreter to parse the standard device description file to obtain device description information. The device description information includes at least basic device identity information, device communication protocol attribute information, and device interaction command attribute information. The device description information is converted into a set format, and the standard device description file and the device description information in the set format are associated and stored in the database. Import the system configuration of the current system, determine the communication address of each device under test and the mapping data point of the input and output data of each device under test in the current system based on the system configuration, configure the read and write permissions of the mapping data point, and associate the communication address, mapping data point and the read and write permissions of the mapping data point with the standard device description file corresponding to the device model of the device under test and store it in the database.

3. The method according to claim 1, characterized in that, Based on the idle state of the data transmission module between the device under test (DUT) cluster and the test parameter information, concurrent point-marking tests are performed on each DUT in the DUT cluster to obtain point-marking test results, including: All devices under test in the device under test cluster are divided into at least one queue to be tested, and each queue to be tested is traversed. For each device under test in the test queue, determine whether the data transmission module corresponding to the device under test is in an idle state based on the communication address of the device under test. If the data transmission module corresponding to the device under test is in an idle state, the device under test is removed from the test queue, and based on the device type of the device under test, a point test is performed on the device under test according to the test parameter information to obtain the point test result.

4. The method according to claim 3, characterized in that, The step of performing a point-marking test on the device under test based on the device type and the test parameter information to obtain the point-marking test results includes: If the device under test is a first type of device under test, a test data packet is generated based on the fixed communication command number, the current test value of at least one test point and the communication address of the device under test in the test parameter information, and the test data packet is sent to the device under test through the data transmission module. Read the process variable values ​​of the corresponding mapped data points of the device under test in the current system at a preset frequency, compare the process variable values ​​with the current test values ​​of the corresponding test points one by one, and determine the result of each test point based on the comparison results and the preset error allowable range. Summarize the test results of all test points to generate the test results of the device under test, and record the test process data and error type information. The test process data includes at least the response delay of the test data packet and the total test time of each device under test. The error type information includes at least the error type and the frequency of error type occurrence.

5. The method according to claim 3, characterized in that, The step of performing a point-marking test on the device under test based on the device type and the test parameter information to obtain the point-marking test results includes: If the device under test is a second type of device under test, a test data packet is generated based on the percentage test value of at least one test point in the test parameter information, the valve position variable identifier and the communication address of the device under test, and the test data packet is sent to the device under test through the data transmission module. According to the test data packet, write at least one percentage test value to the corresponding mapped data point of the device under test in the current system, read the actual valve position value of the device under test at a preset frequency, compare the actual valve position value with the percentage test value of the corresponding test point one by one, and determine the result of each test point according to the comparison result and the preset error allowable range. The test results of all test points are summarized to generate the test results of the device under test, and the test process data and error type information are recorded. The test process data includes at least the response delay of the test data packet, the total test time of each device under test, and the convergence process value of the actual value of the valve position. The error type information includes the error type and the frequency of error type generation.

6. The method according to claim 4 or 5, characterized in that, The process involves generating a health profile and test result analysis corresponding to the device model of the tested equipment based on the point-based test results, and generating corresponding equipment maintenance suggestions, including: For the same model of devices under test in the device cluster, the overall failure rate of each device model is calculated based on the point test results, and cluster analysis is performed on the test process data to generate a health profile of each device model. Based on the health profile and the test process data, identify the potential fault modes of the tested equipment of the corresponding equipment model, and store the potential fault modes in the database in association with the standard equipment description file of the equipment model. For each device under test, the test process data of the device under test is compared to determine the performance change trend of the device under test, and corresponding personalized equipment maintenance suggestions are generated.

7. The method according to claim 5, characterized in that, Also includes: For each second type of device under test, monitor the actual value change of the valve position of the device under test. If the actual value change of the valve position indicates that there is abnormal behavior, terminate the point test of the device under test and generate an error warning message. If the change in the actual valve position indicates that there is no abnormal behavior, after completing the point test of the device under test, a convergence curve is generated based on the actual valve position values ​​of different test points. Based on the fluctuation amplitude and convergence time of the convergence curve, it is determined whether the dynamic response characteristics of the device under test meet expectations. If they do not meet expectations, the device performance degradation trend is determined by combining the historical test data of the device under test, and degradation warning information is generated.

8. The method according to claim 1, characterized in that, Also includes: If the test termination conditions are met, a stop current mode command is sent to the device under test. The test termination conditions include test completion, test failure, or receiving a terminate test command through the operation interface.

9. A dot-marking test device, characterized in that, include: The test information determination module is used to obtain a point-marking test request for the cluster of devices under test, call a pre-stored standard device description file according to the point-marking test request, and determine the test parameter information of the devices under test according to the standard device description file and the point-marking test request. The dot-matrix test module is used to perform concurrent dot-matrix tests on each device under test in the device under test cluster based on the idle state of the data transmission module between the device under test and the cluster of devices under test and according to the test parameter information, so as to obtain the dot-matrix test results. The test evaluation module is used to generate a health profile and test result analysis corresponding to the equipment model of the tested equipment based on the point test results, and to generate corresponding equipment maintenance suggestions.

10. An electronic device, characterized in that, include: At least one processor; as well as A memory communicatively connected to the at least one processor; wherein, The memory stores a computer program that can be executed by the at least one processor, the computer program being executed by the at least one processor to enable the at least one processor to perform a dot-marking test method according to any one of claims 1-8.

11. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions that cause a processor to execute a dot-marking test method according to any one of claims 1-8.

12. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, implements a dot-marking test method according to any one of claims 1-8.

Images