Cloud-edge collaborative data processing method and device based on power IoT operating system

Abstract

This application relates to a cloud-edge collaborative data processing method and apparatus based on a power IoT operating system. The method is applied to a power IoT cloud server, where the power IoT cloud server and access entities constitute the power IoT operating system. The access entities include power IoT smart terminals and power IoT edge nodes. The method includes: acquiring transmission data sent by the access entities in the power system; determining the task type for the data processing task based on the service quality classification identifier and data type label contained in the transmission data; determining the task priority and task complexity based on the data under the target field in the transmission data; determining the task processing strategy based on the task complexity of the data processing task and the device status information of the access entities; and performing resource scheduling and task processing based on predicted resource requirements, task priority, and task processing strategy to obtain the data processing result. This method can improve data processing efficiency.

Description

Technical Field

[0001] This application relates to the field of data processing technology, and in particular to a cloud-edge collaborative data processing method and apparatus based on a power IoT operating system. Background Technology

[0002] In the cloud-edge collaboration scenario of power production, the types of connected entities are highly diverse, covering sensing terminals and control units corresponding to different equipment such as generator sets, transformers, and distribution switches. The cloud is used to perform collaborative processing based on the data collected from the edge, such as resource allocation and task assignment.

[0003] In related technologies, data collected at the edge is transmitted to the cloud through a full data transmission mode. The cloud uses a static resource allocation method for collaborative processing, but this method suffers from low processing efficiency.

[0004] The current construction of the power Internet of Things (IoT) faces numerous technical bottlenecks: First, there is a lack of a unified power IoT operating system platform. Different manufacturers' terminal devices use proprietary protocols, leading to severe protocol heterogeneity, difficulties in data interoperability, and high system integration costs. Second, terminal device access requires complex manual configuration, failing to achieve plug-and-play functionality and resulting in low efficiency for large-scale deployment. Third, the cloud-edge collaboration mechanism is weak; edge and cloud computing resources cannot be dynamically scheduled, making it difficult to guarantee the real-time requirements of power production in terms of data transmission and processing latency. Fourth, the security protection system is incomplete, lacking end-to-end trusted security guarantees from terminal to cloud, posing security risks of data leakage and device attacks. Fifth, the core operating system and key technologies rely on foreign products, with insufficient domestic self-sufficiency and controllability, making it difficult to meet the security requirements of critical power infrastructure. The power IoT operating system, as a domestically developed IoT operating system for the power sector, provides a systematic solution to these problems by constructing an integrated cloud-edge-device technical architecture. Summary of the Invention

[0005] Therefore, it is necessary to provide a cloud-edge collaborative data processing method and device based on a power IoT operating system that can improve the data processing efficiency of power systems, addressing the aforementioned technical problems.

[0006] Firstly, this application provides a cloud-edge collaborative data processing method based on a power IoT operating system, applied to a power IoT cloud server. The power IoT cloud server and the access entity constitute the power IoT operating system. The access entity includes power IoT smart terminals and power IoT edge nodes, comprising:

[0007] Acquire transmission data sent by entities connected to the power system;

[0008] Based on the service quality classification identifier and data type label contained in the transmitted data, determine the task type for the data processing task for the transmitted data;

[0009] Based on the data under the target field in the transmitted data, the task priority and task complexity of the data processing task are determined; wherein, the target field is determined based on the task type;

[0010] Based on the task complexity of the data processing task and the device status information of the access entity, a task processing strategy is determined for the data processing task.

[0011] Based on the predicted resource requirements, the task priority, and the task processing strategy, resource scheduling and task processing are performed for the data processing task to obtain the data processing result of the data processing task; wherein, the predicted resource requirements are determined by the power IoT cloud server based on the execution records of historical data processing tasks.

[0012] Secondly, this application also provides a cloud-edge collaborative data processing device based on a power IoT operating system, applied to a power IoT cloud server, comprising:

[0013] The acquisition module is used to acquire transmission data sent by access entities in the power system;

[0014] The task generation module is used to determine the task type of the data processing task for the transmitted data based on the service quality classification identifier and data type label contained in the transmitted data.

[0015] The first processing module is used to determine the task priority and task complexity of the data processing task based on the data under the target field in the transmitted data; wherein the target field is determined based on the task type;

[0016] The second processing module is used to determine a task processing strategy for the data processing task based on the task complexity of the data processing task and the device status information of the access entity.

[0017] The execution module is used to perform resource scheduling and task processing for the data processing task based on the predicted resource requirements, the task priority, and the task processing strategy, and to obtain the data processing result of the data processing task; wherein, the predicted resource requirements are determined by the power IoT cloud server based on the execution records of historical data processing tasks.

[0018] Thirdly, this application also provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps of the above-described method.

[0019] Fourthly, this application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the above-described method.

[0020] Fifthly, this application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the above-described method.

[0021] The aforementioned cloud-edge collaborative data processing method and device based on the power IoT operating system acquires transmission data uploaded by access entities and classifies data processing tasks based on service quality classification identifiers and data type labels in the transmission data, thereby enabling classified processing of various types of transmission data. Then, based on the task type, corresponding target fields are matched, and task priority and complexity are dynamically parsed from the transmission data, achieving dynamic task evaluation and enabling hierarchical and layered task management. Finally, an appropriate task processing strategy is formulated by combining task complexity and the actual equipment status information of the access entities, thus balancing cloud computing load and access entity operating conditions, achieving load balancing and adaptive linkage of the cloud-edge collaborative link. Furthermore, by predicting resource demand based on historical task execution records and combining task priority with predetermined processing strategies for resource scheduling and task processing, dynamic allocation and predictive scheduling of cloud resources can be achieved, effectively reducing the possibility of resource idleness and waste. This ensures that cloud resource scheduling considers both timely response to current data processing tasks and addressing future predicted resource demands, effectively improving the real-time performance and resource utilization of data processing under the power production cloud-edge collaborative architecture, and increasing data processing efficiency. Attached Figure Description

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

[0023] Figure 1 This is an application environment diagram of a cloud-edge collaborative data processing method based on a power IoT operating system in one embodiment.

[0024] Figure 2 This is a flowchart illustrating a cloud-edge collaborative data processing method based on a power IoT operating system in one embodiment.

[0025] Figure 3 This is a schematic diagram of the data acquisition process in one embodiment;

[0026] Figure 4 This is a schematic diagram of the application process of a cloud-edge collaborative data processing method based on a power IoT operating system in one embodiment.

[0027] Figure 5 This is a flowchart illustrating the dynamic protocol parsing and standardization process in one embodiment;

[0028] Figure 6 This is a structural block diagram of a cloud-edge collaborative data processing device based on a power IoT operating system in one embodiment.

[0029] Figure 7 This is an internal structural diagram of a computer device in one embodiment. Detailed Implementation

[0030] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0031] It should be noted that the terms "first," "second," etc., used in this application can be used to describe various elements, but these elements are not limited by these terms. These terms are only used to distinguish the first element from the second element. The terms "comprising" and "having," and any variations thereof, used in this application, are intended to cover non-exclusive inclusion. The term "multiple" used in this application refers to two or more. The term "and / or" used in this application refers to one of the embodiments, or any combination of multiple embodiments.

[0032] The cloud-edge collaborative data processing method based on a power IoT operating system provided in this application can be applied to, for example... Figure 1 The application environment shown is illustrated. Terminal 101 communicates with server 102 via a network. A data storage system can store the data that server 102 needs to process. The data storage system can be integrated onto server 102, or it can be located in the cloud or on another network server.

[0033] There can be multiple terminals 101. Multiple terminals 101 and server 102 together form a power system for monitoring the power grid. Terminals 101, as access entities, collect and transmit various types of data from the power grid. Server 102 acquires the transmitted data sent by the access entities in the power system. Based on the service quality classification identifier and data type label contained in the transmitted data, the task type for the data processing task is determined. Based on the data under the target field in the transmitted data, the task priority and complexity of the data processing task are determined. The target field is determined based on the task type. Based on the task complexity of the data processing task and the device status information of the access entities, a task processing strategy for the data processing task is determined. Based on the predicted resource requirements, task priority, and task processing strategy, resource scheduling and task processing are performed for the data processing task to obtain the data processing result. The predicted resource requirements are determined by the power IoT cloud server based on the execution records of historical data processing tasks.

[0034] Terminal 101 can be, but is not limited to, various personal computers, laptops, smartphones, tablets, drones, low-altitude aircraft, IoT devices, and portable wearable devices. IoT devices can include smart speakers, smart TVs, smart air conditioners, smart in-vehicle devices, and projection equipment. Portable wearable devices can include smartwatches, smart bracelets, and head-mounted displays. Head-mounted displays can be virtual reality (VR) devices, augmented reality (AR) devices, and smart glasses. Server 102 can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing cloud computing services.

[0035] In one exemplary embodiment, such as Figure 2 As shown, a cloud-edge collaborative data processing method based on a power IoT operating system is provided. This method is applied to a power IoT cloud server, where the power IoT cloud server and access entities constitute the power IoT operating system. The access entities include power IoT smart terminals and power IoT edge nodes. The method includes the following steps 201 to 205. Wherein:

[0036] Step 201: Obtain the transmission data sent by the access entity in the power system.

[0037] Among them, the power IoT smart terminal can first connect to the power IoT edge node, and then connect to the power IoT cloud server through the power IoT edge node; the power IoT smart terminal and the power IoT edge node can also connect to the power IoT cloud server respectively.

[0038] In some embodiments, the power IoT operating system constructs a three-layer collaborative architecture of cloud, edge, and terminal. Specifically, the power IoT intelligent terminal layer is responsible for power field data acquisition and edge computing, the power IoT edge node layer is responsible for regional data aggregation, preprocessing, and local intelligence, and the power IoT cloud server layer is responsible for global scheduling, big data analysis, and model training. The three layers are interconnected through the power IoT unified data bus to form an integrated data processing system of terminal, edge, and cloud collaboration.

[0039] The power system refers to the overall power operation network system that includes all aspects such as power generation, transmission, transformation, distribution, consumption, and dispatch monitoring.

