Cloud edge collaboration-based power grid cloud management platform internet of things data optimization access method

Abstract

The application discloses a power grid cloud end management platform Internet of Things data optimization access method based on cloud edge cooperation, and the power grid cloud end management platform Internet of Things data optimization access method based on cloud edge cooperation. Through the intermediate management between the edge node intervention terminal and the cloud end management platform, the cloud end management platform is compiled into an edge rule package and is distributed to the adaptive edge node. The edge node is internally provided with a lightweight rule engine. The conventional data is reported by changing, periodically aggregated and compressed. Local real-time alarm is judged and reported with the highest priority. Meanwhile, the layered cache and breakpoint resume mechanism are adopted to guarantee the data integrity during network interruption, reduce the network transmission amount and cloud end processing load, realize the rapid response of faults, and improve the efficiency, reliability and business adaptability of power grid data access.

Description

Technical Field

[0001] This invention relates to the field of communication technology, and more specifically, to a method for optimizing IoT data access in a power grid cloud management platform based on cloud-edge collaboration. Background Technology

[0002] The Internet of Things (IoT) is a network technology system that connects various physical entities to the internet through information sensing devices such as RFID, sensors, and GPS, according to agreed-upon protocols, to exchange and communicate information, thereby achieving intelligent identification, positioning, tracking, monitoring, and management. In the process of smart grid construction, IoT technology has been widely applied in grid production and operation. Various monitoring terminals are extensively installed at grid production sites such as substations, distribution rooms, transmission line towers, and smart distribution areas to collect real-time data on equipment operating status, environmental parameters, electricity consumption, and other data. With the reconstruction and new construction of existing grids, the number of IoT terminals in the grid continues to grow, and the requirements for data acquisition accuracy are constantly increasing, making traditional grid data processing and access architectures increasingly unable to adapt to the growing scale of data generated by the grid.

[0003] In the traditional power grid IoT data processing architecture, all raw data collected by terminal devices are directly uploaded to the cloud management platform for centralized processing. This massive flow of raw data places immense pressure on the power grid communication network, especially in remote substations and mountainous distribution centers with relatively weak network infrastructure. This can easily lead to network bandwidth congestion, significantly increasing data transmission latency and potentially causing the loss of critical operational data, thus failing to guarantee the real-time and reliable transmission of power grid operational status data.

[0004] The cloud management platform needs to handle raw data processing tasks from all terminal devices across the network, including a large number of repetitive, low-value-density tasks such as data cleaning, format conversion, and basic statistics. This results in a large consumption of cloud computing and storage resources, a continuous increase in the processing load of the cloud center, and low overall resource utilization efficiency of the system. Consequently, the construction party continues to invest high costs in expanding and maintaining the cloud system, increasing the construction and operation costs of the power grid Internet of Things system.

[0005] Furthermore, power grid production and operation place extremely high demands on the real-time performance of data processing, requiring timely detection and rapid handling of equipment failures. However, in traditional centralized processing architectures, data must undergo long-distance network transmission and then be queued for processing in the cloud. This results in significant delays in the generation and dissemination of critical alarm information, preventing maintenance personnel from immediately grasping the abnormal status of equipment and hindering timely warnings and rapid handling of potential faults, thus posing risks to the safe operation of the power grid. Summary of the Invention

[0006] To address the data congestion issue caused by the centralized transmission of existing power grid IoT data to the cloud management platform, this invention provides a cloud-edge collaborative method for optimizing IoT data access in a power grid cloud management platform. This invention utilizes edge nodes to act as intermediaries between the terminal and the cloud management platform, enabling intermediate management. The cloud management platform compiles rules into edge rule packages and distributes them to suitable edge nodes. Each edge node has a built-in lightweight rule engine that performs change reporting, periodic aggregation and compression of regular data, and real-time local alarm detection with the highest priority. Simultaneously, it employs layered caching and breakpoint resumption mechanisms to ensure data integrity during network interruptions, reducing network transmission volume and cloud processing load, enabling rapid fault response, and improving the efficiency, reliability, and business adaptability of power grid data access.

[0007] The technical solution of this invention is as follows: Based on cloud-edge collaboration, a method for optimizing IoT data access in a power grid cloud management platform is proposed. A cloud management platform is established, which provides a visual low-code business rule customization environment. The visual low-code business rule customization environment adopts a drag-and-drop component design and has a built-in rule template library and parameter configuration panel. After being compiled and encapsulated by the cloud management platform, the data access strategy forms an edge rule package; The cloud management platform maintains the edge node registration database, which uses a distributed database to store and record detailed information about the edge nodes. The cloud management platform maintains real-time communication with all edge nodes through a heartbeat mechanism, sending heartbeat packets, receiving status information returned by the edge nodes, and updating the data in the edge node registration database. The cloud management platform distributes edge rule packages to the corresponding edge nodes or edge node groups. The cloud management platform assesses the current load of the edge nodes. When the resource utilization of an edge node exceeds a preset threshold, the cloud management platform migrates some rules to adjacent edge nodes for execution. Edge nodes are set up at the power grid production site. After establishing an encrypted connection with the cloud management platform, the edge node initiates an identity authentication request to the cloud management platform. The identities of both parties are verified through two-way verification based on digital certificates. After successful verification, the edge node registers with the cloud management platform and reports its own hardware resource capacity, firmware version, and a detailed list of all connected terminal devices. The cloud management platform enters the edge node's information into the registration database and assigns a unique node identifier to the edge node. Edge nodes initiate rule query requests to the cloud management platform, or receive the latest edge rule packages proactively pushed by the cloud management platform; An edge node is equipped with a rule engine. After receiving an edge rule package, the edge node uses a pre-stored cloud public key to verify the digital signature of the rule package, calculates the hash value of the edge rule package to verify its integrity, and after the edge rule package is verified, the rule engine loads and parses the contents of the edge rule package. The rule engine automatically identifies different types of rules in the edge rule package, classifies and stores them in the corresponding execution modules, and converts them into an executable task instruction set. After loading and classifying all rules, the rule engine initializes the local runtime environment according to the rule configuration. The data acquisition scheduler creates corresponding timed tasks according to the tasks in the sampling task queue and reads raw data from various connected IoT terminal devices at a specified frequency and precision. At the same time, the rule engine initializes the local memory data structure and temporary database according to the preprocessing logic defined in the edge rule package, creates a corresponding circular buffer for each terminal device, and creates a time-series database instance. Raw data from terminal devices enters the data acquisition module of the edge node. The data acquisition module performs format conversion and preliminary cleaning on the raw data. The data after preliminary cleaning enters the dynamic control and preprocessing process. For regular operational data, the rule engine applies a change reporting strategy or a periodic aggregation strategy for processing. When the event trigger in the rule engine detects that the data meets the preset alarm conditions, the processing flow switches to the high-speed channel, and the event trigger interrupts the current regular processing pipeline to process the alarm event. Before being sent to the cloud management platform, the edge nodes standardize and encapsulate the processed data, generating a standard envelope for each data packet to be sent. The envelope encapsulates a structured business data body and contains several key metadata fields. Edge nodes transmit encapsulated data packets to the cloud management platform through encrypted communication channels. The communication management module inside the edge node schedules the transmission queue and adjusts the transmission rate of data packets with different priorities based on the priority of the data packets and the real-time status of the current network. After receiving the data packet, the cloud management platform's access service uses the edge node's public key to verify the digital signature of the data packet, uses a symmetric key to decrypt the data body, parses the metadata in the data packet envelope, and routes the data packet to different downstream processing units.

