A modular, scalable, transparent power distribution terminal multifunction test system and fault tracing method

Abstract

This invention discloses a modular, scalable, transparent, multi-functional testing system for power distribution terminals and a fault tracing method, relating to the field of electronic testing technology. It includes a power distribution terminal under test (PDT), a test function component module for encapsulating different test functions into independent functional plug-in units conforming to a unified interface specification for system invocation, a multi-protocol edge collaboration module for adapting to various communication protocols, converting heterogeneous data from the PDT into a standardized data format, and providing a consistent data service interface, an intelligent process control module for dynamically loading corresponding functional plug-in units according to test tasks, executing test processes according to preset parameters and logical serialization, and monitoring process status, and a test anomaly tracing module for collecting and correlating operational data from the test function component module, the multi-protocol edge collaboration module, and the intelligent process control module when test process execution anomalies, locating the root cause of the fault, and generating an anomaly tracing report.

Description

Technical Field

[0001] This invention relates to the field of electronic testing technology, and in particular to a modular, scalable, transparent, multi-functional testing system for power distribution terminals and a fault tracing method. Background Technology

[0002] Against the backdrop of the rapid development of Industry 4.0 and the Internet of Things (IoT) technologies, the research and application of various types of terminals in power systems are moving towards intelligence, miniaturization, and customization. Different types of terminals have different testing systems, testing functions, and performance requirements, posing unprecedented challenges to traditional power equipment production testing systems. Current equipment testing systems operate independently, with varying interface standards and data formats, making interconnection and data aggregation impossible. Testing processes are cumbersome, involve a large amount of manual operation, are inefficient, and struggle to meet the customized testing needs of different equipment. With the increasing variety of equipment, achieving efficient, unified, and flexible testing has become an urgent problem to be solved. Summary of the Invention

[0003] In view of the above-mentioned prior art, the present invention provides a modular, scalable, transparent power distribution terminal multi-functional testing system, which mainly solves the technical problems existing in the background art.

[0004] To achieve the above objectives, the technical solution of this invention is implemented as follows: In a first aspect, the present invention provides a modular, scalable, transparent, multi-functional testing system for power distribution terminals, including a power distribution terminal under test. The system also includes a testing function component module, a multi-protocol edge collaboration module, an intelligent process control module, and a test anomaly tracing module. The test function component module is used to encapsulate different test functions into independent functional plug-in units that follow a unified interface specification, and to provide them to the system for invocation through a dynamic loading mechanism; The multi-protocol edge collaboration module is used to adapt to multiple communication protocols, convert heterogeneous data of the power distribution terminal under test into a standardized data format, provide a consistent data service interface, and synchronize it to the intelligent process control module. The intelligent process control module is used to dynamically load the corresponding functional plug-in units according to the test task, execute the test process according to preset parameters and logical serialization, and monitor the process status. The test anomaly tracing module is used to collect and analyze the running data from the test function component module, the multi-protocol edge collaboration module and the intelligent process control module when an anomaly occurs during the execution of the test process, locate the root cause of the fault and generate an anomaly tracing report.

[0005] As a preferred embodiment of the present invention, the test function component module includes an interface specification unit, multiple functional plug-in units, and a plug-in loader; The interface specification unit is used to define the unified functional interface that all plug-in units must follow; Each of the multiple functional plug-in units inherits from the interface specification unit and encapsulates an independent test function, which is then compiled into an independent dynamic link library file. The plugin loader is used to dynamically load the dynamic link library file at runtime and instantiate a plugin object that conforms to the unified functional interface.

[0006] As a preferred embodiment of the present invention, the testing functions include hardware interface testing and functional testing. The hardware interface testing is used to test the RS485 interface, GPS interface, Bluetooth interface, 4G module interface, carrier interface, and external Flash interface. The functional testing is used to test the power-on / off function, telemetry calibration, remote signaling function, and remote control operation.

[0007] As a preferred embodiment of the present invention, the multi-protocol edge collaboration module includes a device service layer and an application layer. The device service layer is used to interface with power distribution terminals under test using different protocols, and convert the collected raw non-standardized data into unified Core Data standardized format data. The application layer establishes a communication connection with the device service layer through a predefined service interface, obtains the standardized format data output by the device service layer through the service interface, and realizes data interaction using a hybrid mode combining REST API polling and WebSocket protocol real-time push. At the same time, a data caching mechanism is introduced to maintain the continuity of data display by calling cached data in scenarios of network fluctuations or data transmission delays.

[0008] As a preferred embodiment of the present invention, the method of using a hybrid mode combining REST API polling and WebSocket real-time push to achieve data interaction specifically includes: All data points to be interacted with are classified and labeled, with low-frequency and non-real-time data labeled as the first category and high-frequency and real-time data labeled as the second category; For the first category, the application layer scheduler only enables the REST API polling channel. Its internal timer initiates synchronous query requests to the resource endpoints corresponding to the device service layer at preset long intervals. The device service layer processes the requests and returns the current value from its data pool. For the second category, the application layer scheduler starts a real-time push channel using the WebSocket protocol. After establishing a connection with the WebSocket protocol, the application layer sends a subscription message to the device service layer, listing all the second category data point paths that need to be pushed in real time. When the device service layer detects any update to a subscribed data point, it does not need to wait for a request and immediately pushes a standardized message frame containing the new data value to the application layer via the WebSocket protocol.

[0009] As a preferred embodiment of the present invention, a data caching mechanism is introduced at the application layer. In scenarios of network fluctuations or data transmission delays, cached data is invoked to maintain the continuity of data display. Specifically, this includes: A data cache is established at the application layer to store data from REST API polling and WebSocket protocol channel transmission in a structured data cache in real time. When network fluctuations cause data transmission delays or brief communication interruptions, a cache protection mechanism will be triggered. This mechanism intercepts data requests, prioritizes querying the data cache, and if the interception is successful, immediately returns the most recently successfully stored cached data and its timestamp.

[0010] As a preferred embodiment of the present invention, the test execution process of the intelligent process control module specifically includes: Based on the type of terminal under test and the user's test instructions, the corresponding functional plug-in units and their configuration files are scanned and loaded from the specified folder. The configuration files are parsed to obtain test parameters, and an automated test sequence is generated based on the test parameters and preset test logic. The multi-protocol edge collaboration module is invoked to send an excitation signal to the power distribution terminal under test and to receive its response data. After the test command is triggered, the response data is compared with the expected state, the test result is output, and during the execution process, communication timeouts or interruptions are automatically recovered according to the fixed number of retry strategies or exponential backoff retry strategies preset in the configuration file.