[0040] Access entities refer to various terminal devices deployed at the edge of the power field, such as power Internet of Things terminals, station monitoring and control devices, power distribution terminals, sensors, intelligent inspection equipment, substation edge gateways, etc.

[0041] The access entity and the power IoT cloud server together form a cloud-edge collaborative architecture for the power system, that is, the access entity collects data and the access entity and the power IoT cloud server work together to process the data.

[0042] Transmitted data refers to the power business data to be processed that the access entity uploads to the cloud, such as real-time power monitoring data, periodic statistical data, and equipment operation logs.

[0043] In some embodiments, the transmitted data may be the raw data collected by the access entity; or it may be the data obtained by the access entity after preprocessing the collected raw data, wherein the preprocessing may include filtering, data classification, format conversion, etc.

[0044] During the data acquisition phase, the power IoT smart terminal, based on the Hardware Abstraction Layer (HAL) of the power IoT operating system, achieves unified driving and data acquisition of various sensors and acquisition modules, supporting multi-channel parallel acquisition and hardware-level time synchronization. The acquired raw data is transmitted to the power IoT edge nodes through the real-time data bus of the power IoT operating system. The edge nodes perform data cleaning, feature extraction, and preliminary analysis based on the power IoT edge computing framework. The preprocessed data is then uploaded to the power IoT cloud platform through the power IoT cloud-edge collaboration channel, realizing standardized processing of the entire data acquisition-preprocessing-upload process.

[0045] Step 202: Based on the quality of service classification identifier and data type label contained in the transmitted data, determine the task type for the data processing task of the transmitted data.

[0046] Quality of Service (QoS) refers to the differentiated processing strategies provided for different traffic or services based on indicators such as service type, user priority, or application requirements.

[0047] The Quality of Service (QoS) rating identifier is used to mark the QoS classification results of transmitted data.

[0048] The service quality is divided into three levels: high, medium, and low. In this embodiment, real-time detection data is identified as high-quality data, periodic statistical data is identified as medium-quality data, and log data is identified as low-quality data.

[0049] Data type labeling involves tagging the service type, message type, application type, or traffic attribute of transmitted data to quickly identify the data category.

[0050] In some embodiments, the data type of the transmitted data may include fault diagnosis data, historical report data, equipment operating parameter statistics, power grid load allocation data, monthly power generation report data, etc.

[0051] For example, based on the QoS classification metadata (such as "high QoS - real-time monitoring", "low QoS - non-real-time statistics") and data type labels (such as "fault diagnosis data" and "historical report data") carried by the transmitted data stream, the data processing tasks can be divided into the following four categories: For "high QoS" data belonging to the "fault monitoring" category (such as the data stream carrying the identifier "equipment short circuit detection data - response time ≤ 1s"), the task type is determined to be a fault diagnosis task; for "high QoS" data belonging to the "control and regulation support" category (such as the data stream carrying the identifier "grid load allocation data - real-time requirement ≤ 100ms"), the task type is determined to be a real-time control task; for "medium QoS" data belonging to the "operation and maintenance support" category (such as the data stream carrying the identifier "equipment operation parameter statistics - response time ≤ 1s"), the task type is determined to be a status monitoring task; for "low QoS" data belonging to the "non-real-time" category (such as the data stream carrying the identifier "monthly power generation report data - no real-time requirement"), the task type is determined to be a historical analysis task.

[0052] Step 203: Based on the data under the target field in the transmitted data, determine the task priority and task complexity of the data processing task; wherein, the target field is determined based on the task type.

[0053] The target field is pre-defined, and the target field can be the same or different for different task types.

[0054] Task priority describes the scheduling order and resource preemption level of current data processing tasks. The higher the priority, the earlier the task will be scheduled and executed, and the faster the system processing resources can be allocated.

[0055] Task complexity is used to characterize the difficulty of processing the current data processing task. The difficulty can be the amount of data computation, the number of processing steps, the logical complexity, and the degree of resource consumption. The higher the task complexity, the more high-performance processing nodes need to be considered when deploying the task.

[0056] In some embodiments, the task priority and task complexity can be determined by range mapping based on the field content (such as identifier parameters, attribute values, or business tags) carried under the target field corresponding to different task types; wherein, different ranges correspond to different task priorities (or task complexities).

[0057] It should be noted that task priority and task complexity can correspond to different target fields. In this case, the task priority needs to be determined based on the field content under the target field corresponding to the task priority, and the task complexity needs to be determined based on the field content under the target field corresponding to the task complexity.

[0058] In other embodiments, under the same task type, there may be multiple target fields corresponding to task priority (or task complexity). When there are multiple target fields, scores can be mapped according to the field content of each target field. Finally, the scores of multiple target fields are merged to obtain the task priority (or task complexity).

[0059] Step 204: Based on the task complexity of the data processing task and the device status information of the access entity, determine the task processing strategy for the data processing task.

[0060] Among them, the task processing strategy is used to indicate the processing and deployment method of data processing tasks, such as edge processing, cloud processing, collaborative processing, etc.

[0061] Device status information of an access entity refers to operational status information that reflects the service processing capabilities of the access entity, such as remaining computing resources, remaining storage resources, device load rate, operating power consumption, online status, and service processing capabilities.

[0062] For example, when the task complexity indicator is a simple task, it means that the data processing task is computationally simple, has low performance requirements, and low resource requirements. In this case, the task processing strategy can be determined to be access entity processing, so that the data processing task can be sent to the access entity for processing, so as to reserve the high-performance resources of the power IoT cloud server for high-complexity data processing tasks, thereby improving the overall task processing efficiency.

[0063] Step 205: Based on the predicted resource requirements, task priorities, and task processing strategies, resource scheduling and task processing are performed for the data processing task to obtain the data processing result of the data processing task; wherein, the predicted resource requirements are determined by the power IoT cloud server based on the execution records of historical data processing tasks.

[0064] Among them, the predicted resource demand is determined by the power IoT cloud server based on the execution records of historical data processing tasks; furthermore, the power IoT cloud server can perform task prediction based on the execution records of historical data processing tasks to obtain predicted tasks, and then perform resource prediction based on the predicted tasks to obtain predicted resource demand.

[0065] The execution records of historical data processing tasks can include historical data processing tasks archived in chronological order, as well as the associated information of each historical data processing task. The associated information includes, for example, the task type of the historical data processing task, the equipment load status at the corresponding time, the power grid load at the corresponding time, the task processing time, and the data scale of the processed data.

[0066] Resource scheduling refers to the rational allocation, dynamic deployment, and reserved planning of resources (such as computing resources, storage resources, network resources, etc.) of power IoT cloud servers and access entities.

[0067] Task processing refers to the process of sending data processing tasks to corresponding execution nodes (such as power IoT cloud servers or access entities), and then having the execution nodes use the scheduled resources to complete the data processing.

[0068] Understandably, predicted resource demand represents the potential resource needs of the power IoT cloud server over a future period, while task priority and task processing strategy determine the resource scheduling needs of the power IoT cloud server at the current moment. Therefore, by combining predicted resource demand, task priority, and task processing strategy, resource scheduling and task processing can be performed for data processing tasks. This allows the power IoT cloud server to balance the scheduling needs of current real-time tasks with the predicted resource reserve needs for future periods, effectively avoiding resource idleness or resource overload and improving the overall system's resource utilization rate.

[0069] For example, assuming that the predicted resource demand indicates that a large number of highly complex and high-priority data processing tasks will be connected in the near future, the power IoT cloud server can reserve sufficient resources in advance (such as 30%); the remaining 70% of resources will be scheduled according to the task priority and task processing strategy of the current tasks to be processed, with priority given to allocating dedicated resource quotas to high-priority tasks, and scheduled and executed in an orderly manner according to the deployment method of edge processing, cloud processing or edge-cloud collaborative processing, while low-priority tasks will be scheduled later.

[0070] In some embodiments, the data processing results may include at least one of the following: task parsing results, status feedback information, anomaly alarm information, and task suggestions.

[0071] In the aforementioned cloud-edge collaborative data processing method based on the power IoT operating system, the transmission data uploaded by the access entity is acquired, and the data processing task types are classified based on the service quality classification identifier and data type label in the transmission data, thereby enabling classified processing of various types of transmission data. Then, based on the task type, corresponding target fields are matched, and task priority and complexity are dynamically parsed from the transmission data, achieving dynamic task evaluation and enabling hierarchical and layered task management. Finally, an appropriate task processing strategy is formulated by combining task complexity and the actual equipment status information of the access entity, thus taking into account both cloud computing load and access entity operating conditions, achieving load balancing and adaptive linkage of the cloud-edge collaborative link. Furthermore, by predicting resource demand based on historical task execution records, and then combining task priority and predetermined processing strategies for resource scheduling and task processing, dynamic allocation and predictive scheduling of cloud resources can be achieved, effectively reducing the possibility of resource idleness and waste. This ensures that cloud resource scheduling considers both timely response to current data processing tasks and addressing future predicted resource demands, effectively improving the real-time performance and resource utilization of data processing under the power production cloud-edge collaborative architecture, and increasing data processing efficiency.

[0072] In some of these embodiments, please refer to Figure 3 , Figure 3 This illustration shows a schematic diagram of the data acquisition process in an embodiment of this application. Step 201 includes steps 301 to 305, wherein:

[0073] Step 301: Obtain the probe data sent by the access entity in the power system.

[0074] Among them, the probe data refers to the raw, unprocessed data collected by the access entity.

[0075] Step 302: Perform data parsing on the probe data based on the data parsing protocols contained in the preset protocol template library to obtain parsed data; the preset protocol template library contains a variety of data parsing protocols.

[0076] In some embodiments, the preset protocol template library contains a variety of data protocols that can cover mainstream standard protocols and vendor-defined protocols. Each protocol template is a complete set of parsing rules. Parsing the protocol template can store all the information required for parsing, such as protocol field definitions (e.g., field name, data type, length, offset), verification rules (e.g., cyclic redundancy check (CRC), XOR check), and data frame format (e.g., start character, address field, function code, data field, end character), in a structured format.