[0008] The aforementioned IoT data optimization access method for the power grid cloud management platform based on cloud-edge collaboration adopts a hierarchical caching architecture for the local caching of edge nodes. During the processing, the edge nodes divide the data to be uploaded into multiple priority queues according to business importance. When a network connection interruption is detected, all data to be uploaded is stored in local non-volatile persistent storage in order of priority. The caching system has a capacity management mechanism. When the cache utilization rate exceeds the set value, the earliest data in the low priority queue is automatically deleted. Once the network is restored, the edge nodes resend the cached data to the cloud management platform in order of priority from high to low.

[0009] The above-mentioned method for optimizing IoT data access in a power grid cloud management platform based on cloud-edge collaboration involves setting up a rule receiving module at the edge node to receive edge rule packets sent by the cloud management platform. The edge node is configured with a security verification module, an integrity verification module, a rule loading module, a rule parsing module, a rule classification and storage module, and a runtime environment initialization module. The security verification module uses a pre-stored cloud public key to verify the digital signature of the edge rule package. The integrity verification module calculates the hash value of the edge rule package to verify its integrity. After successful verification, the rule loading module loads the content of the edge rule package, and the rule parsing module parses the JSON structure of the edge rule package. The JSON structure within the edge rule package contains a rule array. Each rule object in the array contains a rule type field. The rule parsing module iterates through each rule object in the rule array, reads the value of the ruleType field, and then the rule classification and storage module maps the content of the rule object to the corresponding execution module for storage based on the value of the ruleType field. The runtime environment initialization module initializes the local runtime environment based on the loaded rule configuration.

[0010] The above-mentioned method for optimizing IoT data access in a power grid cloud management platform based on cloud-edge collaboration involves setting up a sampling strategy configuration module and a data acquisition scheduler at the edge node. The sampling strategy configuration module configures the corresponding sampling frequency for terminal devices with different security levels. The data acquisition scheduler creates corresponding timed tasks based on the tasks in the sampling task queue and controls the sampling operation to read raw data from various connected IoT terminal devices at a specified frequency and precision through a hardware timer. The edge node is configured with an initialization module, a format conversion module, and a temporary database initialization module. The initialization module initializes the local memory data structure according to the preprocessing logic defined in the rules. The format conversion module receives the raw data stream from the terminal device and converts the raw data from different communication protocols into an internal standard format. The format conversion module sends the converted data to the data filtering component in the rule engine. The data filtering component processes the raw data according to preset thresholds and conditions, and removes data that exceeds the physical range. Then, the processed data is sent to the temporary database initialization module. The temporary database initialization module creates a temporary database and a corresponding circular buffer for each terminal device. The circular buffer stores the raw sampling data and intermediate calculation results for the most recent period. At the same time, the temporary database initialization module creates a time-series database instance, which stores long-term retained aggregate data and alarm data.

[0011] The above-mentioned IoT data optimization access method for the power grid cloud management platform based on cloud-edge collaboration includes an edge node setting change reporting execution module, which processes the routine operating data after preliminary cleaning, and maintains a record of the last successfully reported data point for each monitoring indicator of each terminal device. The change reporting execution module obtains the currently collected data and compares the current data with the data point that was successfully reported last time. If the change between the two is less than the dead zone threshold set in the rule, only the latest data value in the local cache is updated. If the change between the two is greater than or equal to the dead zone threshold set in the rule, the upload task is triggered. Dead zone thresholds include fixed thresholds and relative thresholds.

[0012] The aforementioned method for optimizing IoT data access in a power grid cloud management platform based on cloud-edge collaboration involves setting up a periodic aggregation execution module at the edge node. This module maintains a sliding or fixed time window within the edge node. Within the time window, real-time incremental calculations are performed on the high-speed collected raw data. When the time window expires, the statistical results within the window are extracted. These results include the average, maximum, minimum, number of samples, median, standard deviation, and percentiles. The statistical results are then encapsulated into a data packet and added to the queue to be uploaded.

[0013] The above-mentioned method for optimizing IoT data access in the power grid cloud management platform based on cloud-edge collaboration involves setting up a hierarchical caching architecture at the edge nodes, dividing the data to be uploaded into multiple priority queues. The high-priority queue stores alarm event snapshot data, the medium-priority queue stores regular aggregated data, and the low-priority queue stores node status heartbeat packets. Edge nodes use solid-state drives (SSDs) as storage media for non-volatile persistent storage modules. The cache capacity management module of the edge node monitors the cache utilization rate in real time. When the cache utilization rate exceeds the set value, the earliest data stored in the low priority queue is deleted. The network status detection module of the edge node continuously monitors the network connection status with the cloud management platform. When a network connection interruption is detected, a local caching process is triggered. All data to be uploaded is stored in local non-volatile persistent storage according to priority. When the network status detection module detects that the network connection is restored, a breakpoint resume process is triggered. The edge node sends the cached data to the cloud management platform in order of priority from high to low.

[0014] The above-mentioned method for optimizing IoT data access in a power grid cloud management platform based on cloud-edge collaboration involves setting up a data encapsulation module at the edge node. The data encapsulation module processes the data to be sent after processing by the edge node and generates a standard envelope for each data packet to be sent. The envelope contains a unique identifier for the data packet, an edge node identifier, a timestamp sequence, a data packet type label, and a data model version number field. The timestamp uses UTC time and includes data acquisition time, edge processing completion time, and data packet transmission time. The data encapsulation module encapsulates a structured business data body inside the envelope. For regular aggregated data, the data body includes the start time and end time of the statistical time window, the name, value, unit, and data quality code information of the monitoring indicator. For alarm event snapshots, the data body includes the alarm ID, alarm level, alarm type, alarm occurrence time, alarm description, unique identifier of the associated device, trigger value and threshold of the alarm condition, and the time range and specific data content of the additional original data fragment. Edge nodes are equipped with an encrypted communication module and a communication scheduling module. The encrypted communication module sends data packets through a TLS-encrypted communication channel. The communication scheduling module schedules the transmission queue and adjusts the transmission rate of data packets of different priorities according to the priority of the data packets and the real-time status of the current network.

[0015] The above-mentioned method for optimizing IoT data access in a power grid cloud management platform based on cloud-edge collaboration involves setting up a distributed data access service cluster in the cloud management platform. The access service cluster adopts a microservice architecture and includes a signature verification module, a decryption module, a metadata parsing module, a data routing module, and a data fusion module. The access service cluster receives data packets sent by edge nodes. The signature verification module uses the public key of the edge node to verify the digital signature of the data packet. The decryption module uses the symmetric key to decrypt the data body of the data packet. The metadata parsing module parses the metadata in the data packet envelope. The metadata includes the data packet type label and the edge node identifier. The data routing module sends the data packets to different downstream processing units according to the information of the parsed metadata. Data packets with alarm labels are sent to the real-time alarm analysis engine and the power grid dynamic map service. Data packets with regular aggregation labels are sent to the distributed time series database for persistent storage or sent to the data fusion module. The data fusion module receives data packets from different edge nodes, performs secondary aggregation operations on data belonging to the same business entity, and performs correlation analysis operations on data belonging to the same business entity.

