A power distribution switchgear remote monitoring and maintenance method based on internet of things

Abstract

The application discloses a kind of based on power distribution switchgear remote monitoring and maintenance method of Internet of Things, it is related to electric power system operation and maintenance technical field, it solves the problem that weak edge abnormality identification capability, control feedback chain is not closed loop and multiple terminal control conflict frequently occurs in existing power distribution system, scheme is: in edge device construction multi-source data structured time sequence index, based on residual function angle change determination equipment state drift;Introduce the control command management mechanism of unique transaction identification, combine double channel feedback structure and control exclusion stack, establish remote instruction consistency control chain;In cloud based on abnormal Boolean bitmap and topological relationship Construction hazard propagation chain, realize multi-node state linkage analysis and risk priority intervention strategy;The application significantly improves the abnormal identification accuracy of power distribution switchgear, remote control stability and system-level operation and maintenance response efficiency.

Description

Technical Field

[0001] This invention relates to the field of power system operation and maintenance technology, and more specifically to a method for remote monitoring and maintenance of power distribution switchgear based on the Internet of Things. Background Technology

[0002] As power distribution systems evolve towards intelligence and unmanned operation, IoT-based remote monitoring and maintenance methods are gradually replacing traditional manual inspections. By deploying sensor terminals, communication modules, and remote platforms, real-time perception, remote control, and fault early warning of the operating status of power distribution switchgear are achieved, improving system operation and maintenance efficiency and safety, and becoming a core technological direction for the intelligent development of power grids.

[0003] Existing methods typically employ an architecture of "local data acquisition + wireless remote transmission + cloud monitoring + mobile collaboration." Taking CN114784972A as an example, this system consists of a local power equipment monitoring system, a central controller, and a maintenance mobile terminal. It wirelessly uploads the status of switching equipment, electrical parameters, and alarm information, enabling centralized cloud display and fault notification. CN117013686A provides a monitoring model for the operating status and fault probability of power distribution components, emphasizing the identification of fault trends based on operating data. CN114123479A achieves low-power remote transmission of terminal data through NB-IoT, simplifying communication deployment. CN114006469A further incorporates multi-dimensional data such as images, tilt angles, and micro-meteorological data to identify abnormalities in power distribution network operation.

[0004] Existing technologies have generally improved visualization and automation, providing remote monitoring, alarm response, and maintenance scheduling capabilities. However, these systems primarily focus on front-end data acquisition and uploading, with insufficient edge-side anomaly detection capabilities. For example, while CN117013686A and CN114006469A collect data from multiple dimensions, edge devices generally lack high-performance processing capabilities and can only identify anomalies based on low-order statistical rules such as fixed thresholds and historical averages, failing to dynamically adapt to factors such as equipment aging, load fluctuations, and environmental changes. More importantly, inconsistent sampling periods and asynchronous upload delays from different data sources make it difficult to achieve time alignment and multimodal data fusion, resulting in delayed or even misjudged fault identification, especially for early latent faults (such as micro-discharges and loose contacts). Secondly, remote control mechanisms suffer from command feedback delays and execution consistency risks. CN114784972A relies on cloud-based unified scheduling commands to devices, with the path including a central controller, wireless link, and device response; the entire chain carries the risk of signaling delays and packet loss. While CN114123479A utilizes NB-IoT to reduce communication costs, its communication is highly unidirectional, its feedback mechanism is weak, and the control result feedback is severely delayed. If the execution result feedback fails, the platform struggles to determine whether the device has actually performed an action, easily creating the illusion of operation. More seriously, in scenarios with multiple terminals controlling concurrently (such as cloud platforms and maintenance terminals), the current system lacks a clear master-slave permission control protocol, posing a risk of operational conflicts and duplicate device execution. Summary of the Invention

[0005] To address the shortcomings of existing technologies, this invention discloses a method for remote monitoring and maintenance of power distribution switchgear based on the Internet of Things (IoT). The aim is to construct a closed-loop power distribution monitoring system with structured data expression capabilities, transaction consistency control mechanisms, and state propagation perception capabilities, thereby improving the accuracy of early fault identification and the reliability of remote control execution.

[0006] To achieve the above-mentioned technical effects, the present invention adopts the following technical solution: A method for remote monitoring and maintenance of power distribution switchgear based on the Internet of Things, comprising: Step 1: Receive the current transient sequence, voltage waveform vector, contact resistance change data, partial discharge acoustic signal and mechanical vibration spectrum signal of the target power distribution switchgear at the edge node, and assign a unified format timestamp identifier to each data stream to construct a structured time-series index array divided by period; Step 2: Calculate the first derivative sequence based on the same sampling channels in the adjacent period index array, generate the residual function set using the local least squares fitting method, and construct the dynamic benchmark state model; Step 3: Use the cosine angle between the residual functions of the current period and the previous period as the drift index. When the drift is greater than a preset standard deviation multiple, mark the corresponding sampling segment of the period as an abnormal segment and generate a Boolean bitmap for uploading. Step 4: When issuing control commands, the remote platform attaches a transaction identifier, which includes a hash combination of the device identification code, the issuance timestamp, the command type code, and the calling source module number. The edge node records the transaction identifier and caches the execution path and result status before executing the control command. Step 5: After the device completes the execution, it uploads the control execution feedback data corresponding to the identifier through two independent communication paths. The remote platform confirms the completion of the transaction after receiving a valid acknowledgment from either channel. Step 6: Configure a control priority mutex stack on the device side to restrict unauthorized terminals from issuing control commands while a transaction is not completed; Step 7: Use the cloud-based state drift analysis module to receive the abnormal Boolean bitmap of the edge device, and combine it with historical state data to perform node instability analysis and establish a chain of potential problems.

[0007] Based on the above technical solution, the positive and beneficial effects of the present invention are as follows: This invention constructs a dynamic baseline state model based on the derivative residual function in edge devices. It combines the periodic trend changes of various operating signals (such as current, voltage, contact resistance, partial discharge, and vibration spectrum) to replace the fixed threshold judgment mechanism, achieving dynamic adaptive identification of unsteady-state conditions, aging characteristics, and early latent faults. This approach overcomes the problems of anomaly misjudgment and identification blind spots caused by asynchronous sampling and low-order rules in existing systems.

[0008] By introducing a unique transaction identifier into the control commands and caching command execution paths, action states, and feedback channel information on the device side, coupled with a multi-channel acknowledgment reporting mechanism and a control mutual exclusion structure, a complete closed-loop management chain for control transactions is established. This mechanism effectively avoids problems such as unclear command feedback, failed status updates, duplicate command execution, or master-slave conflicts in traditional architectures, improving the reliability and scheduling controllability of the remote control chain in multi-source environments.

[0009] This invention introduces a state drift analysis module in the cloud, constructing anomaly propagation paths based on the distribution network topology and anomaly Boolean bitmaps uploaded by multiple devices. By calculating the propagation delay between nodes, the Boolean sequence overlap rate, and the edge weighting influence coefficient, a hidden danger chain structure is generated. This structure can identify potential state-linked nodes, supporting the scheduling system to prioritize intervention in high-risk nodes. This breaks the traditional isolated monitoring logic, enabling proactive judgment of the anomaly evolution trend of the distribution system and dynamic adjustment of control strategies. Attached Figure Description

[0010] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort, wherein: Figure 1 This is a flowchart of the steps of the present invention; Figure 2 This is an example diagram of the state machine of the edge node of the present invention; Figure 3 This is a flowchart illustrating the working principle of step 5 of the present invention; Figure 4 This is an example diagram of the control priority mutex stack architecture of the present invention; Figure 5 This is a structural diagram of the present invention. Detailed Implementation

[0011] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of this application will be clearly and completely described below in conjunction with the embodiments. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0012] To facilitate understanding of the present invention, a detailed description of a remote monitoring and maintenance method for power distribution switchgear based on the Internet of Things (IoT) disclosed in the embodiments of this application is provided. Please refer to [link to relevant documentation]. Figure 1 The diagram illustrates the steps of a method for remote monitoring and maintenance of power distribution switchgear based on the Internet of Things (IoT). Figure 5 The architecture diagram shown indicates that the technical solution of this application is as follows: Step 1: Receive the current transient sequence, voltage waveform vector, contact resistance change data, partial discharge acoustic signal and mechanical vibration spectrum signal of the target power distribution switchgear at the edge node, and assign a unified format timestamp identifier to each data stream to construct a structured time-series index array divided by period; Specifically, the edge node acquisition module is configured with multiple parallel data channels, which are used to receive and buffer data from the following five types of sensor modules: current transient sequences, voltage waveform vectors, contact resistance change data, partial discharge acoustic signals, and mechanical vibration spectrum signals. These sensor signal types differ significantly in physical characteristics, sampling frequency, and waveform scale, therefore the system needs to uniformly manage their time reference and structural definition at the acquisition level.