[0077] In some embodiments, after receiving the probe data, the power IoT cloud server can identify the device based on the device identity identifier contained in the probe data. If the identity identifier indicates that the access entity is a pre-registered device, the power IoT cloud server determines the corresponding target data parsing protocol from the preset protocol template library according to the pre-maintained mapping relationship between devices and data parsing protocols, and uses the target data parsing protocol to parse the probe data to obtain parsed data.

[0078] If the identification indicates that the access entity is a new access device, data feature extraction can be performed on the probe data to determine the corresponding data protocol features, such as frame delimiters, address field format and location, function codes, data field length identifiers, verification algorithms and locations, etc. Then, the data protocol features are used to perform protocol matching in the preset protocol template library. Based on the matched data parsing protocol, the probe data is parsed to obtain the parsed data. If there is no matching data parsing protocol, it is determined to be a new protocol. The power IoT cloud server dynamically constructs a "minimum available parser" containing inferred frame structure, field extraction rules and verification methods as a temporary parsing rule for data parsing based on the probe results, and saves the constructed parsing rule in the new data parsing protocol. After being confirmed by the management personnel, it is written into the preset protocol template library.

[0079] Step 303: Perform data evaluation processing based on the parsed data to determine the data quality evaluation results and data compression instructions for the access entity; wherein, the data evaluation processing includes at least a service quality classification.

[0080] In some embodiments, data evaluation processing may also include format conversion, filtering, noise reduction, etc.

[0081] In some embodiments, the parsed data may first be converted to a standard format to obtain standard format data. Then, the standard format data may be graded according to its quality of service. Different filtering and noise reduction methods may be adopted for data with different quality of service.

[0082] Data quality assessment results may include service quality grading labels for probe data, labels for abnormal data in probe data, and labels for noisy data.

[0083] Data compression instructions are used to instruct access entities to compress data; they may include recommended compression algorithms, compression levels, data sampling rates, etc.

[0084] In some embodiments, compression instructions can be generated based on parsed data to obtain data compression instructions; on this basis, data compression instructions can also be obtained by fusing the data characteristics of the parsed data (such as data type, data size, data real-time requirements), the data transmission parameters of the access entity during the transmission of probe data (such as transmission time, latency, etc.), and the current transmission status of the access entity (such as currently available bandwidth).

[0085] Step 304: Return the data quality assessment results and data compression instructions to the access entity.

[0086] In some embodiments, the access entity can perform data processing on the collected raw data based on the data quality assessment results, such as noise removal, invalid data removal, service quality labeling, and compliance screening. At the same time, the processed data can be adaptively compressed using data compression commands, and the compressed data can be transmitted.

[0087] Step 305: Receive the transmission data sent by the access entity after processing the raw data collected by the access entity based on the data quality assessment results and data compression instructions.

[0088] Understandably, the computing power of the access entities in power production is limited. If the access entities were to perform data evaluation and processing, it would severely impact data transmission efficiency. However, by having the power IoT cloud server perform data evaluation and processing, and then returning the data quality evaluation results and data compression instructions to the access entities, the access entities can achieve data processing and compression under the guidance of the power IoT cloud server without performing data analysis. This enables refined management and lightweight encapsulation of raw data, reduces the amount of redundant and invalid data transmitted upstream, and lowers network bandwidth usage and transmission latency between the edge and the cloud.

[0089] In the above embodiments, the probe data reported by the access entity is acquired, and the corresponding parsing protocol is matched according to the preset protocol template library to complete the data parsing. Then, the parsed data is subjected to data evaluation processing, including service quality classification, and the data quality evaluation result and data compression instruction are generated simultaneously and sent to the access entity. This allows the access entity to standardize the local raw data collection based on the evaluation result and compression instruction before uploading and transmitting the data. On the one hand, it can adapt to the heterogeneous protocol data access of various types of access entities in the power system through the preset protocol template library. On the other hand, processing the raw data before transmission effectively reduces the data transmission bandwidth overhead between the power IoT cloud server and the access entity, reduces invalid data transmission and system resource waste, and improves the overall quality of uploaded and transmitted data.

[0090] In some embodiments, the target field includes a plurality of first business fields for determining task priority and a plurality of second business fields for determining task complexity; determining the task priority and task complexity of the data processing task based on the data under the target field in the transmitted data includes:

[0091] Based on the data under each first service field in the transmitted data, determine the initial priority score of each first service field.

[0092] In some embodiments, interval mapping can be performed based on the data under the first business field to obtain the initial priority score of the first business field. For example, the data interval corresponding to the first business field is the first data interval, and the first data interval corresponds to the first score range. At this time, according to the position of the data under the first business field in the first data interval, its position in the first score range can be determined, thereby determining the initial priority score of the first business field.

[0093] Based on the power system's operational status data, the priority weights corresponding to each primary business field are determined.

[0094] Among them, the power system's operating status data is used to assess the current overall operating condition of the power system. It is understood that the impact of various first business fields on priority differs when the power system is in different operating conditions. For example, multiple first business fields may include fields for assessing the scope of impact, fields for assessing the urgency, and fields for assessing the business value. In this case, if the power system is operating under high load, the priority weight of the first business field of the scope of impact will be increased to avoid the risk of large-scale failures caused by high load conditions. If the power system is operating under low load, the priority weight of the first business fields of urgency and business medium will be increased to ensure that urgent business tasks and high-value businesses can be dispatched and processed in a timely manner.

[0095] In some embodiments, a mapping relationship between the operating status of the power system and the priority weight distribution can be established in advance. For example, the first operating status corresponds to the first set of priority weight distributions, and each set of priority weight distributions contains the priority weights corresponding to each first business field. In this way, the operating status of the power system can be determined based on the operating status data of the power system, and then the priority weights corresponding to each first business field can be determined based on the mapping relationship.

[0096] In other embodiments, the operating status data of the power system may be used as the input to the decision network, and the decision network may output the priority weights corresponding to each first service field.

[0097] In other embodiments, the decision network can be continuously optimized during processing, and the cloud-edge collaborative data processing method based on the power IoT operating system can also include:

[0098] The target reward value is calculated based on the data processing results of the preset reward function and the data processing task.

[0099] Among them, the preset reward function is a pre-constructed evaluation function used to quantitatively assess the rationality of the output weights of the decision network, the effect of task scheduling, and the performance of the power system. It can comprehensively consider multiple evaluation dimensions such as the degree of system load balance, fault avoidance effect, emergency task response delay, resource utilization rate, and data transmission quality, providing a quantitative evaluation standard for the optimization and iteration of the decision network.

[0100] The target reward value refers to the evaluation value obtained by quantifying the actual execution effect of the current data processing task through a preset reward function. It is used to characterize the quality of the priority weight configuration of each first business field. The higher the reward value, the more suitable the current weight configuration and task scheduling strategy are to the current operating conditions of the power system.

[0101] The decision network parameters are updated based on the target reward value.

[0102] In some embodiments, the decision network parameters are updated based on the target reward value. By using the target reward value to reverse correct the network weights and bias parameters of the decision network, online learning and continuous iterative optimization of the decision network are achieved. This enables the decision network to continuously adapt to the dynamically changing operating state of the power system and adaptively output more reasonable and more suitable first business field priority weights that meet actual business needs.

[0103] Based on the priority weights corresponding to each first business field, the initial priority scores of each first business field are weighted and merged to obtain the task priority of the data processing task.

[0104] In some embodiments, the weighted and fused score of the initial priority scores of each first business field can be used as the task priority of the data processing task; or the weighted and fused score can be mapped to an interval, and the task priority of the data processing task can be determined based on the mapped interval. For example, if the weighted score belongs to the first interval, then the task priority is the highest priority.

[0105] Based on the data under each second business field in the transmitted data, determine the initial complexity score of each second business field.

[0106] Similar to the initial priority score, the initial complexity score of the second business field can be obtained by performing interval mapping based on the data under the second business field. For example, the data interval corresponding to the second business field is the second data interval, and the second data interval corresponds to the second score range. At this time, according to the position of the data under the second business field in the second data interval, its position in the second score range can be determined, and thus the initial complexity score of the second business field can be determined.

[0107] Based on the preset weights of each second business field, the initial complexity scores of each second business field are weighted to obtain the task complexity of the data processing task.

[0108] In some embodiments, the second business field may include a field for assessing the data size, a field for assessing the degree of data correlation, a field for assessing the data calculation steps, etc.

[0109] It is understandable that the complexity of a task is an inherent objective attribute of the task itself and will not change due to the state of the power system. Therefore, by using preset weights to weight the initial complexity scores of each second business field to obtain the task complexity of the data processing task, we can ensure a unified evaluation standard and provide data support for subsequent processing.

[0110] In the above embodiments, the target field is divided into a first business field and a second business field, which are used to evaluate task priority and task complexity, respectively. Among them, the task priority is combined with the dynamic configuration field weight of the power system operating status and weighted fusion, so that the task priority can adapt to the dynamic changes of the power grid operating conditions and the priority determination is more accurate. The task complexity is calculated by pre-set fixed weights, and the evaluation standard is unified and stable. This allows for accurate quantification of task priority and task complexity, providing a reliable basis for subsequent task strategy formulation and resource scheduling, and improving the rationality and operational efficiency of power system task scheduling and resource allocation.

[0111] In some embodiments, a task processing strategy for the data processing task is determined based on the task complexity of the data processing task and the equipment status information of the entities connected in the power system, including:

[0112] If the task complexity is indicated as a first type of task, and the equipment status information of the access entity in the power system indicates that the access entity has sufficient computing resources, the task processing strategy for the data processing task is determined as the first processing strategy; the first processing strategy is that the access entity performs the task processing.

[0113] The first category of tasks is simple tasks; specifically, a task is classified as a task if its complexity score is lower than a first threshold.

[0114] In some embodiments, there may be multiple access entities in a power system. The device status information of an access entity indicating that the computing resources of the access entity are sufficient means that there is at least one access entity whose device status information indicates that the computing resources are sufficient.

[0115] In some embodiments, when there are multiple access entities in a power system and multiple access entities have sufficient computing resources, a graph neural network algorithm can be introduced. The access entities with sufficient computing resources are regarded as graph nodes, and the operating status data, load conditions, and data interaction relationships of each access entity are regarded as edge relationships. The graph neural network algorithm is used to mine and learn the correlation influence and resource adaptation correlation features between each node, evaluate the task carrying capacity and cooperative adaptation degree of each access entity, and then select and determine the optimal access entity to undertake the corresponding data processing task, so as to realize the cooperative and optimal scheduling among multiple access entities.