[0016] The aforementioned method for optimizing IoT data access in a power grid cloud management platform based on cloud-edge collaboration involves setting up an operation status monitoring module, a parameter adjustment module, and a rule update module on the cloud management platform. The operation status monitoring module continuously acquires overall network data access quality data, rule execution efficiency data, and edge node operation status data. The parameter adjustment module performs the following parameter adjustment operations based on the acquired monitoring data: (1) Regarding data redundancy adjustment, obtain the terminal device change reporting trigger rate data and adjust the dead zone threshold based on the data; (2) Regarding the adjustment of the aggregation period, obtain the alarm occurrence data of the terminal device and the reflection data of the aggregation data, and adjust the length of the aggregation time window according to the data; (3) Regarding the adjustment of sampling frequency, the operating status data of the equipment is obtained, and the sampling frequency is adjusted according to the data; (4) Regarding alarm rule adjustment, obtain false alarm rate and false negative rate data of alarm rules, adjust the threshold of alarm conditions based on the data, or add associated alarm conditions; (5) Regarding edge resource adjustment, obtain the CPU utilization data of edge nodes and send rule migration instructions to adjacent edge nodes based on the data; The rule update module compiles and encapsulates the adjusted rule parameters into an edge rule package, and then sends the updated edge rule package to the corresponding edge nodes for execution.

[0017] According to the above-described solution, the beneficial effects of this invention are as follows: This invention employs a combination of techniques: a change reporting strategy using a built-in rule engine in edge nodes to filter out minor fluctuations in data; a periodic aggregation strategy to perform real-time incremental statistics on high-speed raw data; and a switch to the high-speed channel to interrupt routine processes and prioritize alarm events when an alarm is triggered. This enables traffic control and business priority classification of power grid IoT data at the edge, resolving network congestion caused by massive raw data transmission and ensuring the responsiveness of critical fault information. In traditional centralized architectures, all raw data is directly uploaded, causing significant network bandwidth pressure and delays in processing critical alarm data due to queuing. In this invention, the change reporting strategy triggers uploading only when the data change exceeds a dead zone threshold, filtering out a large amount of meaningless minor fluctuations. The periodic aggregation strategy compresses massive amounts of raw data within a time window into statistical features such as averages and maximum values, thus compressing the data. Meanwhile, the high-speed alarm channel immediately interrupts routine processing upon detecting anomalies, allocating the highest transmission priority to alarm data. A hierarchical processing mechanism has been formed, which prioritizes the transmission of critical data and compresses routine data. Data compression alone cannot guarantee the real-time performance of alarm data. If alarms are transmitted in a priority manner without data compression, the network will still be blocked by massive amounts of routine data. Change reporting alone cannot handle the massive redundancy problem of high-speed data collection. All three must be implemented together to ensure that data does not block bandwidth.

[0018] The edge nodes of this invention adopt a hierarchical caching architecture, industrial-grade non-volatile persistent storage, and a breakpoint resume mechanism, which enables the power grid Internet of Things data to maintain integrity and reliability even in scenarios of network instability or interruption. This solves the problem of data loss caused by network interruption and ensures the continuity and integrity of power grid operation data.

[0019] The distributed edge node registration library in this invention records detailed information such as the unique identifier, hardware configuration, firmware version, connected device list, online status, and resource utilization of all edge nodes, enabling unified management of all network nodes. The two-way authentication mechanism based on digital certificates verifies the legitimacy of both parties' identities when establishing a connection between the edge node and the cloud, preventing unauthorized device access and data tampering. The heartbeat mechanism sends heartbeat packets at fixed intervals to update the online status and operating parameters of nodes in real time, and immediately issues an alarm when a node is detected to be offline or experiencing resource anomalies, thus constructing a secure edge node management system.

[0020] This invention continuously monitors the quality of data access across the entire network, the efficiency of rule execution, and the operational status of edge nodes through a cloud management platform. Based on the monitoring data, it automatically adjusts data access parameters and generates updated edge rule packages for execution. This enables the power grid IoT data access system to possess self-optimization capabilities, allowing it to continuously adapt to ever-changing business needs and operating environments. Traditional power grid IoT data access rules are difficult to adjust once deployed, and cannot be optimized according to changes in equipment operating status, network conditions, and business needs, leading to a gradual decrease in system operating efficiency. In this invention, the cloud management platform continuously collects monitoring data such as change reporting trigger rate, false alarm rate and missed alarm rate, edge node CPU utilization, and data transmission latency. By analyzing this data, it automatically adjusts parameters such as dead zone threshold, aggregation time window, sampling frequency, and alarm conditions, and compiles the adjusted rules into new edge rule packages, which are then sent to the corresponding nodes for execution. For example, when the change reporting trigger rate of a terminal device is too low, the dead zone threshold is automatically reduced to improve data accuracy; when the CPU utilization of an edge node is consistently too high, some rules are automatically migrated to adjacent nodes, enabling the system to always maintain an optimal operating state and reduce network bandwidth consumption and computing resource usage while meeting business needs. Attached Figure Description

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

[0022] Figure 1 This is a schematic diagram of the overall architecture and macroscopic data flow of the cloud management platform and edge nodes of this invention.

[0023] Figure 2 This is a schematic diagram of the functional modules of the cloud management platform.

[0024] Figure 3 This is a schematic diagram of the edge node rule engine and data preprocessing process.

[0025] Figure 4 A schematic diagram illustrating the process of hierarchical caching and transmission for edge nodes.

[0026] Figure 5 A flowchart illustrating the process of cloud data access services and downstream routing. Detailed Implementation

[0027] To make the technical problems to be solved, the technical solutions, and the beneficial effects of the present invention clearer, the present invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present invention and are not intended to limit the present invention.

[0028] A cloud-edge collaborative approach to optimize IoT data access for power grid cloud management platforms, its composition and data flow are as follows: Figure 1 As shown.

[0029] Establish a cloud-based management platform with global control and intelligent scheduling capabilities, such as... Figure 2 As shown, the cloud management platform possesses capabilities for business rule definition, edge node management, data fusion analysis, and continuous system optimization. The cloud management platform provides a visual, low-code business rule customization environment. This environment adopts a drag-and-drop component-based design and includes a built-in rule template library and parameter configuration panel covering the entire power grid IoT scenario. Engineers do not need to write any complex underlying code; they can quickly define differentiated data access strategies for different types, regions, and importance levels of power grid IoT terminal devices simply by graphically dragging and dropping rule components and configuring corresponding parameters.

[0030] The cloud management platform supports online debugging and simulation of rules. Before officially issuing rules, engineers can import historical data to simulate the execution effect of the rules, promptly identify and correct logical loopholes in the rules, and ensure the accuracy and effectiveness of the rules.