[0011] As a preferred embodiment of the present invention, the test anomaly tracing module includes a log parsing unit, a historical data comparison unit, a process dependency verification unit, an anomaly level determination unit, an automatic fault cause location unit, and a report tracing unit. The log parsing unit is used to collect and structure test logs, protocol interaction logs and status logs of each module generated during system operation, and performs log parsing based on the QTextBrowser component and the qInstallMessageHandler function. The historical data comparison unit obtains historical test data through the EdgeX service, and after data preprocessing, uses a trend analysis algorithm to complete the comparative analysis of historical data and current test data. The process dependency verification unit adopts a state machine model to abstract each module in the test process into a state node, clarifying the running state of each node; and parses the dependency relationship between each state node to construct a test process dependency graph; when a test exception occurs, it traverses the dependency graph to check the running state of the preceding associated modules of the exception module and locates the dependency exception point. The anomaly level determination unit is used to distinguish the anomaly level using different color codes on the QT interface according to the pre-set anomaly level determination rules. The automatic fault location unit is used to receive structured log data from the log parsing unit, trend analysis results from the historical data comparison unit, and dependency anomalies from the process dependency verification unit; and to perform correlation analysis based on a predefined anomaly rule library to output the most likely fault cause and location information. The report tracing unit is used to assign a unique test ID during each test, bind the device ID and various data generated in the test process to the unique test ID, and then use the database, with the unique test ID as the index, to query and integrate all test data of the relevant device ID to generate a tracing report.

[0012] As a preferred embodiment of the present invention, the status of each module in the process dependency verification unit includes inactive, executing, completed, and abnormal.

[0013] Secondly, the present invention also provides a modular, scalable, transparent, multi-functional test fault tracing method for power distribution terminals, characterized in that the method includes the following steps: Step S1: Collect and structure the test logs, protocol interaction logs, and status logs of each module generated during system operation, and parse the logs based on the QTextBrowser component and the qInstallMessageHandler function; Step S2: Obtain historical test data through EdgeX service, and after data preprocessing, use trend analysis algorithm to perform comparative analysis between historical data and current test data; Step S3: Using a state machine model, each module in the test process is abstracted into a state node, and the running state of each node is clarified; the dependency relationship between each state node is analyzed, and a dependency relationship graph of the test process is constructed; when a test exception occurs, the dependency relationship graph is traversed to check the running state of the preceding associated modules of the exception module and locate the dependency exception point. Step S4: Receive the structured log data from the log parsing unit, the trend analysis results from the historical data comparison unit, and the dependency anomalies from the process dependency verification unit; perform correlation analysis based on the predefined anomaly rule base, and output the most likely cause of the failure and its location information; Step S5: Assign a unique test ID during each test, and bind the device ID and various data generated in the test process to the unique test ID. Then, using the database and the unique test ID as the index, query and integrate all test data related to the device ID to generate a traceability report.

[0014] The beneficial effects of this invention are as follows: By adopting a modular testing architecture, this invention breaks down the testing process into standardized independent modules, and realizes intelligent linkage and plug-and-play expansion through status identifiers, thereby improving the system's flexibility and scalability and supporting the rapid access of new testing functions.

[0015] When testing IoT devices, EdgeX device services are used to ensure compatibility with differences in test devices. No need to develop multiple drivers. The system can automatically switch between RS485, Bluetooth, and 4G. The intelligent one-click testing process can reduce manual operations when testing devices in batches, generate test reports, and facilitate device production traceability. At the same time, combined with adaptive calibration of the testing process, the overall testing efficiency is improved. Multi-task parallel operation can be performed to improve production efficiency and reduce production costs. Attached Figure Description

[0016] Figure 1 This is a schematic diagram of a modular, scalable, transparent, multi-functional testing system for power distribution terminals. Figure 2 This is a schematic diagram illustrating the steps of a modular, scalable, transparent, multi-functional test fault tracing method for power distribution terminals. Detailed Implementation

[0017] The technical solution of the present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments. Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention pertains. The terminology used in this specification is for the purpose of describing particular embodiments only and is not intended to limit the invention. In the following description, the expression "some embodiments" refers to a subset of all possible embodiments; however, it should be understood that "some embodiments" can be the same subset or different subsets of all possible embodiments and can be combined with each other without conflict.

[0018] In the following description, numerous specific details are set forth in order to provide a more thorough understanding of the invention. However, it will be apparent to those skilled in the art that the invention can be practiced without one or more of these details. In other instances, certain technical features well-known in the art have not been described in order to avoid obscuring the invention.

[0019] It should be understood that the present invention can be embodied in various forms and should not be construed as being limited to the embodiments set forth herein. Rather, providing these embodiments will make the disclosure thorough and complete, and will fully convey the scope of the invention to those skilled in the art. Furthermore, the terminology used herein is intended only to describe particular embodiments and is not intended to limit the invention. When used herein, the singular forms “a,” “an,” and “the” are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the terms “compose” and / or “comprising,” when used in this specification, identify the presence of the stated features, integers, steps, operations, elements, and / or components, but do not exclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups. When used herein, the term “and / or” includes any and all combinations of the associated listed items.

[0020] It should also be noted that when an element is referred to as being "fixed to" another element, it can be directly attached to the other element or there may be an intervening element. When an element is referred to as being "connected to" another element, it can be directly connected to the other element or there may be an intervening element. The terms "vertical," "horizontal," "inner," "outer," "left," "right," and similar expressions used herein are for illustrative purposes only and do not represent the only possible implementation.

[0021] To fully understand this invention, a detailed structure will be presented in the following description to illustrate the technical solution proposed by this invention. Optional embodiments of the invention are described in detail below; however, in addition to these detailed descriptions, the invention may have other embodiments.

