A device abnormality early warning method based on internet of things energy consumption big data analysis

Abstract

The present application relates to the technical field of internet of things equipment state detection and monitoring, and discloses a device abnormal early warning method based on internet of things energy consumption big data analysis. An edge energy consumption collection terminal collects energy consumption monitoring data of a monitored device and adds state and communication fields; an internet of things gateway forms an aligned batch according to a gateway clock, encapsulates continuous aligned batches as a device monitoring window, and generates an edge collection credibility mark; a cloud monitoring platform writes an effective device monitoring window into an internet of things energy consumption big data pool, selects a same kind and same state historical window, generates an energy consumption monitoring feature vector and a device abnormal monitoring value, generates device abnormal early warning information when a pre-warning trigger condition is met, and marks the device monitoring window as a to-be-verified window or a monitoring abnormal window through a pre-warning review window group. The method is used for continuous monitoring and abnormal early warning of the internet of things energy consumption state.

Description

Technical Field

[0001] This invention relates to the field of IoT device status detection and monitoring technology, and in particular to a device anomaly early warning method based on IoT energy consumption big data analysis. Background Technology

[0002] With the application of IoT monitoring networks in energy consumption monitoring scenarios for industrial equipment, building equipment, and park equipment, it is typically necessary to set up edge energy consumption acquisition terminals at multiple monitored devices. These terminals collect energy consumption monitoring data such as active power, current, voltage, and cumulative power consumption, which is then uploaded to a cloud monitoring platform via an IoT gateway or network transmission layer. The cloud monitoring platform stores, processes, and outputs early warnings based on the device energy consumption monitoring data. The main purpose of this type of technical solution is to continuously detect and monitor the operating energy consumption status of the monitored equipment and generate corresponding early warnings when the equipment's energy consumption status deviates from preset conditions.

[0003] For example, patent application CN114071258A discloses a smart electricity monitoring and early warning system based on the Internet of Things (IoT) and wired networking. Its system architecture includes a physical sensing layer, a network transmission layer, a data service layer, and a user application layer. The physical sensing layer collects data from electrical devices, the network transmission layer transmits the collected data to the data service layer, the data service layer stores and processes the data, and uploads the processed data to the user application layer. This type of solution can realize data collection, data uploading, data storage and processing, and early warning display based on an IoT architecture, and is a relatively typical IoT-based electricity monitoring and early warning technology.

[0004] In the aforementioned existing technologies, to improve monitoring data processing capabilities, big data analytics are typically introduced into the data service layer or cloud monitoring platform to store, statistically analyze, compare, or threshold-determine large amounts of historical and real-time energy consumption data, thereby assisting in the detection of abnormal energy consumption states of monitored devices. However, in real-world scenarios with massive IoT device connectivity, the data acquisition time, upload path, communication quality, and message status of different edge energy consumption acquisition terminals are not entirely consistent. During the upload process, device energy consumption monitoring data is prone to issues such as discontinuous acquisition timestamps, message retransmissions, abnormal terminal heartbeats, inconsistent terminal parameter versions, and discrepancies between the number of registered terminals and the actual number of reported terminals within the same gateway area.

[0005] When anomalies in the underlying data acquisition or transmission links are not effectively identified, the device energy consumption monitoring data received by the cloud monitoring platform may not accurately reflect the energy consumption status of the monitored devices. If this type of data is directly written into the historical sample set or used as input for big data analysis to determine energy consumption anomalies, the anomaly warning results are easily affected by data acquisition link anomalies, timing misalignments, or data gaps, leading to false alarms or missed alarms regarding device anomalies. Furthermore, in scenarios where multiple monitored devices concurrently connect to the same IoT gateway, without correlating and verifying the data acquisition timing, communication status, and terminal reporting status of different devices, the cloud monitoring platform cannot accurately distinguish whether the current energy consumption deviation originates from an anomaly in the energy consumption status of the monitored devices or from an anomaly in the IoT data acquisition link.

[0006] Therefore, the main technical problem that existing IoT energy consumption monitoring and early warning technologies still need to solve is: in IoT energy consumption monitoring scenarios where multiple edge energy consumption acquisition terminals are accessed concurrently, how to distinguish between abnormal acquisition links and abnormal energy consumption status of monitored devices based on acquisition timing, communication status, and terminal reporting status, and reduce the impact of abnormal acquisition data on historical monitoring benchmarks and device abnormality early warning judgments. Summary of the Invention

[0007] To overcome the aforementioned technical deficiencies, the present invention aims to provide a device anomaly early warning method based on IoT energy consumption big data analysis. This invention employs a technical solution whereby an IoT gateway aligns and batches device energy consumption monitoring data to generate edge acquisition credibility markers; a cloud monitoring platform compares similar and homomorphic historical windows based on valid device monitoring windows and generates energy consumption monitoring feature vectors; and an early warning verification window group separates the window to be verified from the monitored anomaly window. This solution addresses the difficulty in distinguishing between abnormal acquisition links and abnormal energy consumption status of monitored devices, as well as the impact of abnormal acquisition data on historical monitoring benchmarks.

[0008] This invention discloses a device anomaly early warning method based on IoT energy consumption big data analysis, applicable to an IoT monitoring network including edge energy consumption acquisition terminals, IoT gateways, and cloud monitoring platforms. The method includes:

[0009] The edge energy consumption acquisition terminal collects the energy consumption monitoring data of the monitored equipment. The equipment energy consumption monitoring data includes active power, current, voltage and cumulative power consumption. The equipment energy consumption monitoring data is supplemented with equipment identification, sampling number, acquisition timestamp, equipment operation status code, terminal heartbeat flag, terminal parameter version number and message retransmission record.

[0010] The IoT gateway forms an aligned batch of device energy consumption monitoring data uploaded by multiple edge energy consumption acquisition terminals according to the gateway clock. The continuous aligned batches are encapsulated into a device monitoring window and written with window number, gateway area identifier, data integrity mark, current threshold version and edge acquisition confidence mark.

[0011] The edge acquisition credibility marker is determined by the acquisition timestamp increment status, message retransmission record, terminal heartbeat marker, consistency of terminal parameter version number, and consistency between the number of registered terminals and the number of actual reported terminals in the same gateway area.

[0012] The cloud monitoring platform matches the device type based on the device identifier, generates a runtime segment label based on the collection timestamp, and writes the device type and runtime segment label into the corresponding device monitoring window;

[0013] The cloud-based monitoring platform marks edge-collected data as valid device monitoring windows and writes them into the IoT energy consumption big data pool.

[0014] The big data analysis engine of the cloud monitoring platform selects similar historical windows and generates an energy consumption monitoring feature vector based on the current device monitoring window and similar historical windows. The energy consumption monitoring feature vector includes the energy consumption per unit time period field, window fluctuation field, state energy consumption matching field, similar distribution deviation field, regional synchronization deviation field, and data collection reliability field.

[0015] Based on the energy consumption monitoring feature vector, generate equipment abnormal monitoring values. When the equipment abnormal monitoring values ​​meet the early warning triggering conditions, generate equipment abnormal early warning information and establish an early warning review window group.