[0031] After being compiled and packaged by the cloud management platform, the data access strategy forms a standardized task package that can be independently distributed and directly executed, namely the edge rule package. The customization process of the edge rule package needs to comprehensively consider multiple factors such as the importance of the equipment, the real-time requirements of the business, the resource capabilities of the edge nodes, and the network transmission conditions to achieve precise matching between the strategy and the scenario. Among them, the edge node refers to the industrial-grade hardware device with independent computing, storage and network communication capabilities, which is set up in power grid production sites such as substations, distribution rooms, and smart distribution areas. It is usually composed of high-performance industrial gateways or embedded servers. Unlike traditional ordinary gateways that only have data pass-through functions, the edge node can complete a series of intelligent processing tasks such as data cleaning, filtering, aggregation and alarm judgment locally. It is a key middle layer connecting terminal devices and the cloud management platform, and serves as the first processing gate for field data.

[0032] Regarding the sampling frequency configuration of edge nodes, a tiered sampling strategy is adopted for devices with different safety levels: For oil temperature monitoring terminals installed on key transformers at voltage levels of 220kV and above, since their operating status is directly related to the core safety of the power grid, a high-frequency sampling frequency of 100 milliseconds is required to ensure that millisecond-level temperature change signals can be captured; for current and voltage monitoring terminals on important transmission lines at voltage levels of 110kV, a sampling frequency of 1 second is set to balance the data processing and transmission pressure while meeting the requirements for monitoring the line's operating status; for non-critical monitoring sensors such as ambient temperature and humidity and water immersion in ordinary substations, a sampling frequency of 5 minutes is set, as it is only necessary to grasp the overall trend of environmental changes.

[0033] The real-time calculation logic defined in the edge rules package includes explicit statistical indicators and calculation methods. These include arithmetic averages based on sliding time windows. For example, for critical transformer oil temperature data, a 1-second sliding window is used to calculate the arithmetic average of 10 original sampling points within the window. Smoothing processes are used to eliminate instantaneous data fluctuations caused by electromagnetic interference, sensor noise, and other factors, resulting in a temperature value that truly reflects the equipment's operating status. Trends are also included. Trend refers to the slope of data change per unit time, which is calculated by linear regression of the average of multiple consecutive time windows. For example, calculating the rate of change of oil temperature within 5 seconds can predict the overheating trend of the equipment in advance and issue an early warning signal before a fault occurs.

[0034] The edge nodes run a lightweight rules engine, such as... Figure 3 As shown, the rule engine is used to receive edge rule packages issued by the cloud management platform.

[0035] When the rule engine detects alarm conditions such as abnormal temperature change rate or absolute value exceeding the limit, it will immediately trigger the highest priority alarm data report, along with historical data for a period of time before and after the alarm event. The logic for setting the length of historical data is based on the development pattern of electrical faults in the power grid and the actual needs of fault analysis. Electrical faults are usually characterized by their suddenness and rapid development. Fault symptoms generally appear several seconds to tens of seconds before the fault occurs, while the development process after the fault lasts for tens of seconds to several minutes. Therefore, only by covering the complete data segment before and after the fault can accurate root cause analysis be performed. Specifically, the time length before the alarm needs to be able to capture the abnormal symptoms before the fault occurs, and the time length after the alarm needs to be able to cover the development and evolution process of the fault. At the same time, it needs to be set differently according to the alarm level: Level 1 emergency alarm corresponds to 30 seconds before and 60 seconds after, Level 2 important alarm corresponds to 10 seconds before and 30 seconds after, and Level 3 general alarm corresponds to 5 seconds before and 15 seconds after. The accompanying historical data includes raw high-frequency sampling data for a specified time period before and after the alarm event, intermediate calculated moving averages, rates of change, trend values, and operating data of other equipment associated with the device, such as load current, cooling fan operating status, and on-load tap changer position data accompanying transformer oil temperature alarms. This data supports multi-dimensional root cause analysis in the cloud. By comparing the relationship between oil temperature changes and load current, it can determine whether the oil temperature rise is due to normal temperature rise caused by equipment overload or abnormal heating caused by internal faults. By analyzing the operating status of the cooling fan, it can determine whether the abnormal oil temperature is caused by a cooling system fault, thus providing data support for maintenance personnel to formulate accurate fault handling plans.

[0036] For sensors monitoring the ambient temperature of ordinary power distribution rooms, a reasonable quiescent threshold is set in the edge rules. This threshold is set based on the environmental fluctuation range during normal equipment operation and business monitoring needs. By statistically analyzing the historical ambient temperature data of the power distribution room over the past year, the normal temperature fluctuation range for different seasons is calculated. Typically, the quiescent threshold is set to 1.5 times the maximum value of the normal fluctuation range. For example, the normal temperature fluctuation range of an ordinary power distribution room in summer is 25℃ to 35℃, with a fluctuation amplitude of approximately ±2℃; therefore, the summer quiescent threshold is set to ±3℃. The normal temperature fluctuation range in winter is 10℃ to 20℃, with a fluctuation amplitude of approximately ±1.5℃; therefore, the winter quiescent threshold is set to ±2℃. Only when the change in ambient temperature exceeds this quiescent threshold, or reaches the timed reporting point set by the rules, will the edge node report the current temperature value or aggregated values ​​over a period of time, such as minute-level maximum, minimum, and average values. This effectively filters out normal temperature fluctuations caused by factors such as air conditioning start-up and shutdown, and personnel entry and exit, significantly reducing unnecessary data transmission.

[0037] The edge rule package also defines business-oriented preprocessing logic. For example, the rule specifies that an edge node in a transformer area processes the smart meter data of all users within its jurisdiction in real time. Through a parallel computing engine, it statistically analyzes the overall load curve, peak and valley electricity consumption characteristics, three-phase imbalance, and electricity consumption behavior characteristics of specific important users such as hospitals, government agencies, and large enterprises in real time. These high-value results after aggregation and analysis, rather than the original massive single-household meter reading data, are packaged into standard format data blocks and reported, so that the cloud can directly obtain regional electricity consumption information with clear business semantics.

[0038] The cloud management platform maintains a comprehensive edge node registry, stored in a distributed database. This registry records detailed information about all edge nodes across the network, including their unique identifiers, geographic coordinates, hardware configuration parameters (CPU model, number of cores, memory size, storage capacity), operating system version, firmware version, a list of connected terminal devices (device type, device ID, communication protocol, sampling parameters), online status, real-time resource utilization (CPU utilization, memory utilization, disk utilization), network health status (bandwidth, latency, packet loss rate), and the currently running rule package version. The cloud management platform maintains real-time communication with all edge nodes via a heartbeat mechanism, sending heartbeat packets every 30 seconds and receiving status information from the edge nodes. It dynamically updates the data in the registry and immediately issues an alarm to notify operations personnel when an edge node goes offline or its resource utilization exceeds a preset threshold.

[0039] The cloud management platform uses an intelligent distribution algorithm to accurately distribute pre-defined edge rule packages to corresponding edge nodes or edge node groups based on the geographical location of the edge nodes, the type of connected devices, and the real-time processing capabilities of the nodes. The distribution algorithm comprehensively evaluates the current load of the edge nodes. When the CPU utilization of an edge node exceeds 80% or the memory utilization exceeds 75%, the cloud management platform automatically migrates some non-critical rules to adjacent edge nodes with lower resource utilization for execution, achieving load balancing among edge nodes and ensuring that all rules can run stably and efficiently. Simultaneously, the cloud management platform supports batch distribution and incremental updates of rule packages. When only some parameters in a rule need to be modified, only the changed parameter fragments are distributed instead of the complete rule package, significantly reducing network transmission volume during rule updates and shortening the rule effective time.