[0116] Based on this, and taking into account predicted resource requirements, task priorities, and task processing strategies, resource scheduling and task processing are performed for data processing tasks to obtain the data processing results, including:

[0117] The access entity performs resource scheduling and task processing for the data processing task based on predicted resource requirements and task priorities, and obtains the data processing result of the data processing task.

[0118] In some embodiments, the access entity parses the data processing tasks to be executed, queues the local multiple tasks according to task priority, prioritizes scheduling high-priority tasks to seize resources and execute them first; at the same time, combined with the predicted resource demand issued by the power IoT cloud server, it predicts the resource consumption situation in the future period, dynamically allocates resources, reserves dedicated resources for high-priority tasks, and avoids resource contention and overload.

[0119] After completing the task, the access entity returns the data processing results to the power IoT cloud server for reporting and storage.

[0120] In other embodiments, considering that the resource prediction demand mainly reflects the resource demand of the power IoT cloud server, the access entity can also directly schedule resources and process tasks based on task priority to obtain the data processing results of the data processing task.

[0121] In the above embodiments, the task processing strategy is adaptively determined based on the task complexity type and the resource status of the access entity. For tasks with low complexity and sufficient edge resources, a first processing strategy is determined to be executed locally on the edge. Then, the access entity autonomously carries out resource scheduling and task processing based on the predicted resource requirements and task priorities. This can make full use of the idle computing power on the edge and reduce the computing pressure and transmission burden on the cloud.

[0122] In some embodiments, a task processing strategy for the data processing task is determined based on the task complexity of the data processing task and the equipment status information of the entities connected in the power system, including:

[0123] When the task complexity indicator is a second type of task, the task processing strategy for the data processing task is determined to be the second processing strategy; the second processing strategy is to be processed collaboratively by the access entity and the power IoT cloud server.

[0124] The second type of task is a normal task; specifically, the task complexity score can be determined as a second type of task if it is not lower than the first threshold and not higher than the second threshold; where the second threshold is greater than the first threshold.

[0125] In some embodiments, the access entity indicated by the second processing strategy may be the access entity corresponding to the transmitted data, that is, the same access entity handles the transmission of data and task coordination.

[0126] Based on this, and taking into account predicted resource requirements, task priorities, and task processing strategies, resource scheduling and task processing are performed for data processing tasks to obtain the data processing results, including:

[0127] The access entity and the power IoT cloud server coordinate resource scheduling and task processing based on predicted resource demand and task priority to obtain the data processing results of the data processing task.

[0128] In some embodiments, a simple part of the data processing task (such as feature extraction, data transformation, etc.) may be distributed to the access entity for processing, and the power IoT cloud server performs complex data processing on the data processed by the access entity, such as data analysis, joint judgment, deep model processing, etc.

[0129] In some embodiments, the power IoT cloud server prioritizes and coordinates various tasks, combines predicted resource demand to achieve unified allocation of cloud resources, and coordinates the scheduling of idle resources on each edge device. At the same time, it reasonably breaks down data processing tasks, delegating simple data processing steps to the edge device for execution, while undertaking complex deep computations itself, and finally generating complete data processing results.

[0130] In the above embodiments, by coordinating and dividing the work between the edge and the cloud, simple pre-processing tasks are devolved to the edge for execution, while complex and in-depth tasks are centrally processed in the cloud. By combining predicted resource requirements and task priorities to coordinate resource scheduling, the advantages of edge processing and low latency are fully utilized, while the powerful computing power of the cloud is used to complete high-order business operations. This effectively balances the edge and cloud load, reduces data transmission volume, and improves the overall task processing efficiency and the rationality of resource allocation.

[0131] In some embodiments, a task processing strategy for the data processing task is determined based on the task complexity of the data processing task and the equipment status information of the entities connected in the power system, including:

[0132] When the task complexity indicator is classified as a third type of task, the task processing strategy for the data processing task is determined to be the third processing strategy; the third processing strategy is to have the task processed by the power IoT cloud server.

[0133] The third category of tasks is complex tasks; specifically, a task's complexity score can be higher than a second threshold to determine that it is a third category of task.

[0134] Based on this, and taking into account predicted resource requirements, task priorities, and task processing strategies, resource scheduling and task processing are performed for data processing tasks to obtain the data processing results, including:

[0135] The power IoT cloud server performs resource scheduling and task processing for data processing tasks based on predicted resource demand and task priorities, and obtains the data processing results of the data processing tasks.

[0136] In some embodiments, the power IoT cloud server prioritizes and coordinates various tasks, combines predicted resource demands to complete the unified allocation of cloud resources, and uses the allocated resources to process the tasks in sequence.

[0137] In the above embodiments, the powerful computing power of the cloud is used to complete complex tasks, thereby improving the processing efficiency of data processing tasks.

[0138] In some embodiments, before performing resource scheduling and task processing for data processing tasks based on predicted resource requirements, task priorities, and task processing strategies, and obtaining the data processing results of the data processing tasks, the method further includes:

[0139] It acquires the execution records of historical data processing tasks and the current power grid operation status information; the power grid operation status information is used to describe the operation status of the power grid corresponding to the power system.

[0140] It is understandable that the current operating status of the power grid can reflect, to some extent, the data change trend that may occur over a period of time. For example, if the power grid operating status information indicates that multiple thermal power units are newly started, it means that the amount of data to be processed may increase in the future. If the power grid operating status information indicates that multiple thermal power units are shut down, it means that the amount of data to be processed may decrease in the future. For another example, if the power grid operating status information indicates that the electricity load is gradually increasing, it means that the monitoring, alarm and inspection data of various equipment will increase significantly.

[0141] Data is extracted from the execution records of historical data processing tasks to obtain historical task feature data.

[0142] Historical task characteristic data can be data extracted from execution records, such as task type, task duration, task priority, etc., or data obtained by statistics based on execution records, such as the number of tasks at each level, average resource consumption, etc.

[0143] Feature extraction is performed based on the current power grid operating status information to obtain operating features.

[0144] In some embodiments, key information, such as load peak, number of generator starts and stops, and line overload ratio, can be filtered from the power grid operation status information through preset extraction rules as operation features; alternatively, models can be used to mine the deeper features contained in the power grid operation status information to obtain operation features.

[0145] Resource demand is predicted based on historical task characteristic data and operational characteristics.

[0146] In some embodiments, historical task feature data and operational features may be used as input to a neural network, which performs task prediction and resource requirement fitting calculations to output predicted resource requirements.

[0147] In the above embodiments, by acquiring historical task execution records and current power grid operation status information, extracting historical task features and power grid operation features respectively, and integrating the two types of features to carry out resource demand prediction, it is possible to predict the data volume and resource occupancy trend of subsequent tasks in advance, realize the prediction of resource demand, and provide data support for subsequent resource scheduling and task processing.

[0148] For easier understanding, please refer to Figure 4 , Figure 4 This illustration shows an application flow diagram related to an embodiment of the present application, including steps S1 to S6, wherein:

[0149] S1, Dynamic Protocol Parsing and Data Standardization. Specifically, the power IoT cloud server performs dynamic protocol parsing on the heterogeneous data (i.e., the detection data of this application) of the power production access entity and standardizes the data.

[0150] In some embodiments, power generation access entities are diverse (such as sensor terminals corresponding to generator sets, sensor terminals corresponding to transformers, sensor terminals corresponding to distribution switches, etc.), and their respective data transmission protocols (such as IEC61850, Modbus-RTU, DL / T 645, MQTT, etc.) differ significantly. Dynamic protocol parsing is performed on the heterogeneous data of power generation access entities, specifically including the following processes: Figure 5 As shown, Figure 5 The process of dynamic protocol parsing is illustrated, including S11 to S16;

[0151] S11 is a dedicated protocol template library for the power industry, covering mainstream standard protocols and vendor-defined protocols. Each protocol template is a complete set of parsing rules. The template stores all the information required for parsing, such as protocol field definitions (field name, data type, length, offset), verification rules (CRC, XOR check), and data frame format (start character, address field, function code, data field, end character), in a structured format. It supports importing new protocol templates through the cloud-based management platform without modifying the underlying parsing code.

[0152] S12 supports importing new protocol templates into the cloud platform. New protocol templates, which contain complete parsing information such as field definitions, verification rules, and data frame formats, are confirmed by administrators and updated to the protocol template library, thus updating the power-specific protocol template library.

[0153] S13 is a pluggable architecture design parsing engine. When a power production access entity connects, the engine uses the device's identity identifier (such as the device serial number or Media Access Control Address (MAC address)) to query the corresponding protocol type in an independent "device identifier-protocol template" mapping table maintained on the cloud side or in the device registration information database, thereby automatically matching the protocol template.

[0154] S14. Automatic backpropagation when protocol mismatch occurs. Specifically, if no corresponding protocol type is found, the "protocol detection process" is triggered. This involves sending a protocol detection frame to the edge, and inferring protocol features such as frame delimiters, address field format and location, function codes, data field length identifiers, and verification algorithms and locations based on the returned frame structure. Fuzzy matching (based on feature similarity calculation) is then performed with the protocol template library. If a match is found, the corresponding template is used. If multiple candidate templates are matched, the one with the highest confidence is selected or reported for manual confirmation. If no matching template is found, it is determined to be a new protocol. The system dynamically constructs a "minimum available parser" containing the inferred frame structure, field extraction rules, and verification methods as a temporary parsing rule based on the detection results, instead of directly using existing rules in the template library. Simultaneously, the inferred new protocol features and complete structural information are uploaded to the cloud side. After confirmation by administrators, this is standardized into a new protocol template containing complete parsing information such as field definitions, verification rules, and data frame formats, and updated to the protocol template library, achieving "adaptation upon access."

[0155] S15, Data Standardization Conversion. The parsed raw data (such as current, voltage, temperature, switch status, etc.) is converted into standardized JSON format according to the power production data model (refer to IEC61970CIM standard).