[0016] According to the early warning review window group, the corresponding device monitoring window is marked as a window to be verified or a monitoring abnormal window, and the window to be verified does not participate in the selection of the same type of historical window or the update of the current threshold version.

[0017] Preferably, the edge energy consumption acquisition terminal forms an energy metering frame and a status sampling frame under the same sampling sequence number; the energy metering frame includes active power, current, voltage and cumulative energy consumption, and the status sampling frame includes the device operating status code, terminal heartbeat flag, terminal parameter version number and message retransmission record; when there is no energy metering frame or status sampling frame under the same sampling sequence number, the data integrity mark of the corresponding device energy consumption monitoring data is set to invalid.

[0018] Preferably, the IoT gateway forming an alignment batch includes: generating a unified sampling time using the gateway clock; grouping energy metering frames and status sampling frames whose collection timestamps fall within the same time interval corresponding to the unified sampling time into the same alignment batch; when multiple energy metering frames exist for the same device identifier within the same alignment batch, retaining the energy metering frame with the latest collection timestamp and the same terminal parameter version number; and writing a status energy consumption mismatch flag to the corresponding device monitoring window when the device operating status code under the same sampling sequence number does not match the active power field in the energy metering frame.

[0019] Preferably, the window number consists of the gateway area identifier, the device identifier, the window start alignment batch number, and the gateway generation serial number; the IoT gateway stores the correspondence between the window number and the device monitoring window in its local cache, and receives the window receipt number after uploading the device monitoring window to the cloud monitoring platform; when the window number and the window receipt number are inconsistent, the cloud monitoring platform adds the corresponding device monitoring window to the early warning review window group.

[0020] Preferably, the same type of homomorphic historical windows are selected in the following way: historical device monitoring windows with the same device type, the same device operating status code, the same operating period label, the same gateway area identifier, and the same current threshold version as the current device monitoring window are screened from the IoT energy consumption big data pool to form a candidate historical window set; historical device monitoring windows marked as invalid for edge collection credibility, invalid for data integrity, or marked as windows to be verified are deleted from the candidate historical window set to obtain the same type of homomorphic historical windows.

[0021] Preferably, when the historical device monitoring windows in the candidate historical window set have a regional synchronization deviation field and are set to be valid, the cloud monitoring platform groups them according to the number of continuous windows with the regional synchronization deviation field being valid; a group of historical device monitoring windows whose number of continuous windows reaches the regional synchronization verification condition is marked as regional disturbance windows, and regional disturbance windows are not treated as homomorphic historical windows of the same type.

[0022] Preferably, the unit time period energy consumption field is generated from the cumulative power consumption change within the current device monitoring window; the window fluctuation field is generated from the active power change relationship corresponding to adjacent sampling numbers within the current device monitoring window; the status energy consumption matching field is generated from the device operating status code and the unit time period energy consumption field; the similar distribution deviation field is generated from the distribution position of the current device monitoring window relative to similar homomorphic historical windows; and the acquisition credibility field is generated from the edge acquisition credibility marker.

[0023] Preferably, the regional synchronization deviation field is generated in the following way: within the same gateway area corresponding to the current device monitoring window, other monitored devices with the same device running status code and valid edge acquisition confidence mark are selected as reference devices; the same distribution deviation fields of the current monitored device and the reference device relative to their respective same type of homomorphic historical windows are determined respectively; when the current monitored device and no less than two reference devices have the same deviation state in the same window number corresponding time period, the regional synchronization deviation field is set to valid.

[0024] Preferably, the abnormal monitoring value of the equipment is generated by the same type distribution deviation field, window fluctuation field, status energy consumption matching field, regional synchronization deviation field, and acquisition reliability field in a preset field order; when the acquisition reliability field is invalid, the cloud monitoring platform does not generate a monitoring abnormal window, but generates a review warning information and adds the current equipment monitoring window to the warning review window group; when the acquisition reliability field is valid and the status energy consumption matching field is mismatched, the cloud monitoring platform generates a review warning information; when the acquisition reliability field is valid and the same type distribution deviation field and window fluctuation field meet the warning triggering conditions, the cloud monitoring platform generates an equipment abnormal warning information.

[0025] Preferably, the early warning triggering conditions include continuous window triggering conditions and sudden window triggering conditions; the continuous window triggering condition is that multiple consecutive device monitoring windows corresponding to the same device identifier generate device abnormal monitoring values ​​that reach the continuous early warning level; the sudden window triggering condition is that the current device monitoring window corresponding to the same device identifier generates device abnormal monitoring values ​​that reach the sudden warning level, and the regional synchronization deviation field of the current device monitoring window is invalid.

[0026] Preferably, the early warning review window group includes multiple review device monitoring windows received consecutively after the current device monitoring window; the cloud monitoring platform performs window number consistency verification, terminal parameter version number consistency verification, data collection timestamp increment verification, registered terminal quantity consistency verification with actual reported terminal quantity verification, and status energy consumption matching verification on the multiple review device monitoring windows respectively, and marks the current device monitoring window as a window to be verified or a monitoring abnormal window according to the above verification results.

[0027] Preferably, when the current device monitoring window is marked as a window to be verified, the cloud monitoring platform writes the current device monitoring window, the corresponding early warning review window group, and the triggered verification items into the sample table to be verified; when the current device monitoring window is marked as a monitoring anomaly window, the cloud monitoring platform writes the current device monitoring window, the corresponding energy consumption monitoring feature vector, the device anomaly monitoring value, and the device anomaly early warning information into the monitoring anomaly sample table; the device monitoring windows in the sample table to be verified do not participate in the selection of similar homomorphic historical windows.

[0028] Preferably, the current threshold version is updated in the following way: The cloud monitoring platform selects device monitoring windows from the IoT energy consumption big data pool that are marked as valid for edge acquisition credibility, valid for data integrity, and not marked as windows to be verified or as monitoring anomalies. It forms a threshold update sample set according to device type, device operating status code, runtime segment label, and gateway area identifier, and generates a new threshold version based on the threshold update sample set. The new threshold version is bound to the corresponding device type, device operating status code, runtime segment label, and gateway area identifier, and serves as the current threshold version for subsequent use by the corresponding device monitoring window.

[0029] Preferably, the cloud monitoring platform sends a monitoring parameter package to the IoT gateway. The monitoring parameter package includes the sampling period, window length, device operating status code table, data field format, and current threshold version. The IoT gateway forwards the monitoring parameter package to the corresponding edge energy consumption acquisition terminal and receives parameter confirmation information returned by the edge energy consumption acquisition terminal. When the IoT gateway does not receive parameter confirmation information or the terminal parameter version number in the parameter confirmation information is inconsistent with the current threshold version, the IoT gateway writes a parameter unconfirmed flag to the corresponding device monitoring window and uses the parameter unconfirmed flag as the basis for determining the consistency of the terminal parameter version number.