[0040] Edge nodes located in substations, distribution rooms, or smart distribution areas are composed of high-performance hardware with industrial-grade protection capabilities. They can adapt to the complex electromagnetic environment, wide temperature range, and harsh climatic conditions of the power grid site and have the ability to operate 24 / 7.

[0041] Once an edge node starts up or establishes a secure TLS encrypted connection with the cloud management platform, it initiates an authentication request to the cloud management platform. This uses a two-way authentication mechanism based on digital certificates to verify the legitimacy of both parties, preventing unauthorized devices from accessing the system. After successful authentication, the edge node registers with the cloud management platform, reporting its hardware resource capacity, firmware version, and a detailed list of all connected terminal devices. The cloud management platform then enters this information into its registration database and assigns it a unique node identifier. Subsequently, the edge node initiates a rule query request to the cloud management platform or receives the latest edge rule package proactively pushed to it. The cloud management platform ensures, based on the edge node's registration information, that the issued rule package matches the node's hardware capabilities and the types of connected devices.

[0042] The rule engine within the edge node employs a modular design, specifically optimized for the limited computing and storage resources of the edge node. The rule engine receives edge rule packages from the cloud management platform and performs rule verification, parsing, and execution. Edge rule packages are described using standard JSON data format, offering good readability and cross-cloud management platform compatibility, facilitating parsing and verification by edge devices from different vendors. Upon receiving the edge rule package, the edge node performs rigorous security and integrity verification. It uses a pre-stored cloud public key to verify the digital signature of the rule package, ensuring it originates from a trusted cloud management platform. Simultaneously, it verifies the integrity of the rule package by calculating its hash value, preventing tampering or corruption during transmission. After successful verification, the rule engine loads and parses the content of the edge rule package, transforming it into an internally executable set of task instructions.

[0043] The rule engine can automatically identify different types of rules within an edge rule package and categorize and store them in the corresponding execution modules. This process is based on predefined rule type identifiers within the rule package. Each edge rule package's JSON structure contains a `rules` array (i.e., a rules array). Each rule object in the array has a required `ruleType` field (i.e., a rule type field). The value of this field explicitly identifies the rule type, including five categories: "sampling," "filter," "aggregation," "alarm," and "communication." When parsing a rule package, the rule engine iterates through each rule object in the `rules` array, reads the value of the `ruleType` field, and maps the specific content of the rule object to the corresponding execution module for storage based on this value. For example, when a rule with "ruleType" set to "sampling" is parsed, the engine extracts parameters such as sampling frequency, sampling precision, sampling channel, and terminal device ID from the rule, encapsulates them into a sampling task object, and stores it in the task queue of the data acquisition scheduler. When a rule with "ruleType" set to "filter" is parsed, parameters such as filtering conditions and filtering thresholds are extracted, encapsulated into a filtering operator, and stored in the filtering stage of the real-time data processing pipeline. When a rule with "ruleType" set to "aggregation" is parsed, parameters such as aggregation time window, aggregation function, and output fields are extracted, encapsulated into an aggregation operator, and stored in the aggregation stage of the real-time data processing pipeline. When a rule with "ruleType" set to "alarm" is parsed, parameters such as alarm conditions, alarm level, trigger action, and data acquisition range are extracted, encapsulated into an alarm rule object, and stored in the rule table of the event trigger. When a rule with "ruleType" set to "communication" is parsed, parameters such as transmission priority, transmission protocol, number of retries, and caching strategy are extracted and stored in the configuration table of the communication management module.

[0044] During the parsing process, the rule engine also performs semantic verification, checking whether the parameters in the rule are valid. For example, whether the sampling frequency is within the supported range of the terminal device, whether the expression of the alarm condition conforms to the syntax specification, and whether the aggregate function is suitable for the corresponding data type. For rules that fail the verification, error logs will be generated and reported to the cloud management platform to ensure that only valid rules can be loaded and executed.

[0045] After loading and classifying all rules, the rule engine initializes its local runtime environment based on the rule configuration. The data acquisition scheduler creates corresponding high-precision timed tasks based on the tasks in the sampling task queue, using hardware timers to ensure sampling time accuracy, with errors controlled within 1 millisecond. Raw data is read from various connected IoT terminal devices at a specified frequency and precision. Simultaneously, the rule engine initializes its local memory data structure and temporary database according to the preprocessing logic defined in the rules. A corresponding circular buffer is created for each terminal device to store recent raw sampling data and intermediate calculation results, and a time-series database instance is created to store long-term aggregated data and alarm data.

[0046] After the edge node rule engine is initialized, it enters the continuous real-time data processing and dynamic control phase. Raw data streams from terminal devices enter the data acquisition module, which converts the raw data into a unified internal standard format, merging data from different communication protocols (such as Modbus, MQTT, and IEC61850) before sending it to the data filtering component in the rule engine. The data filtering component performs preliminary cleaning of the raw data based on preset thresholds and conditions, removing invalid data that clearly exceeds the physical measurement range. For example, the range of an oil temperature sensor is -40℃ to 150℃. If the acquired data is less than -40℃ or greater than 150℃, it is determined to be invalid data caused by sensor malfunction or electromagnetic interference, discarded directly, and an error log is recorded. For status data such as switch quantities, a debouncing algorithm is used. Only when a status change lasts for more than 200 milliseconds is it considered a valid status change, avoiding false alarms caused by transient electromagnetic interference.

[0047] After initial cleaning, the data enters the dynamic control and preprocessing process. For most routine operating data, the rule engine applies a change reporting strategy or a periodic aggregation strategy for intelligent compression. In the change reporting strategy, the rule engine only reports data that has changed significantly. It maintains a record of the last successfully reported data point for each monitoring indicator of each terminal device. The currently collected data is compared with the previously reported data point. If the change is less than the dead zone threshold set in the rule, the current data only updates the latest value in the local cache without triggering an upload task, greatly reducing the transmission of duplicate or slightly fluctuating data over the network. The dead zone threshold supports both fixed and relative threshold settings. For analog quantities with relatively gradual changes, such as temperature and pressure, a fixed threshold is typically used; for analog quantities with large load variations, such as current and power, a relative threshold is typically used, for example, set to 1% of the rated value, to adapt to the operating characteristics of the equipment. The periodic aggregation strategy maintains a sliding or fixed time window within the edge node. The time window refers to a fixed time length used for data aggregation and statistics. Within this time window, the rule engine performs real-time incremental calculations on the high-speed collected raw data. Finally, when the time window arrives, it encapsulates only the statistical results within the window, such as the average, maximum, minimum, number of samples, median, standard deviation, and 95th percentile, into a single data packet. This compresses massive amounts of raw time-series data into information-rich statistical features, resulting in an exponential reduction in data volume. Typically, the compression ratio can reach 10:1 to 100:1.