[0022] Please refer to the attached document. Figure 1 In a first aspect, the present invention provides a modular and scalable transparent power distribution terminal multi-functional testing system, including a power distribution terminal under test, and the system further includes a test function component module, a multi-protocol edge collaboration module, an intelligent process control module, and a test anomaly tracing module; The test function component module is used to encapsulate different test functions into independent functional plug-in units that follow a unified interface specification, and to provide them to the system for invocation through a dynamic loading mechanism; The multi-protocol edge collaboration module is used to adapt to multiple communication protocols, convert heterogeneous data of the power distribution terminal under test into a standardized data format, provide a consistent data service interface, and synchronize it to the intelligent process control module. The intelligent process control module is used to dynamically load the corresponding functional plug-in units according to the test task, execute the test process according to preset parameters and logical serialization, and monitor the process status. The test anomaly tracing module is used to collect and analyze the running data from the test function component module, the multi-protocol edge collaboration module and the intelligent process control module when an anomaly occurs during the execution of the test process, locate the root cause of the fault and generate an anomaly tracing report.

[0023] The testing system provided by this invention has the following workflow: The test function component module also includes a visual configuration component, a one-click test execution component, a telemetry calibration algorithm component, and a multi-interface adaptation component. Each component is an independent, pluggable unit that can be combined, configured, and parameter-set according to customized test requirements. The intelligent process control module receives the device identifier from the user-connected power distribution terminal under test, or uses it as an index to query a pre-set device feature database in the background. This database stores the functional configurations of different terminal models (such as whether they have a 4G module, GPS module, carrier communication, etc.).

[0024] Based on the device characteristics obtained from the query, the intelligent process control module automatically generates a list of test functions to be activated. For example, for devices with a 4G module, the list includes "4G interface test module"; for devices without GPS functionality, "GPS interface test module" is automatically excluded. This process achieves precise matching between test functions and the actual device configuration.

[0025] Simultaneously, the system retrieves the corresponding preset template from the test parameter template library based on the device identifier. This template defines all test parameters related to this device model, including protocol type (e.g., DL / T645, Modbus), accuracy threshold, performance indicators (e.g., remote signaling response time ≤50ms), and number of retries. The system parses the template parameters into a structured set of device-specific test parameters.

[0026] Based on the logical relationships between modules in the list of functions to be activated (e.g., communication interface testing must be completed before remote control function testing that depends on this communication channel can be performed), a dynamic dependency graph is initialized. The initial state of each node in the graph is set to "inactive". This results in a test plan that includes the list of functions to be activated, the device-specific test parameter set, and the initialized dynamic dependency graph.

[0027] Based on the user's "one-click test" start command issued through the human-machine interface and the test plan, the intelligent process control module first sends a specific debug mode switching command to the terminal under test through the multi-protocol edge collaboration module, causing the terminal to disable unnecessary functions and prepare for testing. After receiving a confirmation response from the terminal, the module records that the device has entered "debug mode".

[0028] Based on the dynamic dependency graph, execution is scheduled sequentially. Identify all nodes (i.e., test modules) in the graph whose state is "inactive" and all their prerequisites have been satisfied (state "completed"). For each node: Based on the function identifier corresponding to the node, the test function component module dynamically loads the corresponding function plug-in unit (DLL) and injects the relevant parameters from the device-specific test parameter set into the plug-in instance.

[0029] The intelligent process control module executes instructions from its plug-in. The plug-in may apply excitation signals to the terminal under test (DUT) by controlling an external standard signal source (such as applying standard current or voltage) or a digital output card (such as sending switching signals). Simultaneously, the plug-in sends corresponding test commands to the terminal through the standard data interface of the multi-protocol edge collaboration module.

[0030] The plugin collects terminal response data in real time through a multi-protocol edge collaboration module. The collected data (such as sampled values ​​and status messages returned by the terminal) is automatically compared and verified with the expected standard values ​​or status based on injected threshold parameters (such as accuracy threshold ±0.5%).

[0031] Based on the comparison results, the plugin determines whether the step "passes" or "fails." The intelligent process control module then updates the status of the node in the dynamic dependency graph to "completed" or "abnormal" and records the result in the log. If it is determined to be "passes," it automatically triggers the search for the next executable node, and the process continues; if it is "failed," the exception handling mechanism is triggered, as follows: Based on real-time generated test result data, communication link status reports, and a predefined rule base for anomaly classification and handling.

[0032] Data is monitored in real time at each test step. When situations such as communication timeouts, missing response data, or measurements exceeding allowable thresholds occur, the monitoring unit in the intelligent process control module or test anomaly tracing module immediately identifies them as an abnormal event. The system automatically classifies the event according to predefined rules (such as DataAnomalyType and DataAnomalySeverity). For example, "hardware interface unresponsive" is classified as "severe," and "single data instantaneous fluctuation" is classified as "warning."

[0033] For "critical" level anomalies: If the system determines that it is a possible critical fault (such as hardware damage), it will automatically terminate the current overall test process, generate a clear alarm message (such as "Hardware failure, please check the interface"), and wait for manual intervention.

[0034] For "warning" level or other recoverable anomalies (such as communication timeouts or intermittent packet loss): the system does not terminate the main process but automatically invokes a preset retry strategy. This strategy is read from the device-specific test parameter set and may be "fixed number of retries" (e.g., retrying 3 times immediately after failure) or "exponential backoff retries" (e.g., retrying after waiting 1 second for the first time, 2 seconds for the second time, and 4 seconds for the third time). The system automatically executes the retry operation.

[0035] After a retry, if a correct response is successfully received, the system clears the exception record, marks the current test step as "passed," and continues to execute subsequent processes, achieving self-recovery and resuming of the process. If the retry exhaustion fails, the step is ultimately judged as "failed," and its exception level may be escalated and handled according to the serious exception process or recorded and skipped (if the configuration allows).

[0036] All abnormal events, level determinations, retry processes, and final results are synchronously captured by the test anomaly tracing module and recorded in detail with a globally unique test traceability ID, providing a data foundation for the subsequent generation of in-depth analysis reports.

[0037] The test anomaly tracing module takes the test traceability ID as its core, integrates logs from the entire process, test data from each step, all anomaly events and handling records, historical comparative analysis results, etc., and automatically generates a structured comprehensive test and tracing report, presenting a complete test process, results list and problem analysis.

[0038] As a preferred embodiment of the present invention, the test function component module includes an interface specification unit, multiple functional plug-in units, and a plug-in loader; The interface specification unit is used to define the unified functional interface that all plug-in units must follow; Each of the multiple functional plug-in units inherits from the interface specification unit and encapsulates an independent test function, which is then compiled into an independent dynamic link library file. The plugin loader is used to dynamically load the dynamic link library file at runtime and instantiate a plugin object that conforms to the unified functional interface.