[0030] Preferably, when the cloud monitoring platform generates a review warning, the cloud monitoring platform sends a review sampling task to the corresponding IoT gateway. The review sampling task carries the device identifier, window number, sampling period, number of review windows, and terminal parameter version number. The IoT gateway receives the review device energy consumption monitoring data returned by the edge energy consumption collection terminal according to the review sampling task, and encapsulates the review device energy consumption monitoring data into a review device monitoring window. The cloud monitoring platform assigns the review device monitoring window to the corresponding warning review window group.

[0031] Compared with existing technologies, the above technical solution has the following advantages:

[0032] 1. This invention uses an IoT gateway to form aligned batches of device energy consumption monitoring data uploaded by multiple edge energy consumption acquisition terminals according to the gateway clock, and encapsulates consecutive aligned batches into device monitoring windows. This allows data uploaded by different edge energy consumption acquisition terminals to enter the subsequent monitoring process under a unified time reference, reducing the impact of inconsistent acquisition timing, data disorder, or inconsistent window boundaries on the judgment of device anomaly warnings.

[0033] 2. This invention incorporates the increasing status of the collection timestamp, message retransmission records, terminal heartbeat markers, consistency of terminal parameter version numbers, and consistency between the number of registered terminals and the number of actually reported terminals in the same gateway area into the monitoring and judgment process by using edge collection credibility marking. This enables the identification of collection link anomalies before big data analysis in the cloud, distinguishing collection link anomalies from energy consumption anomalies of the monitored devices, thereby reducing the risk of false alarms caused by underlying communication anomalies or terminal status anomalies.

[0034] 3. This invention selects historical windows of the same type and state as the current device monitoring window from the IoT energy consumption big data pool. These windows have the same device type, the same device operating status code, the same operating period label, the same gateway area identifier, and the same current threshold version. It also deletes historical device monitoring windows that have invalid edge acquisition credibility markings, invalid data integrity markings, or windows marked as pending verification. This allows the current device monitoring window to be compared with historical benchmarks of the same type, state, region, and version, reducing the interference of different operating states, different time periods, or abnormal acquisition data on historical monitoring benchmarks.

[0035] 4. This invention generates abnormal monitoring values ​​for equipment by using energy consumption monitoring feature vectors, and combines regional synchronization deviation fields and early warning verification window groups to verify and divert equipment monitoring windows, so that equipment monitoring windows can be marked as windows to be verified or monitoring abnormal windows; wherein, windows to be verified do not participate in the selection of similar homomorphic historical windows and the current threshold version update, which can reduce the continuous impact of abnormal data collection on subsequent abnormal early warning judgment after entering the historical sample set.

[0036] 5. This invention ensures that the sampling period, window length, device operating status code table, data field format, and current threshold version are consistent among the cloud monitoring platform, IoT gateway, and edge energy consumption acquisition terminal by updating the current threshold version and distributing monitoring parameter packages. Furthermore, by using parameter confirmation information and parameter unconfirmation flags to participate in the consistency judgment of terminal parameter version numbers, it can improve the parameter consistency and traceability of early warning verification in multi-node collaborative monitoring in the IoT energy consumption monitoring network. Attached Figure Description

[0038] Figure 1 This is a physical architecture topology diagram of an IoT monitoring network provided in an embodiment of the present invention;

[0039] Figure 2 This is a diagram illustrating the structure of the device energy consumption monitoring data message provided in an embodiment of the present invention.

[0040] Figure 3 This is the main flowchart of the equipment anomaly early warning method provided in the embodiments of the present invention;

[0041] Figure 4 This is a flowchart of the IoT gateway clock alignment and window encapsulation sub-process provided in an embodiment of the present invention;

[0042] Figure 5 A flowchart of the same homomorphic historical window filtering and regional disturbance exclusion provided in the embodiments of the present invention;

[0043] Figure 6 This is a sub-flowchart for the current threshold version update and monitoring parameter package distribution provided in an embodiment of the present invention;

[0044] Figure 7 This is a timing diagram of the data interaction between the edge power consumption acquisition terminal, the IoT gateway, and the cloud monitoring platform provided in an embodiment of the present invention.

[0045] Figure 8 This is a comparison diagram of regional synchronization deviation waveforms provided in an embodiment of the present invention;

[0046] Figure 9 This is a state transition diagram of the device monitoring window provided in an embodiment of the present invention;

[0047] Figure 10 This is a multidimensional clustering scatter plot showing similar distribution deviations provided in an embodiment of the present invention. Detailed Implementation

[0049] The following is combined with Figures 1 to 10 This paper describes a device anomaly early warning method based on IoT energy consumption big data analysis. Figure 1 The physical architecture of the IoT monitoring network is shown. Figure 2 The message structure of the equipment energy consumption monitoring data is shown. Figure 3 The main flow of the equipment anomaly early warning method is shown. Figure 4 This illustrates the clock alignment and window encapsulation process for an IoT gateway. Figure 5 The process of filtering homomorphic historical windows and excluding regional disturbances is illustrated. Figure 6 This shows the current threshold version update and monitoring parameter package distribution process. Figure 7 The data interaction sequence between the edge power consumption acquisition terminal, the IoT gateway, and the cloud monitoring platform is shown. Figure 8 The waveform characteristics of the regional synchronization deviation are shown. Figure 9 The state transition process of the device monitoring window is shown. Figure 10 The multidimensional clustering scatter plots with similar distribution deviations are shown. The following examples are used to illustrate specific implementations of the method and do not constitute an undue limitation on the scope of the technical solution.

[0050] The equipment anomaly early warning method provided in this embodiment is applicable to industrial equipment, building equipment, park equipment, data center auxiliary equipment, and other IoT energy consumption monitoring scenarios that require continuous energy consumption status monitoring. See also Figure 1 The IoT monitoring network comprises multiple edge energy consumption acquisition terminals, at least one IoT gateway, and a cloud monitoring platform. Edge energy consumption acquisition terminals are located at the power supply circuits or metering nodes of the monitored equipment and may include voltage sampling circuits, current transformers, metering chips, microcontrollers, and communication interfaces. IoT gateways are deployed in workshops, floors, power distribution areas, or equipment groups to receive equipment energy consumption monitoring data uploaded by multiple edge energy consumption acquisition terminals and perform protocol parsing, gateway clock alignment, local caching, window encapsulation, and uploading. The cloud monitoring platform includes an equipment archive, an IoT energy consumption big data pool, a big data analysis engine, a current threshold version management module, an early warning verification module, and an early warning display module, used for storing, comparing, detecting, monitoring, and outputting early warnings for the equipment monitoring windows.

[0051] In one implementation, the monitored equipment is a motor, air compressor, circulating pump, cooling tower fan, or continuously operating production auxiliary equipment in the workshop. Each monitored device is equipped with a corresponding edge energy consumption acquisition terminal, which collects active power, current, voltage, and cumulative electricity consumption according to a set sampling period. The sampling period can be set to 5 seconds to 60 seconds; in scenarios with frequent equipment start-ups and shutdowns or large load fluctuations, the sampling period can be set to 5 seconds or 10 seconds; in scenarios involving building lighting, office sockets, or low-frequency operating equipment, the sampling period can be set to 30 seconds or 60 seconds. Each time a sample is taken, the edge energy consumption acquisition terminal adds the device identifier, sampling sequence number, collection timestamp, device operating status code, terminal heartbeat flag, terminal parameter version number, and message retransmission record to the device energy consumption monitoring data.