[0048] When the event trigger in the rules engine detects that the data meets the preset alarm conditions, the processing flow immediately switches to the high-speed channel. The event trigger will instantly interrupt the current regular processing pipeline to handle the alarm event with the highest priority. Specific alarm conditions are mainly divided into three categories: The first category is threshold alarms, including absolute value exceeding limits alarms, such as transformer oil temperature exceeding 85℃ or line current exceeding 1.2 times the rated value; and rate of change exceeding limits alarms, such as oil temperature rising by more than 5℃ within 1 minute or voltage fluctuating by more than 10% of the rated value within 10 seconds. The second category is trend alarms, including continuously rising trend alarms, such as oil temperature showing a monotonous upward trend for 10 consecutive minutes; and continuously falling trend alarms, such as bus voltage showing a monotonous downward trend for 5 consecutive minutes. The third category is correlation alarms, including multi-device correlation anomaly alarms, such as transformer oil temperature rising while the cooling fan stops operating; and status and parameter mismatch alarms, such as the circuit breaker being in the closed state but the line current being zero. Different alarm levels correspond to different historical data collection time periods. Level 1 emergency alarms (serious faults that may cause equipment damage or widespread power outages) collect raw high-frequency data and intermediate calculation results from 30 seconds before to 60 seconds after the alarm occurs. Level 2 important alarms (anomalies that may develop into serious faults if handled promptly) collect relevant data from 10 seconds before to 30 seconds after the alarm occurs. Level 3 general alarms (minor anomalies that do not affect normal equipment operation) collect relevant data from 5 seconds before to 15 seconds after the alarm occurs. Different types of alarm events correspond to different data content. Threshold alarms mainly include raw sampled data and corresponding statistical values ​​to confirm the authenticity of the alarm. Trend alarms mainly include intermediate calculated trend values ​​and historical change curves to analyze the development speed and evolution process of the anomaly. Correlated alarms mainly include operating data from multiple related devices for root cause analysis. The event trigger automatically extracts this data and packages it into a detailed event snapshot data packet. Simultaneously, the edge node's communication management module assigns the highest transmission priority to this data packet, preempting network resources to ensure it can be quickly delivered to the cloud management platform for alarm response.

[0049] like Figure 4As shown, the edge nodes are equipped with local caching and resuming transmission capabilities after disconnection. The local cache adopts a hierarchical caching architecture, dividing the data to be uploaded into three priority queues—high, medium, and low—based on business importance. The high-priority queue stores alarm event snapshot data, the medium-priority queue stores regular aggregated data, and the low-priority queue stores node status heartbeat packets. When a network connection interruption is detected, all data to be uploaded is stored in order of priority in local non-volatile persistent storage, using industrial-grade solid-state drives (SSDs). The caching system has a capacity management mechanism; when the cache utilization exceeds 90%, it automatically deletes the oldest data in the low-priority queue, ensuring that high-priority alarm data is stored first. Once the network is restored, the edge nodes resend the cached data to the cloud management platform in descending order of priority. During transmission, a resuming mechanism is used, recording the transmission status of each data packet to avoid duplicate transmissions and effectively prevent data loss due to network interruption.

[0050] Data processed at the edge nodes undergoes standardized encapsulation before being sent to the cloud management platform. This encapsulation process endows the data with self-describing capabilities, facilitating efficient cloud parsing and routing, while also standardizing data formats across different edge nodes and devices, eliminating data heterogeneity. Each edge node generates a standard envelope for each data packet to be sent. This envelope is analogous to the header of a network communication message, containing all the control information required for data transmission, routing, and processing. The business data body encapsulated within the envelope serves as the message's payload. The envelope contains several key metadata fields: a unique data packet identifier, generated using the UUIDv4 algorithm to ensure global uniqueness, used for data deduplication and end-to-end tracing in the cloud; an edge node identifier, i.e., the unique ID of the edge node in the cloud registration database, used by the cloud to identify the source node of the data; a timestamp sequence, using UTC time, accurate to milliseconds, including data acquisition time, edge processing completion time, and data packet transmission time, ensuring time consistency of data across the entire network; a data packet type label, clearly identifying whether this data packet is regular aggregated data, alarm event snapshot, or node status heartbeat packet; and the data model version number followed, used to ensure compatibility with different versions of rules and data formats, ensuring backward compatibility of the system.

[0051] The envelope contains a processed, structured business data body. For regular aggregated data, the data body is a standardized JSON object containing information such as the start and end times of the statistical time window, the name, value, and unit of the monitoring indicator, and the data quality code. The data quality code is used to identify the validity of the data: 0 indicates normal data, 1 indicates missing data, 2 indicates abnormal data, and 3 indicates that the data has undergone interpolation. For alarm event snapshots, the data body is a complex nested object containing the alarm ID, alarm level, alarm type, alarm occurrence time, detailed alarm description, unique identifier of the associated device, trigger values ​​and thresholds for alarm conditions, and the time range and specific data content of the additional raw data fragments.

[0052] The data encapsulation format prioritizes efficient binary serialization protocols such as Avro or MessagePack, rather than the traditional JSON text format. These binary protocols offer both high compression ratios and fast serialization / deserialization capabilities. MessagePack's serialization speed is more than 10 times faster than JSON, and its compression ratio is 3-5 times higher. Avro supports dynamic data modes, allowing serialization and deserialization without predefined data structures, making it ideal for edge computing scenarios with dynamically changing rules. This further reduces network transmission overhead and improves data transmission efficiency. The encapsulated data packets are transmitted to the cloud management platform via a secure communication channel based on TLS 1.3 encryption. The communication management module intelligently schedules the transmission queue based on the packet priority and the real-time network conditions, dynamically adjusting the transmission rate of packets with different priorities. When network bandwidth is limited, the transmission rate of low-priority data is automatically reduced to ensure that high-priority alarm information is sent out in a timely manner.

[0053] like Figure 5As shown, the cloud management platform has a distributed data access service cluster, which adopts a microservice architecture. Upon receiving a data packet, the access service performs signature verification and decryption operations. It uses the public key of the edge node to verify the digital signature of the data packet, ensuring the legitimacy of the data source. Simultaneously, it uses a symmetric key to decrypt the data body, ensuring confidentiality and integrity during data transmission. Subsequently, the access service parses the metadata in the data packet envelope, especially the data packet type label and edge node identifier. Based on this information, it routes the data packet to different downstream processing units. For example, data packets with alarm tags are directly and rapidly routed to the real-time alarm analysis engine and the power grid dynamic map service, bypassing conventional data processing flows and achieving sub-second alarm presentation, allowing maintenance personnel to grasp fault information immediately. Data packets with regular aggregation tags are routed to a distributed time-series database for persistent storage or further sent to the data fusion module. In the data fusion module, data from different edge nodes but belonging to the same business entity are subjected to secondary aggregation or correlation analysis. For example, monitoring data from all transformers, circuit breakers, and lines within the same substation are merged to generate a comprehensive operational status view of the substation; load data from all distribution areas within the same region are further aggregated to generate a regional-level overall load curve, providing macro-level decision support for power grid dispatch and operation. Various data services on the cloud management platform, including measurement object services, equipment status assessment services, fault diagnosis services, and electricity consumption analysis services, directly utilize these standard data that have already undergone preliminary processing at edge nodes and possess clear business semantics. This eliminates the need for complex data cleaning, conversion, and format unification, resulting in faster service response times and higher resource utilization efficiency.