[0039] In this embodiment, based on the various testing functions (such as telemetry, remote signaling, and remote control) required by the system, one or more abstract interface classes are first defined. These classes are implemented as pure virtual base classes, declaring common public methods that all plugins must provide, such as `initialize()`, `executeTest()`, `getResult()`, and `cleanup()`, and specifying unified input parameters and output data formats. This ensures that all subsequently developed functional modules have a consistent calling method, laying the foundation for runtime polymorphic interaction.

[0040] Based on the abstract interface specification defined in the first step, specific functional plugins are developed for specific testing needs (such as "RS485 interface testing" or "telemetry calibration function"). This plugin class inherits from two base classes at the code level: one is the QObject base class provided by the framework, to obtain support from the meta-object system; the other is the defined abstract interface class, promising to implement all interface methods. Developers provide specific business logic implementations for all pure virtual functions in this plugin class. After implementation, the plugin code is compiled separately to generate an independent dynamic link library file. This dynamic link library file is a fully encapsulated functional carrier, physically separated from the main program, which internally registers the implemented interface information in the meta-object system through the Q_INTERFACES macro.

[0041] The plugin loader begins operation when the main program starts or when a specific test task needs to be executed. It scans the preset or configured plugin directory path for all dynamic link library files that conform to the naming conventions. For each scanned dynamic link library file, the plugin loader instantiates a QPluginLoader object and instructs it to load the file. The plugin loader executes underlying system calls to load the dynamic link library file into memory and accesses its meta-object system to query the plugin class information it contains.

[0042] After successfully loading the dynamic link library file, the plugin loader does not directly create an object; instead, it first performs interface compliance verification. It checks whether the plugin class exported by the dynamic link library file actually implements the abstract interface class defined in the first step. Verification is done by querying the list of interfaces registered by the Q_INTERFACES macro in the plugin class metadata. Only when it is confirmed that the plugin class implements the required interface does the plugin loader call the instance() method, requesting the dynamic link library file to create and return an instance object of that plugin class. This instance object is safely upcast to a pointer to the abstract interface class. This step ensures that only plugins conforming to the unified contract can be accepted and used by the system.

[0043] Once the main program framework or intelligent flow control module obtains the returned abstract interface class pointer, it can operate entirely based on that interface. For example, when a test task needs to be executed, the main program calls the `executeTest()` method of that pointer. Since this method is a virtual function defined in the interface, the actual business logic implemented in the specific plugin's dynamic link library file is executed. Throughout the entire process, the main program only depends on the abstract interface specification and does not need to know or link to the implementation details of any specific plugin. After the call is completed, the main program can also obtain standard-formatted result data through other methods defined in the interface (such as `getResult()`).

[0044] When a plugin's functionality is no longer needed, the main program can instruct the plugin loader to unload the plugin. The plugin loader first calls the plugin's `cleanup()` method via an abstract interface class pointer, causing it to release the resources it occupies. Then, the plugin loader destroys the plugin instance and instructs `QPluginLoader` to unload the corresponding dynamic link library file from memory. This achieves on-demand loading of functionality and dynamic resource reclamation.

[0045] As a preferred embodiment of the present invention, the testing functions include hardware interface testing and functional testing. The hardware interface testing is used to test the RS485 interface, GPS interface, Bluetooth interface, 4G module interface, carrier interface, and external Flash interface. The functional testing is used to test the power-on / off function, telemetry calibration, remote signaling function, and remote control operation.

[0046] As a preferred embodiment of the present invention, the multi-protocol edge collaboration module includes a device service layer and an application layer. The device service layer is used to interface with power distribution terminals under test using different protocols, and convert the collected raw non-standardized data into unified Core Data standardized format data. The application layer establishes a communication connection with the device service layer through a predefined service interface, obtains the standardized format data output by the device service layer through the service interface, and realizes data interaction using a hybrid mode combining REST API polling and WebSocket protocol real-time push. At the same time, a data caching mechanism is introduced to maintain the continuity of data display by calling cached data in scenarios of network fluctuations or data transmission delays.

[0047] As a preferred embodiment of the present invention, the method of using a hybrid mode combining REST API polling and WebSocket real-time push to achieve data interaction specifically includes: All data points to be interacted with are classified and labeled, with low-frequency and non-real-time data labeled as the first category and high-frequency and real-time data labeled as the second category; For the first category, the application layer scheduler only enables the REST API polling channel. Its internal timer initiates synchronous query requests to the resource endpoints corresponding to the device service layer at preset long intervals. The device service layer processes the requests and returns the current value from its data pool. For the second category, the application layer scheduler starts a real-time push channel using the WebSocket protocol. After establishing a connection with the WebSocket protocol, the application layer sends a subscription message to the device service layer, listing all the second category data point paths that need to be pushed in real time. When the device service layer detects any update to a subscribed data point, it does not need to wait for a request and immediately pushes a standardized message frame containing the new data value to the application layer via the WebSocket protocol.

[0048] As a preferred embodiment of the present invention, a data caching mechanism is introduced at the application layer. In scenarios of network fluctuations or data transmission delays, cached data is invoked to maintain the continuity of data display. Specifically, this includes: A data cache is established at the application layer to store data from REST API polling and WebSocket protocol channel transmission in a structured data cache in real time. When network fluctuations cause data transmission delays or brief communication interruptions, a cache protection mechanism will be triggered. This mechanism intercepts data requests, prioritizes querying the data cache, and if the interception is successful, immediately returns the most recently successfully stored cached data and its timestamp.

[0049] For example, taking IEC 61850 MMS and Modbus RTU as examples, the power distribution terminal under test (DUT) A supports the IEC 61850 protocol, and terminal B supports the Modbus RTU protocol. The test system needs to collect telemetry data from both. The system pre-configures or dynamically loads two device service plugins: IEC61850-Device-Service and ModbusRTU-Device-Service. Each service plugin encapsulates the complete communication stack for the corresponding protocol.

[0050] For terminal A (IEC 61850): IEC61850-Device-Service establishes an MMS association based on the configured server address and logical device name. When it is necessary to read the "A-phase current", the service plugin internally maps this read request to the standard GetDataValues ​​service and sends the corresponding MMS message to the terminal. After receiving the MMS response from the terminal, the plugin parses out the floating-point value of the current, the quality stamp, and the timestamp.