[0156] S16. Standardize field naming units and precision. For example, standardize field naming (e.g., "generator_3_phase_current_a" represents the A-phase current of generator set No. 3), data units (e.g., A for current, kV for voltage), and precision (e.g., retain 2 decimal places) to ensure that different modules on the cloud side can directly call data.

[0157] S2, Layered Filtering and Noise Reduction Processing. The power IoT cloud server performs layered filtering and noise reduction on the parsed standardized data according to QoS levels.

[0158] In some embodiments, the parsed standardized data is divided into three levels according to QoS requirements: High QoS data, i.e., real-time monitoring data (such as generator stator current and transformer oil temperature), uses the Kalman filter algorithm to establish data state equations (such as current change models) and observation equations, corrects measurement noise in real time, and quickly tracks dynamic changes in data to ensure the real-time performance and accuracy of the filtered data; Medium QoS data, i.e., periodic statistical data, uses sliding window mean filtering, sets the window size (such as 5 data points), removes extreme values ​​from the data within the window, and calculates the mean to balance the filtering effect and computational complexity; Low QoS data, i.e., log data, does not have strict real-time requirements, uses wavelet transform filtering, separates signals and noise through multi-scale decomposition, performs threshold suppression on high-frequency noise components, preserves data detail features, and is suitable for noise reduction processing of non-stationary noise.

[0159] After filtering and noise reduction are completed in the cloud, the cloud does not return all the processed probe data to the edge. Instead, it only returns the data quality assessment results (including abnormal data identifiers) and adaptive compression control instructions to the corresponding access entity that sent the data. The original data after filtering and noise reduction is directly stored in the real-time data cache area on the cloud side for subsequent global status monitoring, historical trend analysis and model training.

[0160] In some embodiments, filtering and noise reduction are performed by the power IoT cloud server because the computing power of the power production access entity is limited, making it impossible to efficiently complete large-scale, multi-dimensional layered filtering and noise reduction (especially for noise elimination of multiple associated devices). Moreover, the cloud performs data quality assessment first, which can accurately identify invalid data and noise, guiding the edge to transmit only valid data, saving more than 30% of bandwidth compared to the solution of directly compressing and transmitting data at the edge. In addition, the compression control instructions generated by the cloud based on global data are more reasonable than the local decision-making at the edge, and can achieve optimal allocation of bandwidth across the entire network.

[0161] On the access entity side, after receiving the adaptive compression control command, it can perform adaptive data compression and transmission control according to the data type and real-time bandwidth status to form a transmission data stream that can be processed in real time by the cloud side (i.e., the transmission data of this application).

[0162] The adaptive compression control command sent from the cloud to the edge can include the following core parameters: data classification identifier (corresponding to high / medium / low QoS levels); recommended compression algorithm (such as Delta encoding + LZ77, Zstandard, Gzip); dynamic compression level (levels 1-22, adjusted according to real-time bandwidth status); data sampling rate (for non-critical data); transmission time window and priority.

[0163] S3, Adaptive Data Compression and Transmission Control. Specifically, the access entity performs adaptive data compression and transmission control on the collected raw data.

[0164] In some embodiments, for numerical data (such as current and voltage), the access entity can use Delta encoding + LZ77 compression. Specifically, the difference (Delta value) between the current data and the previous data is first calculated to reduce data redundancy, and then the Delta value sequence is compressed using the LZ77 algorithm. For binary data (such as equipment fault waveforms), the Zstandard compression algorithm can be used, which supports configurable compression levels (1-22 levels). Lower levels (1-5 levels) focus on compression speed and are suitable for high QoS data, while higher levels (6-22 levels) focus on compression ratio and are suitable for low QoS data. For textual data (such as logs), Gzip compression can be used, combined with a power-specific dictionary (containing high-frequency words such as "trip" and "overload") to optimize compression efficiency.

[0165] In some embodiments, the power production access entity monitors its uplink transmission bandwidth to the cloud server in real time (obtained by periodically sending bandwidth probe packets) and establishes a "bandwidth-compression ratio" mapping model: when the bandwidth is ≥ a preset threshold (e.g., 10Mbps), the compression ratio is reduced (e.g., using Zstandard Level 3) to prioritize processing and uploading speed; when the bandwidth is < a preset threshold, the compression ratio is increased (e.g., using Zstandard Level 10) to reduce data transmission volume and alleviate network pressure.

[0166] In some embodiments, after data compression at the edge, a "priority queue + traffic shaping" mechanism can be used for data transmission. That is, high QoS data enters the high priority queue and is transmitted first; medium and low QoS data enters the low priority queue and is transmitted when bandwidth is idle; traffic shaping controls the data transmission rate through the token bucket algorithm to avoid a large amount of data impacting the network in a short period of time and ensure transmission stability.

[0167] S4, multi-dimensional task priority assessment and decomposition.

[0168] In some embodiments, the power IoT cloud server can construct a multi-dimensional task priority evaluation model to determine the data processing tasks corresponding to the transmitted data and to determine the task priority of the data processing tasks.

[0169] For example, task categories are first defined based on the attribute labels of the transmitted data stream. For instance, based on the QoS classification metadata (such as "high QoS - real-time monitoring" and "low QoS - non-real-time statistics") and data type labels (such as "fault diagnosis data" and "historical report data") carried by the transmitted data stream, cloud-side data processing tasks are precisely divided into four categories: fault diagnosis tasks, real-time control tasks, status monitoring tasks, and historical analysis tasks.

[0170] Next, the content of the corresponding feature metadata (i.e., the content of the target field) is determined according to the task category, and the priority is calculated based on the content of the feature metadata. For example, a "task priority assessment metadata dictionary" is predefined in the cloud. This dictionary is based on the power production business logic and standard data model (such as IEC 61970 CIM) and clarifies the key status fields necessary for assessing indicators such as task urgency, scope of impact, data dependence and business value (for example, for fault diagnosis data, its specific metadata may include fault code (Fault_Code), device number (Device_ID), timestamp (Timestamp) etc.).

[0171] A reinforcement learning algorithm is employed, using real-time metadata from the transmitted data stream (such as a vector composed of fields like "grid status," "fault codes," and "load rate") as the state (s_t) input. The action (a_t) is defined as the adjustment ΔW to the weight vector W = [w_e, w_s, w_d, w_v] of each evaluation indicator (corresponding to urgency, impact range, data dependency, and business value, respectively). The reward function (r_t) is designed based on the quantitative analysis of power safety indicators, for example: r_t = α * ΔT + β * U, where ΔT is the reduction in fault response time (negative values ​​indicate reduction), U is the improvement in resource utilization, and α and β are positive coefficients.

[0172] The weights of various evaluation indicators are dynamically adjusted through online learning. The core update mechanism can adopt an actor-critic mechanism, where the critic network evaluates the state value using a value function V, with a loss function of L_v=(R_t-V(s_t))^2, where R_t is the discounted cumulative reward and V(s_t) is the value function value. The actor network (policy function π) outputs the action probability, with a loss function (policy gradient) of L_π=-logπ(a_t|s_t)×A(s_t, a_t), where the advantage function A(s_t, a_t)=R_t-V(s_t). Network parameters are updated through asynchronous multi-threaded interaction.

[0173] Through the above embodiments, the weights w_e, w_s, w_d, and w_v corresponding to urgency, scope of impact, data dependence, and business value are no longer fixed, but are adaptively optimized according to real-time task load and power grid status. The final priority score is the weighted sum of the scores f_i of each indicator and the dynamic weight w_i, i.e., Priority_Score=Σ(f_i×w_i), where i∈{e, s, d, v}. The calculation result is normalized to the (0,1) range by the Sigmoid function. A score ≥0.8 is the highest priority, 0.6-0.8 is high priority, 0.4-0.6 is medium priority, and <0.4 is low priority.

[0174] Task priority is used to determine the processing order and resource allocation weight of tasks. For example, after the priority is determined, the highest priority task immediately preempts computing resources and interrupts the currently executing low priority task; high priority tasks are queued and executed in priority order, and the remaining resources are allocated first; medium priority tasks are executed sequentially during the intervals between high priority tasks; low priority tasks are executed only when the cloud side resource utilization rate is <50%; the resource scheduling module dynamically allocates memory and network bandwidth resources according to task priority, and the higher the priority, the more resource quota is allocated.

[0175] For example, suppose at a certain moment, the data stream status s_t displays "Power Grid Status" as "Warning" and the "Fault Code" is not empty. The actor network outputs action a_t according to policy π: increasing the urgency weight w_e by 0.3, and fine-tuning other weights, resulting in weight W = [0.7, 0.1, 0.1, 0.1]. The initial priority scores of various indicators for a certain fault diagnosis task are evaluated as [f_e, f_s, f_d, f_v] = [0.9, 0.8, 0.6, 0.7], then its priority score is: 0.9 × 0.7 + 0.8 × 0.1 + 0.6 × 0.1 + 0.7 × 0.1 = 0.84. After normalization, the score is > 0.8, so it is determined to be the highest priority task and is immediately scheduled. After the task is completed quickly, the system calculates the reward r_t (e.g., a high reward for a fast response), and then optimizes the actor-commentator network parameters through the above update formula, making the policy more inclined to increase the urgency weight in similar states.

[0176] Task decomposition is performed based on the edge resource status fed back from the transmitted data stream, specifically including the following processes:

[0177] Edge resource status monitoring: Real-time status is obtained based on the "resource metadata field" of the transmitted data stream;

[0178] The cloud side periodically parses the resource information uploaded by the edge by feeding back metadata fields of the resource status in the transmitted data stream. The power production access entity will encapsulate the real-time resource status into the reserved metadata fields of the transmitted data stream (separate from the business data fields, so as not to affect the transmission of business data). The cloud side does not need to establish an additional communication channel and can directly obtain the following information by parsing this field:

[0179] Computing resources: The data stream is labeled with "CPU_utilization: 65%" (≤70% threshold, considered usable) and "Memory_usage: 55%" (≤60% threshold, considered usable); Storage resources: The data stream is labeled with "Local_cache_remaining: 8GB". The cloud side determines whether the storage resources are sufficient based on the temporary data volume requirements of the task (e.g., a simple task requires 2GB of cache); Network resources: The data stream is labeled with "Upstream_bandwidth: 3Mbps". The cloud side determines whether the bandwidth is sufficient for the backhaul requirements based on the amount of data returned from the task (e.g., 100KB of feature data needs to be returned after edge preprocessing).