[0054] The cloud management platform continuously monitors the overall quality of data access across the network, the efficiency of rule execution, and the operational status of edge nodes. If it finds that the aggregated data uploaded by a certain edge node can fully meet business needs and there are few alarm triggers for 30 consecutive days, its rules will be further optimized, the dead zone threshold will be relaxed, or the aggregation time window will be extended to save more network bandwidth and edge computing resources. Conversely, if a certain area experiences frequent failures, more refined data analysis will be used to locate the cause of the failure, and the rules may be adjusted to increase the data sampling frequency of edge nodes in that area or extend the historical data recording duration of alarm events. Specifically, the system's continuous optimization rules and corresponding adjustment actions mainly include the following aspects: First, data redundancy optimization. When the change reporting trigger rate of a certain terminal device is less than 5% for 7 consecutive days, it indicates that the current dead zone threshold setting is too loose and there is data redundancy, so the dead zone threshold should be appropriately reduced. When the change reporting trigger rate is higher than 30%, it indicates that the dead zone threshold setting is too tight, resulting in a large amount of unnecessary data uploads, so the dead zone threshold should be appropriately relaxed. Second, the aggregation cycle is optimized. When the aggregated data of a terminal device can fully reflect the device's operating status and there are no alarms for 30 consecutive days, the aggregation time window is extended from 1 minute to 5 minutes. When a region experiences frequent faults, more refined time-granular data is used, and the aggregation time window is shortened from 5 minutes to 1 minute. Third, the sampling frequency is optimized. When a critical device operates stably and there are no anomalies for 30 consecutive days, the sampling frequency is reduced from 100 milliseconds to 500 milliseconds. When a device experiences frequent minor anomalies, more detailed anomaly characteristics are captured, and the sampling frequency is increased from 1 second to 500 milliseconds. Fourth, alarm rules are optimized. When the false alarm rate of an alarm rule is higher than 10%, the threshold of the alarm condition is adjusted or associated alarm conditions are added to reduce the false alarm rate. When the false negative rate of an alarm rule is higher than 5%, the threshold of the alarm condition is appropriately relaxed to improve the sensitivity of the alarm. Fifth, edge node resource optimization: when the CPU utilization of an edge node remains above 80% for more than 24 hours, some non-critical rules are migrated to adjacent edge nodes with CPU utilization below 30%; when the CPU utilization of an edge node remains below 20% for more than 7 days, some rules from adjacent edge nodes are migrated to that node, improving overall resource utilization. Through these refined optimizations, the system can always maintain optimal operating conditions, minimizing network bandwidth consumption, computing resource usage, and system operation and maintenance costs while meeting the needs of power grid operations.

[0055] The above description is merely a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A method for optimizing IoT data access in a power grid cloud management platform based on cloud-edge collaboration, characterized in that: Establish a cloud management platform that provides a visual low-code business rule customization environment. The visual low-code business rule customization environment adopts a drag-and-drop component design and has a built-in rule template library and parameter configuration panel. After being compiled and encapsulated by the cloud management platform, the data access strategy forms an edge rule package; The cloud management platform maintains the edge node registration database, which uses a distributed database to store and record detailed information about the edge nodes. The cloud management platform maintains real-time communication with all edge nodes through a heartbeat mechanism, sending heartbeat packets, receiving status information returned by the edge nodes, and updating the data in the edge node registration database. The cloud management platform distributes edge rule packages to the corresponding edge nodes or edge node groups. The cloud management platform assesses the current load of the edge nodes. When the resource utilization of an edge node exceeds a preset threshold, the cloud management platform migrates some rules to adjacent edge nodes for execution. Edge nodes are set up at the power grid production site. After establishing an encrypted connection with the cloud management platform, the edge node initiates an identity authentication request to the cloud management platform. The identities of both parties are verified through two-way verification based on digital certificates. After successful verification, the edge node registers with the cloud management platform and reports its own hardware resource capacity, firmware version, and a detailed list of all connected terminal devices. The cloud management platform enters the edge node's information into the registration database and assigns a unique node identifier to the edge node. Edge nodes initiate rule query requests to the cloud management platform, or receive the latest edge rule packages proactively pushed by the cloud management platform; An edge node is equipped with a rule engine. After receiving an edge rule package, the edge node uses a pre-stored cloud public key to verify the digital signature of the rule package, calculates the hash value of the edge rule package to verify its integrity, and after the edge rule package is verified, the rule engine loads and parses the contents of the edge rule package. The rule engine automatically identifies different types of rules in the edge rule package, classifies and stores them in the corresponding execution modules, and converts them into an executable task instruction set. After loading and classifying all rules, the rule engine initializes the local runtime environment according to the rule configuration. The data acquisition scheduler creates corresponding timed tasks according to the tasks in the sampling task queue and reads raw data from various connected IoT terminal devices at a specified frequency and precision. At the same time, the rule engine initializes the local memory data structure and temporary database according to the preprocessing logic defined in the edge rule package, creates a corresponding circular buffer for each terminal device, and creates a time-series database instance. Raw data from terminal devices enters the data acquisition module of the edge node. The data acquisition module performs format conversion and preliminary cleaning on the raw data. The data after preliminary cleaning enters the dynamic control and preprocessing process. For regular operational data, the rule engine applies a change reporting strategy or a periodic aggregation strategy for processing. When the event trigger in the rule engine detects that the data meets the preset alarm conditions, the processing flow switches to the high-speed channel, and the event trigger interrupts the current regular processing pipeline to process the alarm event. Before being sent to the cloud management platform, the edge nodes standardize and encapsulate the processed data, generating a standard envelope for each data packet to be sent. The envelope encapsulates a structured business data body and contains several key metadata fields. Edge nodes transmit encapsulated data packets to the cloud management platform through encrypted communication channels. The communication management module inside the edge node schedules the transmission queue and adjusts the transmission rate of data packets with different priorities based on the priority of the data packets and the real-time status of the current network. After receiving the data packet, the cloud management platform's access service uses the edge node's public key to verify the digital signature of the data packet, uses a symmetric key to decrypt the data body, parses the metadata in the data packet envelope, and routes the data packet to different downstream processing units.

2. The method for optimizing IoT data access in a power grid cloud management platform based on cloud-edge collaboration as described in claim 1, characterized in that, The edge node's local cache adopts a hierarchical caching architecture. During processing, the edge node divides the data to be uploaded into multiple priority queues according to business importance. When a network connection interruption is detected, all data to be uploaded is stored in local non-volatile persistent storage in priority order. The caching system has a capacity management mechanism. When the cache utilization exceeds the set value, the oldest data in the low priority queue is automatically deleted. Once the network is restored, the edge node resends the cached data to the cloud management platform in order of priority from high to low.

3. The method for optimizing IoT data access in a power grid cloud management platform based on cloud-edge collaboration as described in claim 1, characterized in that, The edge node rule receiving module receives edge rule packets sent by the cloud management platform. The edge node is configured with a security verification module, an integrity verification module, a rule loading module, a rule parsing module, a rule classification and storage module, and a runtime environment initialization module. The security verification module uses a pre-stored cloud public key to verify the digital signature of the edge rule package. The integrity verification module calculates the hash value of the edge rule package to verify its integrity. After successful verification, the rule loading module loads the content of the edge rule package, and the rule parsing module parses the JSON structure of the edge rule package. The JSON structure within the edge rule package contains a rule array. Each rule object in the array contains a rule type field. The rule parsing module iterates through each rule object in the rule array, reads the value of the ruleType field, and then the rule classification and storage module maps the content of the rule object to the corresponding execution module for storage based on the value of the ruleType field. The runtime environment initialization module initializes the local runtime environment based on the loaded rule configuration.