[0013] It should be noted that the “voltage waveform vector” in this application is different from the traditional voltage scalar value acquisition. It refers to the vector group formed by synchronously sampling multiple frequency domain components such as the main power frequency component and harmonic components (e.g., the 3rd and 5th) within a specified period. It can reflect the overall trend characteristics of the voltage distortion structure, rather than single-point fluctuations.

[0014] After receiving the raw signals, the edge nodes first synchronize all channel sampling modules using a unified time base. The time base uses millisecond-level UTC timestamps and is synchronized to the device-level RTC chip via GPS or network time synchronization. A high-precision timestamp is appended to each sampling completion event to ensure that all data streams have a unique sequence on the global timeline. Each type of sensor data is configured as a key-value pair with its original sampling order and corresponding timestamp. The key is a combined primary key of the channel number and timestamp, and the value is the corresponding raw sampled data.

[0015] As a possible implementation: the sampling frequencies for edge nodes are: 10kHz for current and voltage, 5kHz for partial discharge and vibration, and 1Hz for contact resistance. The system achieves sampling period merging through independent channel buffering and timestamp window matching. The matching window is ±0.5ms; sampling values ​​exceeding this tolerance range are considered asynchronous points and will be discarded. The sampling period is uniformly 50ms. If channel data is lost within this period, the effective value of the channel from the previous period is used for "forward filling," or interpolation filling (for analog signals), where the interpolation function is: The interpolation strategy is determined by the device configuration parameters. Forward filling is enabled by default. Users can switch the interpolation mode through the device configuration tool. The specific settings can be flexibly configured according to the actual deployment environment, and there are no restrictions on this.