[0180] If the data stream fails to upload resource metadata on time (e.g., due to network outage), the cloud side determines the edge resource status as "unavailable" and suspends task delivery to avoid task execution failure.

[0181] Subsequently, the difficulty of the task was quantified based on the "business metadata field" of the transmitted data stream.

[0182] In some embodiments, a task complexity model can be established, with the core evaluation metrics derived from the business metadata fields labeled in the transmitted data stream. These business metadata fields can be labeled in a layered and collaborative manner: First, at the access entity or gateway side, based on pre-defined rules (such as the algorithm complexity corresponding to sensor type) or lightweight model inference, source labeling is performed on the data to generate basic attributes (such as data volume and data type); second, during the cloud-side data standardization phase, enhanced labeling is performed based on a unified data model (such as IEC 61970 CIM) and context (such as data source device and acquisition frequency) to supplement business semantics (such as business type and dependencies); finally, during cloud-side task generation, the complete set of business metadata is determined by integrating the data metadata and task attributes (such as the complexity of the called algorithm modules).

[0183] Then, a task complexity model is established to evaluate the task complexity based on business metadata fields. For example, business metadata fields may include data volume, computation steps, and dependencies. The task complexity is calculated as follows:

[0184] Regarding data volume: Parse the “Data_volume” metadata field of the transmitted data stream—if the field is marked “5MB (single device current statistics)”, it is determined to be a simple task; if it is marked “200MB (power output correlation data of wind farms across the entire network)”, it is determined to be a complex task.

[0185] For the computation steps: parse the "Algorithm_complexity" metadata field of the transmitted data stream—if the field is labeled "O(n) (mean calculation)," it is determined to be a simple task; if it is labeled "O(n²) (vibration data deep learning feature extraction)," it is determined to be a medium task.

[0186] Regarding dependencies: Parse the metadata field "Data_source" of the transmitted data stream—if the field is marked "Single_edge_device:ID_123" (depending only on data from access entity 1), it is determined to be a simple task; if it is marked "Multi_edge_stations:[Station_A,Station_B]" (depending on data from both stations A and B), it is determined to be a complex task.

[0187] Complexity scores are calculated by weighting "data volume (40% weight) + computation steps (30% weight) + dependencies (30% weight)" with a score range of 0-1, classifying task difficulty levels. In the cloud-edge collaboration scenario of power production, the weight allocation of "data volume (40%), computation steps (30%), and dependencies (30%)" is a scientific result derived from being guided by "the core bottleneck of the access entity," constrained by "the core objectives of cloud-edge collaboration (real-time performance, accuracy, and resource efficiency)," and verified in conjunction with actual power production scenarios.

[0188] Task complexity is the core basis for determining the task processing deployment method. For low-complexity tasks (complexity score < 0.3, such as simple threshold judgment and data acquisition control), they can be preferentially assigned to the access entity for processing. For medium-complexity tasks (complexity score 0.3-0.7, such as single device status prediction and local data statistics), a collaborative processing method of "edge preprocessing + cloud-side fine processing" can be adopted. For high-complexity tasks (complexity score > 0.7, such as network-wide fault diagnosis and global resource optimization), they can all be processed by the cloud.

[0189] Of course, when edge resources are insufficient, even low-complexity tasks can be processed by the cloud; when the cloud load is too high, some medium-complexity tasks can be processed by the edge.

[0190] Finally, using the transmitted data stream as the carrier for "protocol delivery / result feedback," and based on the matching results of "edge resource status (from the data stream) + task complexity (from the data stream)," decomposition rules are formulated, and the entire process is executed through the transmitted data stream. The decomposition rules employ multi-objective optimization algorithms (such as the Non-dominated Sorting Genetic Algorithm (NSGA)) to minimize latency, maximize resource utilization, and maximize accuracy. The input data is the business metadata fields of the transmitted data stream (such as data volume and computation steps), and the output is a Pareto-optimal decomposition strategy, for example:

[0191] For simple tasks (complexity score < 0.3), if the data stream indicates that edge resources are available (e.g., CPU utilization 60%, bandwidth 3Mbps), then the task description (processing algorithm: mean calculation, parameters: 10s window, result format: JSON) is encapsulated in the "Task_Instruction" field of the data stream and sent to the edge. After the edge completes the processing, only "abnormal results" (e.g., average current exceeding 500A) are encapsulated in the "Result" field of the data stream and sent back to the cloud side (normal results are stored locally to reduce the amount of data stream transmission).

[0192] For medium-level tasks (complexity score 0.3-0.7), the process is broken down into "edge preprocessing + cloud-side refinement". The cloud sends a "preprocessing algorithm (such as time-domain feature extraction of vibration data)" to the edge via the "Task_Instruction" field of the data stream. The edge encapsulates the preprocessed feature data (such as frequency and amplitude) into the "Preprocessed_Data" field of the data stream and uploads it to the cloud. The cloud parses this field and combines it with the feature data from multiple edge devices to complete the "refinement" (such as fault diagnosis).

[0193] For complex tasks (complexity score > 0.7), the cloud side sends "data collection instructions" (such as collecting full network load data) only to the edge via the "Task_Instruction" field of the data stream. The edge compresses the collected raw data and uploads it to the cloud side via the "Raw_Data" field of the data stream for unified processing by the cloud side (such as full network load prediction).

[0194] After disassembly, the cloud side verifies the integrity and accuracy of the edge results by parsing the checksum (such as CRC check) of the "Result" or "Preprocessed_Data" field of the transmitted data stream, ensuring that the disassembly task is executed effectively.

[0195] S5, predictive scheduling of cloud computing resources.

[0196] In some embodiments, a resource demand forecasting model can be used for demand forecasting; specifically, the core input is the "historical task execution records and real-time power grid operation status" of the transmitted data stream; wherein, the historical archived metadata mainly includes task characteristics and resource consumption records such as task number, task type, task priority, CPU utilization, memory utilization, processing time, input data volume, and start timestamp archived in chronological order; the real-time status metadata mainly includes power grid operation characteristic fields such as power grid status, load rate, and error codes parsed from the real-time data stream, as well as time characteristics such as time period and date type mapped by the timestamp.

[0197] Resource demand forecasting models can employ LSTM (Long Short-Term Memory) models. The input features of LSTM models are derived from the "historical archive" and "real-time transmission fields" of the transmitted data stream, without relying on other independent data channels. The specific logic for obtaining input features is as follows:

[0198] Historical task data: The power IoT cloud server archives the "task metadata" carried by the data stream according to the time dimension (such as hourly). The LSTM model reads the archived data of the past hour and counts the number of tasks of each priority and the average resource consumption.

[0199] Power grid operation characteristics: Access entities (such as substations and wind farms) will encapsulate real-time power grid data into metadata fields of the transmitted data stream, such as the "Grid Status (Grid_Status)" field. The model reads this field in real time to obtain the current power grid operation status.

[0200] Time characteristics: Combined with the "timestamp field" of the transmitted data stream, it is automatically mapped to "time period" and "date type (such as ordinary day)".

[0201] The model outputs the estimated number of tasks of each priority level in the next 10 minutes (e.g., "15 highest priority tasks are expected") and the estimated resource requirements (e.g., "12 CPU cores and 8GB of memory are required"), with a prediction accuracy of ≥85%. The output results will be synchronously written to the "Resource_Prediction" field of the transmitted data stream to provide a basis for subsequent resource allocation.

[0202] Based on this, dynamic adaptation is performed using "real-time task metadata" from the transmitted data stream. For example, based on the prediction results of the LSTM model and combined with the "task arrival status" parsed in real time from the transmitted data stream, a "priority-first + resource reservation" strategy is adopted. Resource allocation is linked with the transmitted data stream throughout the entire process. For the highest priority tasks, the power IoT cloud server monitors the arrival status of fault diagnosis and real-time control tasks in real time through the transmitted data stream (such as "equipment short circuit detection task has arrived, requiring 2 CPU cores"). At the same time, 30% of the cloud-side peak resources (such as 30% of the number of CPU cores) are reserved according to the prediction results to ensure that computing power can be allocated immediately from the reserved resource pool when the task arrives, avoiding waiting.

[0203] For high / medium priority tasks, the power IoT cloud server parses the "real-time task quantity" field (e.g., "currently 10 high priority tasks and 20 medium priority tasks") contained in the transmitted data stream and adopts "on-demand allocation". For example, every 50ms, the resource ratio is adjusted according to the field value (e.g., when high priority tasks increase, 2 CPU cores are temporarily allocated from the low priority resource pool). Resource allocation is based on "containerization". The container parameters (CPU / memory) of each task are sent to the cloud-side resource management module through the "Container_Config" field of the transmitted data stream. When container resources are insufficient, expansion is triggered within 100ms through this field.

[0204] For low-priority tasks, the power IoT cloud server provides real-time feedback on cloud-side resource utilization through the "resource utilization" field included in the transmitted data stream, such as "CPU_Utilization: 45%". Tasks (such as monthly report generation) are allocated to the idle resource pool only when the utilization rate is less than 50%, thus avoiding impacting high-priority tasks.

[0205] In addition, in some embodiments, the power IoT cloud server can also perform overload warnings and adjustments; for example, the power IoT cloud server monitors the cloud-side resource utilization rate in real time, and, in conjunction with the "resource warning field" and "edge resource feedback field" of the transmitted data stream, triggers targeted adjustment strategies to ensure that overload handling can be implemented.