[0052] Among them, the device identifier is used to indicate the unique number of the monitored device in the device archive; the sampling sequence number is used to indicate the order in which the same edge energy consumption acquisition terminal continuously collects data; the acquisition timestamp is used to indicate the moment when the edge energy consumption acquisition terminal generates device energy consumption monitoring data; the device operating status code is used to indicate whether the monitored device is in a stopped, idle, half-load, full-load, standby, or other preset operating state; the terminal heartbeat flag is used to indicate the online status of the edge energy consumption acquisition terminal within the current sampling period; the terminal parameter version number is used to indicate the version code formed by the edge energy consumption acquisition terminal after confirming the sampling period, window length, device operating status code table, data field format, and current threshold version in the monitoring parameter package; and the message retransmission record is used to indicate the number of retransmissions or retransmission status of the message corresponding to the same sampling sequence number. In this embodiment, the terminal parameter version number and the current threshold version use the same version encoding rule so that the IoT gateway can determine whether the monitoring parameters used by the edge energy consumption acquisition terminal are consistent with the current threshold version issued by the cloud monitoring platform.

[0053] See Figure 2 In one implementation, the edge energy consumption acquisition terminal generates an energy metering frame and a status sampling frame under the same sampling sequence number. The energy metering frame carries active power, current, voltage, and cumulative energy consumption, while the status sampling frame carries the device operating status code, terminal heartbeat flag, terminal parameter version number, and message retransmission record. Both the energy metering frame and the status sampling frame include a frame header, device identifier, sampling sequence number, acquisition timestamp, and checksum. After receiving the energy metering frame and status sampling frame under the same sampling sequence number, the IoT gateway merges them into a single device energy consumption monitoring data entry. When an energy metering frame or status sampling frame is missing under the same sampling sequence number, the IoT gateway sets the data integrity flag of the corresponding device energy consumption monitoring data to invalid.

[0054] Table 1 shows an example of the raw data frame format acquired at the edge. This table represents only one feasible data frame organization method; field lengths can be adjusted based on communication protocols, measurement accuracy, and device type.

[0055] Table 1 Data Message Format Table

[0056] Frame header 2 Byte Hex 0xAA55 Message start identifier Equipment identification 4 Byte Hex 0A 1B 2C 3D Workshop 1, No. 3 motor Sampling sequence number 4 Byte Int 1025 The current terminal is sampling for the 1025th time. Collection timestamp 8 Byte Long 1718342400 2024-06-14 13:20:00 corresponding timestamp Active power 4 Byte Float 45.50 kW Current load power Current 4 Byte Float 82.30 A Current loop current Voltage 4 Byte Float 380.20 V Current circuit voltage Cumulative electricity consumption 4 Byte Float 12500.50 kWh Current meter reading Device status codes 1 Byte Hex 0x01 0x01 indicates full load operation. Terminal heartbeat marker 1 Byte Bool 1 1 indicates a normal heartbeat. Terminal parameter version number 2 Byte Hex 0x0302 Current terminal parameter version Message retransmission record 1 Byte Int 0 0 indicates no retransmission Check bit 2 Byte CRC 0x7A3C Data integrity verification

[0057] See Figure 3 The equipment anomaly early warning method includes equipment energy consumption monitoring data acquisition, gateway clock alignment, equipment monitoring window encapsulation, edge acquisition credibility marker generation, equipment type matching, runtime segment label generation, effective window writing, selection of similar and homomorphic historical windows, energy consumption monitoring feature vector generation, equipment anomaly monitoring value generation, early warning review window group establishment, and split processing of windows to be verified and monitoring anomaly windows.

[0058] Specifically, after receiving device energy consumption monitoring data uploaded by multiple edge energy consumption acquisition terminals, the IoT gateway establishes a unified sampling time according to the gateway clock. See also Figure 4 The IoT gateway can generate a unified sampling time every 10 seconds based on the gateway clock and set the corresponding time interval. For example, when the unified sampling time is 13:20:00, the corresponding time interval can be from 13:19:55 to 13:20:05. Device energy consumption monitoring data whose timestamps fall within this time interval are grouped into the same alignment batch. If multiple energy metering frames exist for the same device identifier within the same alignment batch, the IoT gateway retains the energy metering frame with the latest collection timestamp and the same terminal parameter version number. If the device's operating status code under the same sampling sequence number does not match the active power field in the energy metering frame, for example, if the device's operating status code is "stop" but the active power is higher than the allowable power for the stop state, the IoT gateway writes a status energy consumption mismatch flag to the corresponding device monitoring window.

[0059] The IoT gateway encapsulates multiple consecutive aligned batches into a device monitoring window. The window length can be 6 to 60 aligned batches. In this embodiment, the sampling period is 10 seconds, and the window length is 6 aligned batches, so one device monitoring window covers 60 seconds. Each device monitoring window is written with a window number, gateway region identifier, data integrity flag, current threshold version, and edge acquisition confidence flag. The window number consists of the gateway region identifier, device identifier, window start aligned batch number, and gateway generation sequence number. For example, the window number can be represented as "G01-M003-B202406141320-S0001", where "G01" represents the first gateway region, "M003" represents the third motor, "B202406141320" represents the window start aligned batch, and "S0001" represents the gateway generation sequence number. The IoT gateway stores the correspondence between window numbers and device monitoring windows in its local cache and receives the window receipt number after uploading the device monitoring window to the cloud monitoring platform. When the window number and the window receipt number are inconsistent, the cloud monitoring platform will add the corresponding device monitoring window to the early warning review window group.

[0060] The edge acquisition reliability flag is determined by the increasing acquisition timestamp status, message retransmission records, terminal heartbeat flag, consistency of terminal parameter version number, and consistency between the number of registered terminals and the actual number of reported terminals within the same gateway area. In one implementation, the IoT gateway generates the edge acquisition reliability flag according to the following decision tree: when the acquisition timestamp corresponding to the same device identifier does not increase according to the sampling sequence number, the edge acquisition reliability flag is set to invalid; when the retransmission count shown in the message retransmission record is greater than 3, the edge acquisition reliability flag is set to invalid; when the terminal heartbeat flag is 0, the edge acquisition reliability flag is set to invalid; when the terminal parameter version number corresponding to the same device identifier is inconsistent with the current threshold version issued by the IoT gateway, the edge acquisition reliability flag is set to invalid; when the number of registered terminals and the actual number of reported terminals within the same gateway area are inconsistent, an invalid edge acquisition reliability flag is written to the device monitoring window corresponding to the missing terminal. The edge acquisition reliability flag is set to valid only when all the above checks meet the valid conditions. The retransmission count threshold in the above decision tree can be set to 2 to 5 times; in this embodiment, it is set to 3 times.

