A measuring switch fault diagnosis system
By using a measurement switch fault diagnosis system to perform unified time verification and correlation discrimination of multi-source heterogeneous information, the problem of information incompatibility in existing technologies is solved, and accurate diagnosis and stable handling of measurement switch faults are achieved.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- ZHEJIANG YIZHI ELECTRIC CO LTD
- Filing Date
- 2026-04-10
- Publication Date
- 2026-07-21
AI Technical Summary
Existing technologies make it difficult to perform unified time verification and correlation judgment on multi-source heterogeneous information of measuring switches, resulting in unstable remote verification results, duplicate or deviated field dispatches, difficulty in effectively writing back the handling results, and the simultaneous existence of false alarms and missed alarms, making it difficult to stably control the timeliness of fault handling.
A fault diagnosis system for a measurement switch is provided, including a session registration module, a timing verification module, an association receiving module, and a verification closed-loop module. By establishing a diagnostic session, the system performs time alignment and association discrimination of multi-source heterogeneous information, determines the verification order, and performs remote review, on-site dispatch, and result write-back.
It enables accurate differentiation of measurement switch faults, reduces false alarms and missed alarms, reduces duplicate dispatching, stabilizes the timeliness of fault handling, and enhances the traceability of the diagnostic process and the consistency of judgments before and after.
Smart Images