[0206] Specifically, the power IoT cloud server generates real-time "cloud resource status" metadata (such as "CPU_Utilization: 92%), which is encapsulated in the "load warning" field of the transmitted data stream. When the field value is ≥90%, an overload warning is triggered. When an overload warning is triggered, the "Task_Type_Overload" field of the transmitted data stream (such as "High_Priority_Task_Count: 25, accounting for 80% of total resources") is used to determine whether the overload is caused by high-priority tasks. If the field shows that the proportion of high-priority tasks is ≥70%, it is determined as "high-priority task overload"; otherwise, it is "medium-low priority task overload".

[0207] If high-priority tasks are overloaded, the cloud side sends resource call instructions (such as "call 4-core CPU and 2GB memory") to the Elastic Cloud Server through the "Standby_Resource_Call" field in the transmitted data stream, with an expansion time of ≤1s; if medium- and low-priority tasks are overloaded, the cloud side pauses low-priority tasks (such as historical report generation) through the "Low_Priority_Task_Pause" field in the transmitted data stream, and the released resources are allocated to high-priority tasks through the "Resource_Reallocate" field.

[0208] If the overload continues (overload exceeds 30 seconds), the cloud side parses the "Edge_Resource_Feedback" field of the transmitted data stream (e.g., "Edge Average CPU_Utilization: 40%, Bandwidth: 5Mbps"), and after determining that there are remaining edge resources, it increases the task splitting ratio through the "Task_Split_Ratio_Adjust" field (e.g., increasing the splitting ratio of medium tasks from 50% to 70%). At the same time, it sends a description of the newly added splitting task to the edge and encapsulates it in the "Task_Instruction" field to reduce the pressure on the cloud side.

[0209] S6 enables real-time processing and analysis of cloud-based data.

[0210] In some embodiments, a graph neural network (GNN) algorithm can be introduced, treating access entities as graph nodes and power grid topology data as edge relationships. The GNN learns the influence between nodes and optimizes the task distribution path. Based on the containerized resources allocated by predictive scheduling (such as the 30% peak CPU / GPU reserved for the highest priority task), the distribution is completed through a "data-resource mapping engine".

[0211] For example, read the "Task_Priority" metadata of the data stream (such as "highest priority - fault diagnosis"), route it to a dedicated computing container reserved for that priority (such as a fault diagnosis container equipped with a GPU); synchronously verify the integrity of the data stream (such as CRC check); if data is missing, trigger a retransmission mechanism (only retransmit the missing segments to avoid full retransmission) to ensure that the processed data is not damaged.

[0212] For tasks of different priorities, appropriate computing modules are invoked to complete real-time processing based on scheduling resources, which is closely aligned with the needs of power business. For example, the highest priority tasks (such as fault diagnosis tasks) invoke pre-deployed "multimodal fault diagnosis models" (such as CNN-LSTM hybrid models), input characteristic data such as equipment vibration, current, and temperature from the data stream, and output the fault type (such as short circuit, insulation aging) and risk level within 100ms, triggering alarms simultaneously; high priority tasks (such as real-time control tasks) invoke "grid load coordination algorithms", input the load data of the entire network, calculate the output adjustment value of each plant within 500ms, and generate standardized control instructions; medium priority tasks (such as equipment parameter statistics tasks) invoke lightweight statistics modules (such as sliding window analysis), and output the operating trend within 1 second; low priority tasks (such as monthly report tasks) invoke idle resources to complete data aggregation in batches without affecting high priority tasks.

[0213] In some embodiments, to avoid single-module calculation errors, key results can be verified in multiple dimensions; for example, the calculation results of multiple sets of data for the same task can be compared (such as whether the current and voltage fault characteristics of the same device are consistent), and recalculation can be performed when the error exceeds 0.5%; the real-time control results can be correlated with the power grid topology data to verify whether the output adjustment meets the power grid carrying capacity limit (such as line load rate ≤ 80%); the results that pass the verification are marked as "valid results", and those that fail are triggered to "resource supplementary calculation" for recalculation.

[0214] Understandably, since critical data in power production is collected simultaneously by multiple redundant sensors, the same task will process multiple sets of data from different sensors that share the same source. Furthermore, complex tasks are broken down into multiple sub-tasks, assigned to different access entities for parallel computation, generating multiple sets of intermediate results. Additionally, for tasks with high reliability requirements, the same task will be assigned to 2-3 different access entities for computation, with results verified through a majority voting mechanism. Therefore, the same task can produce multiple sets of data computation results.

[0215] After obtaining the data processing results, control instructions can be generated based on the data processing results and then sent to the edge for execution.

[0216] In addition, in some embodiments, the processing results of medium-level tasks (such as monthly reports and device status trends) can be archived to the cloud-side database to provide historical samples for subsequent resource demand prediction; and the actual processing time and resource utilization of each priority task (such as "the highest priority task actually occupies 2 CPU cores and takes 80ms") can be fed back to the LSTM prediction model to optimize the accuracy of the next round of resource demand prediction.

[0217] In some embodiments, a standardized data parsing engine can be built based on the unified power IoT model protocol stack built into the power IoT operating system. This engine incorporates parsing templates for mainstream power protocols such as IEC 61850, Modbus-RTU, DL / T 645, MQTT, and OPC UA, supporting dynamic loading and hot updates of protocol templates. When data from a power IoT smart terminal is accessed, the system automatically identifies the protocol type, matches the corresponding parsing template to complete data frame parsing, field extraction, and format conversion, uniformly converting heterogeneous data into JSON format conforming to the power IoT data model standard, achieving cross-vendor and cross-device data semantic interoperability. The unified power IoT model protocol parsing supports automatic protocol detection and reverse inference; for unknown protocols, it can automatically identify protocol characteristics through feature matching and generate a temporary parser, achieving immediate adaptation upon access.

[0218] In some embodiments, the device self-discovery and self-registration mechanism of the power IoT operating system can enable zero-configuration access for terminal devices. After power-on, the power IoT smart terminal automatically sends a device discovery broadcast. Upon receiving this broadcast, the power IoT edge node initiates a device authentication process to verify the device's identity and integrity. After successful authentication, the power IoT edge node automatically allocates network resources, data channels, and computing resources to the terminal and reports the device's capability description and resource configuration information to the power IoT cloud platform. The power IoT cloud platform completes device registration and resource scheduling. The entire process requires no manual intervention, enabling plug-and-play functionality for terminal devices. It also supports hot-swapping and dynamic expansion of devices; resources are automatically released when a device goes offline, and the configuration is automatically restored upon re-entry.

[0219] In some embodiments, a full-stack trusted security system from terminal to cloud can be constructed based on the trusted computing root of the power IoT operating system. At the power IoT smart terminal hardware layer, a Trusted Platform Module (TPM) is used to achieve unique device identification and hardware-level trusted measurement. At the operating system layer, secure boot, integrity verification, and access control mechanisms ensure the trusted operation of the operating system kernel and critical services. At the application layer, application signature authentication and sandbox isolation are implemented. At the data transmission layer, end-to-end encrypted transmission is achieved using national cryptographic algorithms SM2 / SM3 / SM4. At the power IoT cloud platform layer, data integrity verification, security auditing, and abnormal behavior detection are implemented. End-to-end trusted measurement ensures the integrity and security of each layer, constructing a defense-in-depth system for the power IoT.

[0220] In the aforementioned application scenarios, the power IoT operating system is completely autonomous and controllable, ensuring the security and controllability of critical power infrastructure. Simultaneously, it supports automatic access for power IoT smart terminals with zero configuration, significantly reducing the labor and time costs of large-scale deployment and improving system scalability. Furthermore, by constructing a three-layer collaborative architecture for power IoT cloud-edge-device, it achieves dynamic scheduling of computing resources and intelligent task distribution, improving the real-time performance of data processing and overall system efficiency. Moreover, the unified model protocol for power IoT enables automatic parsing of multiple protocols and data standardization, solving the problem of data interoperability between heterogeneous devices and reducing system integration complexity. Finally, through the power IoT full-stack trusted security system, it achieves end-to-end security protection from hardware to applications, meeting the high security requirements of power systems.

[0221] It should be understood that although the steps in the flowcharts of the above embodiments are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the above embodiments may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages in other steps. It is understood that the steps in different embodiments can be freely combined as needed, and all non-contradictory solutions formed by such combinations are within the scope of protection of this application.

[0222] Based on the same inventive concept, this application also provides a cloud-edge collaborative data processing device based on a power IoT operating system for implementing the aforementioned cloud-edge collaborative data processing method based on a power IoT operating system. The solution provided by this device is similar to the solution described in the above method. Therefore, the specific limitations of one or more embodiments of the cloud-edge collaborative data processing device based on a power IoT operating system provided below can be found in the limitations of the cloud-edge collaborative data processing method based on a power IoT operating system described above, and will not be repeated here.

[0223] In one exemplary embodiment, such as Figure 6 The diagram illustrates a cloud-edge collaborative data processing device 500 based on a power IoT operating system. This device is applied to a power IoT cloud server. The power IoT cloud server and access entities constitute the power IoT operating system. The access entities include power IoT smart terminals and power IoT edge nodes, including:

[0224] The acquisition module 501 is used to acquire transmission data sent by the access entity in the power system.

[0225] The task generation module 502 is used to determine the task type for the data processing task of the transmitted data based on the service quality classification identifier and data type label contained in the transmitted data.

[0226] The first processing module 503 is used to determine the task priority and task complexity of the data processing task based on the data under the target field in the transmitted data; wherein, the target field is determined based on the task type.

[0227] The second processing module 504 is used to determine the task processing strategy for the data processing task based on the task complexity of the data processing task and the device status information of the access entity.

[0228] The execution module 505 is used to perform resource scheduling and task processing for data processing tasks based on predicted resource requirements, task priorities, and task processing strategies, and to obtain the data processing results of the data processing tasks; wherein, the predicted resource requirements are determined by the power IoT cloud server based on the execution records of historical data processing tasks.

[0229] In some embodiments, the acquisition module 501 is used to acquire probe data sent by an access entity in the power system; parse the probe data based on data parsing protocols contained in a preset protocol template library to obtain parsed data; the preset protocol template library contains multiple data parsing protocols; perform data evaluation processing based on the parsed data to determine the data quality evaluation result and data compression instruction for the access entity; wherein, the data evaluation processing includes at least a service quality classification; return the data quality evaluation result and data compression instruction to the access entity; and receive the transmission data sent by the access entity after processing the original data collected by the access entity based on the data quality evaluation result and data compression instruction.

[0230] In some embodiments, the target field includes multiple first service fields for determining task priority and multiple second service fields for determining task complexity; the first processing module 503 is configured to: determine the initial priority score of each first service field based on the data under each first service field in the transmitted data; determine the priority weight corresponding to each first service field based on the operating status data of the power system; perform weighted fusion of the initial priority scores of each first service field based on the priority weight corresponding to each first service field to obtain the task priority of the data processing task; determine the initial complexity score of each second service field based on the data under each second service field in the transmitted data; and perform weighted fusion of the initial complexity scores of each second service field based on the preset weight of each second service field to obtain the task complexity of the data processing task.

[0231] In some embodiments, the first processing module 503 is specifically used to take the operating status data of the power system as input to the decision network, and the decision network outputs the priority weights corresponding to each first business field; the cloud-edge collaborative data processing device 500 based on the power IoT operating system also includes an optimization module, which is used to calculate the target reward value based on the preset reward function and the data processing results of the data processing task; and update the parameters of the decision network based on the target reward value.

[0232] In some embodiments, the second processing module 504 is used to determine the task processing strategy for the data processing task as the first processing strategy when the task complexity is indicated as a first type of task and the equipment status information of the access entity in the power system indicates that the access entity has sufficient computing resources; the first processing strategy is for the access entity to perform task processing; the execution module 505 is used to have the access entity perform resource scheduling and task processing for the data processing task based on predicted resource requirements and task priorities, and obtain the data processing result of the data processing task.

[0233] In some embodiments, the second processing module 504 is used to determine the task processing strategy for the data processing task as a second processing strategy when the task complexity indication is a second type of task; the second processing strategy is to be processed collaboratively by the access entity and the power IoT cloud server; the execution module 505 is used to coordinate resource scheduling and task processing for the data processing task by the access entity and the power IoT cloud server based on predicted resource requirements and task priorities, so as to obtain the data processing result of the data processing task.

[0234] In some embodiments, the second processing module 504 is used to determine the task processing strategy for the data processing task as a third processing strategy when the task complexity indication is a third type of task; the third processing strategy is to have the task processed by the power IoT cloud server; the execution module 505 is used to have the power IoT cloud server perform resource scheduling and task processing for the data processing task based on predicted resource requirements and task priorities, and obtain the data processing result of the data processing task.

[0235] In some embodiments, the cloud-edge collaborative data processing device 500 based on the power IoT operating system further includes a prediction module, used to acquire the execution records of historical data processing tasks and the current power grid operating status information; the power grid operating status information is used to describe the operating status of the power grid corresponding to the power system; data is extracted based on the execution records of historical data processing tasks to obtain historical task feature data; features are extracted based on the current power grid operating status information to obtain operating features; and resource demand is predicted based on the historical task feature data and operating features to obtain predicted resource demand.

[0236] The modules in the aforementioned cloud-edge collaborative data processing device based on the power IoT operating system can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device, or stored in the memory of a computer device as software, so that the processor can call and execute the corresponding operations of each module.

[0237] In one exemplary embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 7As shown, this computer device includes a processor, memory, input / output (I / O) interfaces, and a communication interface. The processor, memory, and I / O interfaces are connected via a system bus, and the communication interface is also connected to the system bus via the I / O interfaces. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and a database. The internal memory provides the environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The database stores data related to power production. The I / O interfaces are used for information exchange between the processor and external devices. The communication interface is used for communication with external terminals via a network connection. When the computer program is executed by the processor, it implements a cloud-edge collaborative data processing method based on a power IoT operating system.

[0238] Those skilled in the art will understand that Figure 7 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0239] In one exemplary embodiment, a computer device is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps of the method described above.