[0051] For Terminal B (Modbus RTU): The ModbusRTU-Device-Service sends a "Read Holding Register" command frame to a specific slave address of Terminal B via the serial bus, specifying the register address where the A-phase current value is stored. Upon receiving the response frame, the plugin converts the original integer into an engineered value based on a known scaling factor (e.g., a register value of 5000 corresponds to an actual value of 5.000A), and appends the current system time as a timestamp and a quality stamp generated based on the communication status.

[0052] For example, when the test interface needs to simultaneously display the real-time voltage waveform (high-frequency variation) and its firmware version information (static data) of terminal A, for the real-time voltage waveform data (second category of data), the application layer subscribes to the data point Terminal_A_001 / Voltage_Waveform from the device service layer via a WebSocket protocol connection during initialization. Subsequently, whenever the device service layer collects a new voltage sample value from terminal A and converts it into a core data event, it immediately pushes it proactively and in real-time to the application layer via the WebSocket protocol channel. Upon receiving the data, the application layer can immediately refresh the waveform, achieving a visual presentation with millisecond-level latency.

[0053] For firmware version information (Category 1 data): The application layer sends a request to a fixed endpoint of the device service layer (e.g., GET / api / v2 / device / Terminal_A_001 / FirmwareVersion) via a REST API. Upon receiving the request, the device service layer may read the information from the terminal through a one-time protocol interaction or return it from a cache as an HTTP response. The application layer only calls this API when needed (e.g., before a test begins) and does not need to maintain a continuous data stream.

[0054] For example, when continuously receiving real-time voltage data via the WebSocket protocol channel, a brief network interruption (such as a 500-millisecond switch port oscillation) causes the WebSocket connection to temporarily break. When the data stream is interrupted, a caching mechanism is activated. Under normal conditions, each time the application layer successfully receives voltage data via the WebSocket protocol, in addition to sending it to the interface for display, it also synchronously updates the local cache database, storing it with the device ID and data point name as the key. When the network is interrupted, the WebSocket connection's onclose event is triggered. The application layer immediately performs degradation: while attempting to reconnect to the WebSocket protocol, it starts high-frequency REST polling of the voltage data point (e.g., every 100 milliseconds) to try to retrieve the data.

[0055] Although network interruptions may temporarily prevent new data from being delivered, the rendering module of the human-machine interface intercepts its data requests via a unified data access interface every time it refreshes (e.g., every 50 milliseconds). Upon detecting an anomaly in the real-time channel, this interface retrieves the most recently successfully received voltage value and its timestamp from the local cache database and returns it to the rendering module. Therefore, the voltage waveform display on the interface will not become blank or freeze, but will temporarily stabilize at the last valid value, and may inform the user through UI prompts (such as the value turning gray) that the data may not be up-to-date.

[0056] When the network is restored, the WebSocket protocol reconnects successfully, and the real-time data stream resumes. New data updates the cache again and drives the interface to refresh in real time, and the system fully returns to normal.

[0057] As a preferred embodiment of the present invention, the test execution process of the intelligent process control module specifically includes: Based on the type of terminal under test and the user's test instructions, the corresponding functional plug-in units and their configuration files are scanned and loaded from the specified folder. The configuration files are parsed to obtain test parameters, and an automated test sequence is generated based on the test parameters and preset test logic. The multi-protocol edge collaboration module is invoked to send an excitation signal to the power distribution terminal under test and to receive its response data. After the test command is triggered, the response data is compared with the expected state, the test result is output, and during the execution process, communication timeouts or interruptions are automatically recovered according to the fixed number of retry strategies or exponential backoff retry strategies preset in the configuration file.

[0058] In this embodiment, the intelligent process control module is activated based on the test command issued by the user through the human-computer interaction interface or the ID of the terminal device under test automatically identified by the system. This test command or ID is associated with a specific test project (such as "full-function automated test" or "telemetry-specific test"). First, according to predefined mapping rules, a set of functional plug-in unit identifiers (e.g., Plugin_Telemetry.dll, Plugin_RemoteSignal.dll) required to execute the test project are determined.

[0059] Subsequently, the system scans specified files according to the preset global plugin storage path. For each identifier, it locates the corresponding dynamic link library file and configuration file with the same name (e.g., Plugin_Telemetry.ini) in the storage path. The plugin loading mechanism is invoked to load the dynamic library into memory and instantiate the plugin object, while simultaneously parsing the configuration file. The parsing process extracts all configurable parameters for the test function. For example, for a telemetry plugin, parameters include the upper limit of the measurement range, sampling interval time, and accuracy error threshold; for a communication test plugin, parameters include the protocol type, server address, and heartbeat timeout. The system outputs a set of instantiated plugin objects and their corresponding structured parameter sets.

[0060] Based on the obtained set of instantiated plugin objects and their structured parameter sets, and combined with the test logic dependencies pre-defined within the module or configuration file (e.g., a communication connection must be established before remote control testing), the sequence planner of the intelligent flow control module begins to operate. The planner analyzes the dependencies and parameter constraints between plugins, generating an executable linear or branching test sequence. This sequence explicitly specifies the calling order, execution conditions, and specific parameter values ​​passed to each plugin unit.

[0061] Before the sequence is executed, the multi-protocol edge collaboration module is invoked to establish a communication connection with the power distribution terminal under test based on the parameters required by the first plug-in in the sequence, ensuring that the data channel is ready. Then, each functional plug-in unit is scheduled to execute sequentially according to the generated test sequence.

[0062] For example, taking the "telemetry accuracy calibration" sub-process as an example, its closed-loop execution steps are as follows: Based on the plug-in parameters, the external high-precision analog output device is instructed to apply a standard excitation signal (such as a 3.000A power frequency current) to the power distribution terminal under test. Simultaneously, the execution interface of the telemetry plug-in is invoked. This plug-in sends a command to the power distribution terminal under test to read the current sampled value through the established data channel of the multi-protocol edge collaboration module.

[0063] The plugin receives response data from the terminal (e.g., the terminal reports a current value of 3.012A). The plugin's internal logic automatically compares the response data with the standard excitation signal value and accuracy error threshold loaded via a configuration file. Based on the comparison result, it determines whether the test is "qualified". The intelligent process control module records this comparison result in the test log and immediately sends a status update (e.g., "Telemetry Test: Pass") to the human-machine interface for real-time display via a message mechanism.