Figure CN122432729A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of power distribution operation and maintenance data processing technology, specifically to a measurement switch fault diagnosis system. Background Technology
[0002] Measuring switches are widely used in low-voltage power distribution monitoring, abnormal power consumption identification, and remote operation and maintenance scenarios. Their fault diagnosis results directly affect the efficiency of remote verification, on-site dispatch, and subsequent handling. In existing technologies, for example, the published invention patent application CN119335383B discloses a method and system for abnormal state monitoring and early warning of measuring switches, which mainly uses mechanical status, electrical characteristics, environmental conditions, expert knowledge base, and machine learning model to provide abnormal early warning of measuring switches. Another example is the published invention patent application CN115453269B, which discloses a fault judgment method and terminal based on distribution network protection setting scheme, which mainly uses switch coordination relationship and protection setting information to judge faults. Although the above technologies have improved the abnormal monitoring capability of measuring switches and the fault analysis capability of distribution networks, their analysis objects are still mainly single-type equipment status information or distribution network operation relationship information, lacking a unified organization, correlation verification, and closed-loop handling mechanism for multi-source heterogeneous information in the fault diagnosis scenario of measuring switches. In actual operation, power supply records, power consumption records, switch status records, communication quality records, and historical maintenance records usually come from different business systems, making them susceptible to factors such as inconsistent acquisition clocks, communication delay fluctuations, changes in transformer area line relationships, and drastic fluctuations in user load. Existing technologies struggle to perform unified time verification and correlation judgment on the aforementioned multi-source heterogeneous information, and also find it difficult to establish a reasonable verification sequence based on the reliability and correlation of different information. Therefore, it is difficult to accurately distinguish between faults in the measurement switch itself, abnormal sampling links, communication anomalies, and actual power consumption anomalies in the area. Due to the difficulty in accurately determining the source of anomalies, remote verification conclusions become unstable, on-site dispatching becomes duplicated or deviates from the actual fault location, and handling results are difficult to effectively write back and use for subsequent diagnosis, resulting in both false alarms and missed alarms, and the timeliness of fault handling is difficult to control stably. Based on this, it is necessary to propose a measurement switch fault diagnosis system to perform unified time verification, correlation judgment, and closed-loop scheduling on multi-source heterogeneous information. Summary of the Invention
[0003] To address the shortcomings of existing technologies, this invention provides a measurement switch fault diagnosis system that solves the problem in traditional methods of difficulty in performing unified time verification, correlation discrimination, and closed-loop scheduling of multi-source heterogeneous information.
[0004] To achieve the above objectives, the present invention provides the following technical solution: A fault diagnosis system for a measuring switch, comprising: Session registration module: Used to establish a diagnostic session based on anomaly trigger information and determine the current diagnostic rule version; Time sequence verification module: used to perform time alignment and time interval consistency verification on power supply records, power consumption records, switch status records, communication records and maintenance records; Association Module: Used to establish associations within the diagnostic session based on the line connection relationship of the transformer area, the corresponding relationship of the equipment, and the historical handling association relationship; Evidence arrangement module: used to determine the verification order based on the directness of the record, temporal consistency, source reliability, and interference status; Verification closed-loop module: used to perform remote review, on-site dispatch, handling tracking and result writing in the verification order.
[0005] Preferably, the session registration module includes: Based on the equipment ledger mapping relationship, the objects from which anomalies originate are unified; The judgment is made by combining the reporting time from the source system and the receiving time from the main station. Session identifiers are generated based on unified object identifiers and trigger time slices; Freeze the rule version and generate session base records and input lists; For data items with gaps, perform tiered retrying; Perform incorporation processing on the information returned from the site, and initiate manual ledger verification when object mapping is abnormal.
[0006] Preferably, the timing verification module includes: Based on the input list, records are extracted from each source to establish the original time, received time, corrected time, and time reliability level; Layered time correction and correction amount limits are implemented by combining time logs, time synchronization records, and link latency samples; The system constructs a leading interval, a core interval, and an extended interval based on the session trigger time, and performs time consistency verification, interval relationship comparison, abnormal segment marking, manual interval identification, and link blockage assisted alignment according to record type.
[0007] Preferably, layered time correction and correction amount limits are applied by combining time logs, time synchronization records, and link latency samples, including: The correction path is determined based on the timeliness of time recording, the validity of communication samples, and the availability of the original time. Offset correction is performed on records with valid time synchronization basis; Records with insufficient timeliness are corrected by combining the median value of transmission delay; For records lacking reliable original timestamps, comparisons are made based on the time of receipt, and a downgrade flag is assigned. The correction amount is subject to double constraints, and records that are time-reversed after correction retain their original order and are marked as pending verification.
[0008] Preferably, the associated receiving module includes: Based on the unified verification table, construct object association tables corresponding to the core object layer, the nearest neighbor object layer, and the historical reference layer; Establish operation acceptance, communication acceptance, and handling acceptance by combining the relationships between frozen lines, equipment correspondence, and historical work orders; Determine the strength and validity of relationships based on time relationships and record integrity, and execute mapping decisions or experience-based correspondences when there are object conflicts, relationship rollbacks, or incomplete ledgers.
[0009] Preferably, an object association table is constructed based on the unified verification table, corresponding to the core object layer, the nearest neighbor object layer, and the historical reference layer, including: Based on the unified verification table and the correspondence between the devices that take effect at the trigger time; The associated objects of the target device are hierarchically categorized, including direct upstream objects, direct downstream objects, neighboring objects on the same branch, objects on the same communication node, objects processed in the same batch, and historically similar objects. The system records the unified object identifier, its hierarchical level, line connection location, communication affiliation, most recent processing record number, and the current session validity status.
[0010] Preferably, the evidence arrangement module includes: Evidence items are formed based on the unified verification form and the conversation relationship table; The evidence includes source category, usage status, source reliability level, relationship strength, and interference markers; Candidates for primary verification, secondary verification, observation, and exclusion are stratified according to the inclusion criteria. The verification sequence chain is generated by combining historical processing corrections, verification relationships, pending certificate constraints, prohibition of direct order dispatch constraints, rollback rules in abnormal scenarios, improvement rules, and template call rules.
[0011] Preferably, evidence items are formed based on a unified checklist and a conversation relationship table, including: The record items in the unified verification table and the relationship items in the session relationship table are merged and matched within the same diagnostic session to form evidence items; For each piece of evidence, include the evidence number, uniform object identifier, source category, relationship category, time consistency marker, interval relationship marker, source reliability level, interference marker, relationship strength, and usage status.
[0012] Preferably, the verification closed-loop module includes: Collect key data based on the list of certificates to be supplemented; Perform non-disruptive reading, comparison verification, and light-trigger verification according to the verification sequence chain; When the remote termination conditions are met, a structured work order is generated and work order status tracking is initiated. Perform integrity verification and conflict review on the field feedback; The closed-loop conclusions, work order trajectories, and observation periods are linked and written into the corresponding files, and branch processing is carried out for observation scenarios that prohibit direct work order assignment, correct object mapping, or postpone work order assignment.
[0013] Preferably, the verification sequence chain is used to perform non-disruptive reading, comparison verification, and light-trigger verification, including: The non-disruptive reading, comparison verification, and light-trigger verification are invoked sequentially according to the verification order chain. Record the target object, input evidence number, expected receipt time limit, success criteria, failure criteria, and timeout handling strategy for each remote action; Triggering conditions, receipt processing paths, and retry rules are determined based on constraints prohibiting direct order dispatch, session priority, and action category.
[0014] Compared with the prior art, the present invention provides a measurement switch fault diagnosis system, which has the following beneficial effects: 1. This invention, by normalizing sessions and freezing rules for abnormal triggering information, performs unified time verification on power supply records, power consumption records, switch status records, communication records, and maintenance records. It also establishes intra-session associations by combining line connection relationships, equipment correspondence relationships, and historical handling relationships. Furthermore, it determines the verification order based on record directness, time consistency, source reliability, and interference status, connecting remote review, on-site dispatch, handling tracking, and result writing. This enables continuous discrimination and closed-loop handling of multi-source heterogeneous information within the same diagnostic chain, thereby accurately distinguishing between measurement switch body faults, sampling link anomalies, communication anomalies, and actual regional power consumption anomalies. This reduces false alarms and missed alarms, decreases duplicate dispatches, and stabilizes the timeliness of fault handling.
[0015] 2. This invention establishes a diagnostic session and freezes the rule version after an anomaly is triggered, thereby enabling unified management of the temporal, object, and treatment relationships of multi-source records. It also writes remote review processes, on-site treatment processes, and observation period information into corresponding files. This allows the same anomaly to be judged using consistent criteria at different treatment stages, and maintains a continuous association between on-site treatment records, retest records, and subsequent recurrence information. This enhances the traceability of the diagnostic process, improves the consistency of judgments before and after, and allows for the continuous reuse of historical treatment experience. Attached Figure Description
[0016] Figure 1 This is a schematic diagram of the structure of a measurement switch fault diagnosis system according to the present invention; Figure 2This is a schematic diagram illustrating the diagnostic session establishment and rule freezing of the present invention; Figure 3 This is a schematic representation of the multi-source record timing verification and unified verification of the present invention; Figure 4 This is a diagram showing the hierarchical structure and associated relationships of the session objects in this invention. Figure 5 This is a schematic diagram of the evidence arrangement and verification sequence chain of the present invention; Figure 6 This is a diagram illustrating the closed-loop processing of remote verification and on-site dispatching in this invention. Figure 7 This is a schematic diagram illustrating the correlation between the results of this invention, observation period management, and recurrence. Detailed Implementation
[0017] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. 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 are within the scope of protection of the present invention.
[0018] Example 1: Figures 1-7 A fault diagnosis system for a measuring switch is presented, comprising: Session registration module: Used to establish a diagnostic session based on anomaly trigger information and determine the current diagnostic rule version; Time sequence verification module: used to perform time alignment and time interval consistency verification on power supply records, power consumption records, switch status records, communication records and maintenance records; Association Module: Used to establish associations within the diagnostic session based on the line connection relationship of the transformer area, the corresponding relationship of the equipment, and the historical handling association relationship; Evidence arrangement module: used to determine the verification order based on the directness of the record, temporal consistency, source reliability, and interference status; Verification closed-loop module: used to perform remote review, on-site dispatch, handling tracking, and result writing in the verification sequence. Specifically, such as Figure 2As shown: The session registration module is deployed on the main station's diagnostic service node and is connected to the alarm access interface, work order platform interface, equipment ledger interface, rule version management interface, historical archive interface, and field feedback interface. The session registration module is activated when any anomaly source enters the diagnostic entry point. Anomaly sources include at least main station anomaly alarms, communication anomaly alarms, manually reported anomalies, field inspection anomaly feedback, linkage anomalies of related equipment in the same area, and re-triggering within the historical work order observation period. After the module starts, it first performs object normalization processing on the trigger information. The trigger information includes at least the equipment code, area code, branch code, user group code, source system code, and trigger time. Based on the mapping relationship in the equipment ledger, the module normalizes the alias code, old code, and other relevant fields. Codes, temporary codes generated by batch imports, and manually entered abbreviations are all uniformly converted into a unified object identifier. The unified object identifier can be a combination of the station area number and the device's unique number, used to uniquely point to the target device throughout the entire diagnostic process. The session identifier is generated by overlaying the first trigger time slice number on the unified object identifier. The time slice granularity is set to 5 minutes. The reason for setting this is that the alarm refresh cycle of the master station is usually 1 to 5 minutes, and the device status transmission cycle is usually also 1 to 5 minutes. Using a 5-minute granularity can cover a complete refresh cycle and avoid the same anomaly being split into multiple sessions due to overly fine time slices. The unified object identifier is used for device unification, and the session identifier is used to distinguish different diagnostic processes formed by the same device at different time periods. After object unification is completed, the module enters the session merging and judgment phase. The session merging and judgment phase simultaneously checks the trigger time, exception type, exception manifestation, handling object, source type, and unclosed loop status. The trigger time is verified using two time fields: the source system's reporting time and the master station's receiving time. The first round of grouping prioritizes the master station's receiving time to reduce the impact of reporting delays on the grouping results. When the difference between the source system's reporting time and the master station's receiving time exceeds 10 minutes, the trigger is marked as a late trigger, and its priority for establishing a separate session is reduced in subsequent judgments. The 10-minute setting is because common link jitter and short-term retransmissions generally complete within 10 minutes; records exceeding this time difference are more likely to be delayed or retransmitted. Exception types can be selected as four categories: power supply execution exception, status acquisition exception, communication transmission exception, and handling feedback exception. Exception manifestations can be selected as continuous offline, status jump, missing records, inconsistent records, repeated actions, and... There are 6 types of verification failures; the handling objects can be selected from 4 types: measurement switch body, sampling link, communication link, and associated user-side objects; similar anomaly types mean that the current trigger and the existing session are consistent in at least 2 of the 3 dimensions of anomaly type, anomaly manifestation, and handling object; the reason for this setting is that the same anomaly chain may not be exactly the same in different systems, but as long as 2 of the 3 key dimensions are consistent, it can be considered that they have a high degree of homology; the source type is used to distinguish between automatic triggering by the main station, manual initiation, and on-site verification feedback, among which manual initiation and on-site verification feedback usually have stronger on-site correlation and need to be prioritized to correspond to the existing handling process; the unclosed loop status is used to identify whether there is already a similar session still being processed in the system; if the existing session is in the state of waiting for on-site verification, on-site processing, or waiting to be written back, and the current trigger comes from on-site feedback, then the current trigger is directly written into the feedback channel of the existing session, and no new session is established; The session merging window is determined comprehensively based on the main station alarm refresh cycle, equipment status upload cycle, communication retransmission latency, and field feedback time. The main station alarm refresh cycle is typically 1 to 5 minutes, the equipment status upload cycle is typically 5 to 15 minutes, the communication retransmission latency is typically 10 to 30 minutes under normal circumstances, and the initial field feedback is generally generated within 10 to 60 minutes after arrival. Considering the above operating rhythm, the session merging window is set to 30 to 120 minutes. For ordinary residential transformer substations, 60 minutes can be selected to cover a complete abnormality trigger, status retransmission, and initial judgment process. For important load transformer substations, 30 minutes can be selected to quickly distinguish between continuous abnormalities and newly occurring abnormalities. For remote areas, 90 minutes can be selected to cover retransmission latency caused by link fluctuations and manual feedback latency. 120 minutes is used as the upper limit to avoid excessive merging of irrelevant events. Important load transformer substations refer to those with key supply guarantee markings such as hospitals, communication base stations, rail transit, government support facilities, or continuous production industrial users in the equipment ledger or power supply file. Remote areas are defined as areas with an average round-trip latency greater than 20 seconds over 30 consecutive days, or an average of no less than 3 offline events per day. They can also be identified based on pre-marked area attributes on the operations and maintenance platform. The 20-second and 3-event thresholds are based on the fact that the daily round-trip latency of common urban transformer substations is generally less than 10 seconds, and the average number of offline events per day is generally less than 1. Setting the thresholds to 20 seconds and 3 events can distinguish areas with significantly weaker link conditions. If the current trigger and an existing session simultaneously meet the following conditions within the session merging window: identical target object, similar anomaly type, and the existing session has not entered a closed-loop state, then the current trigger is added to the existing session as a successor event. If the target object is identical but the anomaly type is significantly different, or the current trigger exceeds the session merging window, then a new session is established. After a session is established, the module generates a basic session record. The basic session record includes at least the following fields: session identifier, unified object identifier, station area identifier, first trigger time, current acceptance time, trigger source, current exception type, status identifier, priority identifier, associated work order identifier, and rule version identifier. The status identifier can be selected from nine categories: pending data retrieval, pending verification, pending judgment, pending remote review, pending on-site verification, in on-site processing, pending observation, closed loop, and manual takeover. The adoption of nine status categories is mainly due to the fact that the session processing process usually covers data preparation, time verification, rule judgment, remote review, on-site handling, observation and tracking, and manual backup. If the number of statuses is too small, the stage boundaries will be unclear, and if the number of statuses is too large, it will increase the complexity of the main station's workflow. Priority is assigned in five levels: Level 1 corresponds to power supply anomalies affecting critical users, three or more related devices in the same distribution area triggering anomalies within one hour, or the same or similar anomaly type being triggered again within 72 hours after a maintenance work order is completed; Level 2 corresponds to anomalies affecting at least 20 users, or the same device triggering anomalies at least three times within two consecutive hours; Level 3 corresponds to anomalies affecting 5 to 19 users, or the same device triggering anomalies at least twice within 24 consecutive hours; Level 4 corresponds to the first anomaly at a common single point with no obvious spread currently observed; Level 5 corresponds to low-intensity recurring anomalies at the end of the observation period; low-intensity... The degree of recurrence can be selected as follows: the duration of a single anomaly does not exceed 5 minutes, the interval between two triggers is not less than 30 minutes, and the scope of impact does not expand to new users or new associated devices. The above time and quantity parameters are mainly determined based on the alarm duration, the anomaly recurrence rhythm, the user impact range, and the existing work order hierarchical management method. Among them, 72 hours is used to cover the early recurrence process that is more common within 1 to 3 days after the maintenance is completed, 20 users are used to distinguish between single-point anomalies and localized spread anomalies, 3 times in 2 consecutive hours and 2 times in 24 consecutive hours are used to distinguish between short-cycle recurrence anomalies and general recurrence anomalies, and 5 minutes and 30 minutes are used to identify short-term jitter-type recurrence alarms. To ensure that the same judgment boundary is used in the current session during processing, the module synchronously freezes the diagnostic rule version, time tolerance version, verification order version, and work order mapping version when the session is established. When freezing, the current release number, key threshold number, and effective timestamp of the rule base are recorded, and the corresponding version is called according to the frozen number in subsequent processing. The key threshold number corresponds to at least the session merging window threshold, data retrieval range threshold, retry interval threshold, priority division threshold, and re-trigger judgment threshold. The version freezing method is adopted mainly because the rule base may be updated during session processing. If the version is not frozen, the judgment results before and after may lose consistency due to threshold changes, thereby affecting the traceability and reproducibility of the session. The module also establishes a session input list; the input list should include at least the following fields: source category, data item name, data range, gap identifier, and pull status; in general diagnostic scenarios, the input list should include at least five types of data: power supply records, power consumption records, switch status records, communication records, and maintenance records; if the trigger source involves on-site inspection or manual reporting, an on-site image index, a summary of the manual description, and the inspection time can also be added; if the trigger source involves a re-trigger within the historical work order observation period, the previous work order's handling action, retest results, and the observation period setting value can also be added; the data range is set in conjunction with the alarm refresh cycle, status transmission cycle, communication retransmission delay, and on-site feedback delay; the forward data range should be no less than 10 minutes to extract continuous status changes before the anomaly occurs; the 10-minute setting mainly refers to the common status transmission cycle of 1 to 5 minutes. Using a forward retrieval range of 10 minutes can cover 2 to 3 complete upload cycles; the backward retrieval range is no less than 30 minutes, used to cover the retransmission, receipt, and initial review processes; the 30-minute setting is mainly based on the fact that communication retransmission and main station re-retrieval usually occur about 20 minutes after triggering; for frequent recurring anomalies, the retrieval range can be expanded to a forward retrieval range of 2 hours and a backward retrieval range of 4 hours; frequent recurring anomalies can be selected as the same object triggering no less than 3 times in 2 consecutive hours, or triggering no less than 5 times in 24 consecutive hours; the forward 2 hours are used to cover multiple rounds of status fluctuations and cumulative changes before repeated alarms, and the backward 4 hours are used to cover the on-site arrival, processing, retesting, and initial observation write-back process; for work order recurrence scenarios, the continuous observation interval from the completion of the previous work order to the current trigger can also be retrieved to determine whether the current anomaly has a direct relationship with the previous handling; After the input list is written, the module generates a data retrieval instruction and pushes it to the timing verification module. If a source system is temporarily unavailable, the corresponding data item is marked as to be retrieved and a gap identifier is written. The gap identifier includes at least the following fields: source offline, permission not enabled, object mapping failure, no data in the time range, and interface return error. Source offline means that a connection cannot be established after two consecutive calls within a retry cycle. Permission not enabled means that the interface returns an explicit permission denial message. Object mapping failure means that the same source record cannot form a unique device correspondence in the current ledger, or it is mapped to two or more conflicting objects at the same time. No data in the time range means that the interface call is successful but no valid record is retrieved within the request time window. Interface return error means that the interface returns a failure status, key fields are missing, the returned object identifier does not match, or a single call times out for more than 30 seconds. The 30-second time setting is mainly determined based on the running situation of the main site interface usually returning within a few seconds under normal load. Continuing to wait after 30 seconds will significantly affect the processing time of the current session. For situations where the source is offline or the interface returns an anomaly, the module adopts a layered retry mechanism with retry intervals of 5 minutes, 15 minutes, and 30 minutes. The 5-minute interval is mainly used to cover momentary jitter and short-term link recovery, the 15-minute interval is mainly used to cover common retransmission cycles and medium-duration network recovery, and the 30-minute interval is mainly used to determine whether the source system is persistently unreachable. If the retry fails after 3 attempts, the session status is changed to pending retrieval, and the acquired data is continued to be transmitted to the downstream module. The number of retry attempts is set to 3, which is mainly determined by the needs of momentary fault identification and session registration duration control. Too few attempts are not conducive to distinguishing between momentary and persistent faults, while too many attempts will significantly prolong the preprocessing time. For object mapping failures, the module initiates a manual ledger verification task. Before the manual ledger verification is completed, the session does not enter the final diagnosis stage, but is allowed to enter the preliminary analysis and observation stage. The session basic record, freeze rule version, input list, gap identifier, and priority identifier serve as inputs to the timing verification module.
[0019] Specifically, such as Figure 3As shown: The timing verification module is connected to the main station data bus, device historical database, communication log database, and work order archive database. It starts after receiving the session basic record, freeze rule version, input list, gap identifier, and priority identifier output by the session registration module. The module retrieves original records source by source according to the input list and establishes fields such as source record number, unified object identifier, original time field, received time field, corrected time field, and time reliability level field for each record. The original time field corresponds to the generation time of the record in the source system, the received time field corresponds to the actual received time of the main station or intermediate platform, and the corrected time field corresponds to the comparison time after time correction. The module prioritizes reading the target device's most recent time synchronization log, the concentrator's most recent time synchronization record, and the communication network... The most recent link latency sample is used. If the most recent time synchronization log is no more than 24 hours from the current trigger time, the time synchronization offset of that time synchronization is directly used as the basic correction value. If it is more than 24 hours but no more than 72 hours, the median transmission delay of the recent valid communication samples is added to the basic correction value for compensation. If there is no new time synchronization record after more than 72 hours, or there is no valid time synchronization log for the current object, the corresponding record is marked as a low-confidence time source and is only used for auxiliary comparison and trend analysis, not as the main time reference source. The 24-hour setting is mainly to consider that the daily time synchronization cycle of the device and the concentrator is usually executed on a daily basis. The 72-hour setting is mainly used to distinguish between short-term and long-term non-resynchronization. After exceeding this time, the risk of clock drift accumulation increases significantly. The module employs different time reference strategies for different record types. Power transmission records typically originate from the master station control log, transformer area master table change log, and line status log. The master station control log serves as the primary time reference source, the transformer area master table change log as the secondary time reference source, and the line status log as a supplementary time reference source. This configuration is based on the fact that the master station control log directly reflects the time when control actions are issued, the transformer area master table change log reflects the time when the power supply effect occurs, and the line status log is used to supplement line operation sequence information. Power consumption records can originate from user meter periodic data, short-cycle load data, frozen values, and event records. The module independently aligns periodic data, short-cycle load data, and frozen values, without mixing time stamps. Periodic data is used to reflect continuous changes. Short-cycle load data is used to reflect local fluctuations, while frozen values are used to reflect metering cycle boundaries. Switch status records can include events such as opening, closing, refusal to operate, interlocking, and local buffering. The module first establishes an event sequence according to the order of events, and then checks the time difference between adjacent events to avoid retransmission records and late records disrupting the event chain. Communication records include at least fields such as round-trip delay, number of packet losses, number of retransmissions, offline duration, and link switching time. These records are used for both time correction and identification of transmission interference. Maintenance records correspond to process nodes such as work order creation, arrival, processing start, processing end, and retest completion. The module is aligned according to the work order process sequence and is not compared point-by-point with second-level equipment events, but is used to delineate the boundaries of manual processing intervals and observation periods. After completing the source-by-source fetching, the module enters the time correction phase. Time correction, based on the principle of not disrupting the chronological order of events, aims to establish a unified comparison time range, rather than mechanically correcting all records to the exact same absolute time. For records with valid time logs, the corrected time field is the original time field plus the time offset. For records with significant communication delays and continuous delay samples, the corrected time field is further reduced by the median transmission delay of recent valid communication samples. Recent valid communication samples are those successfully connected within the last 24 hours, with complete fields and matching object identifiers, excluding samples from offline periods and retransmissions exceeding 300 seconds. The median value is used instead of the arithmetic mean. The mean is used primarily to reduce the amplified impact of extreme time delay samples on the correction results. If there are fewer than 20 valid samples in the most recent 24 hours, the median of the valid samples in the most recent 72 hours is used as a substitute to balance the sample size and the length of the statistical window. For records that only have a received time field but no reliable original time field, the received time field is used for comparison, and a downgrade mark is made in the time reliability level. The time reliability level is divided into three levels: Level 1 indicates that it can be used as the main alignment reference, Level 2 indicates that it can be used for auxiliary comparison, and Level 3 indicates that it is only used for trend observation. The three-level division is mainly to distinguish the three levels of use: main reference, auxiliary reference, and observation reference, so that subsequent modules can use time information according to different levels. To prevent over-correction from introducing new errors, the module employs a dual constraint on the amount of delay correction. The first constraint is a dynamic upper limit, meaning the delay correction for a single record cannot exceed three times the median delay of the most recent day's valid communication samples from the corresponding source. The three-times limit is chosen to cover common link jitter ranges while preventing individual abnormal samples from amplifying the correction to the point of distortion. The second constraint is an absolute upper limit, meaning the maximum correction amount cannot exceed 120 seconds. The 120-second limit is chosen because records exceeding this duration are more likely to be retransmissions or delayed records, and should not be corrected as real-time records. If a record, after correction, shows a time inversion with adjacent records from the same source, the module does not directly delete the record but retains the original event sequence and marks the segment as a sequence to be verified, to be treated as a special segment during subsequent verification. After time correction, the module establishes a unified verification window around the session trigger time. The unified verification window is divided into a leading interval, a core interval, and an extended interval. The leading interval is used to extract continuous state changes before the anomaly occurs. When the target device status transmission cycle is no more than 5 minutes, and the current anomaly is a single jump or a single offline event, the leading interval is set to 10 minutes before the trigger to cover at least two consecutive transmission cycles, in order to identify the stable state and initial fluctuations before the anomaly. When the status transmission cycle is greater than 5 minutes, or the current anomaly is continuous fluctuation, continuous offline, or multiple rounds of retransmission, the leading interval can be selected as 20 to 30 minutes before the trigger to cover a longer chain of changes before the anomaly. If the session registration module has determined that the current object belongs to a frequently repeated anomaly, the leading interval is extended to 2 hours before the trigger to trace the cumulative changes over a longer period of time. The aforementioned 2-hour setting is consistent with the judgment criteria for repeated triggers within 2 consecutive hours in the session registration module to ensure the consistency of the processing boundaries between the front and back modules. The core interval is used to pinpoint the main anomaly. When the current anomaly manifests as a single state change, a single refusal to act, or a single record inconsistency, the core interval is set to 3 minutes before and after the trigger, primarily considering that state changes ranging from seconds to minutes, master station reception delays, and short-term receipt offsets typically occur within this timeframe. When the current anomaly involves continuous offline activity, continuous retransmission, multiple records simultaneously failing, or simultaneous triggering across systems, the core interval can be selected to be 10 to 15 minutes before and after the trigger, covering the period when alarms, retransmissions, and control receipts arrive in concentrated quantities. If the current anomaly manifests as a high-frequency change, and the average interval between adjacent events is no greater than 60 seconds, the core interval is compressed to 1 to 3 minutes before and after the trigger to improve the ability to distinguish high-frequency events. A 60-second interval is used as the threshold for a high-frequency change. The boundary determination primarily considers that when the interval between adjacent events is less than 1 minute, it is usually significantly higher than the normal control and sampling rhythm. The extended interval is used to identify the impact of recovery, retransmission, and manual processing after anomalies. When the current session has not yet entered the work order processing flow, the extended interval is 15 minutes to 1 hour after the trigger, with 15 minutes covering the first retransmission and initial receipt, and 1 hour covering a complete remote review and preliminary result return. When the current session is directly associated with the maintenance work order, or the trigger source is a re-trigger within the work order observation period, the extended interval is extended to 24 hours to identify short-term recurrences after maintenance and re-anomalies after retesting. The 24-hour interval is mainly used because the first day after the work order is completed is usually a sensitive period for recurrence identification. The module maps various corrected records to a unified verification window and sets consistency verification tolerances based on record type. The tolerance for the connection between power supply records and switch status records ranges from 5 to 60 seconds. When power supply records originate from the main station control log and switch status records originate from the event log, a tolerance of 5 to 20 seconds is preferred. When switch status records require forwarding via a communication link and experience moderate latency fluctuations, the tolerance can be relaxed to 60 seconds. This tolerance is primarily determined by the fine-grained characteristics of the control log and event log. The tolerance for the connection between short-cycle power consumption records and power supply records ranges from 30 seconds to 3 minutes. When the sampling period for short-cycle load records is 1 minute, a tolerance of 30 to 90 seconds is preferred. When the sampling period is 5 minutes, the tolerance can be relaxed to 3 minutes. This tolerance primarily... The tolerance for the acceptance of maintenance records and equipment events should be determined by combining the load sampling cycle and the upload buffer time; the tolerance for acceptance of maintenance records and equipment events should be between 3 and 30 minutes; when maintenance records are written back from automatic work order nodes, 3 to 10 minutes can be preferred; when maintenance records are filled back from manual terminals, the tolerance can be relaxed to 30 minutes; this tolerance is mainly used to adapt to situations where the granularity of work order node records is significantly coarser than that of equipment events; if the two types of records reflect changes in the same direction within the tolerance range, they are marked as time-consistent; if the order is reversed but the time difference does not exceed the maximum tolerance, they are marked as time-nearly consistent; if the time difference exceeds the tolerance but is still within the unified verification window, it is marked as time-weakly consistent; if one is missing or the time difference significantly exceeds the window range, it is marked as time-inconsistent. After completing the time consistency check between individual records, the module further performs a time interval consistency check. The time interval consistency check focuses on whether a certain type of record maintains a reasonable continuity with another type of record within a continuous time period. The module establishes interval segments for each type of record, with each interval segment including at least start time, end time, status direction, continuity marker, and gap marker. Subsequently, different interval segments are overlaid and compared according to a unified object identifier and device correspondence. Interval relationships are categorized into four types: complete overlap, one-sided coverage, partial overlap, and no overlap. Complete overlap indicates that two types of records match within the same time range; one-sided coverage indicates that one type of record lasts significantly longer than the other, requiring further assessment of whether there is retransmission, delay, or status maintenance; partial overlap indicates discrepancies... It is usually true only within a certain sub-interval. No overlap means that there is no direct time continuity between the two types of records. If there is no overlap and the corresponding source has a gap mark, it is first identified as a scenario to be supplemented. If there is no overlap and no gap mark, and both types of records come from the primary time reference source or the secondary time reference source, they are included in the key inconsistency list. If one type of record comes only from the auxiliary time source, it is included in the inconsistency list to be reviewed. For example, if the power supply record shows that a certain branch is continuously supplying power, while the power consumption record is all zero in the same continuous interval, it can be determined as an obvious interval inconsistency. If the switch status record shows multiple opening and closing actions, while the communication record shows a large number of continuous packet loss in the same interval, the interval inconsistency is first classified as a transmission abnormality pending review scenario, rather than directly classified as a device abnormality. The module also handles abnormal branches and rollback scenarios. If there are no fewer than 5 records from the same source within 10 minutes, and the time interval deviation between adjacent records does not exceed 10%, the segment is identified as a fixed-interval pulse record, used to identify batch retransmission, procedural replay, or abnormal duplicate reporting. The reason for using 10 minutes, 5 records, and 10% interval deviation is mainly to consider that the occurrence of multiple records with nearly equal intervals in a short period of time usually deviates significantly from the natural uploading rhythm. If a large number of duplicate records, time-inverted records, or fixed-interval pulse records from the same source appear in the verification window, the segment is marked as an abnormal segment from the source. Instead of deleting it directly, an abnormal segment index is created, and the overall time reliability level of the segment is reduced. If key sources are simultaneously missing, such as power supply records and switch status records not being obtained, the module will not terminate the session processing, but will retain the current session and mark the status as pending analysis. It will only allow entry into the relationship establishment and trend analysis stages, and will not directly enter the final verification conclusion. If the maintenance record shows that on-site processing has started, the time period from the start of processing to the completion of retesting will be marked as the manual processing interval. Equipment jumps collected during the manual processing interval will not be directly included in the natural fault judgment, but will be interpreted in conjunction with the work order action in the closed-loop stage. If the work order has not returned the retest completion time, the manual processing interval will be temporarily extended to the work order closing time. If the work order closing time is also missing, it will be extended to the time of the last on-site record. If communication records indicate overall link congestion within the core area, the reliability level of the received time field in that area is reduced, and auxiliary alignment is preferentially performed using the original time field of the device or the relative timing relationship of stable reference devices in the same branch. The judgment criteria for overall link congestion can be selected as follows: at least three devices in the same communication link within the core area simultaneously experience retransmission counts exceeding twice the average of the same period in the past seven days, or continuous offline duration exceeding five minutes. The use of three devices is mainly used to distinguish between single-point anomalies and common-cause link anomalies. The use of twice the average and five minutes is mainly determined by combining daily communication fluctuation levels and continuous congestion characteristics. The selection criteria for stable reference devices include at least the following conditions: being in the same branch as the target object, having no offline records and no time-reversed records in the current session window, having valid time synchronization records in the past 24 hours, and having a communication success rate of not less than 95%. For devices that do not have effective time synchronization capabilities, the module allows indirect alignment using the concentrator's unified sampling time, the master station's batch processing timestamp, or the timing relationship of stable reference devices in the same branch. Records obtained through indirect alignment retain auxiliary time source markers and are not included in the main time reference source. After the module completes the processing, it outputs a unified verification table. The unified verification table includes at least the following fields: source record number, unified object identifier, source category, original time, receiving time, correction time, interval, consistency flag, interval relationship flag, gap flag, and time reliability level. It is used as input to the associated receiving module.
[0020] Specifically, such as Figure 4 As shown: The associated receiving module receives the unified verification table output by the timing verification module, and simultaneously reads the equipment ledger, transformer area line file, equipment correspondence table, work order file, and historical handling file to establish a session object set and association table. The session object set is organized hierarchically around the target measurement switch of the current session. The core object layer includes at least the target measurement switch, the directly upstream power supply object, the directly downstream affected object, and the direct communication node. The neighboring object layer includes at least the neighboring switches on the same branch, the associated user set that is on the same power supply branch as the target measurement switch and has a valid power consumption record in the current session window, the associated equipment with a valid communication record under the same communication node, and the equipment that belongs to the same maintenance batch, the same replacement batch, or the same inspection and handling batch within the past 30 days. Here, 30 days is used, mainly based on the calendar month. The common management cycles for centralized maintenance, retesting and follow-up visits, and re-triggering are determined. The historical reference layer should include at least a set of objects that have exhibited the same anomaly type, the same processing location, the same handling path, or a similar triggering time period as the target measurement switch within the last 90 days. Here, 90 days is used, mainly determined by combining the monthly metering cycle, the regular inspection cycle, and the work order closed-loop observation cycle. Similar triggering time periods can be selected as those occurring during the same peak load period, the same metering freeze period, or when the time difference between two triggers does not exceed 2 hours. 2 hours is used, mainly determined by combining the common time range of repeated triggering within the same operating fluctuation cycle. After the object association table is established, at least the following fields should be recorded for each object: unified object identifier, level, line connection location, communication node affiliation, most recent handling record number, and current session validity status. When establishing the object association table, the module first reads the device correspondence of the target device in the current session that took effect at the trigger time. The device correspondence includes at least the correspondence between the measurement switch and the distribution area, the measurement switch and the upstream control point, the measurement switch and the user set, the measurement switch and the concentrator, the measurement switch and the communication gateway, and the measurement switch and the most recent work order object. If the timing verification module has marked the current session window as having a manual processing interval or a device replacement action, it further reads the device mapping relationship before and after the replacement to ensure that the old and new number records after the device replacement fall into the same association chain. For cases where the line connection relationship changes, the module prioritizes using the line connection relationship version that has been frozen during the session registration phase and does not use the version updated later during session processing. The route file directly overwrites the associated results of the current session. If a new route adjustment occurs after the session starts, the changes are written to the relationship change record and the effective time of the change is marked for subsequent closed-loop interpretation, without changing the main association chain already established in the current session. This approach is mainly to avoid unclosed-loop sessions pointing to different objects due to changes in the route file. For the identification of the same maintenance batch, the same parts replacement batch, or the same inspection and handling batch, the consistency of the work order batch number, parts replacement batch number, or inspection task number is used as the primary criterion. When the batch number is missing, it is further combined with the same execution team, the same execution date, and the same processing location for auxiliary merging, in order to take into account both the system's automatic judgment and scenarios with incomplete historical files. After completing the reading of the object set and basic correspondence, the module organizes the associations into three categories: operation inheritance relationship, communication inheritance relationship, and disposal inheritance relationship. The operation inheritance relationship is used to connect power supply records, power consumption records, and switch status records. The module first reads the status interval of the upstream power supply object of the target measurement switch in the unified verification table, then compares it with the status interval of the target measurement switch itself, and finally compares it with the power consumption interval of the downstream affected object. If the upstream power supply change and the target switch action change are consistent or nearly consistent in time in the unified verification table, and the status direction is consistent, and the downstream power consumption change and the target switch action have a response relationship, then an operation inheritance chain is established. If the upstream power supply change and the target switch action change are consistent or nearly consistent in time, but the downstream power consumption has no corresponding response, then the relationship is marked as an operation pending verification relationship, and the relationship description is written as possibly involving sampling link anomalies or user-side individual anomalies. If the target switch action and downstream power consumption changes can be accommodated, but there is no corresponding change in upstream power supply, the relationship is marked as a local status pending verification relationship, and the relationship description should include information about potential local status anomalies or recording errors. The communication connection relationship is used to connect communication records, switch status receipts, and the status of devices at the same node. The module first merges the communication records in the unified verification table according to the communication nodes, and then includes the target measurement switch, devices at the same node, and gateway status into the same communication association group. If no fewer than 3 devices in the same communication association group simultaneously experience receipt delays, increased retransmissions, or continuous offline status in the core area, a common cause communication connection relationship is established. The use of no fewer than 3 devices here is mainly to distinguish between link common cause anomalies and single-point device anomalies, and to avoid interference from one or two devices accidentally occurring concurrently with subsequent judgments. If only the target device is abnormal while the status of other devices in the same group is normal, a single-point communication pending verification relationship is established. The handling succession relationship is used to connect historical maintenance records, previous work order processing actions, current anomaly triggers, and observation period results. The module merges historical work orders according to a unified object identifier, processing location, processing action, and completion time. If the current session and a historical work order have at least two identical items in the four dimensions of object, processing location, anomaly type, and trigger time window, a repeatable pattern is identified, and a historical handling succession relationship is established. The requirement of at least two identical items is mainly determined by the stability and coverage of the identification: if only one item is identical, irrelevant history may be introduced; if three or more items are required to be identical, valuable previous handling records may be missed. Through the above processing, the module can organize the operation chain, communication chain, and previous handling chain separately within the current session, and provide a basis for subsequent relationship strength determination and verification order determination. To ensure that the association results can be directly used for subsequent verification and sorting, the module assigns a relationship strength identifier to each relationship. Relationship strength is divided into four levels: direct acceptance, nearest neighbor acceptance, indirect acceptance, and pending verification acceptance. Direct acceptance is used for relationships between the target measurement switch and its direct upstream, direct downstream, and direct communication nodes. Nearby acceptance is used for relationships between neighboring devices on the same branch, associated user sets within the same power supply branch, associated devices at the same communication node, and devices from the same maintenance batch within the past 30 days. Indirect acceptance is used for relationships between historical reference layer objects and the current session. Pending verification acceptance is used for relationships that are close in time but have gaps in object mapping, unclear line connection relationships, or incomplete records. The four levels of relationship strength are primarily used for… The relationship strength is determined by considering the degree of certainty of the relationship, the order of reference, and the need for subsequent verification. This distinction is used to differentiate between highly certain relationships, adjacent relationships, empirical relationships, and relationships awaiting confirmation. The strength of the relationship is also assessed by considering line connection relationships, temporal relationships, and record completeness. If two objects are directly corresponding in the fixed correspondence table, and the unified verification table shows complete overlap or high consistency in their time intervals, they are marked as directly connected. If the fixed relationship is clear, but the temporal relationship only shows partial overlap, it is marked as a close neighbor connection. If the relationship mainly relies on historical work order experience, and there is no direct correspondence in the current line file, it is marked as an indirect connection. If the relationship has some basis but still has gaps in objects, records, or unstable time, it is marked as a relationship awaiting verification. Relationship validity status can be divided into four categories: valid, pending verification, rollback, and invalid. Valid means that the current relationship can directly proceed to subsequent verification; pending verification means that the current relationship exists, but still needs to be verified by supplementing records; rollback means that the original high-level relationship has been downgraded due to missing records or unmet conditions; invalid means that the current relationship is no longer applicable to this session. Relationship records should include at least the following fields: source object, target object, relationship category, relationship strength, association time period, supporting record number, relationship description, and relationship validity status. After adopting the above writing method, the hierarchy between relationship strength, relationship status, and record fields is clearer and more in line with the expression habits of module processing logic in the specification. In complex scenarios, the module also handles object conflicts and relationship rollback. Object conflicts mainly occur after equipment replacement, user migration, concentrator replacement, and line segmentation adjustments. If the same electricity usage record may be mapped to two different devices simultaneously within the current session window, the decision is made based on the effective time of the device correspondence and the most recent manual confirmation record. If the manual confirmation record is no more than 30 days old from the current session, the manual confirmation result is adopted first. The 30-day period is mainly considered because manual confirmation information usually still has high practical validity within a calendar month. If the manual confirmation record is more than 30 days old, the decision is further made based on the currently frozen line connection relationship, the current communication node affiliation, and the most recent manual confirmation record. The most recent valid manual confirmation result will be used for a second ruling; if a conflict still exists, the record will be included in the pending verification set and will not participate in the direct execution of the connection chain, but will only be used as auxiliary observation information; relationship rollback mainly occurs when the current relationship strength is insufficient to support downstream verification; for example, the relationship between the target measurement switch and a certain group of users exists in the ledger, but there are no available records for that group of users in the session window, then the originally expected direct connection will be rolled back to pending verification connection, and the reason for the missing data will be written in the relationship description; another example is that there is a connection in the same communication association group, but only one device other than the target object has a valid record in the current session window, then the originally expected common cause communication connection relationship will be rolled back to single point communication pending verification relationship; For regions with incomplete records, the module allows the construction of empirical correlation relationships using stable linkage records within the last 90 days. Stable linkage records can be defined as linkage records with the same object combination, the same abnormal direction, and similar triggering time periods occurring at least three times within the last 90 days, provided that the same line connection relationship has not changed. The use of 90 days and at least three times is mainly to ensure that empirical relationships have both continuity and repetition, so as to avoid misjudging a single accidental co-occurrence as a stable association. The association established through empirical correlation relationships is only used as a nearest neighbor or indirect association and does not replace direct association. After the module completes the processing, it outputs a session relationship table. The session relationship table includes at least the following fields: running association, communication association, disposal association, relationship strength, relationship validity status, association time period, and relationship description, and serves as the input for the evidence arrangement module.
[0021] Specifically, such as Figure 5As shown: The evidence orchestration module starts after receiving the unified verification table and the session relationship table; the module converts the record items in the unified verification table and the relationship items in the session relationship table into evidence items, and establishes an evidence set within the same diagnostic session; each evidence item includes at least the following fields: evidence number, unified object identifier, source category, relationship category, time consistency marker, interval relationship marker, source reliability level, interference marker, relationship strength, and current usage status; the current usage status can be divided into five categories: pending orchestration, primary verification candidate, secondary verification candidate, observation candidate, and exclusion candidate; the source category can be divided into power supply execution, power consumption performance, switch status, communication link, and handling history. Historical data and field feedback data are categorized into three reliability levels: high, medium, and low. High-level sources include main station control logs, device local cache, field retest results, and official work order write-backs; low-level sources include manual summary descriptions, supplementary log entries, and pending audit ledger mappings; and medium-level sources include other records that form stable source chains but are less direct than high-level sources. Interference tags include at least manual processing interference, link blocking interference, supplementary transmission interference, load fluctuation interference, and undetermined object mapping interference. Manual processing interference, link blocking interference, and undetermined object mapping interference are classified as strong interference, while supplementary transmission interference and load fluctuation interference are classified as general interference. The module does not use a single score for direct sorting, but instead employs a combination of hierarchical entry and sequential arrangement. In the hierarchical entry stage, it first determines whether a single piece of evidence meets the criteria for entering the primary verification candidate layer. The criteria for entering the primary verification candidate layer include at least the following: the object relationship is direct or near-direct; time consistency is consistent or nearly consistent; the source reliability level is not lower than medium; and the interference marker is not strong interference. If a piece of evidence meets at least three of the above four conditions, it enters the primary verification candidate layer; if it meets only two conditions, it enters the auxiliary verification candidate layer; if it meets only one condition but still has supplementary value for the current session... If the evidence has sufficient explanatory value, it will enter the observation candidate layer; if the object mapping conflict is obvious, the time is inconsistent, the relationship has been excluded, or the interference mark is a strong interference and there is currently no supplementary evidence, it will enter the exclusion candidate layer; at least 3 of the 4 conditions must be met, mainly to ensure the quality of evidence while retaining the necessary candidate range; if only 2 conditions are met, it is easy to include records of average quality in the main verification candidate layer; if all 4 conditions are required to be met, it is easy to make the main verification candidate layer too empty in complex scenarios; "currently no supplementary evidence" means that there is no source to be supplemented corresponding to the evidence in the supplementary evidence list, and the remote review interface does not support the supplementation of such records; During the hierarchical entry process, historical processing corrections can also be introduced. If a piece of historical processing evidence comes from the most recent valid work order, and the current anomaly is still within the observation period corresponding to that work order, then even if the reliability level of the source is only medium, this evidence can be promoted one level from the original level to prioritize checking for duplicate work orders or incomplete processing. The observation period here uses the valid observation interval that has been written into the work order file or observation period file by the verification closure module, without setting a new time boundary separately. Promotion by one level is limited to promotion between adjacent levels and does not cross the exclusion candidate layer to directly enter the main verification candidate layer. If the historical work order is far from the current session, or the processing part is not obviously related to the current anomaly direction, then this piece of historical evidence is retained in the observation candidate layer and does not participate in the main verification order. After the hierarchical entry is completed, the module performs a priority ranking of the primary verification candidate layer and the auxiliary verification candidate layer. The ranking ranking considers at least four rules: directness of record, temporal consistency, source reliability, and interference status. The directness of record priority rule prioritizes evidence that directly reflects the operating status, communication status, and upstream and downstream response relationships of the target measurement switch, placing evidence that only indirectly reflects regional trends or historical experience at the bottom. The temporal consistency priority rule prioritizes evidence that is in the core interval and shows temporal consistency with the first triggering event, placing evidence that is nearly temporally consistent at the bottom, and further shifting evidence that is only in the extended interval or only shows weak temporal consistency to the bottom. (Source...) The reliability priority rule is used to rank evidence from highest to lowest reliability level; the interference avoidance rule is used to move evidence that is strongly affected by interference to the next level within the same hierarchy; if there is insufficient high-quality evidence, fewer than two pieces of evidence can be considered as primary verification candidate evidence, or if there are at least two primary verification candidate pieces but they all come from the same source system and do not have independent generation paths; two pieces are used as the boundary, mainly because a single piece of evidence cannot form the most basic cross-verification; the situation where the evidence comes from the same source system and does not have independent generation paths is considered insufficient, mainly because the evidence lacks source independence at this time; if the evidence comes from the same system but originates from independent log chains and independent cache chains respectively, it can not be directly considered as not being source-independent; To avoid overly rigid sorting, the module can also introduce session priority correction rules. When the session registration module gives a priority of level one or level two, power supply execution evidence and switch status evidence involving a large number of users or important users are allowed to move forward one position within the same candidate layer, but not across the hierarchical boundary between the primary verification candidate layer and the secondary verification candidate layer. Here, "large number of users" can be taken as the number of associated users not less than the user scale corresponding to the level two priority in the session registration module. For historical evidence that has entered the primary verification candidate layer or the secondary verification candidate layer, if the current session is a repeated trigger within the observation period, it is allowed to move forward one position within the original layer to prioritize the identification of whether there is a closed-loop failure or repeated order dispatch. This setting can maintain the basic stability of evidence sorting and improve the calling order of key evidence in high-priority and repeated abnormal scenarios. After completing the sequential arrangement, the module further establishes a verification sequence chain. This chain is used to fix the dependencies and calling order between high-level evidence, rather than simply generating a linear list. The verification sequence chain includes at least a first verification pair formed by power supply execution evidence and switch status evidence, a second verification pair formed by switch status evidence and electricity consumption performance evidence, a third verification pair formed by communication link evidence and switch status receipt evidence, and a correction rule item formed by handling historical evidence. The first verification pair is used to determine whether upstream actions and equipment actions are accepted; the second verification pair is used to determine whether equipment actions and load responses are accepted; the third verification pair is used to determine whether the anomaly may be caused by link delays or communication gaps; and the correction rule item is used to adjust whether to directly dispatch orders on-site or perform remote verification first. Each verification... Trigger conditions are set for each verification pair. When power supply execution evidence and switch status evidence are both in the primary verification candidate layer and their time consistency is not less than near-consistent time, the first verification pair is executed first. When switch status evidence is insufficient or the object relationship is marked as pending verification, the first verification pair is skipped and the third verification pair is executed first to check whether the communication link has caused a state loss. When the first verification pair is valid and the power consumption performance evidence corresponding to the second verification pair is also eligible for primary verification, the second verification pair is executed. When the second verification pair lacks key downstream evidence, the downstream response judgment is suspended and added to the list of evidence to be supplemented. This sequential chain method is mainly to enable the verification closed-loop module to execute directly along the predetermined path without having to redetermine the verification starting point and switching conditions in each session. The module also generates a list of documents to be supplemented; this list addresses situations where there are critical gaps in the primary verification candidate layer that can still be resolved through supplementary data retrieval or remote review, such as missing local cache entries for switch states, insufficient communication samples within the same node, or gaps in short-cycle load records of downstream users. The list includes at least the following fields: the object to be supplemented, the source to be supplemented, the fields to be supplemented, the allowed number of retries, and the latest time to supplement the data. The critical source to be supplemented can be selected as a source directly corresponding to the first, second, or third verification pair, and whose current absence would cause an interruption in the verification sequence chain. For critical sources to be supplemented, automatic retries are allowed by default twice; this can be extended to three times when the session priority is level one or two and the critical evidence to be supplemented is still missing. The default setting of 2 retry attempts, which can be extended to 3 attempts if necessary, primarily considers the control of retry time in normal scenarios and the additional re-certification requirements in high-priority sessions. The retry interval can be set to 5 minutes or 15 minutes, where 5 minutes mainly corresponds to short-term interface jitter and fast re-transmission, and 15 minutes mainly corresponds to a complete re-transmission cycle. The latest retry time is generated according to the session priority. When the session priority is level 1 or 2, it can be set to 15 minutes after the current time; when the session priority is level 3, it can be set to 30 minutes after the current time; when the session priority is level 4 or 5, it can be set to 60 minutes after the current time. The above time settings mainly consider that high-priority sessions need to converge as soon as possible, while low-priority sessions can retain a relatively lenient re-certification window. The module also generates a list of prohibited direct work orders. This list is for situations where it is not appropriate to immediately issue on-site work orders under the current evidence conditions, such as obvious manual processing interference in the core area, unconfirmed changes in line relationships, communication blockages that meet the conditions for establishing common-cause communication connection relationships, and incomplete key ledger mapping. For sessions entering the prohibited direct work order list, the verification closed-loop module prioritizes remote review or manual ledger verification and does not directly generate work orders for replacing the measurement switch itself. In handling abnormal scenarios, the module sets rollback and manual takeover conditions. When the current session meets the condition of insufficient high-quality evidence, the session is marked as an insufficient evidence session. At this time, only observation suggestions and supplementary tasks are generated, and the session does not enter the direct order dispatch judgment. When there are at least two pieces of evidence with high source reliability in the main verification candidate layer, and the two pieces of evidence give opposite state directions in the same object and the same time window, the session is marked as a conflict session and transferred to the manual takeover queue. At least two pieces of highly reliable evidence are used as the trigger boundary. This is mainly because a single piece of evidence is not enough to form a stable conflict judgment, while when two or more pieces of highly reliable evidence show opposite directions, it can better reflect the substantial conflict at the conclusion level. When there are no less than two pieces of neighboring evidence in the auxiliary verification candidate layer that match the main verification candidate layer, and the neighboring evidence is consistent with or complementary to the current high-ranking evidence in terms of source category, relationship category, and time consistency, one of them can be automatically promoted to the main verification candidate layer to enhance the decidability of the current session. Here, consistency can be selected as consistent or complementary source category, consistent relationship category, and time consistency not lower than time near consistency. For historical recurrence anomaly scenarios, when the high-ranking evidence from the most recent three sessions is highly similar, this arrangement is allowed to be written into the same type of template. The use of the most recent three sessions is mainly to consider that three consecutive repetitions can better distinguish between stable patterns and occasional repetitions, avoiding interference from single or two consecutive anomalies on the template. Here, "high similarity" can be selected as at least two of the source category, relationship category, and verification order of the first three high-ranking evidence in the most recent three sessions being consistent. The template is only called when the object category, station type, and source integrity all meet the consistency condition. Consistent source integrity can be selected as at least two types of sources in the first three high-ranking evidence being continuously present in each session. After the module completes the processing, it outputs an evidence sequence table, a verification sequence chain, a list of evidence to be supplemented, and a list of orders prohibited from direct dispatch, which serve as inputs to the verification closed-loop module.
[0022] Specifically, such as Figure 6 and Figure 7As shown: The verification closed-loop module starts upon receiving the evidence sequence list, verification sequence chain, list of documents to be supplemented, and list of documents prohibited from direct dispatch, prioritizing the document supplementation list. For data that can be supplemented via remote interface, such as device local cache summaries, the most recent successful receipt, communication samples from the same node, and downstream short-cycle load records, the module initiates supplementation according to the source of the document to be supplemented, the latest supplementation time, and the allowed number of retries recorded in the document supplementation list. The supplementation priority follows the order in the evidence sequence list, with higher-order evidence gaps being supplemented first, and lower-order evidence gaps being supplemented later. (The document also mentions supplementation boundaries.) If the key missing data sources have been fully retrieved, or if the maximum number of retries for all key missing data sources has been reached and no valid data has been returned, the data can be written to the backfill record table after successful retrieval and returned to the evidence arrangement module through the internal data write-back channel to re-determine the level and order of the relevant evidence. If the retrieval fails and the maximum number of retries is reached, the corresponding gap status will be fixed as incomplete and the reason for failure will be recorded. The backfill record table should include at least the following fields: session identifier, unified object identifier, retrieval source, retrieval time, backfill field, retrieval result, and reason for failure. After the supplementary certificate is completed or the supplementary certificate boundary is reached, the module performs remote review according to the verification sequence chain. Remote review actions can be divided into non-disruptive reading, comparison verification, and light-trigger verification. Non-disruptive reading actions are used to read the device's local cache, gateway status, and short-cycle load segments without changing the device's operating status, and have the highest priority. Comparison verification actions are used to compare high-level evidence in the same session, such as comparing the upstream power supply log with the target switch event sequence, comparing the target switch receipt with the receipt of the same node device, and comparing the processing location of the previous work order with the current abnormal direction. Light-trigger verification actions are only allowed to be executed when the list of prohibited direct dispatch orders is not hit and the current session priority is level one or level two, such as initiating a short-cycle status refresh request or a communication connectivity check request. The module generates an action record for each remote review action. The action record includes at least the following fields: action number, session identifier, trigger time, target object, input evidence number, expected receipt time limit, success criterion, failure criterion, and timeout handling strategy. The expected response time limit is determined based on the action category and link conditions. For comparison of internal logs on the main station, a time limit of 5 to 15 seconds is acceptable, primarily considering the fact that internal index queries on the main station are typically completed within seconds. For remote device reading, a time limit of 10 to 30 seconds is acceptable in urban direct-connection scenarios, and can be extended to 60 seconds in scenarios with link fluctuations or remote areas, mainly considering the differences in link transmission latency and terminal response latency. For communication connectivity checks, a time limit of 30 to 60 seconds is acceptable in direct gateway channel scenarios, and can be extended to 120 seconds in scenarios involving multi-level forwarding or narrowband links, mainly to cover the response return cycle under different communication paths. Uninterrupted reading actions are allowed to retry once by default. Comparison and verification actions are generally not retried, and the current result is directly retained. Lightly triggered verification actions are only allowed to retry once in level 1 or 2 sessions, and not in level 3 to 5 sessions. The above time limits and retry methods are mainly to improve the convergence efficiency of high-priority sessions without excessively extending the remote processing time. After remote review is completed, the module determines whether to end the remote phase. The termination conditions can be divided into two categories: The first category is that a single verification conclusion chain has been formed. A single verification conclusion chain can be selected as follows: there are no unexcluded competing conclusions among the top 3 pieces of evidence in the main verification candidate layer, and at least one verification pair has been established. The second category is that although there is still a competitive relationship, the on-site verification boundary has been clearly defined, and the list of prohibited direct dispatching has been removed. The on-site verification boundary has been clearly defined as follows: the minimum set of items has been generated, the scope of the on-site objects has been determined, and the prohibited misoperation items have been written into the work order draft. If the first category of conditions is met, the module directly enters the closed-loop judgment and does not generate an on-site work order. If the second category of conditions is met, the on-site dispatching phase begins. Structured work orders are generated during the on-site dispatch phase, instead of directly issuing abnormal equipment numbers. Structured work orders should include at least the target object, the scope of associated objects, a minimum set of items, prohibited misoperations, a suggested order of arrival, arrival time limits, retesting requirements, and feedback field requirements. The minimum set of items is derived from high-level gaps in the evidence sequence table and currently unresolved competing items, and can be 3 to 5 items. Using 3 to 5 items is primarily because on-site work orders need to simultaneously cover object verification, status verification, and cause verification; too many items would distract on-site attention and prolong processing time. The suggested order of arrival is based on the direct acceptance relationship output by the associated acceptance module and the nearest... Once the adjacent connection relationship is determined, priority is given to reaching the core object, and then upstream objects or communication nodes are checked as needed. The returned fields must include at least the arrival time, on-site observation status, retest results of key components, whether components were replaced, post-retest status, image index, and manual judgment. Work order escalation reminders are generated according to session priority. Level 1 sessions automatically escalate to a reminder if no work order is accepted within 15 minutes of its issuance. Level 2 and 3 sessions can be set to 30 minutes; Level 4 and 5 sessions can be set to 60 minutes. The use of 15-minute, 30-minute, and 60-minute timeframes is primarily to maintain consistency with the session priority system and to ensure that high-priority sessions receive on-site resources first. During the execution of on-site work orders, the module continuously tracks the processing status. The tracking source can be status changes on the work order platform or real-time feedback from the on-site terminal. The work order status can be divided into nine categories: pending order, accepted order, on-site, verification in progress, processing in progress, retesting in progress, pending supplementary feedback, pending write-back, and completed. The allowed stay time for the on-site status is controlled according to regional conditions: no more than 45 minutes in urban areas, no more than 90 minutes in suburbs or general mountainous areas, and no more than 120 minutes in remote areas. The above classification is mainly to take into account the significant differences in traffic accessibility in different areas, and the session registration module has already identified remote areas. The supplementary reminders for the verification in progress status are controlled according to session priority. Level 1 and Level 2 sessions will be automatically reminded if no key results are returned within 30 minutes after the start of verification, while Level 3 to Level 5 sessions can be given 60 minutes. The use of 30 minutes and 60 minutes is mainly to take into account that the former can cover the on-site initial inspection, retesting, and first feedback cycle of high-priority sessions, while the latter can take into account the relatively relaxed processing pace of ordinary sessions. Upon arrival of the field feedback, the module first verifies its completeness. If retest results, key image indexes, or processing action descriptions are missing, the work order status enters the "pending feedback" phase, not the "complete" phase. If the feedback is complete, the content is converted into a field review result item, which, together with existing remote review results, forms the closed-loop judgment input. The closed-loop judgment follows the order of field priority, structured priority, and same-session priority, meaning that field structured retest results take precedence over remote trend inference, and direct feedback within the same session takes precedence over old records in the historical archive. If the field results are consistent with the remote results, a stable closed-loop conclusion is formed. If the field results conflict with the remote results, a conflict list is generated, and the session is transferred to the manual review queue. Before the manual review is completed, the current conclusion is not written into the formal rule archive. The conflict list includes at least the conflict evidence number, conflict object, conflict time window, conflict direction, and items to be confirmed. During the result write-back phase, the module writes the final conclusion of the current session, the remote review trajectory, the on-site work order trajectory, and the observation period settings into the corresponding files. The files to be written include at least the session file, the equipment anomaly file, the work order file, and the observation period file. The session file records at least the first trigger time, the sequence of key evidence, the main verification actions, and the final closure method. The equipment anomaly file records at least the anomaly category, the verified location, whether there are duplicate anomalies, and suggested points of attention. The work order file records at least whether the on-site handling hit the root cause, whether there are duplicate work orders, and whether the work order object deviates from the actual fault object. The observation period file records at least the observation period duration, the observed object, the observed indicators, and the re-triggering judgment threshold. The re-triggering judgment threshold here directly calls the re-triggering judgment rules in the session registration module and the duplicate anomaly judgment criteria in the evidence arrangement module, without setting new judgment boundaries separately. The observation period is set according to the anomaly category and the handling action. The observation period for communication anomalies can be set to 4 to 24 hours, mainly based on the operational characteristics of communication problems, which are relatively quick to recover and quick to recur. The observation period for sampling link anomalies can be set to 1 to 3 days, mainly based on the sampling cycle and the coverage requirements of the settlement boundary. The observation period for equipment replacement anomalies can be set to 3 to 7 days, mainly based on the installation stabilization period and continuous operation period after replacement. If a same-direction anomaly is triggered again during the observation period, the module will automatically establish a recurrence association between the newly triggered session and the old session, and move the competing items in the old session that have not yet been prioritized for verification one position forward. If no same-direction anomaly is triggered again after the observation period ends, the current session will be marked as a stable closed loop. The module also includes an exception branch and rollback mechanism. If the remote review has met the conditions for establishing a common cause communication relationship and there is currently no contrary high-reliability evidence, then the generation of a measurement switch replacement work order is prohibited. Only the generation of a link inspection work order or a gateway inspection work order is allowed. Here, "no contrary high-reliability evidence" means that within the same object and the same time window, there is no evidence that the source reliability level is high and the state direction is contrary to the common cause communication conclusion. If the field feedback indicates that the object mapping is incorrect, such as the field equipment number not matching the equipment ledger, then the current session is paused and the formal closure is initiated. The ledger correction task is initiated first, and the association acceptance and evidence arrangement are re-executed after the correction is completed. If the field personnel only perform processing actions but do not complete the retest, the work order status remains "pending write-back" and direct termination is not allowed. If a new anomaly occurs during the observation period and the old work order is still in an incomplete state, the new anomaly is preferentially merged into the continuation of the old work order to avoid forming parallel work orders. For unattended areas, if the current session priority is level three, four, or five, and a single verification conclusion chain has been formed in the remote phase, then the process of delaying on-site dispatch and first executing extended observation is allowed. The extended observation period can be 4 to 12 hours, with ordinary sessions involving communication or missing statuses taking a priority of 4 to 8 hours, and ordinary sessions involving equipment status fluctuations taking up to 12 hours. This duration is mainly to cover one round of retransmission, receipt, and re-triggering observation cycle while controlling on-site resource input. During the extended observation period of delayed on-site dispatch, if an anomaly in the same direction is triggered again, or if key supplementary evidence is still not complete, the process will automatically switch to the on-site dispatch phase. If no further anomalies are triggered after the extended observation period ends, and the remote verification results remain consistent, the process will directly enter the closed-loop judgment phase.
[0023] Example 2: Based on Example 1, the specific application process of a measurement switch fault diagnosis system is further explained: For example, a measuring switch in a low-voltage distribution area continuously triggered abnormal status alarms during the evening peak hours. The main station successively received alarms of switch status jumps, records of short-cycle abnormal load fluctuations of users on the same branch, and records of increased communication retransmissions. At the same time, historical work order files showed that the measuring switch had undergone on-site maintenance three days prior. This system is deployed at the diagnostic service node on the main station side and is connected to the alarm access interface, equipment ledger interface, communication log interface, work order platform interface, historical file interface, and on-site feedback interface. When the above-mentioned abnormal trigger information enters the diagnostic entry point, the system first establishes a diagnostic session through the session registration module, then the time sequence verification module uniformly organizes the time relationships of multi-source records, then the association and acceptance module establishes the object relationships and handling relationships within the current session, then the evidence arrangement module forms the verification order and dispatch constraints, and finally the verification closed-loop module completes remote review, on-site work order execution, result writing back, and observation period tracking. In this scenario, the session registration module receives alarms from the main station, communication anomaly records, and re-trigger records within the observation period of historical work orders. It then converts the device code, station code, branch code, source system code, and trigger time into a unified object identifier. The unified object identifier can be a combination of the station number and the device's unique number, ensuring a unique correspondence across different business systems. The module further generates a session identifier based on the first trigger time and merges the current trigger with historical unclosed sessions. If the main station's receiving time and an existing session are within the same session merging window, and at least two of the three dimensions—anomaly type, anomaly manifestation, and handling object—are consistent, the current trigger is appended to the existing session. If these conditions are not met, a new session is established. In this example, because the current alarm is a re-trigger within the observation period corresponding to a work order from three days prior... Since the records are consistent in terms of anomaly type and handling object, and do not exceed the session merging window, the system classifies them into the same diagnostic session; the session registration module generates a basic session record; the basic session record includes at least the following fields: unified object identifier, first trigger time, current acceptance time, trigger source set, current anomaly type, status identifier, priority identifier, associated work order identifier, and rule version identifier; considering that the measured switch corresponds to a large number of branch users and is in a short-term recurrence phase after maintenance, the module marks the current session as a higher priority; then, the module establishes an input list; the input list includes at least the following data items: power supply record, power consumption record, switch status record, communication record, and maintenance record, and further retrieves the previous work order handling action, retest results, and observation period setting value, and then transmits the above content along with the gap identifier to the timing verification module; After receiving the basic session records and input list, the timing verification module retrieves records source by source from the main station data bus, device historical database, communication log database, and work order archive database. For each record, the module establishes fields such as source record number, original time field, received time field, corrected time field, and time reliability level field. Taking the current scenario as an example, power supply records can come from the main station control log and the transformer area master table change log, switch status records can come from the measurement switch event cache and status receipt, communication records can come from the gateway communication log, maintenance records can come from the work order platform, and user load records can come from the short-cycle load acquisition database. Due to differences in time standards, upload paths, and retransmission methods among various types of records... If discrepancies exist, the module first reads the most recent time synchronization log of the target measurement switch, the most recent time synchronization record of the concentrator, and the most recent link delay sample of the communication gateway, and then performs time correction on various records. If the time synchronization log is no more than 24 hours from the current trigger time, the time synchronization offset is directly used for correction. If it is more than 24 hours but no more than 72 hours, the median transmission delay of the recent valid communication samples is added to the base offset. If there is no valid time synchronization log, the corresponding record is marked as a low-confidence time source and only participates in auxiliary comparison. For communication records in the current scenario, the module further removes offline period samples and excessively long retransmission samples to avoid abnormal samples amplifying the correction deviation. After completing the time correction, the module establishes a unified verification window. Since the current alarm occurs during a short-cycle fluctuation during the evening rush hour, the leading interval can be set to 10 to 30 minutes before triggering, used to extract continuous changes before the anomaly; the core interval can be set to 3 to 15 minutes before and after triggering, used to lock the main state change; the extended interval can be set to 15 minutes to 1 hour after triggering, used to identify the impact of retransmissions, initial receipts, and manual intervention. Subsequently, the module sets tolerances according to different record granularities. Power supply records and switch status records can use tolerances on the order of seconds to 1 minute, short-cycle power consumption records and power supply records can use tolerances on the order of minutes, and maintenance records and equipment records can use tolerances on the order of minutes. The backup event can adopt a tolerance of minutes to 30 minutes. If two types of records show changes in the same direction within the corresponding tolerance range, they are marked as time-consistent. If the order is slightly reversed but does not exceed the maximum tolerance, it is marked as time-nearly consistent. If it exceeds the tolerance but is still within the unified verification window, it is marked as time-weakly consistent. If there is no corresponding relationship, it is marked as time-inconsistent. After the above processing, the master station power supply log, switch status jump record and user load drop record in the current scenario are unified into the same time window. The communication retransmission increase segment is marked as transmission interference segment. The module finally outputs a unified verification table as the input for subsequent object relationship establishment. After obtaining the unified verification table, the association module reads the equipment ledger, line connection file, equipment correspondence table, and historical handling file to establish the object set and association table for the current session. The object set is divided into a core object layer, a neighboring object layer, and a historical reference layer around the target measurement switch. The core object layer includes at least the target measurement switch itself, upstream power supply objects, downstream affected user objects, and direct communication nodes. The neighboring object layer includes at least neighboring switches on the same branch, user sets with valid power consumption records within the same power supply branch, associated equipment under the same communication node, and equipment belonging to the same maintenance batch or the same inspection and handling batch within the past 30 days. The historical reference layer includes at least objects that have experienced the same anomaly type, the same handling location, or a similar triggering time with the target measurement switch within the past 90 days. After establishing the object set, the module further locks the correspondence between the target measurement switch and the upstream control point, downstream user set, concentrator, communication gateway, and the most recent work order object. If the target equipment has undergone maintenance, replacement, or numbering change, the module further reads the equipment mapping relationship before and after the replacement to avoid incorrect segmentation of the old and new numbering records during the association process. After completing the reading of the object set and basic correspondence, the module establishes associations within the current session according to operational, communication, and disposal relationships. In operational relationships, if the state change of the upstream power supply object and the action of the target measurement switch are time-consistent or nearly time-consistent, and the downstream user's power consumption changes and the target measurement switch's action have a responsive relationship, then an operational relationship chain is established. In communication relationships, if the target measurement switch and other devices under the same communication node simultaneously experience acknowledgment delays, increased retransmission counts, or continuous offline status within the core interval, then common-cause communication is established. In the process of establishing a handling relationship, if the current session and the historical work order have at least two identical aspects in the dimensions of unified object identifier, processing location, and exception type, then a historical handling handling relationship is established. After establishing the above association, the module further assigns a relationship strength to each relationship. The relationship strength can be selected as direct handling, neighbor handling, indirect handling, or pending verification handling, and the effective status of the relationship is written into the session relationship table. The session relationship table includes at least the following fields: source object, target object, relationship category, relationship strength, associated time period, relationship description, and effective status of the relationship, and serves as the input to the evidence arrangement module. After receiving the unified verification table and session relationship table, the evidence arrangement module converts record items and relationship items into evidence items. Each evidence item includes at least the following fields: unified object identifier, source category, relationship category, time consistency flag, interval relationship flag, source reliability level, interference flag, relationship strength, and current usage status. Combined with the current session, the main station power supply log, measurement switch local event cache, communication retransmission log, downstream load short-cycle records, and historical work order processing records can all be converted into evidence items. The module first performs hierarchical enqueueing. Evidence items are considered evidence items when they simultaneously satisfy the following conditions: the object relationship is a direct or near-adjacent connection, time consistency is consistent or nearly consistent, and the source is reliable. When the level is not lower than medium level and does not belong to strong interference, it is given priority to enter the main verification candidate layer; when only two of the conditions are met, it enters the auxiliary verification candidate layer; when only one condition is met but still has supplementary explanatory value, it enters the observation candidate layer; when there is obvious object mapping conflict, inconsistent time, or strong interference and no supplementary verification conditions at present, it enters the exclusion candidate layer; in the current scenario, the main station power supply log, switch local event cache and downstream user short-cycle load record all have high directness and high time consistency, so they enter the main verification candidate layer; historical work order processing records can be promoted by 1 level to participate in subsequent ranking because they are still within the observation period and have explanatory value for the current anomaly; After hierarchical enqueueing is completed, the module performs sequential arrangement according to the directness of record, temporal consistency, source reliability, and interference status, placing evidence that directly reflects the target equipment status and upstream and downstream response relationships at the top, and historical experience evidence used only for background description at the bottom. For higher priority sessions, power supply execution evidence and switch status evidence can be moved one position forward within the same level. Subsequently, the module establishes a verification sequence chain; the first verification pair can be selected as power supply execution evidence and switch status evidence, used to determine whether upstream actions and equipment actions are connected; the second verification pair can be selected as switch status evidence. Evidence and electricity consumption performance evidence are used to determine whether equipment actions and downstream load responses are accepted; the third verification pair can be communication link evidence and switch status receipt evidence, used to determine whether the current anomaly is caused by link delay; if a key verification pair lacks corresponding evidence, the missing content is added to the supplementary evidence list; if there is manual processing interference, undetermined object mapping, or communication blockage that meets the conditions for establishing a common cause communication acceptance relationship, it is added to the prohibited direct order dispatch list; after processing, the module outputs an evidence sequence table, a verification sequence chain, a supplementary evidence list, and a prohibited direct order dispatch list. Upon receiving the evidence sequence list, verification sequence chain, list of documents requiring supplementary verification, and list of documents prohibited from direct dispatch, the verification closed-loop module prioritizes processing documents requiring supplementary verification. For the current session, the module prioritizes retrieving the most recent successful acknowledgment from the target measurement switch and communication samples from the same node. After retrieval, the module performs remote verification according to the verification sequence chain, prioritizing non-disruptive reading actions such as reading the local cache of the measurement switch and the gateway status, and then performing comparison and verification actions such as comparing the upstream power supply logs, equipment event sequences, and acknowledgments from devices at the same node. When the current session has a higher priority and the list of documents prohibited from direct dispatch is also available, the module will proceed with further verification. If the target measurement switch is not selected, a light-trigger verification action is executed, initiating a short-cycle status refresh request. After remote verification is completed, if a single verification conclusion chain has been formed among the evidence in the primary verification candidate layer, and the on-site verification boundary has been clearly defined, a structured work order is generated. The structured work order includes at least the target object, the scope of related objects, the minimum set of items, prohibited misoperation items, the suggested order of arrival, the arrival time limit, retesting requirements, and return field requirements. If the current session is of high priority and the work order is not accepted within 15 minutes, an escalation reminder is automatically triggered. During the execution of on-site work orders, the module continuously tracks the work order status and, upon arrival, requests on-site personnel to transmit retest results, key component status, whether components were replaced, and image indexes, etc. If the on-site transmission is complete, the module uses both the on-site and remote retest results as inputs for closed-loop judgment. If the two are consistent, a stable closed-loop conclusion is formed; if they conflict, a conflict list is generated and the system is transferred to the manual retest queue. In the current scenario, on-site personnel confirm that the measurement switch itself is functioning normally, but there is poor contact in the communication connector. Based on this, the module determines that the source of the anomaly is a communication link problem rather than a measurement issue. The switch itself is faulty, so no switch replacement work order is generated; only link checks and connector handling actions are generated. After the handling is completed, the module writes the final conclusion, remote verification trajectory, on-site work order trajectory, and observation period settings to the session file, device anomaly file, work order file, and observation period file. Since the current scenario is a communication-related anomaly, the observation period can be set to hours. If the same-direction anomaly is triggered again during the observation period, a recurrence association is established between the new session and the current session, and competing items in the current session that have not yet been prioritized for verification are moved forward. If no further anomalies are triggered after the observation period ends, the current session is marked as a stable closed loop. Through the above operation process, this system can sequentially complete the following tasks under complex conditions such as inconsistent acquisition clocks, communication link fluctuations, changes in line connection relationships, and short-term recurrence after maintenance: session establishment and version freezing, multi-source record time verification, operation relationship establishment, communication relationship establishment, historical handling relationship establishment, evidence arrangement and remote review, on-site order dispatch, status tracking and result writing back, thereby forming a closed-loop processing chain from anomaly triggering to result accumulation.
[0024] It should be noted that this invention can be deployed on the device itself to realize embedded applications, or it can run on a PC or other terminal with a user interface, thereby meeting various hardware environments and usage requirements.
[0025] The above embodiments can be implemented in whole or in part by software, hardware, firmware, or any other combination. When implemented in software, the above embodiments can be implemented in whole or in part by a computer program product. The computer program product includes one or more computer instructions or computer programs. When the computer instructions or computer programs are loaded or executed on a computer, the processes or functions of the embodiments of this application are implemented in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted wirelessly or wiredly from one website, computer, server, or data center to another website, computer, server, or data center. Wired methods include optical fiber, twisted pair, coaxial cable, etc. Wireless methods include infrared, microwave, etc. Available media include any available media that can be accessed by a computer or data storage devices such as servers and data centers that contain one or more sets of available media. Available media can be magnetic media (floppy disks, hard disks, magnetic tapes), optical media (DVDs), or semiconductor media. Semiconductor media can be solid-state drives.
[0026] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.
[0027] In conclusion, the above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.
Claims
1. A fault diagnosis system for a measuring switch, characterized in that, include: Session registration module: Used to establish diagnostic sessions based on anomaly trigger information and determine the current diagnostic rule version; Time sequence verification module: used to perform time alignment and time interval consistency verification on power supply records, power consumption records, switch status records, communication records and maintenance records; Association Module: Used to establish associations within the diagnostic session based on the line connection relationship of the transformer area, the corresponding relationship of the equipment, and the historical handling association relationship; Evidence arrangement module: used to determine the verification order based on the directness of the record, temporal consistency, source reliability, and interference status; Verification closed-loop module: used to perform remote review, on-site dispatch, handling tracking and result writing in the verification order.
2. The measurement switch fault diagnosis system according to claim 1, characterized in that, The session registration module includes: Based on the equipment ledger mapping relationship, the objects from which anomalies originate are unified; The judgment is made by combining the reporting time from the source system and the receiving time from the main station. Session identifiers are generated based on unified object identifiers and trigger time slices; Freeze the rule version and generate session base records and input lists; For data items with gaps, perform tiered retrying; Perform incorporation processing on the information returned from the site, and initiate manual ledger verification when object mapping is abnormal.
3. The measurement switch fault diagnosis system according to claim 1, characterized in that, The timing verification module includes: Based on the input list, records are extracted from each source to establish the original time, received time, corrected time, and time reliability level. Layered time correction and correction amount limits are implemented by combining time logs, time synchronization records, and link latency samples; The system constructs a leading interval, a core interval, and an extended interval based on the session trigger time, and performs time consistency verification, interval relationship comparison, abnormal segment marking, manual interval identification, and link blockage assisted alignment according to record type.
4. The measurement switch fault diagnosis system according to claim 3, characterized in that, Layered time correction and correction amount limits are applied by combining time logs, time synchronization records, and link latency samples, including: The correction path is determined based on the timeliness of time recording, the validity of communication samples, and the availability of the original time. Offset correction is performed on records with valid time synchronization basis; Records with insufficient timeliness are corrected by combining the median value of transmission delay; For records lacking reliable original timestamps, comparisons are made based on the time of receipt, and a downgrade flag is assigned. The correction amount is subject to double constraints, and records that are time-reversed after correction retain their original order and are marked as pending verification.
5. The measurement switch fault diagnosis system according to claim 1, characterized in that, Associated receiving modules include: Based on the unified verification table, construct object association tables corresponding to the core object layer, the nearest neighbor object layer, and the historical reference layer; Establish operation acceptance, communication acceptance, and handling acceptance by combining the relationships between frozen lines, equipment correspondence, and historical work orders; The strength and validity of relationships are determined based on time relationships and record integrity, and mapping decisions or experience correspondences are executed when there are object conflicts, relationship rollbacks, or incomplete ledgers.
6. The measurement switch fault diagnosis system according to claim 5, characterized in that, Based on the unified verification table, construct object association tables corresponding to the core object layer, the nearest neighbor object layer, and the historical reference layer, including: Based on the unified verification table and the correspondence between the devices that take effect at the trigger time; The associated objects of the target device are hierarchically categorized, including direct upstream objects, direct downstream objects, neighboring objects on the same branch, objects on the same communication node, objects processed in the same batch, and historically similar objects. The system records the unified object identifier, its hierarchical level, line connection location, communication affiliation, most recent processing record number, and the current session validity status.
7. The measurement switch fault diagnosis system according to claim 1, characterized in that, The evidence arrangement module includes: Evidence items are formed based on the unified verification form and the conversation relationship table; The evidence includes source category, usage status, source reliability level, relationship strength, and interference markers; Candidates for primary verification, secondary verification, observation, and exclusion are stratified according to the inclusion criteria. The verification sequence chain is generated by combining historical processing corrections, verification relationships, pending certificate constraints, prohibition of direct order dispatch constraints, rollback rules in abnormal scenarios, improvement rules, and template call rules.
8. The measurement switch fault diagnosis system according to claim 7, characterized in that, Evidence items are formed based on the standardized checklist and the conversation relationship table, including: The record items in the unified verification table and the relationship items in the session relationship table are merged and matched within the same diagnostic session to form evidence items; For each piece of evidence, include the evidence number, uniform object identifier, source category, relationship category, time consistency marker, interval relationship marker, source reliability level, interference marker, relationship strength, and usage status.
9. A measurement switch fault diagnosis system according to claim 1, characterized in that, The verification closed-loop module includes: Collect key data based on the list of certificates to be supplemented; Perform non-disruptive reading, comparison verification, and light-trigger verification according to the verification sequence chain; When the remote termination conditions are met, a structured work order is generated and work order status tracking is initiated. Perform integrity verification and conflict review on the field feedback; The closed-loop conclusions, work order trajectories, and observation periods are linked and written into the corresponding files, and branch processing is carried out for observation scenarios that prohibit direct work order assignment, correct object mapping, or postpone work order assignment.
10. A measurement switch fault diagnosis system according to claim 9, characterized in that, Perform uninterrupted reading, comparison verification, and lightly triggered checks according to the verification sequence chain, including: The non-disruptive reading, comparison verification, and light-trigger verification are invoked sequentially according to the verification order chain. Record the target object, input evidence number, expected receipt time limit, success criteria, failure criteria, and timeout handling strategy for each remote action; Triggering conditions, receipt processing paths, and retry rules are determined based on constraints prohibiting direct order dispatch, session priority, and action category.