[0061] After receiving a device monitoring window, the cloud monitoring platform queries the device database based on the device identifier to match the device type and generates a runtime segment tag based on the collection timestamp. The device database can be generated from a device ledger, gateway registration form, or system initialization configuration file. Device types can include motors, pumps, fans, compressors, lighting, or other preset types. Runtime segment tags can be divided according to production shifts, building energy consumption periods, or electricity price periods. For example, 8:00 to 12:00 can be set as the morning runtime, 13:00 to 15:00 as the peak period, and 0:00 to 6:00 as the off-peak period. The cloud monitoring platform writes the device type and runtime segment tag into the corresponding device monitoring window and writes the device monitoring windows marked as valid by edge collection credibility into the IoT energy consumption big data pool. Device monitoring windows marked as invalid by edge collection credibility are not directly used as historical monitoring benchmark update samples, but are instead added to the early warning review window group or the sample table to be verified.

[0062] See Figure 5The same type and similar historical windows are selected from the IoT energy consumption big data pool by the big data analysis engine of the cloud monitoring platform. Specifically, the big data analysis engine filters historical device monitoring windows from the IoT energy consumption big data pool that have the same device type, the same device operating status code, the same operating time tag, the same gateway area identifier, and the same current threshold version as the current device monitoring window, forming a candidate historical window set. Subsequently, historical device monitoring windows marked as invalid due to edge collection credibility, invalid due to data integrity, or marked as windows to be verified are deleted from the candidate historical window set, resulting in the same type and similar historical windows. The above filtering method enables the current device monitoring window to be compared with historical windows that are consistent in device type, operating status, operating time, and gateway area, avoiding direct mixing and comparison of idle windows with full-load windows, low-off-peak windows with peak-off-peak windows, and windows from different gateway areas.

[0063] In one implementation, when a historical device monitoring window in the candidate historical window set corresponds to a regional synchronization deviation field and is set to valid, the cloud monitoring platform groups the windows according to the number of consecutive windows with valid regional synchronization deviation fields. If the regional synchronization deviation field of multiple historical device monitoring windows within the same gateway area is valid for three consecutive windows, the regional synchronization verification condition is met. This group of historical device monitoring windows is marked as regional disturbance windows and is not considered as homomorphic historical windows of the same type. The number of consecutive windows in the regional synchronization verification condition can be set to 2 to 5; in this embodiment, 3 is used.

[0064] The energy consumption monitoring feature vector consists of a unit time period energy consumption field, a window fluctuation field, a state energy consumption matching field, a similar distribution deviation field, a regional synchronization deviation field, and a data acquisition reliability field. Each field is a data field that can be stored, retrieved, and verified by the cloud monitoring platform. To disclose the internal logic of the energy consumption monitoring feature vector in detail, enabling those skilled in the art to implement it, this embodiment describes the generation process of each field as follows.

[0065] The energy consumption per unit time period field is generated from the cumulative change in electricity consumption within the current device monitoring window. In this embodiment, the energy consumption per unit time period field is represented as follows: And calculate according to formula (1):

[0066]

[0067] in, This field represents energy consumption per unit time period, in kWh / min. This indicates the cumulative power consumption corresponding to the last sampling number in the current device monitoring window, in kWh. This indicates the cumulative power consumption corresponding to the first sampling number in the current device monitoring window, in kWh. This indicates the duration of the current device monitoring window, in minutes.

[0068] For example, if the current device monitoring window duration is 1 minute, the cumulative power consumption corresponding to the first sampling number is 12500.50 kWh, and the cumulative power consumption corresponding to the last sampling number is 12501.30 kWh, then the energy consumption per unit time period field is:

[0069]

[0070] Therefore, the energy consumption per unit time period in the current equipment monitoring window is 0.80 kWh / min.

[0071] The window fluctuation field is generated based on the active power change relationship between adjacent sampling numbers within the current device monitoring window. In this embodiment, the window fluctuation field is represented as... And the normalized mean difference method is used to calculate according to formula (2):

[0072]

[0073] in, Indicates the window fluctuation field; This indicates the number of sampling points within the current device monitoring window; Indicates the number of devices in the current monitoring window. The active power corresponding to each sampling point is expressed in kW. Indicates the number of devices in the current monitoring window. The active power corresponding to each sampling point is expressed in kW. This indicates the rated power of the monitored equipment, in kW.

[0074] For example, if the current equipment monitoring window contains 6 sampling points with active power of 45.0kW, 45.5kW, 46.0kW, 62.0kW, 64.0kW, and 63.5kW respectively, and the rated power of the monitored equipment is 75kW, then the window fluctuation field is:

[0075]

[0076]

[0077] Therefore, the current window fluctuation field of the device monitoring window is 0.052.

[0078] The status energy consumption matching field is generated from the device operating status code and the energy consumption field per unit time period. In this embodiment, the status energy consumption matching field is represented as follows: The cloud-based monitoring platform pre-stores the permissible energy consumption range per unit time period corresponding to different equipment operating status codes in the equipment archive. This permissible range can be generated from the equipment's rated power, equipment commissioning data, or historical normal window statistics. For example, the permissible energy consumption range per unit time period for full-load operation is 0.60 kWh / min to 0.95 kWh / min, for no-load operation it is 0.05 kWh / min to 0.18 kWh / min, and for shutdown it is 0 kWh / min to 0.02 kWh / min. When the permissible energy consumption field falls within the permissible range corresponding to the equipment operating status code, the status energy consumption matching field is 1; when the permissible energy consumption field does not fall within the corresponding permissible range, the status energy consumption matching field is 0. This field is used to distinguish whether the equipment operating status code and the physical quantity of energy consumption are consistent.

[0079] The "Same Category Distribution Deviation" field is generated by the distribution position of the current device monitoring window relative to similar homomorphic historical windows. See also... Figure 10 The cloud-based monitoring platform can construct a two-dimensional feature space using the unit time period energy consumption field and the window fluctuation field. It can also further incorporate state energy consumption matching fields, regional synchronization deviation fields, and data acquisition reliability fields to form a multi-dimensional feature space. For ease of implementation, this embodiment uses a two-dimensional Euclidean distance method to calculate the similar distribution deviation field. The similar distribution deviation field is represented as... And calculate according to formula (3):

[0080]

[0081] in, Indicates a field representing deviation from the same distribution; This field represents the energy consumption per unit time period in the current device monitoring window; This field represents the window fluctuation of the current device monitoring window; This represents the center value of the energy consumption field per unit time period within a similar homomorphic historical window; This indicates the center value of the window fluctuation field in a similar homomorphic history window; The standardized scale representing the energy consumption field per unit time period within a similar homomorphic historical window; This represents the standardized scale of the window fluctuation field within a homomorphic historical window of the same type.