[0064] Throughout the entire sequence execution, the intelligent process control module continuously monitors two types of states: first, the execution status (success, failure, timeout) returned by each plug-in unit; and second, the communication link status reported by the multi-protocol edge collaboration module.

[0065] When an abnormal event such as "communication timeout" or "response interruption" is detected, the module immediately interrupts the current normal process and starts the exception handling program. This program queries the configuration file corresponding to the currently executing plugin to obtain the preset retry policy. The policy has two modes: First, a fixed-number retry strategy, for example, RetryCount=3, Interval=1000. It will automatically resend the previous command after waiting 1 second, repeating a maximum of 3 times.

[0066] Second, the exponential backoff retry strategy: For example, BaseInterval=1000, MaxInterval=16000. It will wait 1 second before the first retry, 2 seconds before the second, 4 seconds before the third, and so on, until success or the maximum waiting time is exceeded.

[0067] Retry operations are automatically performed according to the strategy. If the retry is successful, the process automatically resumes from the breakpoint and continues to execute the subsequent sequence, and the recovery event is recorded in the log. If the retry fails after exhausting all attempts, the test step is determined to have failed. The module can choose to skip the step or abort the entire test sequence according to the preset strategy, and trigger a structured exception event to the upper layer. This event will contain information such as the exception step and retry logs, which will be used by the test exception tracing module for in-depth analysis.

[0068] Once all steps in the test sequence have been completed, or if the test is interrupted due to an exception, the intelligent process control module initiates a cleanup process. It reverses the execution order of each plug-in unit to release its resources and notifies the multi-protocol edge collaboration module to disconnect from the terminal. Finally, a summary report of the test process is generated, summarizing the execution results, time consumption, and exception records for all steps.

[0069] As a preferred embodiment of the present invention, the test anomaly tracing module includes a log parsing unit, a historical data comparison unit, a process dependency verification unit, an anomaly level determination unit, an automatic fault cause location unit, and a report tracing unit. The log parsing unit is used to collect and structure test logs, protocol interaction logs and status logs of each module generated during system operation, and performs log parsing based on the QTextBrowser component and the qInstallMessageHandler function. The historical data comparison unit obtains historical test data through the EdgeX service, and after data preprocessing, uses a trend analysis algorithm to complete the comparative analysis of historical data and current test data. The process dependency verification unit adopts a state machine model to abstract each module in the test process into a state node, clarifying the running state of each node; and parses the dependency relationship between each state node to construct a test process dependency graph; when a test exception occurs, it traverses the dependency graph to check the running state of the preceding associated modules of the exception module and locates the dependency exception point. The anomaly level determination unit is used to distinguish the anomaly level using different color codes on the QT interface according to the pre-set anomaly level determination rules. The automatic fault location unit is used to receive structured log data from the log parsing unit, trend analysis results from the historical data comparison unit, and dependency anomalies from the process dependency verification unit; and to perform correlation analysis based on a predefined anomaly rule library to output the most likely fault cause and location information. The report tracing unit is used to assign a unique test ID during each test, bind the device ID and various data generated in the test process to the unique test ID, and then use the database, with the unique test ID as the index, to query and integrate all test data of the relevant device ID to generate a tracing report.

[0070] As a preferred embodiment of the present invention, the status of each module in the process dependency verification unit includes inactive, executing, completed, and abnormal.

[0071] Secondly, please refer to the appendix. Figure 2 The present invention also provides a modular, scalable, transparent, multi-functional test fault tracing method for power distribution terminals, characterized in that the method includes the following steps: Step S1: Collect and structure the test logs, protocol interaction logs, and status logs of each module generated during system operation, and parse the logs based on the QTextBrowser component and the qInstallMessageHandler function; Step S2: Obtain historical test data through EdgeX service, and after data preprocessing, use trend analysis algorithm to perform comparative analysis between historical data and current test data; Step S3: Using a state machine model, each module in the test process is abstracted into a state node, and the running state of each node is clarified; the dependency relationship between each state node is analyzed, and a dependency relationship graph of the test process is constructed; when a test exception occurs, the dependency relationship graph is traversed to check the running state of the preceding associated modules of the exception module and locate the dependency exception point. Step S4: Receive the structured log data from the log parsing unit, the trend analysis results from the historical data comparison unit, and the dependency anomalies from the process dependency verification unit; perform correlation analysis based on the predefined anomaly rule base, and output the most likely cause of the failure and its location information; Step S5: Assign a unique test ID during each test, and bind the device ID and various data generated in the test process to the unique test ID. Then, using the database and the unique test ID as the index, query and integrate all test data related to the device ID to generate a traceability report.

[0072] In this embodiment, the test anomaly tracing module is activated based on a structured anomaly alarm signal issued by the intelligent process control module or underlying functional plug-in. This signal includes at least an anomaly occurrence timestamp, the test step identifier that triggered the anomaly, the anomaly type code, and the associated device identifier. Simultaneously, the report tracing unit assigns a globally unique test tracing ID to this analysis instance. This test tracing ID is bound to the device identifier in the alarm signal, serving as the core index for all subsequent data collection, analysis, and aggregation.

[0073] Based on the globally unique test traceability ID and the timestamp of the exception occurrence, the system starts three data acquisition and analysis threads in parallel: 1. Log Parsing: The log parsing unit focuses on the point of error and extends forward over a preset time range, collecting raw log streams from system runtime files. It captures all messages using the qInstallMessageHandler function redirection mechanism and leverages the parsing capabilities of the QTextBrowser component to filter, classify, and structure the logs, extracting a set of structured log entries related to the error steps, relevant protocol interactions, and key error codes.

[0074] 2. Historical Data Comparison: The historical data comparison unit calls the core data service interface of the EdgeX Foundry framework, using the device identifier and the path of the anomaly-related data point as query conditions to obtain the numerical sequence formed by the data point in each historical test. Then, the current anomaly data and the historical sequence are preprocessed: first, anomaly timestamp alignment and noise filtering are performed; then, a min-max normalization algorithm is used, taking the maximum value (max(x)) and minimum value (min(x)) in the historical sequence as benchmarks, to transform the current value (x) and each value in the historical sequence, using the following formula:

[0075] All data are mapped to the [0,1] interval to eliminate dimensions. Finally, trend analysis algorithms, such as calculating moving averages or fitting trend lines, are used to compare the normalized historical series with the current values, generating a historical data trend comparison report that indicates whether the current parameter deviates from its historical normal fluctuation range and the significance of the deviation.

[0076] 3. Process Dependency Verification: The process dependency verification unit receives the abnormal test step identifier from the alarm signal. Based on the system's built-in test process state machine model, it locates the corresponding abnormal node in the state machine and performs a reverse traversal along the pre-built dependency graph, collecting the states of all direct and indirect predecessor nodes of that node at the moment the abnormality occurs. By verifying state transition rules, such as requiring predecessor nodes to be in the "completed" state before the current node can enter the "execution" state, it locates the first node in the dependency graph whose state does not meet expectations, generates a process dependency anomaly analysis report, and identifies the root cause of the blockage.

[0077] The anomaly level determination unit receives blocking points from the process dependency verification module. Based on a pre-configured rule base, it comprehensively evaluates three dimensions of input: 1) the highest error level in the structured log entry set; 2) the degree of deviation indicated in the historical data trend comparison report; and 3) the criticality of the blocking point in the entire process as determined in the process dependency anomaly analysis report. The rule engine performs comprehensive calculations and outputs the anomaly severity level, such as "Severe," "Moderate," or "Warning." This level information is passed to subsequent analysis units and also drives the human-computer interaction interface, highlighting corresponding alarm information on the interface with specific color codes (such as red, orange, and yellow) according to preset rules, achieving real-time, tiered visual alerts.

[0078] The automatic fault location unit receives and integrates a set of structured log entries, historical data trend comparison reports, process dependency anomaly analysis reports, and anomaly severity levels. Based on a predefined fault rule knowledge base, each rule defines a mapping relationship between a specific fault mode and a set of evidence conditions. For example, rule R1: IF (log contains "checksum error" AND process dependency shows communication front-end module anomaly) THEN (fault cause = "data link layer communication interference")).

[0079] The input multidimensional evidence features are matched against a rule knowledge base. Through pattern matching and confidence calculation, the rules with the highest matching degree are selected. Finally, one or more most likely root cause hypotheses are output, each accompanied by detailed location information (such as faulty component, problem type) and a summary of the reasoning basis, that is, clearly indicating which logs, historical trends, or dependency anomalies are used to arrive at the conclusion.

[0080] The report tracing unit uses a globally unique test traceability ID as its core index to perform database queries: retrieving and aggregating all complete data bound to this ID, including the original device identifier, complete test sequence records, original log fragments, historical data comparison charts, dependency graphs, anomaly severity levels, and root cause hypotheses and location information output by the automatic fault cause localization unit. Subsequently, this heterogeneous information is arranged according to a standardized report template to generate a structured test anomaly tracing report. This report not only records the anomaly but, more importantly, systematically presents the analysis process, judgment criteria, root cause conclusions, and a complete chain of evidence. Furthermore, for common problems encountered in batch testing (e.g., multiple device IDs exhibiting the same carrier interface failure), the system can perform batch tracing analysis using associated device identifiers, providing data support for locating common problems in production batches or designs, achieving precise tracing from the testing end to the production stage.

[0081] Thirdly, the present invention also provides a computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the above-mentioned modular, scalable, transparent power distribution terminal multi-functional test fault tracing method.

[0082] In this embodiment, the computer-readable storage medium may be a non-transitory computer-readable storage medium, such as a read-only memory (ROM), random access memory (RAM), CD-ROM, magnetic tape, floppy disk, and optical data storage device.

[0083] Fourthly, embodiments of this application also provide an electronic device, including a processor and a memory, wherein the memory stores multiple instructions; the processor loads instructions from the memory to execute the steps in a modular, scalable, transparent power distribution terminal multi-functional test fault tracing method provided in embodiments of this application.

[0084] Fifthly, embodiments of this application also provide a computer program product, including a computer program / instructions, which, when executed by a processor, implement the steps in the modular, scalable, transparent power distribution terminal multi-functional test fault tracing method provided in embodiments of this application.

[0085] In this embodiment, those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be accomplished by instructions, or by instructions controlling related hardware. These instructions can be stored in a computer-readable storage medium and loaded and executed by a processor.

[0086] Therefore, embodiments of this application provide a computer-readable storage medium storing a plurality of instructions that can be loaded by a processor to execute the steps in a modular, scalable, transparent power distribution terminal multi-functional test fault tracing method provided in embodiments of this application.

[0087] It should be noted that, through the above description of the implementation methods, those skilled in the art can clearly understand that, for the sake of convenience and brevity, only the division of the above functional modules is used as an example. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above.

[0088] The above are merely specific embodiments of the present invention, but the scope of protection of the present invention is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in the present invention should be included within the scope of protection of the present invention. The scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A modular, scalable, transparent, multi-functional testing system for distribution terminals, comprising a distribution terminal under test, characterized in that, The system also includes a test function component module, a multi-protocol edge collaboration module, an intelligent process control module, and a test anomaly tracing module; The test function component module is used to encapsulate different test functions into independent functional plug-in units that follow a unified interface specification, and to provide them to the system for invocation through a dynamic loading mechanism; The multi-protocol edge collaboration module is used to adapt to multiple communication protocols, convert heterogeneous data of the power distribution terminal under test into a standardized data format, provide a consistent data service interface, and synchronize it to the intelligent process control module. The intelligent process control module is used to dynamically load the corresponding functional plug-in units according to the test task, execute the test process according to preset parameters and logical serialization, and monitor the process status. The test anomaly tracing module is used to collect and analyze the running data from the test function component module, the multi-protocol edge collaboration module and the intelligent process control module when an anomaly occurs during the execution of the test process, locate the root cause of the fault and generate an anomaly tracing report.

2. The modular, scalable, transparent, multi-functional testing system for power distribution terminals according to claim 1, characterized in that, The test function component module includes an interface specification unit, multiple functional plug-in units, and a plug-in loader; The interface specification unit is used to define the unified functional interface that all plug-in units must follow; Each of the multiple functional plug-in units inherits from the interface specification unit and encapsulates an independent test function, which is then compiled into an independent dynamic link library file. The plugin loader is used to dynamically load the dynamic link library file at runtime and instantiate a plugin object that conforms to the unified functional interface.