[0016] After the system-defined sampling period (e.g., 10ms, 20ms, or 50ms) ends, the edge nodes perform a multi-channel data integration and encapsulation operation within the sampling period, using the time axis as the main line. This operation searches for valid sampling points of all channels within that period by setting a unified period boundary, combining them into a "multi-channel synchronous data unit". Each data unit can be represented as: in, This represents a multi-channel data unit within a period t. This represents the sampling result of the i-th channel within the current period. To improve data quality and model usability, the system automatically performs abnormal data cleaning and missing data completion during data unit encapsulation. For out-of-period values ​​(i.e., data points that are not within the current period's sampling window) appearing in each channel, the system removes them; for channel null values ​​caused by signal jitter or sampling delay, the system uses forward padding or linear interpolation to fill them in. The specific method used can be determined based on data characteristics and deployment requirements, and is not limited in this regard. It should be noted that the "structured time-series index array" in this application differs from the unordered log structure in a conventional database. Its core lies in using time as the main index dimension to bind different types of channel data into a unified time-series vector block, which can support subsequent state vector modeling and trend analysis at the edge computing end.

[0017] The aforementioned "vector block" is the final representation unit of the time series sampling structure. Each vector block has the following structure: Primary key: timestamp (e.g., 2025-07-31 10:23:01.500) Subkey: Channel number (e.g., CH1~CH5) Value: Standardized sampled value or characteristic value (such as peak current, partial discharge energy, etc.) In implementation, this structure can be represented using data structures such as JSON objects, Python dictionaries, or nested arrays; in the underlying embedded environment, it can be encoded using a two-dimensional array + timestamp table. To optimize reading efficiency, the system constructs all structured vector blocks into an index key set in the form of "key (timestamp)-value (data block)-time domain identifier" triples, and builds a fast lookup table based on a red-black tree or hash index structure, supporting operations such as periodic backtracking, sequential loading, and cross-channel aggregation. To adapt to bandwidth limitations and device computing power constraints in the IoT environment, the index set supports edge-side batch compression encoding, which can be batch organized according to the sampling period before uploading, and combined with data type for differential encoding or periodic incremental compression to reduce data volume.

[0018] It should be noted that the "multi-channel synchronous data unit" in this application differs from single-channel sequence acquisition. Its purpose is to achieve timing alignment and cross-modal fusion between signals, enabling multi-dimensional modeling during state modeling by utilizing the correlation between multiple signals. For example, it can identify internal short-circuit precursors by synchronizing the current change with the partial discharge acoustic signal fluctuation. Unlike existing multi-sensor data fusion, its encapsulation unit uses a "timestamp primary key" as a unique index field, and the data fields of each vector block satisfy a strict alignment relationship within the period, rather than inferring synchronization solely from the device's reported time.

[0019] The outlier removal rules are as follows: During structured encapsulation of each channel, all points outside the sampling period (i.e., timestamps not within the current sampling period window) are removed. Values ​​that deviate significantly from the historical data of that channel by more than three standard deviations are considered noise or interference anomalies and will also be removed. A median check of the data within the window is performed before removal. The system uses a local FIFO buffer mechanism for delayed encapsulation to ensure that all channel data is aligned before being entered into the index structure.

[0020] In addition, the "contact resistance change data" is not an absolute value record, but a periodic incremental value (resistance in this period - resistance in the previous period). Its detection frequency is much lower than that of other signal channels. Therefore, when constructing the state vector, the system only performs a forced update within a complete update cycle (e.g., every 10th cycle) to prevent the low-frequency channel from causing sparsity damage to the modeling accuracy.

[0021] All structured index arrays are written to a RAM queue via a local data scheduling thread (set to be once every 500ms) and packaged into time-indexed key-value blocks for use by the state modeling module. The index structure adopts a hash + AVL balanced tree dual structure in the software implementation, supporting O(logN) complexity lookup and sliding window iterative traversal within the time range, satisfying the data dependency requirements of the subsequent residual function and angle trend analysis process.

[0022] This step serves as a general state construction interface, allowing upper-layer callers to set the sliding period length, channel activation status, and index field combination modes as needed. The system assigns a globally unique time primary key to each period vector, ensuring correct time alignment and aggregation reconstruction after uploading to the cloud platform. This is suitable for asynchronous sampling and collaborative processing scenarios in distributed edge state acquisition environments.

[0023] Step 2: Calculate the first derivative sequence based on the same sampling channels in the adjacent period index array, generate the residual function set using the local least squares fitting method, and construct the dynamic benchmark state model; Specifically, this step first takes the structured time-series index array established in step 1 as input. This array has encapsulated the multi-channel sampling data of the target power distribution switchgear into time-series vector blocks according to a unified period, possessing a unified timestamp primary key and channel number subkey. In each channel, the system first performs a first-order difference operation on the principal feature components between adjacent periods to construct the trend quantity. Let the periodic sequence be... For any channel c, its characteristic quantity at period t is: Then the derivative sequence Expressed as: The derivative sequences of all channels constitute a channel-specific change sequence matrix, which serves as the basic input for fitting the residual function. It should be noted that the "derivative sequence" in this application differs from the derivative of a continuous function in classical mathematics. Its essence is the differential change of a periodic discrete state, which can reflect the short-term sudden changes, oscillations, or gradual changes in various operating indicators of the equipment within the sampling period, and is used to support the state model's response to early micro-disturbances.

[0024] To establish a unified evaluation benchmark for derivative sequences from different channels, the system divides the derivative sequences into five independent fitting units based on channel type: current fitting unit (CH1), voltage fitting unit (CH2), contact resistance fitting unit (CH3), partial discharge fitting unit (CH4), and mechanical vibration fitting unit (CH5). Within each fitting unit, data normalization is performed, using zero-mean unit variance standardization to process the raw derivative data. in , These are the historical moving average and standard deviation of the derivative sequence of this channel, respectively. The sliding window is set to the most recent 10 periods by default, but the specific value can be determined according to the actual situation. There is no limitation on this.

[0025] The normalized derivative sequences of each channel form a multidimensional state change vector sequence, in the following form: This sequence is in a sliding period window. The local least squares fitting module, which takes the sample set as input, performs a multidimensional residual function fitting to characterize the operational stability and trend of the current device within the specified time window. The residual function is set as a vector space fitting curve. The objective function to be minimized is: in: Fit the parameter vector to the residual function; To fit the weight coefficients, a symmetric decreasing function is defined, satisfying: The exponential decay weight ensures that the weight of the most recent period is the largest, and the further back the historical samples are, the weaker their influence on the current model's fit, thereby enhancing the model's sensitivity to short-term state changes.

[0026] It should be noted that the "dynamic baseline state model" in this application differs from the traditional threshold comparison or static experience template method. It forms an evolutionary trajectory model based on the change behavior by fitting the local trend of the derivative change in each cycle. It can dynamically adjust the response threshold range to abnormal changes, thereby overcoming the misjudgment problem caused by parameter deviations caused by equipment aging, load disturbances, etc.

[0027] In the current fitting unit, for the current transient sequence of the current period, the system uses the zero-crossing point density analysis method to extract current frequency fluctuation information. The number of zero-crossing points detected within the sampling window is... The corresponding frequency estimate is: in The sampling duration is in seconds. In the voltage fitting unit, the system performs a Fast Fourier Transform (FFT) on the original voltage waveform to extract the fundamental amplitude, the amplitude of the 3rd harmonic, and the amplitude of the 5th harmonic. Combined into vector features It is used to describe the waveform distortion trend.

[0028] The contact resistance fitting unit performs a simple first-order difference calculation on the periodic resistance value to calculate the gradient per unit time: in The period duration is specified. The partial discharge fitting unit calculates the short-time energy envelope of the sound signal, extracts the main frequency band energy center, and uses a bandpass filter (5kHz±500Hz) + energy integration to calculate the main energy point. The mechanical vibration fitting unit uses continuous wavelet transform (CWT) to extract the local energy distribution in the 0~300Hz frequency band for identifying low-frequency mechanical vibrations.

[0029] After the five fitting units complete their calculations within the same period, they each generate residual fitting parameters (slope, intercept, and residual sum of squares) and store them in a local circular buffer in the edge node's RAM. The buffer uses the channel number and period label as keys to build a storage index, supporting subsequent anomaly triggering modules to quickly retrieve data based on the period offset.

[0030] The system performs a sliding window averaging of historical residual parameters at fixed intervals (e.g., every 5 intervals) to assess the channel-level operational stability trend and provide model vector input for the angle determination mechanism.

[0031] This step does not rely on complex model training, does not require external cloud inference structures, adapts to edge device resource constraints, is compatible with multi-channel concurrent modeling and independent decision-making mechanisms, and can independently evaluate state drift based on changes in different channels.

[0032] Step 3: Use the cosine angle between the residual functions of the current period and the previous period as the drift index. When the drift is greater than a preset standard deviation multiple, mark the corresponding sampling segment of the period as an abnormal segment and generate a Boolean bitmap for uploading. The input data for this step is the sequence of residual function parameters of the dynamic baseline state model constructed in step 2 over continuous periods. Specifically, within each sampling period tt, the edge device generates a fitting parameter vector for that period through local sliding window weighted least squares fitting, denoted as: ;in The residual function parameter vector represents the period t, and the number of elements n depends on the system's selected fitting dimension and channel configuration. For example, if first-order linear fitting is used for each of the five channels (current, voltage, contact resistance, partial discharge, and vibration), and the residual fitting result for each channel outputs two parameters (slope and intercept), then n = 10. All residual parameter vectors are cached in the local circular queue of the edge nodes with the period label as the primary key, and the results of the most recent M periods are retained for state comparison and trend judgment.

[0033] To determine whether there is a significant state shift in the current cycle, the system uses the angle between the residual vectors of the current cycle and the previous cycle as an indicator of drift. The specific calculation formula is as follows: in, This angle represents the "structural change magnitude" of the current periodic state model relative to the previous periodic model, with a numerical range of [0, π]. In this system, this angle is not interpreted directly in terms of physical meaning, but rather serves as a measure of the degree of change in the model's state evolution trajectory within the high-dimensional parameter space. A larger angle indicates a more drastic jump in the model trajectory, potentially indicating unsteady disturbances, equipment switching, abnormal contact, or high-frequency discharge.

[0034] It should be noted that the term "angle value" in this application is different from the traditional vector direction comparison method. It represents the angle approximation of the structural change trend of the periodic residual function. Its numerical calculation is based on the pre-normalization of all residual vectors, which can truly reflect the symmetric fluctuation of parameter evolution and has good rotation invariance.

[0035] To avoid misjudging instantaneous fluctuations caused by factors such as internal equipment periodic disturbances and environmental noise as abnormalities, this invention further constructs a periodic trend disturbance identification mechanism as a secondary trigger condition. This mechanism includes the following core operations: The system stores the most recent N period angle values ​​within each edge node using a sliding window, forming a historical sequence of angle changes. Calculate the increment of angle change in the current period: Then, a first-order difference operation is performed on all historical increment values ​​within the sliding window to obtain the perturbation trend sequence: Extract the maximum disturbance amplitude from the disturbance trend sequence as the disturbance intensity index: This indicator reflects the steepness of recent state change trends and is a second-order measure of the abrupt nature of state drift.

[0036] The system ultimately uses a dual-threshold criterion for anomaly detection. The detection criteria are as follows: First criterion (static change): Whether the current period's included angle value exceeds the dynamic threshold. The threshold is constructed as follows: in and The mean and standard deviation of the angle within the historical window, and K is an adjustment factor (usually set to 1.5 or 2.0, depending on the device type).

[0037] Second criterion (dynamic trend): Disturbance intensity Has the drift response threshold been exceeded? This threshold is set by the equipment at the factory or determined through on-site debugging, for example, between 0.05 and 0.1 radians. The specific value can be determined according to the application scenario, and there is no limitation on it.

[0038] The current period is marked as an abnormal period only when both conditions are met simultaneously. In the system implementation, the abnormal marking process is expressed using Boolean values: abnormal state: Boolean value is set to 1; normal state: Boolean value is set to 0.

[0039] All Boolean values ​​are written to the local exception flag buffer stack in chronological order, forming a Boolean bitmap sequence. For example: [0,0, 1, 0, 0, 1, 1, 0, 0, 0]; where "1" indicates that the state drift in this period exceeds the limit and the trend is drastic, possibly corresponding to loose contact, arc pulse, or drastic load switching. To improve transmission efficiency, this Boolean sequence is compressed and encoded in fixed-length blocks (e.g., every 10 periods as a group) at the edge nodes, each group is bound to a start timestamp, and then packaged and uploaded to the cloud platform. The upload structure is as follows: { "start_ts": "2025-07-31T10:23:00.000", "bit_map": "0010011000"} After receiving the bitmap, the cloud system matches it with historical operation files, topology, and Boolean bit distribution trends for subsequent hazard chain analysis (step 7).

[0040] It should be noted that the "abnormal Boolean bitmap" in this application is different from the traditional event-triggered log. It is not an event-level trigger, but a state-level periodic marker sequence. It has advantages such as equal periodic distribution, good compressibility, and can be used for periodic trend clustering. It is suitable for remote state expression optimization transmission mechanism under the conditions of limited computing power of edge devices and unstable network bandwidth.

[0041] In actual deployment, this judgment logic is implemented using C language or Python embedded modules. All state calculations are performed on edge nodes, eliminating the need to rely on external platform inference models and ensuring closed-loop state recognition, low latency, and offline operation capability. The system's default window length is N=10 periods, with a maximum support of 30 periods. The disturbance threshold can be set between 0.01 and 0.2. All configuration items support remote adjustment to meet the dynamic response differences of different substations, grid nodes, or terminal devices.

[0042] The final Boolean bitmap output of this step serves as one of the input nodes of the state anomaly marking chain in this invention. It forms the basis for driving the entire control transaction intervention decision and topology linkage hidden danger identification process, and its role in the system structure is a key trigger core. All subsequent remote intervention strategies use the Boolean anomaly segment as the logical anchor point for reasoning and scheduling priority updates. Therefore, this step constitutes the key bridge logic from "fitting the state model" to "periodic determination Booleanization".

[0043] Step 4: When issuing control commands, the remote platform appends a transaction identifier, including a hash combination of the device identification code, issuance timestamp, command type code, and the calling source module number. The edge node records this transaction identifier and caches the execution path and result status before executing the control command. For details, please refer to... Figure 2 As shown in the example diagram, in this step, before issuing control commands (such as opening, closing, reclosing, switching, etc.), the remote platform first calls the transaction identifier generator to generate a unique transaction identifier based on the current operation context. The identifier is constructed by concatenating the following fields to form a hash digest: in: A globally unique device number for the device to be controlled; The timestamp for issuing control commands is accurate to the millisecond level. For control type codes (e.g., 00 for closing, 01 for opening, 10 for switching); This is the instruction call source module number, used to identify whether the source is a scheduling system, maintenance terminal, or AI prediction module.

[0044] The generated TX_ID is a 128-bit hash result (which can be SHA-256 with the first 16 bytes taken, or a lightweight hash function such as SipHash / FNV, depending on the deployment resources, and there is no limitation on this). It is appended to the control command message in the form of a string and sent to the edge node of the target power distribution switchgear via a wireless transmission link (such as NB-IoT, LoRa, or 4G).

[0045] Upon receiving a control command with the TX_ID, the edge node immediately parses the transaction identifier and control field content, and performs the following operations: First, the edge node queries whether there are any pending control transactions pointing to the same controlled object (such as circuit breaker X). If such a transaction exists, and no clear feedback is received (e.g., control status write-back has not yet been received), the system automatically suspends or discards the new instruction to avoid repeated operations on the same object, which could cause electrical status errors or equipment damage.

[0046] If there are no conflicting transactions, or the current transaction status is "completed" or "released," the system allows the current TX_ID to enter the local control transaction management table. This table is a local data structure maintained by the edge nodes, updated using a circular buffer method, and expired transactions are reclaimed according to the FIFO principle. Each table entry uses the transaction identifier as the primary key and stores the following fields: TX_ID (string): A globally unique transaction identifier; CMD_TYPE (enumeration): Instruction type code; T_RECV (timestamp): Controls the command reception time; T_EXP (timer): Controls the effective time window (default value is 10 seconds, configurable); STATE_BEFORE (structure): A snapshot of the state of the controlled object before the current execution (such as relay position, voltage, current); STATE_EXPECTED (structure): controls the target state (such as "closed", "open"); EXEC_PATH (encoding): Execution path identifier, used to indicate which local control module triggers execution; WRITE_LOCK (Boolean): State write lock bit, preventing subsequent instructions from being accepted before the state write-back is complete; STATUS (enumeration): Current transaction status, including "pending", "executed but not written back", "completed", "suspended", "released", etc.

[0047] It should be noted that the "transaction identifier" in this application differs from the unique sequence number or message number of a message. It constructs a state binding identifier through a combination of multi-field hashes, possessing unforgeability and a low collision probability, ensuring a one-to-one mapping relationship between commands and state write-backs. Furthermore, the "control transaction management table" in this application differs from traditional task queues. It is not only used for queue control and sorting but also uses "pairing state fields with control intentions" as its core logic. This allows it to bind the expected control target with the actual execution result and, in conjunction with a state write lock mechanism, achieve behavioral isolation of the controlled object.

[0048] After the control transaction table is built, the system immediately starts a command validity countdown timer. If no state write-back result is detected that matches STATE_EXPECTED within this time period, the system will automatically mark the transaction as "suspended" and lock the corresponding control object execution interface. This interface can only be released when the transaction status is completed or a clear abnormal receipt is received, to prevent the next control transaction from being mistakenly received in scenarios such as receipt failure or execution timeout, which could lead to command overwriting or execution conflicts.

[0049] Control object matching rule: TX_ID must be associated with a specific target object. Example: If the current TX_ID control object is relay A, then all control channel interfaces involving object A are unwritable during WRITE_LOCK=1.

[0050] The locking logic flow is as follows: Initial state: Object A is idle → TX_ID is issued → Status changes to "Executing", WRITE_LOCK=1; Execution proceeds normally and a success message is received: the status changes to "Completed", and WRITE_LOCK=0; If the write operation times out or fails to respond: the status changes to "suspended", WRITE_LOCK=1, and the write lock remains in place; The system requires manual confirmation to unlock or execute forced cleanup logic (such as restart, command rollback, etc.).

[0051] For example, a remote platform issues a "open" command to switch A, with TX_ID "TX20250731-0001", at 10:30:15.123. Upon receiving this command, the edge node finds no ongoing transactions for switch A and immediately registers "TX20250731-0001" in the control transaction table. After execution, the system's expected state is "in the open position." Before the status feedback is written back, WRITE_LOCK = true, and the next control command for port A will be directly rejected.

[0052] If the feedback times out (no response within 10 seconds), the status automatically switches to "SUSPENDED" and remains WRITE_LOCK, requiring manual or remote auditing tools for verification and handling. This mechanism effectively prevents operational risks such as repeated circuit breaker tripping and repeated circuit breaker closure.

[0053] In addition, edge nodes will record detailed instruction processing logs during the execution of control transactions, including: TX_ID; reception time; execution path; execution result (success, failure, timeout); status code (such as "status consistent", "status not responding", "status conflict"); write-back feedback time and channel number; source module number (used for post-event responsibility determination), etc.

[0054] The log is saved locally in text or binary format and uploaded to the remote platform audit module at set intervals (such as every 5 minutes or after 10 transactions). The log storage uses a circular write method, retaining nearly 100 records, and automatically loads the last state when the system starts.

[0055] It should be noted that the "transaction identifier write-back mechanism" in this application is different from the existing NB-IoT one-to-one command response process. It constructs a command lifecycle management mechanism driven by transaction state as the core, which can realize the atomic control logic of command behavior and has high execution security in concurrent control and multi-source scheduling environments.

[0056] Step 5: After the device completes the process, it uploads the control execution feedback data corresponding to the identifier through two independent communication paths. The remote platform confirms the completion of the transaction upon receiving a valid acknowledgment from either channel. For details, please refer to [link to relevant documentation]. Figure 3 Before being sent, the control execution feedback data is constructed by the device into a feedback status packet. This packet includes, in addition to the corresponding transaction identifier, a control execution confirmation bit, an action completion timestamp, a comparison byte before and after the target execution bit change, a device fault flag bit, a communication channel identifier field, and a feedback packet integrity check code. The feedback status packet is sent in parallel to the remote platform via dual physical channels: a primary channel and a secondary channel. Each channel's feedback status packet includes an independent path sequence number and an issuing module number. The primary channel uses NB-IoT or a cellular public network standard for encrypted feedback, while the secondary channel uses LoRa or a private wireless link. Upon receiving a valid feedback packet from any channel, the platform performs consistency analysis based on the control execution confirmation bit and the target status change byte in the feedback status packet. If the analysis confirms consistency with the original control command target, the corresponding transaction is marked as closed-loop. If analysis fails or the status code is inconsistent, the transaction remains in a pending confirmation state, and a secondary request signal is sent to the backup channel. After a second failure, the transaction is marked as "not closed-loop," and a failed transaction log is reported to the platform.

[0057] Specifically, the "feedback status packet" is constructed after the control transaction is completed. The criteria for the completion of the control transaction are: the device completes a physical action (such as the opening and closing of a circuit breaker) and updates the status of the action bit sensing module, triggering a "status write-back" event in the local control module. At this time, the device immediately constructs a feedback status packet, which is a structured byte array with the following format: struct FeedbackPacket { char tx_id

[33] ; / / Control transaction ID (Base64 string) uint8_t ack_flag; / / Control action confirmation bit (0x01 for success, 0x00 for failure) uint64_t action_timestamp; / / Action completion time (ms-level UTC timestamp) uint8_t state_diff_byte; / / Bytes for comparing state differences (e.g., 0x03 indicates a change from combination to separation) uint8_t fault_flag; / / Fault flag (0x00 indicates normal operation, 0x01 indicates abnormal operation after execution) uint8_t channel_id; / / Current communication channel number (main channel = 0x01, auxiliary channel = 0x02) uint8_t signer_id; / / Signing module number (e.g., RELAY_DRV_01 is encoded as 0x10) uint16_t crc16; / / Integrity check code (using CRC-16 / MODBUS standard algorithm)}; It should be noted that the "state difference comparison byte" in this application is different from the final state byte. It is used to indicate whether there is a change in the state before and after the action, and can be used on the platform to confirm consistency by comparing the original target state.

[0058] After the execution path completes its physical actions, the status packet will be sent to the remote platform in parallel via two independent physical communication links. The two links include: Main channel (channel_id = 0x01): Uses NB-IoT or cellular public network standard for acknowledgments, configured with TLS encrypted communication, data packets are encapsulated using the MQTT protocol standard, and the topic field contains the device's unique ID and tx_id; Secondary Channel (channel_id = 0x02): Uses LoRa, ZigBee, or private wireless link for acknowledgments. The packet format is a simplified UDP emulated data frame, supporting a maximum payload of 64 bytes, including a CRC check segment.

[0059] Upon receiving any channel acknowledgment data packet, the platform retrieves the corresponding record in the control transaction table based on its tx_id field and determines whether the transaction status has been completed. If not, the platform determines the validity of the acknowledgment based on the following conditions: Checking that ack_flag == 0x01 indicates that the control action was indeed executed; Check if state_diff_byte matches the expected target state in the transaction record; The CRC16 verification passed, indicating that the receipt data has not been tampered with or interrupted. If fault_flag == 0x01 exists, then even if ack_flag == 0x01, it cannot be determined as "closed loop".

[0060] It should be noted that the "transaction closed loop" state in this application is only valid when two conditions are met simultaneously: (1) Receive a feedback packet from at least one valid communication link; (2) The status confirmation bit in the feedback packet is consistent with the expected status, and the device does not report any abnormality. Otherwise, the transaction status must not be updated to "complete".

[0061] If the platform detects that any check in the feedback packet fails (such as inconsistent status, corrupted data, or device self-test failure), the current transaction status remains "pending confirmation," and the following abnormal path operations are triggered: Send a second acknowledgment request to the communication link that has not yet responded (if the main channel fails, try the secondary channel). The request packet structure contains only tx_id and the request retransmission identifier (0xA5); The maximum waiting time for a second confirmation is 8 seconds by default; exceeding this timeout is considered a communication failure. If the second receipt is still invalid or times out, the transaction status is marked as "not closed," and an error log is generated and uploaded. An example of the error log structure is as follows: { "tx_id": "TX20250731-0017", "status": "unclosed", "reason": "no valid feedback from both channels", "channel_primary": "NB-IoT", "channel_secondary": "LoRa", "retry_attempts": 1, "final_flag": "timeout"} After receiving a transaction marked as "not closed", the platform will temporarily freeze the control permissions of that node in the downstream control strategy, and can automatically issue the next round of diagnostic commands or notify manual intervention.

[0062] The device can, according to configuration, store all sent receipt data packets in a local transaction buffer for a certain period (default 60 seconds) for retransmission or retrospective checks, with the same format as the original feedback structure. If the platform has confirmed the transaction closure, the device will remove the corresponding record from RAM. The signer_id in the feedback record can be used for cross-component behavior confirmation, such as distinguishing the responsibility link in concurrent control operations between the same platform's scheduling and maintenance ends.

[0063] It should be noted that the "dual-path feedback + path identifier" structure differs from the traditional acknowledgment and response model. It can locate the source of abnormal states in the communication channel and configure link backoff, providing auxiliary parameters for link quality in the distributed scheduling architecture.

[0064] The platform's transaction control module records the response time of each channel, maintaining an average RTT (round trip time) and a stability score for subsequent dynamic selection of the primary channel strategy. For example: NB-IoT 215 98.7% 9.8 LoRa 390 84.2% 6.3 When the rating falls below 6.0, the platform will automatically switch the current primary channel to the secondary channel to ensure the robustness of the feedback mechanism. All feedback actions can be configured and deployed by the platform. The following dynamic configuration parameters are supported: Channel transmission sequence (concurrent / master-slave); secondary feedback waiting time (range 5~15s); whether to allow state difference tolerance threshold (e.g., less than a certain current change range); fault flag triggering strategy (e.g., after three false triggers, the device is determined to be untrusted). These parameters are all distributed to the configuration tables of the edge nodes through the platform, and are periodically read and updated by the control service module, supporting hot reloading.

[0065] Ultimately, the transaction feedback mechanism forms the following closed-loop behavior chain: Control command generation → TX_ID binding → Sending to device → Control execution → Status feedback packet construction → Concurrent transmission via primary and secondary channels → Platform reception → Judgment → Marking closed loop or requesting retransmission; Failure handling → Freezing → Logging → Scheduling strategy linkage; This architecture is compatible with large-scale concurrent control transactions, multi-link deployment environments, and embedded resource-constrained devices, and is suitable for the comprehensive technical requirements of real-time performance, security, consistency, and traceability of the control chain in current smart power distribution systems.

[0066] Step 6: Configure a control priority mutex stack on the device side to restrict unauthorized terminals from issuing control commands while a transaction is incomplete; please refer to [link to relevant documentation]. Figure 4 The control priority mutex stack uses a stack-based Last-In-First-Out (LIFO) logic to implement write mutual exclusion. Each stack element includes: a control request origin identifier, a bound transaction identifier, a command type code, a control object marker, a priority label, an authorization token verification field, and a stack push timestamp. When any control transaction is written to the top of the stack, the device control interface enters a locked state, allowing only the top request to initiate control execution. If a non-top request attempts to access the control interface, the remote platform compares the request priority label with the top element. If the request has a lower priority or an invalid authorization token, the control request is rejected and a rejection event is logged. Furthermore, if the current transaction fails to complete and exceeds a preset transaction timeout threshold for an extended period, the control object is frozen through a stack cleanup mechanism, prohibiting all control requests from entering during the frozen state window. The remote platform uses an anomaly propagation impact coefficient. Prioritize and intervene in scheduling window timing adjustments for scheduling control transactions.

[0067] In simple terms, the technical mechanism of step 6 includes: a control priority mutex stack structure configured on the device side, and the platform side adjusting the control priority based on the anomaly propagation influence index. The system intervenes in the scheduling process. The device-side stack structure uses LIFO logic to ensure command mutual exclusion; the platform-side assesses the system impact of abnormal nodes based on the edge anomaly reporting results, dynamically adjusts the scheduling sequence, and raises the priority of control transactions on high-impact paths.

[0068] Specifically, the control priority mutex stack is applied in the following scenarios: On the same power distribution switchgear, there may be multiple control sources that initiate control commands in parallel, such as cloud dispatch centers, field maintenance terminals, mobile maintenance tools, and AI predictive control modules. These control sources send control requests to the device through different paths (NB-IoT, LoRa, local Ethernet, etc.). Without an effective mutual exclusion mechanism, if multiple control requests simultaneously hit the same execution object (such as the main circuit breaker), it can easily lead to serious operational errors such as state confusion, re-entry of actions, and incorrect disconnection or connection. This invention, through the control priority mutex stack, achieves hierarchical behavior of control requests at the device end, conflict avoidance, and transaction context consistency constraints.

[0069] This stack structure is organized in a Last-In-First-Out (LIFO) manner. Control requests are evaluated in reverse order of their push time, and only the current top element of the stack is allowed to hold "control" and trigger the actual control channel. Each stack element is a structure, defined as follows (represented in C structure): struct StackEntry { char tx_id

[33] ; / / Transaction identifier (Base64 string) uint8_t cmd_type; / / Control command type code (e.g., 0x01 closing, 0x02 opening) char origin_id

[16] ; / / Controls the source identifier of the request (such as module ID) uint8_t ctrl_obj_id; / / Control object code (e.g., circuit breaker number) uint8_t priority_level; / / Priority label (0~255, the larger the value, the higher the priority) char auth_token

[32] ; / / Authorization token (JWT, hash digest, or platform signature) uint64_t timestamp; / / Stack push timestamp (ms)}; Each time the device receives a control command, it first preprocesses and parses the command, extracting the aforementioned fields. Then, it determines whether to allow the controlled object to be pushed onto the stack based on whether the controlled object is currently in a "frozen" state. The frozen state is a Boolean flag; it automatically enters the frozen window when a controlled object experiences an abnormal timeout or inconsistent state in historical transactions, leading to a failed acknowledgment. The default frozen time is 30 seconds, during which the object does not accept any control requests pushed onto the stack. The specific time threshold can be configured between 10 and 60 seconds, depending on actual operational stability requirements; there is no fixed limit.

[0070] If the controlled object is not in a frozen state, the system enters the control mutual exclusion determination process. The current request to be pushed onto the stack is compared with the current top element of the stack (TopEntry) using the following fields: Priority determination: If priority_level_new > priority_level_top, then allow pushing onto the stack and set it to the top; Authorization verification: Verify whether the auth_token passes the verification by the device-side embedded verification module; This step can use HMAC-SHA256, RSA2048, or platform private key signing methods; the verification rules should include signature validity, valid time window, and matching of the operation permission list; if token verification fails, the request is directly rejected and a rejection event log is generated. When all requests have the same priority and pass authorization verification, the system defaults to rejecting subsequent requests and maintaining control over the existing transaction. Rejected requests are written to the "Rejection Event Log," and the log fields include: Control source identifier; instruction type; rejected timestamp; stack top holder information; rejection reason (e.g., "low priority" or "invalid authorization"); control object code.

[0071] Logs can be encoded in JSON format and uploaded to the platform's control behavior audit module or stored in the device's local EEPROM for accountability. It should be noted that the "control priority mutex stack" in this application differs from the traditional "priority scheduling queue" or "control permission table." The former uses unidirectional scheduling control logic based on enqueue order and priority fields, while the structure described in this invention emphasizes mutual exclusion of control path access; that is, requests not at the top of the stack have no right to access the actual execution interface, possessing a strict execution-level blocking mechanism.

[0072] When the control transaction bound to the top transaction in the stack completes (including confirmation or failure), the system automatically performs a pop operation. After popping, the next top element in the stack (if it exists) gains access to the control interface; if the stack is empty, the control interface enters an "idle state". If a control transaction does not receive confirmation within the default timeout period (e.g., 10 seconds), the following actions are performed: Mark the transaction at the top of the stack as "timeout failed"; Pop the transaction; Mark the controlled object (such as circuit breaker X) as frozen and set the freeze start time; During the freeze window (e.g., 30 seconds), all control requests are denied from being pushed onto the stack. The system can trigger a self-check command, automatically report an anomaly, or wait for manual confirmation to unlock.

[0073] The priority field is an unsigned integer between 0 and 255; the larger the value, the higher the privilege. Below is an example configuration table: Manual dispatch terminal SCHED_APP 150 AI prediction module AI_CORE_01 120 On-site maintenance terminal MAINT_PAD 100 Cloud platform operating system CLOUD_SYS 130 Unknown source UNKNOWN_SRC 0 (Rejection) The maximum stack depth is set to 10 by default and can be configured to a maximum of 32. Requests exceeding this limit will be considered "stack overflow" and rejected. All stack operations are maintained using a thread-safe structure (which can use double buffering or critical section lock mechanisms) to ensure consistency of concurrent access when multiple path control sources push onto the stack simultaneously.

[0074] The device periodically (e.g., every 100ms) checks whether the state at the top of the stack matches the state of the controlled object. If the transaction at the top of the stack is suspended for a long time, the platform can proactively send a transaction termination command to the device or directly trigger an exception cleanup process. The auth_token for each element in the stack can be generated by the platform, supporting JWT format (including the control target, validity period, initiator ID, etc.). The device embeds parsing logic and uses a pre-set private key or trusted public key to verify the signature's validity. If verification fails, a platform-side account locking mechanism can be triggered to prevent unauthorized access.

[0075] This stack structure forms a cross-binding relationship with the TX_ID field in the aforementioned control transaction table; that is, the TX_id in the stack element must also exist in the control transaction table. If the TX_ID has been marked as completed or timed out in the transaction table, the stack element should be immediately invalidated and popped to avoid dangling control paths or behavior pollution.

[0076] In the overall system behavior chain, the control priority mutex stack constitutes the behavior arbitration layer from "control command issuance" to "control behavior execution". It is a key strategy to ensure that the distributed control system can achieve command isolation, conflict prevention, process authorization and result consistency under high concurrency and high reliability requirements.

[0077] Furthermore, in the remote monitoring and maintenance method for power distribution switchgear described in this application, the mechanism based on the device-side control priority mutual exclusion stack also introduces an anomaly propagation impact coefficient calculated by the cloud platform, which is used to reorder control transaction priorities and intervene in scheduling window timing in multi-device linkage scenarios, thereby improving the response capability to potential fault links.

[0078] The input to the anomaly propagation impact coefficient mechanism is an anomaly Boolean bitmap uploaded by multiple edge devices. Each bit in the bitmap represents whether the device is in an abnormal state (1) or a normal state (0) within a period. After receiving the bitmap, the platform generates a topology matrix G=(V,E) by combining the physical connection relationship of the power distribution network. The node set V is all online devices, and the edge set E represents the direct electrical connection, adjacency, or connection path between devices.

[0079] It should be noted that the "topology matrix" in this application is different from the topology of a normal communication network. This topology is based on electrical connections or line adjacency relationships. For example, two switches on the same tower are regarded as adjacent nodes, which are used to capture abnormal propagation paths.

[0080] Each edge is assigned a weight. This value can be configured by the user or automatically set based on the distance between devices, electrical connectivity, and branch relationships. For example, the weight on the same bus can be set to 1.0, and the weight of adjacent devices between different branches can be set to 0.5. The specific weight can be determined according to the engineering topology and is not limited thereto.

[0081] The platform provides each node Sort the time series of anomaly triggers and find the set of all neighboring nodes that also triggered anomalies within a similar time period. In each round of scheduling decisions, the system extracts the timestamps of abnormal nodes within the latest cycle, such as... For nodes The period number in which the anomaly occurred (based on a uniform sampling period).

[0082] For each adjacent node Define the time difference The unit is the number of cycles (e.g., 1 indicates immediate triggering). Historical Boolean overlap rate. Calculate the proportion of times the Boolean values ​​of two nodes are synchronized to 1 within the past M periods: in This is an indicator function; it takes the value 1 if two nodes fail simultaneously within the same period, otherwise it takes the value 0. The default value for M is 10 periods, but it can also be set to between 5 and 20 periods, depending on the system deployment cycle.

[0083] Finally, the node influence coefficient is defined based on the above values: This formula characterizes the node. "Influence" in the current anomalous propagation network: tightly connected ( Large), abnormally high synchronization ( Large), occurring at close time ( The adjacent nodes of the smaller node will contribute a higher weight, thus inferring... The ability to withstand overall system security risks.

[0084] It should be noted that the "influence coefficient" in this application... "Unlike topological centrality metrics (such as PageRank or degree centrality), it integrates three dimensions: time delay, abnormal overlap, and edge weight. It is a risk quantification based on the propagation behavior of abnormal events and can be directly used for scheduling priority assessment and control path optimization."

[0085] The platform determines the impact coefficients of all currently active abnormal nodes based on the original transaction priorities. Calculate the reordering priority: in This is the scheduling weight parameter, typically set to 0.5. Nodes with higher influence coefficients have significantly higher transaction priorities, thus gaining a earlier execution opportunity in the scheduling window. The specific value can be determined based on the actual situation. Values ​​and thresholds are set, but no restrictions are imposed on them.

[0086] Once the priority reordering is complete, the platform will proceed according to... Control transactions are ordered in descending order, and control commands are redistributed to edge nodes. The command is then pushed onto the device's control mutex stack for execution. This interconnected structure ensures that nodes along the anomaly propagation path receive control requests first and execute control actions on the device first, breaking the conventional "whoever issues the request first executes it first" scheduling model and instead implementing an emergency control model that prioritizes "whoever is closer to the anomaly propagation link."

[0087] The entire process, from anomaly identification (uploading edge Boolean bitmap), impact coefficient calculation (cloud anomaly propagation model), priority reordering (platform scheduling strategy) to control execution (device mutual exclusion stack issuance), forms a closed loop. Together with the transaction identifier management in step 4 and the multi-path acknowledgment confirmation mechanism in step 5, it forms a complete intelligent IoT operation and maintenance structure with resource conflict protection, control execution consistency, and dynamic priority adjustment.

[0088] Step 7: The cloud-based state drift analysis module receives the abnormal Boolean bitmaps from edge devices and performs node instability analysis based on historical state data to establish a hazard chain. The cloud-based state drift analysis module includes a Boolean graph parsing unit, a historical state comparison unit, a topology mapping unit, and a hazard chain construction unit. The Boolean graph parsing unit receives abnormal Boolean bitmaps uploaded by multiple edge devices and extracts continuous periodic segments marked as abnormal as drift intervals. The historical state comparison unit compares the overlap rate of the current drift interval with the preset historical operating segment execution mode based on the device number and period label to obtain a node drift confidence score. The topology mapping unit embeds the abnormal time series of each node into the power distribution topology matrix to construct a node drift vector graph. The hazard chain construction unit aggregates abnormal propagation paths level by level based on the topological adjacency structure, identifies drift time sequence correlations and state propagation signs between multiple nodes, and constructs a hazard chain table containing fields for starting node, associated nodes, propagation order, and influence intensity. The hazard chain is used to guide the intervention scheduling and sorting of potentially unstable nodes.

[0089] Specifically, the cloud-based state drift analysis module first receives anomaly Boolean bitmaps periodically uploaded from multiple edge nodes. Each bitmap is represented by a device ID, a start timestamp, and a binary string of length 10-20 periods. For example: {"device_id":"SW-A01","start_ts":"2025 07 31T10:23:00Z", "bitmap":"00111000010"} It should be noted that the "abnormal Boolean bitmap" in this application is different from the traditional fault alarm log. It encodes whether the device is in an abnormal state in a fixed periodic sequence, which is suitable for clustering and trend analysis with extremely low missed detection rate of parallel target nodes in the cloud.

[0090] The Boolean graph parsing unit traverses all uploaded bitmap records, determining the "drift interval" (the longest substring with consecutive values ​​of '1') for each device within the current time slice. It automatically extracts the start and end period ranges of each substring and outputs the drift interval identifier data structure. {"device_id":"SW-A01","drift_start":3,"drift_length":3, "global_ts_start":"2025 07 31T10:23:02.15Z"} If the substring length is less than the preset minimum drift width threshold (Default value = 2 periods) If the drift segment is ignored, it is considered as transient jitter. This threshold can be configured within 2 to 5 periods without restriction.

[0091] The historical status comparison unit matches the device number with historical anomaly Boolean graphs for the same time period, comparing the current drift interval with historical locations that overlap or are similar to each other in terms of pattern overlap rate. Using the sliding window length M (default = 10 cycles) as a baseline, the overlap rate is defined as: like (Default 0.6) indicates that the node is considered to belong to the "repeated drift pattern", and the credibility score is [not specified]. Otherwise, consider the first drift as... This score is used for subsequent sorting.

[0092] The topology mapping unit generates a matrix G=(V,E,w) based on the power distribution network connection topology, where V is the ID of all monitored devices, E represents the pair of nodes with electrical connections, and the edge weights are... This represents the connection strength (e.g., 0.9 for first-level adjacency, 0.7 for inter-tower spacing within the same column). The topology map is imported from power grid metadata or generated remotely, without restrictions.

[0093] The module will display the current drift timestamp for each node. An embedded graph structure is used to construct a drift vector graph, which is the set of time points with labels for each node. The system calculates the edges that may form propagation paths from historical data: if the device and adjacent devices drift time difference Less than the threshold (If the default is 3 cycles), then a propagation path is considered to exist, and a propagation subgraph is constructed.

[0094] The hidden danger chain construction unit performs path search in the propagation subgraph, describing the potential anomaly propagation path in a chain structure. For each path, it is arranged in propagation order, and the "influence intensity" field is calculated. Influence intensity can be defined as a comprehensive function of multiple edge weights and drift confidence scores: The chain structure is ultimately saved as a table, where each chain contains the following fields: starting node ID, list of subsequent nodes, propagation order, overall propagation strength, and earliest and most recent drift times. The potential hazard chains can be used by the scheduling platform to trigger early control interventions for high-intensity chain nodes.

[0095] All steps are implemented using Java or Python logic, with an overall runtime ranging from microseconds to tens of milliseconds, making it suitable for real-time scheduling support.

[0096] As one possible implementation method, the following describes the method for remote monitoring and maintenance of power distribution switchgear: The overall system architecture consists of three layers: field edge nodes, a cloud platform, and a remote dispatch terminal. The edge nodes are responsible for data acquisition, structured processing, state modeling, anomaly triggering, control transaction caching, execution feedback, and control mutual exclusion; the cloud platform is responsible for anomaly Boolean bitmap aggregation, state drift analysis, impact coefficient calculation, priority reordering, and hazard chain identification; the dispatch terminal issues control commands based on the cloud output.

[0097] Step 1 (refer to the previous description): Acquire five types of signal channels (current transient sequence, voltage waveform vector, contact resistance change, partial discharge acoustics, and mechanical vibration spectrum), unify timestamps, periodically encapsulate, remove anomalies, and fill missing zeros, outputting a structured time-series index array. The vector field value type and sampling frequency are clearly defined; the filling method is forward or linear interpolation.

[0098] Step 2: Extract the first-order difference derivative of the period from the structured index vector, generate standardized z-values ​​by channel, and form a multidimensional state vector sequence; fit the residual parameter vector using weighted least squares (exponentially decaying weights) over N periods of a sliding window. The dimension is the number of channels × the number of fitted parameters (e.g., 5 × 2). Weighting coefficients. It can be configured to 0.5~0.9. The fitting results (intercept, slope, RSS) are stored in a local circular buffer as drift index data for the next step.

[0099] Step 3: Calculate the angle between the residual parameter vectors during the period. and first-order difference trend perturbation Using dual criteria ( and Identify abnormal segments; generate a Boolean bitmap; compress and upload. Threshold parameters. It is adjustable, and the sensitivity of the algorithm to false positive and false negative rates can be evaluated and debugged.

[0100] Step 4: For scheduling control commands, the platform generates a transaction identifier TX_ID (fields include device number, timestamp, instruction type code, and source module ID), combined using a hash function (such as SHA-256). Edge nodes define a control transaction management table structure, with each transaction containing fields such as TX_ID, CMD_TYPE, STATE_BEFORE, STATE_EXPECTED, WRITE_LOCK, expiration timer, execution path, and status code. If the write-back is not completed within the transaction's validity period, it enters a "suspended" state and locks the control object. The data is written to the log table and periodically transmitted back. A maximum of 64 transactions are supported in a circular buffer. The structure fields are clearly defined, and the authorization token uses JWT or HMAC-SHA256.

[0101] Step 5: After control execution is complete, construct the feedback packet structure (fields include TX_ID, acknowledgment bit, action timestamp, status difference byte, fault flag bit, channel ID, source module, CRC16); send it in parallel through two independent physical channels (main link NB-IoT, auxiliary link LoRa); the platform parses and receives any valid feedback packet and marks the transaction as closed after verifying status consistency; otherwise, trigger the secondary request logic; if retransmission fails after exceeding the limit, mark the transaction as "not closed", freeze the control object, and upload the failure log. The feedback logic fields, CRC check behavior, secondary request strategy, and timeout judgment time are all limited.

[0102] Step 6: Control the priority mutex stack (LIFO structure) to manage control requests. Stack elements consist of TX_ID, cmd_type, origin_module, ctrl_object_id, priority_level, auth_token, and timestamp. The maximum depth is configurable. The authorization token verification mechanism uses a device-embedded HMAC or RSA strategy. Priority determination and write lock mechanisms are clearly defined. The freeze window opening logic and stack cleanup mechanism are defined. The conflict rejection write log structure is provided, and the relationship between the locking mechanism and transaction logic is explained. The scheduling platform can also use the anomaly propagation impact coefficient for reordering decisions. The priority label value range, freeze time, and maximum stack depth are all configurable boundaries.

[0103] Step 7: The cloud-based state drift analysis module includes four sub-modules: Boolean graph parsing unit (extracting drift intervals), historical state comparison unit (calculating matching overlap rate). It also generates confidence scores, topology mapping units (generating propagation subgraphs based on the electrical topology matrix), and hazard chain construction units (path search chains, propagation intensity calculation formulas). It outputs a linked list structure containing fields for the starting node, path, propagation order, and propagation strength. The trigger condition for an abnormal propagation path is defined as the time difference. (Default 3 cycles); Chain length can be configured to a maximum of 5 nodes; Influence strength threshold Set to 0.6; all parameter settings have clearly defined ranges; the algorithm supports Java or Python implementation.

[0104] Overall, step 1 provides structured data input; step 2 generates a trend model; step 3 marks anomalies and uploads a bitmap; step 7 aggregates the bitmap and performs topology analysis; the influence coefficient is used in step 6 to control the dynamic prioritization of requests; steps 4 and 5 manage transactions and status feedback on the device side; and step 6 executes final control mutual exclusion and execution permission control, forming a complete closed loop.

[0105] While specific embodiments of the present invention have been described above, those skilled in the art should understand that these specific embodiments are merely illustrative. Those skilled in the art can omit, substitute, and modify the details of the above methods and systems in various ways without departing from the principles and essence of the present invention. For example, combining the above method steps to perform substantially the same function and achieve substantially the same result according to substantially the same method falls within the scope of the present invention. Therefore, the scope of the present invention is defined only by the appended claims.

Claims

1. A method for remote monitoring and maintenance of power distribution switchgear based on the Internet of Things; characterized in that: include: Step 1: Receive the current transient sequence, voltage waveform vector, contact resistance change data, partial discharge acoustic signal and mechanical vibration spectrum signal of the target power distribution switchgear at the edge node, and assign a unified format timestamp identifier to each data stream to construct a structured time-series index array divided by period; Step 2: Calculate the first derivative sequence based on the same sampling channels in the adjacent period index array, generate the residual function set using the local least squares fitting method, and construct the dynamic benchmark state model; Step 3: Use the cosine angle between the residual functions of the current period and the previous period as the drift index. When the drift index is greater than a preset standard deviation multiple, mark the corresponding sampling segment of the period as an abnormal segment and generate a Boolean bitmap for uploading. Step 4: When issuing control commands, the remote platform attaches a transaction identifier, which includes a hash combination of the device identification code, the issuance timestamp, the command type code, and the calling source module number. The edge node records the transaction identifier and caches the execution path and result status before executing the control command. Step 5: After the device completes the execution, it uploads the control execution feedback data corresponding to the identifier through two independent communication paths. The remote platform confirms the completion of the transaction after receiving a valid acknowledgment from either channel. Step 6: Configure a control priority mutex stack on the device side to restrict unauthorized terminals from issuing control commands while a transaction is not completed; Step 7: Use the cloud-based state drift analysis module to receive the abnormal Boolean bitmap of the edge device, and combine it with historical state data to perform node instability analysis and establish a chain of potential problems.

2. The method for remote monitoring and maintenance of power distribution switchgear based on the Internet of Things according to claim 1, characterized in that: In the structured time-series index array, edge nodes assign data channel numbers to different types of sensor signals and record the sampled data of each channel according to the actual timestamp of its sampling completion. After sampling, the edge nodes pair and encapsulate the multi-channel data within each sampling period according to a unified period boundary to form a multi-channel synchronous data unit. When the multi-channel synchronous data unit is encapsulated into a time-series vector block, outliers outside the sampling period are automatically removed, and missing items are filled with zeros. Finally, an index key set is formed using a key-value-time triplet format, and a query index is established with the timestamp as the primary key.

3. The method for remote monitoring and maintenance of power distribution switchgear based on the Internet of Things according to claim 1, characterized in that: The dynamic baseline state model divides the derivative sequence of each period into independent fitting units according to channel type, including current fitting units, voltage fitting units, contact resistance fitting units, partial discharge fitting units, and mechanical vibration fitting units. After normalization of the characteristic components of all fitting units, a multidimensional state vector sequence is formed. A multidimensional residual function group is constructed based on the weighted least squares method under the sliding period window. By configuring the weight coefficients symmetrically decreasing with the preceding and following periods, the current period is given the maximum fitting weight to enhance the model's response sensitivity to short-term operating trend changes. The residual function parameters of the multidimensional residual function group are stored in a local circular buffer and are accompanied by channel identifiers and period labels for evaluating state shifts independently based on the channel.

4. The method for remote monitoring and maintenance of power distribution switchgear based on the Internet of Things according to claim 3, characterized in that: In the dynamic reference state model, the current fitting unit and the voltage fitting unit extract the amplitude, frequency and waveform distortion components respectively through zero crossover density analysis and Fourier coefficient transformation in each sampling period. The contact resistance fitting unit obtains the unit time gradient through periodic difference calculation; the partial discharge fitting unit extracts the main frequency band features through short-time energy envelope; and the mechanical vibration fitting unit generates the local energy distribution vector using continuous wavelet transform.

5. The method for remote monitoring and maintenance of power distribution switchgear based on the Internet of Things according to claim 1, characterized in that: In step 3, the drift index is defined by the angle value calculated from the parameter vector of the residual function in the current period and the parameter vector of the residual function in the previous period. The angle value is then subjected to periodic trend discrimination processing. The processing method is as follows: A first-order difference operation is performed between any newly generated angle value and the incremental sequence of angle changes in the previous N periods to form a trend disturbance sequence, and the maximum disturbance amplitude is extracted as the secondary drift criterion. When the angle value simultaneously meets the following conditions, the feature vector corresponding to that period is marked as an anomalous state: 1) Exceeds the dynamic threshold constructed based on the mean and standard deviation of the angles between the first N periods; 2) The disturbance amplitude of the angle change trend exceeds the preset drift response threshold; All abnormal states are encoded as Boolean values ​​of 1 in a fixed-length abnormal flag buffer stack in chronological order, and non-abnormal states are encoded as 0, forming a bitmap sequence. The bitmap sequence is periodically compressed into a fixed block size and bound to a sampling start timestamp for uploading to a remote monitoring platform.

6. The method for remote monitoring and maintenance of power distribution switchgear based on the Internet of Things according to claim 1, characterized in that: In step 4, after receiving a control instruction with a transaction identifier, the edge node also maps the transaction identifier to a control transaction management table built locally on the device according to the instruction type. Each record in the control transaction management table uses a transaction identifier as the primary key and is associated with the following stored fields: instruction type field, receive timestamp, command validity timer, current device status snapshot, control execution path identifier, status write-back lock status bit, pre-execution status code and expected post-execution status code. If the status feedback is not written within the preset instruction validity period, the transaction identifier status is set to a suspended state, and the local control channel locking mechanism is triggered to prevent subsequent control instructions from writing to the same control object until the current transaction obtains a clear execution conclusion and is released; the control transaction management table is updated in a circular buffer manner, and instruction processing logs are generated periodically by the device-side control module.

7. The method for remote monitoring and maintenance of power distribution switchgear based on the Internet of Things according to claim 1, characterized in that: In step 5, the control execution feedback data is constructed by the device before being sent as a feedback status packet. This feedback status packet includes, in addition to the corresponding transaction identifier, a control execution confirmation bit, an action completion timestamp, a comparison byte before and after the target execution bit change, a device fault flag bit, a communication channel identifier field, and a feedback packet integrity check code. The feedback status packet is sent in parallel to the remote platform via dual physical channels, including a primary channel and a secondary channel. Each channel's feedback status packet includes an independent path sequence number and an issuing module number. The primary channel uses NB-IoT or a cellular public network standard for encrypted feedback, while the secondary channel uses LoRa or a private wireless link. After receiving a valid feedback packet from any channel, the platform performs consistency analysis based on the control execution confirmation bit and the target status change byte in the feedback status packet. If the analysis confirms consistency with the original control command target, the corresponding transaction is marked as closed-loop. If the analysis fails or the status code is inconsistent, the transaction remains in a pending confirmation state, and a secondary request signal is sent to the backup channel. After a second failure, the transaction is marked as unclosed-loop, and a failed transaction log is reported to the platform.

8. The method for remote monitoring and maintenance of power distribution switchgear based on the Internet of Things according to claim 1, characterized in that: The control priority mutex stack uses a stack-based last-in-first-out (LIFO) logic to implement write mutual exclusion. Each stack element includes: control request origin identifier, binding transaction identifier, command type code, control object tag, priority label, authorization token verification field, and stack push timestamp. When any control transaction is written to the top of the stack, the device control interface enters a locked state, allowing only the top request to initiate control execution. If a non-top request attempts to access the control interface, the remote platform compares the request priority label with the top element. If the request has a lower priority or an invalid authorization token, the control request is rejected and a rejection event is logged. Furthermore, if the current transaction fails to complete and exceeds the preset transaction timeout threshold for an extended period, the control object is frozen through a stack cleanup mechanism, prohibiting all control requests from entering during the frozen state window.

9. A method for remote monitoring and maintenance of power distribution switchgear based on the Internet of Things according to claim 1, characterized in that: In step 6, the remote platform uses an abnormal diffusion influence coefficient. Priority reordering and intervention window timing adjustment of scheduling control transactions, the anomaly propagation impact coefficient. The method for obtaining it is as follows: After receiving the abnormal Boolean bitmap uploaded by multiple edge devices, a node topology matrix G=(V,E) is generated according to the physical connection relationship of the power distribution network, where V is the set of nodes and E is the set of edges. Furthermore, a drift propagation path model within the topology is established by combining the time series of anomaly occurrences, for any node. Calculate the influence coefficient of abnormal diffusion The calculation formula is: in, For nodes and The edge weights between them; For nodes Directly connected exception triggering nodes The adjacency set formed This refers to the cycle in which node anomalies occur. Represents a node and The period difference between abnormal triggers, in units of standard sampling periods; This represents the overlap rate of the historical Boolean bitmap.

10. A method for remote monitoring and maintenance of power distribution switchgear based on the Internet of Things according to claim 1, characterized in that: The cloud-based state drift analysis module includes a Boolean graph parsing unit, a historical state comparison unit, a topology mapping unit, and a hidden danger chain construction unit. The Boolean graph parsing unit is used to receive abnormal Boolean bitmaps uploaded by multiple edge devices and extract the continuous periodic segments marked as abnormal as drift intervals. The historical state comparison unit is used to compare the overlap rate of the current drift interval with the preset historical operating segment execution mode based on the equipment number and period label to obtain the node drift confidence score; the topology mapping unit is used to embed the abnormal time series of each node into the power distribution topology matrix to construct a node drift vector graph; the hidden danger chain construction unit is based on the topological adjacency structure to aggregate the abnormal propagation path step by step, identify the drift time sequence correlation and state propagation signs between multiple nodes, and construct a hidden danger chain table containing the fields of starting node, associated node, propagation order, and influence intensity; the hidden danger chain is used to guide the intervention scheduling order of potentially unstable nodes.

Images