[0240] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, implements the steps of the above-described method.

[0241] In one embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps of the method described above.

[0242] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of the relevant data must comply with relevant regulations.

[0243] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile memory and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, artificial intelligence (AI) processors, etc., and are not limited to these.

[0244] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this application.

[0245] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A cloud-edge collaborative data processing method based on a power IoT operating system, characterized in that, The method, applied to a power IoT cloud server, wherein the power IoT cloud server and access entities constitute a power IoT operating system, and the access entities include power IoT smart terminals and power IoT edge nodes, includes: Acquire transmission data sent by entities connected to the power system; Based on the service quality classification identifier and data type label contained in the transmitted data, determine the task type for the data processing task for the transmitted data; Based on the data under the target field in the transmitted data, the task priority and task complexity of the data processing task are determined; wherein, the target field is determined based on the task type; Based on the task complexity of the data processing task and the device status information of the access entity, a task processing strategy is determined for the data processing task. Based on the predicted resource requirements, the task priority, and the task processing strategy, resource scheduling and task processing are performed for the data processing task to obtain the data processing result of the data processing task; wherein, the predicted resource requirements are determined by the power IoT cloud server based on the execution records of historical data processing tasks.

2. The method according to claim 1, characterized in that, The acquisition of transmission data sent by the access entity in the power system includes: Acquire probe data sent by entities connected to the power system; The probe data is parsed based on the data parsing protocols contained in the preset protocol template library to obtain parsed data; the preset protocol template library contains a variety of data parsing protocols; Based on the parsed data, data evaluation processing is performed to determine the data quality evaluation result and data compression instructions for the access entity; wherein, the data evaluation processing includes at least a service quality classification. Return the data quality assessment result and the data compression instruction to the access entity; The system receives transmission data sent by the access entity after processing the raw data collected by the access entity based on the data quality assessment results and the data compression instructions.

3. The method according to claim 1, characterized in that, The target field includes multiple first business fields for determining task priority and multiple second business fields for determining task complexity; The step of determining the task priority and task complexity of the data processing task based on the data under the target field in the transmitted data includes: Based on the data under each of the first service fields in the transmitted data, determine the initial priority score of each of the first service fields; Based on the power system's operating status data, determine the priority weight corresponding to each of the first business fields. Based on the priority weights corresponding to each of the first business fields, the initial priority scores of each of the first business fields are weighted and fused to obtain the task priority of the data processing task. Based on the data under each of the second service fields in the transmitted data, determine the initial complexity score of each of the second service fields; Based on the preset weights of each of the second business fields, the initial complexity scores of each of the second business fields are weighted to obtain the task complexity of the data processing task.

4. The method according to claim 3, characterized in that, The determination of the priority weight corresponding to each of the first business fields based on the power system's operating status data includes: The power system's operating status data is used as input to the decision network, which then outputs the priority weights corresponding to each of the first business fields. The method further includes: Calculate the target reward value based on the preset reward function and the data processing results of the data processing task; The decision network parameters are updated based on the target reward value.

5. The method according to claim 1, characterized in that, The process of determining a task processing strategy for the data processing task based on the task complexity of the data processing task and the equipment status information of the entities connected in the power system includes: If the task complexity indicator is a first type of task, and the device status information of the access entity in the power system indicates that the device of the access entity has sufficient computing resources, then the task processing strategy for the data processing task is determined to be a first processing strategy; the first processing strategy is that the access entity performs the task processing. Based on the predicted resource requirements, the task priority, and the task processing strategy, resource scheduling and task processing are performed for the data processing task to obtain the data processing result of the data processing task, including: The access entity performs resource scheduling and task processing for the data processing task based on the predicted resource requirements and the task priority, and obtains the data processing result of the data processing task.

6. The method according to claim 1, characterized in that, The process of determining a task processing strategy for the data processing task based on the task complexity of the data processing task and the equipment status information of the entities connected in the power system includes: When the task complexity indicator is a second type of task, the task processing strategy for the data processing task is determined to be a second processing strategy; the second processing strategy is that the access entity and the power IoT cloud server process the data collaboratively. Based on the predicted resource requirements, the task priority, and the task processing strategy, resource scheduling and task processing are performed for the data processing task to obtain the data processing result of the data processing task, including: The access entity and the power IoT cloud server, based on predicted resource requirements and task priorities, collaboratively perform resource scheduling and task processing for the data processing task to obtain the data processing result of the data processing task.

7. The method according to claim 1, characterized in that, The process of determining a task processing strategy for the data processing task based on the task complexity of the data processing task and the equipment status information of the entities connected in the power system includes: When the task complexity indicator is a third type of task, the task processing strategy for the data processing task is determined to be the third processing strategy; the third processing strategy is that the task is processed by the power IoT cloud server. Based on the predicted resource requirements, the task priority, and the task processing strategy, resource scheduling and task processing are performed for the data processing task to obtain the data processing result of the data processing task, including: The power IoT cloud server performs resource scheduling and task processing for the data processing task based on predicted resource demand and task priority, and obtains the data processing result of the data processing task.

8. The method according to any one of claims 1-7, characterized in that, Before performing resource scheduling and task processing for the data processing task based on predicted resource demand, task priority, and task processing strategy to obtain the data processing result of the data processing task, the method further includes: The system acquires historical data processing task execution records and current power grid operation status information; the power grid operation status information is used to describe the operation status of the power grid corresponding to the power system. Data is extracted based on the execution records of the historical data processing tasks to obtain historical task feature data; Based on the power grid operating status information at the current moment, feature extraction is performed to obtain operating features; Based on the historical task feature data and the operational features, resource demand is predicted to obtain the predicted resource demand.

9. A cloud-edge collaborative data processing device based on a power IoT operating system, characterized in that, The device is applied to a power IoT cloud server, wherein the power IoT cloud server and the access entity constitute a power IoT operating system, and the access entity includes power IoT smart terminals and power IoT edge nodes. The device includes: The acquisition module is used to acquire transmission data sent by access entities in the power system; The task generation module is used to determine the task type of the data processing task for the transmitted data based on the service quality classification identifier and data type label contained in the transmitted data. The first processing module is used to determine the task priority and task complexity of the data processing task based on the data under the target field in the transmitted data; wherein the target field is determined based on the task type; The second processing module is used to determine a task processing strategy for the data processing task based on the task complexity of the data processing task and the device status information of the access entity. The execution module is used to perform resource scheduling and task processing for the data processing task based on the predicted resource requirements, the task priority, and the task processing strategy, and to obtain the data processing result of the data processing task; wherein, the predicted resource requirements are determined by the power IoT cloud server based on the execution records of historical data processing tasks.

10. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 6.

Images