[0082] For example, in a similar homomorphic historical window, the center value of the energy consumption per unit time period field is 0.62 kWh / min, the center value of the window fluctuation field is 0.030, the standardized scale of the energy consumption per unit time period field is 0.10, and the standardized scale of the window fluctuation field is 0.020. If the energy consumption per unit time period field of the current equipment monitoring window is 0.80 kWh / min, and the window fluctuation field is 0.052, then the similar distribution deviation field is:

[0083]

[0084]

[0085] Therefore, it can be concluded that the current equipment monitoring window deviates from the historical window of the same type.

[0086] The regional synchronization deviation field is determined jointly by multiple monitored devices within the same gateway area. See also Figure 8 Within the same gateway area corresponding to the current device monitoring window, the cloud monitoring platform selects other monitored devices with the same device status code and valid edge acquisition confidence markers as reference devices. Subsequently, it determines the similar distribution deviation fields of the current monitored device and the reference devices relative to their respective similar historical windows. When the current monitored device and at least two reference devices all exhibit the same direction of deviation within the same window number's corresponding time period, the regional synchronization deviation field is set to valid; otherwise, the regional synchronization deviation field is set to invalid. The regional synchronization deviation field is represented as follows: When the regional synchronization deviation field is valid, When the region synchronization deviation field is invalid, A state of deviation from the same direction can refer to a situation where the energy consumption field of each device per unit time period is either higher than the center value of its respective historical window of the same type or lower than the center value of its respective historical window of the same type. In one implementation, if the energy consumption field per unit time period of the currently monitored device and two reference devices are all higher than the corresponding center value by more than 20% within the same window time period, and the deviation field of the same type of distribution is greater than 2.0, then it is determined to be a state of deviation from the same direction.

[0087] The trusted data collection field is generated from the edge data collection trusted data marker. The trusted data collection field is represented as follows: When the edge detection confidence level is marked as valid, When the edge acquisition confidence level is marked as invalid, .

[0088] The abnormal monitoring value of the equipment is generated by the same distribution deviation field, window fluctuation field, status energy consumption matching field, regional synchronization deviation field, and acquisition credibility field in a preset field order. In order to avoid the abnormal data being directly judged as the energy consumption status of the monitored equipment, in one embodiment, the cloud monitoring platform first judges the acquisition credibility field. When the acquisition credibility field is 0, the cloud monitoring platform does not generate the abnormal monitoring value of the equipment, does not generate the abnormal monitoring window, but generates the review and warning information and adds the current equipment monitoring window to the warning and review window group. When the acquisition credibility field is 1, the cloud monitoring platform generates the abnormal monitoring value of the equipment according to formula (4).

[0089] The abnormal monitoring value of the equipment is expressed as: And calculate according to formula (4):

[0090]

[0091] in, Indicates abnormal monitoring values ​​of the equipment; Indicates a field representing deviation from the same distribution; Indicates the window fluctuation field; This field indicates the energy consumption matching status and can take a value of 1 or 0. The field representing regional synchronization deviation takes a value of 1 or 0. The above coefficients are examples of field weights in this embodiment. In practical applications, they can be adjusted according to the device type, device rated power, sampling period, and false alarm tolerance. For example, the weight of the similar distribution deviation field can be set to 30 to 50, the weight of the window fluctuation field can be set to 15 to 30, the weight of the state energy consumption matching field can be set to 10 to 25, and the weight of the regional synchronization deviation field can be set to 5 to 15.

[0092] For example, within a valid acquisition window, if the similar distribution deviation field is 2.11, the window fluctuation field is 0.052, the state energy consumption matching field is 1, and the area synchronization deviation field is 0, then the device anomaly monitoring value is:

[0093]

[0094]

[0095] In one implementation, a higher score for an anomaly monitoring value indicates a more severe anomaly. Specifically, a corresponding warning trigger baseline can be pre-set based on the distribution range of monitoring values ​​under historical normal conditions of the monitored equipment. In one implementation, the continuous warning level is set to 70, and the sudden change warning level is set to 90. If multiple consecutive monitoring windows corresponding to the same equipment identifier generate anomaly monitoring values ​​reaching the continuous warning level, the continuous window trigger condition is met; if the current monitoring window corresponding to the same equipment identifier generates anomaly monitoring values ​​reaching the sudden change warning level, and the regional synchronization deviation field of the current monitoring window is invalid, the sudden change window trigger condition is met. This judgment avoids directly identifying regional disturbances as monitoring anomalies of a single device in regional synchronization deviation scenarios.

[0096] When a trusted field is invalid, the cloud monitoring platform generates a review warning and adds the current device monitoring window to the warning review window group. When a trusted field is valid and the status energy consumption matching field is 0, the cloud monitoring platform generates a review warning. When a trusted field is valid and the similar distribution deviation field and window fluctuation field meet the warning trigger conditions, the cloud monitoring platform generates a device anomaly warning.

[0097] See Figure 9 The device monitoring window starts from the newly encapsulated state of the IoT gateway. After edge acquisition credibility verification, it enters either a valid edge acquisition credibility state or an invalid edge acquisition credibility state. For device monitoring windows with valid edge acquisition credibility, the cloud monitoring platform continues to perform comparison with similar historical windows, generation of energy consumption monitoring feature vectors, and calculation of abnormal device monitoring values. If no warning is triggered, the device monitoring window is marked as a normal window and can participate in the selection of similar historical windows and the update of the current threshold version. If an abnormal device warning is triggered, the device monitoring window further enters the warning review window group and is marked as a monitoring abnormal window or a window to be verified based on the review results. For device monitoring windows with invalid edge acquisition credibility, the cloud monitoring platform directly adds them to the warning review window group, and subsequently determines whether to write them into the sample table to be verified based on the review results.

[0098] The early warning review window group includes multiple consecutively received review device monitoring windows following the current device monitoring window. See also... Figure 7 After generating a review alert on the cloud monitoring platform, the platform sends a review sampling task to the corresponding IoT gateway. The review sampling task carries the device identifier, window number, sampling period, number of review windows, and terminal parameter version number. The IoT gateway receives the energy consumption monitoring data of the review devices returned by the edge energy consumption acquisition terminal according to the review sampling task, and encapsulates this data into review device monitoring windows. The cloud monitoring platform then assigns these review device monitoring windows to the corresponding alert review window group.

[0099] In one implementation, there are three verification windows, and the sampling period for the verification sampling task is half of the original sampling period. For example, if the original sampling period is 10 seconds, the sampling period in the verification sampling task is 5 seconds. The cloud monitoring platform performs window number consistency verification, terminal parameter version number consistency verification, data collection timestamp increment verification, registration terminal quantity consistency verification, and status energy consumption matching verification on multiple verification device monitoring windows. If any of the following occurs in the verification device monitoring window: window number and window receipt number are inconsistent, terminal parameter version number is inconsistent, data collection timestamp is not incrementing, or registration terminal quantity is inconsistent with actual reported terminal quantity, then the current device monitoring window is marked as a window to be verified. If all the above data collection link verifications pass, and the verification device monitoring window continues to meet the device anomaly warning conditions, then the current device monitoring window is marked as a monitoring anomaly window.