4. The method for optimizing IoT data access in a power grid cloud management platform based on cloud-edge collaboration as described in claim 1, characterized in that, The edge node sets up a sampling strategy configuration module and a data acquisition scheduler. The sampling strategy configuration module configures the corresponding sampling frequency for terminal devices with different security levels. The data acquisition scheduler creates corresponding timed tasks according to the tasks in the sampling task queue and controls the sampling operation to read raw data from various connected IoT terminal devices at a specified frequency and precision through a hardware timer. The edge node is configured with an initialization module, a format conversion module, and a temporary database initialization module. The initialization module initializes the local memory data structure according to the preprocessing logic defined in the rules. The format conversion module receives the raw data stream from the terminal device and converts the raw data from different communication protocols into an internal standard format. The format conversion module sends the converted data to the data filtering component in the rule engine. The data filtering component processes the raw data according to preset thresholds and conditions, and removes data that exceeds the physical range. Then, the processed data is sent to the temporary database initialization module. The temporary database initialization module creates a temporary database and a corresponding circular buffer for each terminal device. The circular buffer stores the raw sampling data and intermediate calculation results for the most recent period. At the same time, the temporary database initialization module creates a time-series database instance, which stores long-term retained aggregate data and alarm data.

5. The method for optimizing IoT data access in a power grid cloud management platform based on cloud-edge collaboration as described in claim 1, characterized in that, The edge node setting change reporting execution module processes the routine operation data after preliminary cleaning and maintains a record of the last successfully reported data point for each monitoring indicator of each terminal device. The change reporting execution module obtains the currently collected data and compares the current data with the data point that was successfully reported last time. If the change between the two is less than the dead zone threshold set in the rule, only the latest data value in the local cache is updated. If the change between the two is greater than or equal to the dead zone threshold set in the rule, the upload task is triggered. Dead zone thresholds include fixed thresholds and relative thresholds.

6. The method for optimizing IoT data access in a power grid cloud management platform based on cloud-edge collaboration as described in claim 1, characterized in that, The edge node is configured with a periodic aggregation execution module. The periodic aggregation execution module maintains a sliding or fixed time window within the edge node. Within the time window, real-time incremental calculations are performed on the raw data collected at high speed. When the time window is reached, the statistical results within the window are extracted. The statistical results include the average, maximum, minimum, number of samples, median, standard deviation, and percentiles. The statistical results are then encapsulated into a data packet and added to the queue to be uploaded.

7. The method for optimizing IoT data access in a power grid cloud management platform based on cloud-edge collaboration as described in claim 1, characterized in that, The edge nodes are configured with a hierarchical caching architecture, which divides the data to be uploaded into multiple priority queues. The high-priority queue stores alarm event snapshot data, the medium-priority queue stores regular aggregate data, and the low-priority queue stores node status heartbeat packets. Edge nodes use solid-state drives (SSDs) as storage media for non-volatile persistent storage modules. The cache capacity management module of the edge node monitors the cache utilization rate in real time. When the cache utilization rate exceeds the set value, the earliest data stored in the low priority queue is deleted. The network status detection module of the edge node continuously monitors the network connection status with the cloud management platform. When a network connection interruption is detected, a local caching process is triggered. All data to be uploaded is stored in local non-volatile persistent storage according to priority. When the network status detection module detects that the network connection is restored, a breakpoint resume process is triggered. The edge node sends the cached data to the cloud management platform in order of priority from high to low.

8. The method for optimizing IoT data access in a power grid cloud management platform based on cloud-edge collaboration as described in claim 1, characterized in that, The edge node sets up a data encapsulation module, which processes the data to be sent after being processed by the edge node. It generates a standard envelope for each data packet to be sent. The envelope contains a unique identifier for the data packet, an edge node identifier, a timestamp sequence, a data packet type label, and a data model version number field. The timestamp uses UTC time and includes data acquisition time, edge processing completion time, and data packet transmission time. The data encapsulation module encapsulates a structured business data body inside the envelope. For regular aggregated data, the data body includes the start time and end time of the statistical time window, the name, value, unit, and data quality code information of the monitoring indicator. For alarm event snapshots, the data body includes the alarm ID, alarm level, alarm type, alarm occurrence time, alarm description, unique identifier of the associated device, trigger value and threshold of the alarm condition, and the time range and specific data content of the additional original data fragment. Edge nodes are equipped with an encrypted communication module and a communication scheduling module. The encrypted communication module sends data packets through a TLS-encrypted communication channel. The communication scheduling module schedules the transmission queue and adjusts the transmission rate of data packets of different priorities according to the priority of the data packets and the real-time status of the current network.

9. The method for optimizing IoT data access in a power grid cloud management platform based on cloud-edge collaboration as described in claim 1, characterized in that, The cloud management platform is configured with a distributed data access service cluster. The access service cluster adopts a microservice architecture and includes modules for signature verification, decryption, metadata parsing, data routing, and data fusion. The access service cluster receives data packets sent by edge nodes. The signature verification module uses the public key of the edge node to verify the digital signature of the data packet. The decryption module uses the symmetric key to decrypt the data body of the data packet. The metadata parsing module parses the metadata in the data packet envelope. The metadata includes the data packet type label and the edge node identifier. The data routing module sends the data packets to different downstream processing units according to the information of the parsed metadata. Data packets with alarm labels are sent to the real-time alarm analysis engine and the power grid dynamic map service. Data packets with regular aggregation labels are sent to the distributed time series database for persistent storage or sent to the data fusion module. The data fusion module receives data packets from different edge nodes, performs secondary aggregation operations on data belonging to the same business entity, and performs correlation analysis operations on data belonging to the same business entity.

10. The method for optimizing IoT data access in a power grid cloud management platform based on cloud-edge collaboration as described in claim 1, characterized in that, The cloud management platform includes a runtime status monitoring module, a parameter adjustment module, and a rule update module. The runtime status monitoring module continuously acquires overall quality data of data access across the entire network, rule execution efficiency data, and runtime status data of edge nodes. The parameter adjustment module performs the following parameter adjustment operations based on the acquired monitoring data: (1) Regarding data redundancy adjustment, obtain the terminal device change reporting trigger rate data and adjust the dead zone threshold based on the data; (2) Regarding the adjustment of the aggregation period, obtain the alarm occurrence data of the terminal device and the reflection data of the aggregation data, and adjust the length of the aggregation time window according to the data; (3) Regarding the adjustment of sampling frequency, the operating status data of the equipment is obtained, and the sampling frequency is adjusted according to the data; (4) Regarding alarm rule adjustment, obtain false alarm rate and false negative rate data of alarm rules, adjust the threshold of alarm conditions based on the data, or add associated alarm conditions; (5) Regarding edge resource adjustment, obtain the CPU utilization data of edge nodes and send rule migration instructions to adjacent edge nodes based on the data; The rule update module compiles and encapsulates the adjusted rule parameters into an edge rule package, and then sends the updated edge rule package to the corresponding edge nodes for execution.

Images