3. The modular, scalable, transparent, multi-functional testing system for power distribution terminals according to claim 2, characterized in that, The testing functions include hardware interface testing and functional testing. The hardware interface testing is used to test the RS485 interface, GPS interface, Bluetooth interface, 4G module interface, carrier interface, and external Flash interface. The functional testing is used to test the power-on / off function, telemetry calibration, remote signaling function, and remote control operation.

4. The modular, scalable, transparent, multi-functional testing system for power distribution terminals according to claim 1, characterized in that, The multi-protocol edge collaboration module includes a device service layer and an application layer. The device service layer is used to interface with power distribution terminals under test using different protocols, converting the collected raw, non-standardized data into a unified standardized format. The application layer establishes a communication connection with the device service layer through a predefined service interface, obtains the standardized format data output by the device service layer through the service interface, and uses a hybrid mode combining REST API polling and real-time push via WebSocket protocol to achieve data interaction. At the same time, a data caching mechanism is introduced to maintain the continuity of data display by calling cached data in scenarios of network fluctuations or data transmission delays.

5. The modular, scalable, transparent power distribution terminal multi-functional testing system according to claim 4, characterized in that, The hybrid mode of data interaction, which combines REST API polling with WebSocket real-time push, specifically includes: All data points to be interacted with are classified and labeled, with low-frequency and non-real-time data labeled as the first category and high-frequency and real-time data labeled as the second category; For the first category, the application layer scheduler only enables the REST API polling channel. Its internal timer initiates synchronous query requests to the resource endpoints corresponding to the device service layer at preset long intervals. The device service layer processes the requests and returns the current value from its data pool. For the second category, the application layer scheduler starts a real-time push channel using the WebSocket protocol. After establishing a connection with the WebSocket protocol, the application layer sends a subscription message to the device service layer, listing all the second category data point paths that need to be pushed in real time. When the device service layer detects any update to a subscribed data point, it does not need to wait for a request and immediately pushes a standardized message frame containing the new data value to the application layer via the WebSocket protocol.

6. The modular, scalable, transparent power distribution terminal multi-functional testing system according to claim 5, characterized in that, Introducing a data caching mechanism at the application layer allows for the retrieval of cached data to maintain the continuity of data display in the event of network fluctuations or data transmission delays. Specifically, this includes: A data cache is established at the application layer to store data from REST API polling and WebSocket protocol channel transmission in a structured data cache in real time. When network fluctuations cause data transmission delays or brief communication interruptions, a cache protection mechanism will be triggered. This mechanism intercepts data requests, prioritizes querying the data cache, and if the interception is successful, immediately returns the most recently successfully stored cached data and its timestamp.

7. The modular, scalable, transparent, multi-functional testing system for power distribution terminals according to claim 1, characterized in that, The test execution process of the intelligent process control module specifically includes: Based on the type of terminal under test and the user's test instructions, the corresponding functional plug-in units and their configuration files are scanned and loaded from the specified folder. The configuration files are parsed to obtain test parameters, and an automated test sequence is generated based on the test parameters and preset test logic. The multi-protocol edge collaboration module is invoked to send an excitation signal to the power distribution terminal under test and to receive its response data. After the test command is triggered, the response data is compared with the expected state, the test result is output, and during the execution process, communication timeouts or interruptions are automatically recovered according to the fixed number of retry strategies or exponential backoff retry strategies preset in the configuration file.

8. The modular, scalable, transparent, multi-functional testing system for power distribution terminals according to claim 1, characterized in that, The test anomaly tracing module includes a log parsing unit, a historical data comparison unit, a process dependency verification unit, an anomaly level determination unit, an automatic fault cause location unit, and a report tracing unit. The log parsing unit is used to collect and structure test logs, protocol interaction logs and status logs of each module generated during system operation, and performs log parsing based on the QTextBrowser component and the qInstallMessageHandler function. The historical data comparison unit obtains historical test data through the EdgeX service, and after data preprocessing, uses a trend analysis algorithm to complete the comparative analysis of historical data and current test data. The process relies on a verification unit, which uses a state machine model to abstract each module in the test process into a state node, clarifying the running state of each node. It also analyzes the dependencies between each state node and constructs a dependency graph of the test process; When a test exception occurs, the dependency graph is traversed to check the running status of the preceding associated modules of the exception module and locate the dependency exception point. The anomaly level determination unit is used to distinguish the anomaly level using different color codes on the QT interface according to the pre-set anomaly level determination rules. The automatic fault location unit is used to receive structured log data from the log parsing unit, trend analysis results from the historical data comparison unit, and dependency anomalies from the process dependency verification unit; and to perform correlation analysis based on a predefined anomaly rule library to output the most likely fault cause and location information. The report tracing unit is used to assign a unique test ID during each test, bind the device ID and various data generated in the test process to the unique test ID, and then use the database, with the unique test ID as the index, to query and integrate all test data of the relevant device ID to generate a tracing report.

9. A modular, scalable, transparent, multi-functional testing system for power distribution terminals according to claim 8, characterized in that, The status of each module in the process dependency verification unit includes inactive, executing, completed, and abnormal.

10. A modular, scalable, transparent power distribution terminal multi-functional test fault tracing method, applied to the test anomaly tracing module as described in claim 9, characterized in that, The method includes the following steps: Step S1: Collect and structure the test logs, protocol interaction logs, and status logs of each module generated during system operation, and parse the logs based on the QTextBrowser component and the qInstallMessageHandler function; Step S2: Obtain historical test data through EdgeX service, and after data preprocessing, use trend analysis algorithm to perform comparative analysis between historical data and current test data; Step S3: Using a state machine model, each module in the test process is abstracted into a state node, and the running state of each node is clarified; the dependency relationship between each state node is analyzed, and a dependency relationship graph of the test process is constructed; when a test exception occurs, the dependency relationship graph is traversed to check the running state of the preceding associated modules of the exception module and locate the dependency exception point. Step S4: Receive the structured log data from the log parsing unit, the trend analysis results from the historical data comparison unit, and the dependency anomalies from the process dependency verification unit; perform correlation analysis based on the predefined anomaly rule base, and output the most likely cause of the failure and its location information; Step S5: Assign a unique test ID during each test, and bind the device ID and various data generated in the test process to the unique test ID. Then, using the database and the unique test ID as the index, query and integrate all test data related to the device ID to generate a traceability report.

Images