[0100] When the current device monitoring window is marked as a window to be verified, the cloud monitoring platform writes the current device monitoring window, the corresponding early warning review window group, and the triggered verification items into the sample table to be verified. Device monitoring windows in the sample table to be verified are not included in the selection of similar historical windows, nor are they included in the update of the current threshold version. When the current device monitoring window is marked as a monitoring anomaly window, the cloud monitoring platform writes the current device monitoring window, the corresponding energy consumption monitoring feature vector, the device anomaly monitoring value, and the device anomaly early warning information into the monitoring anomaly sample table. The monitoring anomaly sample table is used for early warning record retention and subsequent review statistics, and is not used as a benchmark for directly updating samples in normal historical monitoring.

[0101] Table 2 shows an example of a cloud-based energy consumption monitoring feature vector database table. This table illustrates the process by which a big data analytics engine stores data in fields and determines anomaly alerts for device monitoring windows.

[0102] Table 2 Window Monitoring Data Table

[0103] G01-M003-B1024-S0001 Peak hours 13:00-15:00 0.051 1.2 invalid efficient 58.4 Normal window G01-M003-B1025-S0002 Peak hours 13:00-15:00 0.89 5.7 efficient efficient 260.3 Window to be verified G01-M003-B1026-S0003 Peak hours 13:00-15:00 1.12 8.4 invalid efficient 374 Monitoring anomaly window G01-M003-B1027-S0004 Peak hours 13:00-15:00 0.5 4.1 invalid invalid No generation Window to be verified

[0104] See Figure 6The current threshold version is updated using a threshold update sample set. The cloud monitoring platform selects device monitoring windows from the IoT energy consumption big data pool that are marked as valid for edge acquisition credibility, valid for data integrity, and neither marked as windows awaiting verification nor as monitoring anomalies. It then forms a threshold update sample set based on device type, device operating status code, runtime segment label, and gateway region identifier, and generates a new threshold version based on this sample set. The new threshold version is bound to the corresponding device type, device operating status code, runtime segment label, and gateway region identifier, and serves as the current threshold version for subsequent use by the corresponding device monitoring window. The current threshold version can be updated daily or when the threshold update sample set reaches a preset number. For example, when the number of valid samples under the same device type, same device operating status code, same runtime segment label, and same gateway region identifier reaches 500, the cloud monitoring platform generates a new threshold version.

[0105] In one implementation, the cloud monitoring platform sends a monitoring parameter package to the IoT gateway. The monitoring parameter package includes the sampling period, window length, device operating status code table, data field format, and current threshold version. The IoT gateway forwards the monitoring parameter package to the corresponding edge energy consumption acquisition terminal and receives parameter confirmation information returned by the edge energy consumption acquisition terminal. When the IoT gateway does not receive parameter confirmation information, or the terminal parameter version number in the parameter confirmation information is inconsistent with the current threshold version, the IoT gateway writes a parameter unconfirmed flag to the corresponding device monitoring window and uses this flag as the basis for determining the consistency of the terminal parameter version number. In this way, the cloud monitoring platform, the IoT gateway, and the edge energy consumption acquisition terminal can maintain consistency in the sampling period, window length, data field format, and current threshold version, avoiding deviations in the calculation of energy consumption monitoring feature vectors due to inconsistent terminal parameter versions.

[0106] In this embodiment, the IoT energy consumption big data pool can be implemented using a relational database, time-series database, distributed columnar database, or a combination of object storage and index tables. Device monitoring windows can be indexed according to device identifier, window number, gateway area identifier, device operating status code, runtime segment label, and current threshold version. The big data analysis engine can periodically update similar historical windows using batch processing, or trigger streaming computation upon receiving the current device monitoring window. Regardless of the data storage and computing framework used, it is essential to ensure that edge acquisition credibility markers, data integrity markers, window verification markers, and monitoring anomaly window markers can participate in the selection of similar historical windows and the update of the current threshold version.

[0107] To verify the technical effectiveness of this embodiment, a similar fixed-threshold monitoring and early warning method in the background technology was used as a comparative example, and the device anomaly early warning method based on IoT energy consumption big data analysis in this embodiment was used as the experimental group for comparative testing. The test scenario consisted of 3 gateway areas and 120 monitored devices in an industrial park, with a sampling period of 10 seconds, a window length of 6 sampling points, and a continuous running time of 7 days. During the test, real device energy consumption anomalies, underlying link anomalies, and regional power grid fluctuations were recorded, and the system alarm results were compared with the results of manual review. The comparison results are shown in Table 3.

[0108] Table 3 Comparison of Test Results

[0109] Fixed threshold monitoring and early warning method 100000 50 120 30 185 73.00% 10.00% The method in this embodiment 100000 50 120 30 52 3.80% 0.00%

[0110] As shown in Table 3, under the same conditions of the number of test windows, the number of actual device energy consumption anomalies, the number of underlying link anomalies, and the number of regional power grid fluctuations, the fixed threshold monitoring and early warning method is prone to misinterpreting energy consumption deviations caused by underlying link anomalies and regional power grid fluctuations as device anomaly warnings, resulting in a high false alarm rate. The method in this embodiment uses edge acquisition credibility marking, homogeneous historical windows, regional synchronization deviation fields, early warning verification window groups, and a mechanism for excluding and updating windows to be verified to divert and process acquisition link anomalies, regional disturbances, and device energy consumption status anomalies, thereby reducing the impact of abnormal acquisition data on historical monitoring benchmarks and device anomaly warning judgments. The test results demonstrate that this embodiment can improve the reliability of device anomaly warnings in IoT device status detection and monitoring scenarios, and enables the big data analysis process to be based on device monitoring windows that have undergone time alignment and credibility verification.

[0111] See Figures 1 to 10 This embodiment enables data uploaded by multiple edge energy consumption acquisition terminals to enter the cloud monitoring platform under a unified time reference through aligned batch generation and device monitoring window encapsulation on the IoT gateway side. Edge acquisition credibility marking and data integrity marking allow acquisition link anomalies to be identified before big data analysis. Homogeneous historical windows and energy consumption monitoring feature vectors allow the current device monitoring window to be compared with historical device monitoring windows of the same device type, operating status code, operating time segment label, gateway area identifier, and current threshold version. Early warning verification window groups, a sample table to be verified, and a monitoring anomaly sample table ensure that abnormal acquisition data and monitoring anomaly data have different lifecycles. Current threshold version updates and monitoring parameter package distribution maintain parameter consistency between the cloud monitoring platform, IoT gateway, and edge energy consumption acquisition terminals. All of the above processes pertain to device energy consumption status detection, monitoring, and early warning processing in IoT scenarios, and are suitable for device anomaly early warning in IoT energy consumption big data analysis scenarios.

[0112] It should be noted that the embodiments of the present invention have better implementability and are not intended to limit the present invention in any way. Any person skilled in the art may use the above-disclosed technical content to change or modify it into equivalent effective embodiments. However, any modifications or equivalent changes and modifications made to the above embodiments based on the technical essence of the present invention without departing from the content of the technical solution of the present invention shall still fall within the scope of the technical solution of the present invention.

Claims

1. A method for early warning of equipment anomalies based on IoT energy consumption big data analysis, characterized in that, The method, applied to an IoT monitoring network including edge power consumption acquisition terminals, IoT gateways, and cloud monitoring platforms, comprises: The edge energy consumption acquisition terminal collects the device energy consumption monitoring data of the monitored device. The device energy consumption monitoring data includes active power, current, voltage and cumulative power consumption. The device energy consumption monitoring data is further supplemented with device identifier, sampling sequence number, acquisition timestamp, device operating status code, terminal heartbeat flag, terminal parameter version number and message retransmission record. The IoT gateway forms an aligned batch of device energy consumption monitoring data uploaded by multiple edge energy consumption acquisition terminals according to the gateway clock. The continuous aligned batches are encapsulated into a device monitoring window and written with window number, gateway area identifier, data integrity mark, current threshold version and edge acquisition confidence mark. The edge acquisition credibility marker is determined by the acquisition timestamp increment status, message retransmission record, terminal heartbeat marker, terminal parameter version number consistency, and the consistency between the number of registered terminals and the actual number of reported terminals in the same gateway area. The cloud monitoring platform matches the device type based on the device identifier, generates a runtime segment tag based on the collection timestamp, and writes the device type and runtime segment tag into the corresponding device monitoring window; The cloud monitoring platform marks the edge acquisition credibility as a valid device monitoring window and writes it into the IoT energy consumption big data pool; The big data analysis engine of the cloud monitoring platform selects similar and homogeneous historical windows, and generates an energy consumption monitoring feature vector based on the current device monitoring window and the similar and homogeneous historical windows. The energy consumption monitoring feature vector includes a unit time period energy consumption field, a window fluctuation field, a state energy consumption matching field, a similar distribution deviation field, a regional synchronization deviation field, and a collection reliability field. Based on the energy consumption monitoring feature vector, an abnormal equipment monitoring value is generated. When the abnormal equipment monitoring value meets the early warning triggering condition, an abnormal equipment early warning information is generated and an early warning review window group is established. According to the warning review window group, the corresponding device monitoring window is marked as a window to be verified or a monitoring anomaly window, and the window to be verified does not participate in the selection of the same type of homogeneous historical window and the update of the current threshold version.

2. The equipment anomaly early warning method according to claim 1, characterized in that, The edge energy consumption acquisition terminal generates an energy metering frame and a status sampling frame under the same sampling sequence number. The energy metering frame includes active power, current, voltage, and cumulative energy consumption. The status sampling frame includes the device operating status code, terminal heartbeat flag, terminal parameter version number, and message retransmission record. When an energy metering frame or a status sampling frame is missing under the same sampling sequence number, the data integrity flag of the corresponding device energy consumption monitoring data is set to invalid.

3. The equipment anomaly early warning method according to claim 2, characterized in that, The IoT gateway forms an alignment batch by: generating a unified sampling time using the gateway clock; grouping energy metering frames and status sampling frames whose collection timestamps fall within the same time interval of the unified sampling time into the same alignment batch; when multiple energy metering frames exist for the same device identifier within the same alignment batch, retaining the energy metering frame with the latest collection timestamp and the same terminal parameter version number; and writing a status energy consumption mismatch flag to the corresponding device monitoring window when the device operating status code under the same sampling sequence number does not match the active power field in the energy metering frame.

4. The equipment anomaly early warning method according to claim 1, characterized in that, The window number consists of the gateway area identifier, device identifier, window start alignment batch number, and gateway generation sequence number; the IoT gateway stores the correspondence between the window number and the device monitoring window in its local cache, and receives the window receipt number after uploading the device monitoring window to the cloud monitoring platform; when the window number and the window receipt number are inconsistent, the cloud monitoring platform adds the corresponding device monitoring window to the early warning review window group.

5. The equipment anomaly early warning method according to claim 1, characterized in that, The homomorphic historical windows are selected in the following way: historical device monitoring windows with the same device type, the same device operating status code, the same operating time tag, the same gateway area identifier, and the same current threshold version as the current device monitoring window are screened from the IoT energy consumption big data pool to form a candidate historical window set; historical device monitoring windows marked as invalid for edge acquisition credibility, invalid for data integrity, or marked as windows to be verified are deleted from the candidate historical window set to obtain the homomorphic historical windows.

6. The equipment anomaly early warning method according to claim 5, characterized in that, When the historical device monitoring windows in the candidate historical window set have a regional synchronization deviation field and are set to valid, the cloud monitoring platform groups them according to the number of continuous windows with the regional synchronization deviation field being valid; a group of historical device monitoring windows whose number of continuous windows reaches the regional synchronization verification condition is marked as regional disturbance windows, and the regional disturbance windows are not treated as homomorphic historical windows of the same type.

7. The equipment anomaly early warning method according to claim 1, characterized in that, The unit time period energy consumption field is generated from the cumulative power consumption change within the current device monitoring window; the window fluctuation field is generated from the active power change relationship corresponding to adjacent sampling numbers within the current device monitoring window; The status energy consumption matching field is generated from the device operating status code and the energy consumption field per unit time period; the same type distribution deviation field is generated from the distribution position of the current device monitoring window relative to the same type of historical window; the acquisition credibility field is generated from the edge acquisition credibility marker.

8. The equipment anomaly early warning method according to claim 7, characterized in that, The regional synchronization deviation field is generated in the following way: within the same gateway area corresponding to the current device monitoring window, other monitored devices with the same device running status code and whose edge acquisition confidence mark is valid are selected as reference devices; Determine the similar distribution deviation fields of the current monitored device and the reference device relative to their respective similar homomorphic historical windows; when the current monitored device and at least two reference devices have the same deviation state in the same window number corresponding time period, set the regional synchronous deviation field to valid.

9. The equipment anomaly early warning method according to claim 7, characterized in that, The abnormal monitoring values ​​of the equipment are generated by the same type distribution deviation field, window fluctuation field, status energy consumption matching field, regional synchronization deviation field and collection trust field in the order of preset fields; when the collection trust field is invalid, the cloud monitoring platform does not generate a monitoring abnormal window, but generates a review warning information and adds the current equipment monitoring window to the warning review window group; When the collected trusted field is valid and the status energy consumption matching field is mismatched, the cloud monitoring platform generates a review warning message; when the collected trusted field is valid and the similar distribution deviation field and window fluctuation field meet the warning triggering conditions, the cloud monitoring platform generates a device abnormality warning message.

10. The equipment anomaly early warning method according to claim 9, characterized in that, The warning triggering conditions include continuous window triggering conditions and sudden window triggering conditions; the continuous window triggering condition is that multiple consecutive device monitoring windows corresponding to the same device identifier generate abnormal device monitoring values ​​that reach the continuous warning level. The mutation window trigger condition is that the current device monitoring window corresponding to the same device identifier generates a device abnormal monitoring value that reaches the mutation warning level, and the regional synchronization deviation field of the current device monitoring window is invalid.

Images