Edge-cloud collaborative real-time data processing method and system for Internet of Things

Abstract

The invention relates to the technical field of data processing, and provides a side-cloud collaborative Internet of Things real-time data processing method and system, and the method comprises the steps: processing Internet of Things data through an edge processing module in combination with a resource load state of an edge node and a cloud load state of control channel broadcast, and generating an edge feature; the dynamic transmission module comprehensively evaluates the emergency degree of the category identifier, the resource load state, the network quality and the cloud load state to generate an unloading strategy, so as to select a transmission channel and control the uploading of edge features; the cloud collaboration module receives and analyzes the edge features to generate cloud features, and generates configuration parameters including feature extraction granularity and processing priority; and the feedback optimization module optimizes the local weight of an unloading strategy for deviation categories which are greater than a difference threshold value in a plurality of continuous periods by accurately calculating the difference degree between the edge features and the cloud features, so that the dynamic correction of the edge-cloud collaborative deviation is realized, and the self-adaptive capability of the system is continuously improved.

Description

A method and system for real-time data processing in the Internet of Things with edge-cloud collaboration Technical Field

[0001] This application relates to the field of data processing technology, and in particular to a method and system for real-time data processing of the Internet of Things with edge-cloud collaboration. Background Technology

[0002] The number of IoT terminals in fields such as industrial monitoring, smart security, and environmental sensing is growing exponentially, generating massive, heterogeneous, and highly real-time data, which places stringent demands on low latency and high reliability in data processing. Edge-cloud collaborative architecture, with its advantages of local processing at edge nodes and centralized analysis in the cloud, has become the mainstream technology for solving the bottleneck of real-time data processing in the IoT. Existing technologies have gradually realized basic functions such as edge data preprocessing, in-depth analysis of cloud data, and preliminary selection of transmission channels, attempting to alleviate the computing power pressure on the cloud through edge computing and improve the integrity of data processing through cloud collaboration.

[0003] However, existing edge-cloud collaborative IoT real-time data processing technologies still have significant shortcomings, making it difficult to meet the needs of accurate collaboration and efficient processing in complex scenarios. Most of them adopt preset fixed processing rules, resulting in edge nodes being unable to balance resource utilization and data processing effects. Moreover, existing transmission strategies are mostly based on a single network quality indicator or data volume to select transmission channels, without comprehensively considering multiple factors, making it difficult to guarantee the real-time performance of core businesses. At the same time, existing technologies are mostly one-way data flow between edge processing and cloud analysis, which cannot dynamically correct deviations in the edge-cloud collaboration process and is difficult to adapt to the dynamic changes in IoT scenarios. Finally, there is a disconnect between the configuration generated in the cloud and the edge processing, which undermines the integrity of edge-cloud collaboration.

[0004] Based on the shortcomings of the existing technologies, the technical problem to be solved in this application is how to build an edge-cloud collaborative IoT real-time data processing system to achieve real-time processing, transmission stability and adaptive optimization in complex scenarios, and improve the overall efficiency and reliability of edge-cloud collaboration. Summary of the Invention

[0005] To address the shortcomings of existing technologies, this application provides a method and system for real-time data processing in the Internet of Things (IoT) through edge-cloud collaboration.

[0006] In a first aspect, this application provides an edge-cloud collaborative IoT real-time data processing system, which includes: an edge processing module, a dynamic transmission module, a cloud collaboration module, and a feedback optimization module;

[0007] The edge processing module is used to obtain the resource load status of the edge nodes and receive the cloud load status broadcast by the control channel, and process IoT data through the edge nodes to generate edge features including category identifiers;

[0008] The dynamic transmission module is used to monitor the network quality of the transmission channel between the edge node and the cloud in real time, and to comprehensively evaluate the urgency of the category identifier, the resource load status of the edge node, the network quality and the cloud load status to generate an offloading strategy, so as to select the transmission channel and control the uploading of edge features.

[0009] The cloud collaboration module is used to receive and analyze edge features to generate cloud features, and generate configuration parameters including feature extraction granularity and processing priority based on the resource load status of edge nodes and cloud load status, so as to distribute them to the corresponding edge nodes through the control channel.

[0010] The feedback optimization module is used to update the edge processing logic after applying configuration parameters at the edge node, calculate the difference between the edge features and the cloud features received through the control channel, and optimize the local weights in the unloading strategy based on the difference and its corresponding category identifier when the difference is greater than the difference threshold for multiple consecutive periods.

[0011] As an optional implementation, generating the edge features includes:

[0012] After acquiring IoT data, the preprocessing intensity and data dimensions are dynamically adjusted based on the resource load status of edge nodes and the cloud load status broadcast by the control channel.

[0013] The initial category identifiers of IoT data are labeled according to the business scenario, and the initial category identifiers are corrected by combining historical cloud characteristics and the urgency of the category identifiers is determined.

[0014] Based on the corrected category identifier and urgency level, feature extraction is performed on the preprocessed IoT data, and adaptive compression is combined with the feature extraction granularity configuration of the historical distribution in the cloud to obtain the initial features;

[0015] Verify the matching between the feature quantity of the initial feature and the resource load status of the edge node, as well as the dimensional consistency between the initial feature and the historical cloud feature. After the verification is passed, generate edge features including category identifiers and associate them with the resource load status of the edge node.

[0016] As an optional implementation, the generation and unloading strategy includes:

[0017] Real-time monitoring of network quality of the transmission channel between edge nodes and the cloud; preset weight benchmarks based on the dimensional consistency between edge features and historical cloud features; and correct weight benchmarks by combining local weight optimization records.

[0018] Based on the revised weighting benchmark, the urgency of category identification, the resource load status of edge nodes, network quality, and cloud load status are dynamically quantified to obtain quantitative evaluation results.

[0019] When conflicts arise in the quantitative assessment results, the conflicts are reconciled by combining the urgency of the category identifiers, and an initial unloading strategy is generated based on the reconciled quantitative assessment results.

[0020] Verify the impact of the initial unloading strategy on the resource load status of edge nodes and its consistency with the configuration of historical distribution processing priorities in the cloud. Once the verification is successful, generate the unloading strategy.

[0021] As an optional implementation, selecting the transmission channel and controlling the uploading of edge features includes:

[0022] Based on the quantitative evaluation results in the offloading strategy, candidate transmission channels are matched, and the fluctuation trend of network quality in different candidate transmission channels is obtained simultaneously. Combining the matching of the feature quantity of the initial feature with the resource load status of the edge node, a group of transmission channels whose matching meets the matching threshold is selected.

[0023] The upload priority of the transmission channel group is dynamically configured based on the urgency of the category identifier, and the upload timing and fragmentation parameters of the edge features are dynamically adjusted in combination with the processing priority of the historical distribution in the cloud.

[0024] When uploading edge features, the upload progress and network quality of the transmission channel are monitored in real time. When the network quality does not meet the stability threshold, exception handling is performed according to the urgency of the category identifier and the handling information is recorded.

[0025] After the upload is completed, the upload status is fed back to the cloud through the control channel. After receiving the confirmation signal from the cloud, the current transmission channel is terminated and the transmission resources of the edge node are released.

[0026] As an optional implementation, the generation of cloud features includes:

[0027] Receive edge features and associated category identifiers and resource load status of edge nodes, and perform preprocessing on edge features based on the dimensional consistency between edge features and historical cloud features;

[0028] Based on the category identifier and the processing priority of historical distribution, core features are extracted from the preprocessed edge features, and the dimensionality deviation between the core features and the historical cloud features is simultaneously calibrated.

[0029] Retrieve historical difference records with a difference greater than the difference threshold, correct the core features, verify the adaptability of the corrected core features to the cloud load status, combine the feature extraction granularity configuration of the historical distribution with reverse calibration, and generate cloud features with associated category identifiers after the verification is passed.

[0030] As an optional implementation, generating the configuration parameters includes:

[0031] Integrate the resource load status of edge nodes, cloud load status, and historical configuration parameters to establish a configuration baseline;

[0032] Based on the configuration baseline, the feature extraction granularity is dynamically generated by combining the urgency of the category identifier and the dimensionality of the cloud features. The feature extraction granularity is optimized based on historical difference records. At the same time, the processing priority is generated by associating the fluctuation trend of network quality with the processing complexity of cloud features.

[0033] Verify the compatibility of feature extraction granularity with processing priority, the degree of matching with the resource load status of edge nodes and the cloud load status, and the consistency with historical configuration parameters. After the verification is passed, configuration parameters are generated and distributed to the corresponding edge nodes through the control channel.

[0034] As an optional implementation, the updated edge processing logic includes:

[0035] The configuration parameters distributed in the cloud are analyzed, and the resource load status of the edge nodes is combined to establish a mapping relationship between the configuration parameters and the preprocessing intensity, data dimension filtering and adaptive compression.

[0036] Based on the mapping relationship, the preprocessing intensity is refined according to the feature extraction granularity, the preprocessing intensity is adjusted according to the resource load status of the edge nodes, and the data dimension filtering rules are set according to the processing priority.

[0037] After updating the preprocessing intensity level, data dimension filtering rules, and compression ratio, a verification is performed. Once the verification passes, the updated edge processing logic is solidified, and the updated content and corresponding mapping relationships are recorded synchronously.

[0038] As an optional implementation, calculating the degree of difference includes:

[0039] The edge features are grouped and matched with the cloud features received through the control channel according to the category identifier. The core dimension data of the edge features and cloud features in each group are extracted, and the consistency of the core dimension data is verified.

[0040] By combining the dimensional importance of cloud features with the resource load status of edge nodes and the cloud load status, dynamic weights are assigned to each set of core dimension data.

[0041] The solution logic is adapted according to the type of core dimension data. Based on the solution logic, the deviation value between the core dimension data of edge features and cloud features is calculated. The deviation value is weighted and summed based on dynamic weights to obtain the single-period difference value.

[0042] The difference values ​​of a single period are accumulated by a sliding window over consecutive periods. At the same time, it is checked whether there are abnormal difference values ​​during the accumulation process. After removing abnormal difference values, the average difference value within the sliding window is calculated to obtain the difference degree.

[0043] As an optional implementation, the local weights in the optimized unloading strategy include:

[0044] Filter the category identifiers corresponding to the differences that exceed the difference threshold for multiple consecutive periods, and retrieve the historical difference records corresponding to the category identifiers, as well as the resource load status of the edge nodes and the cloud load status.

[0045] Optimization priorities are determined by the degree of difference and the urgency of the category identifier. Local weights are adjusted according to optimization priorities by combining historical difference records and the resource load status of edge nodes and cloud load status.

[0046] The weight benchmark is adjusted based on the optimized local weight, and the impact of the adjusted offloading strategy on the resource load status of edge nodes is verified to be within the allowable threshold. At the same time, the consistency with the configuration of the processing priority of the historical distribution in the cloud is verified.

[0047] After the verification is passed, the optimized local weights are fixed and the optimization record of the local weights is generated.

[0048] Secondly, this application provides an edge-cloud collaborative IoT real-time data processing method, which includes: acquiring the resource load status of edge nodes and receiving the cloud load status broadcast by the control channel, and processing and analyzing IoT data through edge nodes to generate edge features including category identifiers;

[0049] Real-time monitoring of network quality of the transmission channel between edge nodes and the cloud, and comprehensive evaluation of the urgency of category identifiers, resource load status, network quality and cloud load status to generate offloading strategies, in order to select transmission channels and control the uploading of edge features;

[0050] Receive and analyze edge features to generate cloud features, and generate configuration parameters including feature extraction granularity and processing priority based on the resource load status of edge nodes and cloud load status, so as to distribute them to the corresponding edge nodes through the control channel;

[0051] After applying configuration parameters at the edge nodes, update the edge processing logic, calculate the difference between edge features and cloud features received through the control channel, and optimize the local weights in the offloading strategy based on the difference and its corresponding category identifier when the difference exceeds the difference threshold for multiple consecutive periods.

[0052] Compared with existing technologies, the beneficial effects of this application are as follows: By combining the resource load status of edge nodes with the cloud load status broadcast by the control channel through the edge processing module, and processing IoT data to generate edge features, the resource constraints of edge nodes and data processing needs are effectively balanced, avoiding resource waste or data quality defects; The dynamic transmission module comprehensively evaluates the urgency of category identifiers, resource load status, network quality and cloud load status to generate offloading strategies, so as to select transmission channels and control the uploading of edge features, ensuring that high-urgency core business data receives priority access to high-quality transmission resources, while avoiding network quality fluctuations and resource overload risks, significantly improving the timeliness and stability of data transmission.

[0053] The cloud collaboration module receives and analyzes edge features to generate cloud features, and generates configuration parameters including feature extraction granularity and processing priority to ensure that the configuration parameters are accurately adapted to edge processing requirements. The feedback optimization module calculates the difference between edge features and cloud features, optimizes the local weight of the unloading strategy for deviation categories that exceed the difference threshold for multiple consecutive periods, and links the weight benchmark and edge processing logic to dynamically correct edge-cloud collaboration deviations and continuously improve the system's adaptability.

[0054] Through the deep collaboration of edge processing module, dynamic transmission module, cloud collaboration module and feedback optimization module, a closed loop of edge-cloud collaboration is formed, which integrates edge processing, dynamic transmission, cloud analysis and feedback optimization. This enables precise scheduling of edge-cloud resources, differentiated adaptation to business needs and continuous correction of collaboration deviations, effectively improving the system's real-time data processing efficiency, resource utilization and operational stability. It can be widely adapted to the dynamic needs of different IoT scenarios such as industrial monitoring and smart security. Attached Figure Description

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

[0056] Figure 1 is a system flowchart of an edge-cloud collaborative IoT real-time data processing system provided in an embodiment of this application;

[0057] Figure 2 is a flowchart illustrating the selection of transmission channels and control of edge feature uploading in an edge-cloud collaborative IoT real-time data processing system provided in an embodiment of this application.

[0058] Figure 3 is a flowchart of a real-time data processing method for IoT with edge-cloud collaboration provided in an embodiment of this application. Detailed Implementation

[0059] To make the objectives, technical solutions, and advantages of the embodiments of this application more apparent and understandable, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments.

[0060] Example 1

[0061] As shown in Figure 1, this application provides an edge-cloud collaborative IoT real-time data processing system, which includes an edge processing module, a dynamic transmission module, a cloud collaboration module, and a feedback optimization module.

[0062] The edge processing module is used to obtain the resource load status of edge nodes and receive the cloud load status broadcast by the control channel. It processes IoT data through edge nodes to generate edge features including category identifiers.

[0063] Specifically, the generated edge features include:

[0064] After acquiring IoT data, the preprocessing intensity and data dimensions are dynamically adjusted based on the resource load status of edge nodes and the cloud load status broadcast by the control channel.

[0065] The initial category identifiers of IoT data are labeled according to the business scenario, and the initial category identifiers are corrected by combining historical cloud characteristics and the urgency of the category identifiers is determined.

[0066] Based on the corrected category identifier and urgency level, feature extraction is performed on the preprocessed IoT data, and adaptive compression is combined with the feature extraction granularity configuration of the historical distribution in the cloud to obtain the initial features;

[0067] Verify the matching between the feature quantity of the initial feature and the resource load status of the edge node, as well as the dimensional consistency between the initial feature and the historical cloud feature. After the verification is passed, generate edge features including category identifiers and associate them with the resource load status of the edge node.

[0068] After acquiring IoT data, the preprocessing intensity is dynamically adjusted and data dimensions are filtered based on the resource load status of edge nodes and the cloud load status broadcast by the control channel. Edge nodes generally have limited computing and storage resources, while IoT data is often accompanied by noise interference and dimensional redundancy. If directly entered into subsequent processing, it can easily lead to resource overload or substandard data quality. Edge nodes acquire resource load status such as CPU utilization and memory usage in real time through resource monitoring processes, while the control channel receives the cloud load status pushed by the cloud using the corresponding protocol to ensure low latency and accuracy of load information transmission.

[0069] The dynamic adjustment of preprocessing intensity is based on the combination of resource load status and cloud load status. When both edge nodes and the cloud are under low load, multi-stage noise reduction and data calibration are used to improve data accuracy. When either node is under high load, the preprocessing process is simplified, retaining only noise reduction and format standardization steps to ensure processing efficiency. Data dimension filtering is combined with the needs of business scenarios to eliminate redundant dimensions that are irrelevant to the current business, ensuring that the data volume is adapted to the resources of the edge nodes. This achieves dynamic matching between preprocessing and edge-cloud load status, avoiding resource overload and ensuring data quality. It provides a reliable data foundation for subsequent labeling and correction of category identifiers, avoiding category judgment bias caused by defects in the original data.

[0070] Secondly, the initial category identifiers of IoT data are labeled according to the business scenarios, and the initial category identifiers are corrected by combining historical cloud features and the urgency of the category identifiers is determined. The business scenarios of IoT data have ambiguous boundaries, and relying solely on business scenario labeling is prone to category bias. Historical cloud features include mature category information that has been verified by business and can be used as a basis for correction. At the same time, the business response priorities of different categories of data are different, and the urgency level needs to be clearly defined to support subsequent processing. In specific implementation, the initial category identifiers are labeled according to the preset business scenario classification logic, and the labeling information is stored in association with the data ontology.

[0071] By controlling the channel to retrieve historical cloud features from the same business scenario, and employing a dual mechanism of feature vector similarity matching and core attribute threshold verification, the initial category identifier is corrected to ensure its accuracy. Based on the corrected category identifier, the urgency level is determined in conjunction with the timeliness requirements of the business response, forming an urgency level bound to the category identifier. This improves the accuracy of the category identifier, clarifies the priority of data processing, provides a clear basis for subsequent processing, and ensures the timeliness of core business data processing.

[0072] Subsequently, based on the corrected category identifiers and urgency levels, feature extraction is performed on the preprocessed IoT data, and adaptive compression is combined with the feature extraction granularity configuration of historical cloud distribution to obtain initial features. Among them, the core features of data with different category identifiers are significantly different, and the urgency level directly determines the trade-off between data quality and processing efficiency. The feature extraction granularity configuration in the cloud is a core convention of edge-cloud collaboration, and it is necessary to ensure that the features extracted on the edge side are compatible with the cloud requirements. In specific implementation, an appropriate feature extraction method is selected according to the category identifier. High-precision feature extraction methods are used for high-urgency data to retain core details, while the feature extraction process is simplified for low-urgency data to improve efficiency.

[0073] The feature extraction granularity configuration of the cloud-based historical distribution is retrieved from the control channel cache, and the level of detail of feature extraction is controlled in accordance with the configuration requirements. Based on the combination logic of category identifier, urgency, and feature extraction granularity configuration, a corresponding compression strategy is adopted. High-urgency and fine-grained features are compressed without loss to ensure data integrity, while low-urgency and coarse-grained features are compressed efficiently to reduce data volume. This achieves precise adaptation of feature extraction and compression strategies, ensures compatibility between edge-side features and cloud requirements, and provides specific processing objects for subsequent verification steps, ensuring the standardization and effectiveness of edge feature generation.

[0074] Finally, the matching between the feature quantity of the initial features and the resource load status of the edge nodes is verified, as well as the dimensional consistency between the initial features and historical cloud features. After verification, edge features including category identifiers are generated and associated with the resource load status of the edge nodes. The initial features may have issues with the feature quantity and edge node resources, or inconsistent dimensions due to processing errors, affecting subsequent edge-cloud collaborative processing. At the same time, the edge features need to be associated with the resource load status to provide a complete basis for cloud configuration parameter generation and dynamic transmission strategy formulation. In the specific implementation process, the feature quantity of the initial features is compared with the current resource load status of the edge nodes to determine whether there is a risk of resource overload. If they do not match, the features are adjusted. For example, for medium-urgency data, the accuracy of auxiliary features can be further reduced. If they still do not match after the second adjustment, the processing is downgraded based on the urgency level. For low-urgency data, the feature dimensions can be simplified, while for high-urgency data, the core features are retained, and some non-critical business edge resources are released.

[0075] Historical cloud feature dimensional data is retrieved to verify the consistency of field dimensions of the initial features, and adaptive corrections are made for any deviations. After the verification is passed, the initial features, category identifiers, and resource load status of edge nodes are integrated to generate edge features. This ensures the feasibility and compatibility of edge features, avoids subsequent process failures due to feature defects, and provides data support for the generation of unloading strategies and the selection of transmission channels for dynamic transmission modules, ensuring the accuracy and efficiency of edge-cloud collaborative data transmission.

[0076] The dynamic transmission module is used to monitor the network quality of the transmission channel between edge nodes and the cloud in real time, and to comprehensively evaluate the urgency of the category identifier, the resource load status of the edge node, the network quality and the cloud load status to generate an offloading strategy, so as to select the transmission channel and control the upload of edge features.

[0077] Furthermore, the generated uninstallation strategy includes:

[0078] Real-time monitoring of network quality of the transmission channel between edge nodes and the cloud; preset weight benchmarks based on the dimensional consistency between edge features and historical cloud features; and correct weight benchmarks by combining local weight optimization records.

[0079] Based on the revised weighting benchmark, the urgency of category identification, the resource load status of edge nodes, network quality, and cloud load status are dynamically quantified to obtain quantitative evaluation results.

[0080] When conflicts arise in the quantitative assessment results, the conflicts are reconciled by combining the urgency of the category identifiers, and an initial unloading strategy is generated based on the reconciled quantitative assessment results.

[0081] Verify the impact of the initial unloading strategy on the resource load status of edge nodes and its consistency with the configuration of historical distribution processing priorities in the cloud. Once the verification is successful, generate the unloading strategy.

[0082] First, the network quality of the transmission channel between edge nodes and the cloud is monitored in real time. A weight benchmark is preset based on the dimensional consistency between edge features and historical cloud features, and the weight benchmark is adjusted by combining the optimization records of local weights. Among them, network quality is a key variable affecting the stability and timeliness of data transmission. Its dynamic changes need to be captured in real time to adapt to the transmission strategy. The weight benchmark is the core basis for subsequent multi-dimensional quantitative evaluation. The dimensional consistency between edge features and historical cloud features directly reflects the compatibility of edge-cloud data. Presetting the weight benchmark based on this can ensure the pertinence of the evaluation. The optimization records of local weights carry the practical experience of historical strategy optimization. Combining them with the adjustment of the weight benchmark can avoid repeated trial and error and improve the rationality of the weight benchmark.

[0083] In practice, edge nodes acquire real-time network quality data such as bandwidth, latency, and packet loss rate of the transmission channel through network monitoring processes, ensuring the real-time nature and accuracy of the monitoring data. Based on the consistency results of edge features and historical cloud features, differentiated weight benchmarks are preset for scenarios with varying degrees of consistency. When the dimensions are completely consistent, the weight allocation focuses on network quality and urgency; when there are slight deviations, the weight ratio of the two load states is appropriately increased. The optimization records of local weights are retrieved from local storage, and the validated weight adjustment logic from historical optimizations is extracted to dynamically correct the preset weight benchmarks, ensuring that the corrected weight benchmarks fit the actual business scenarios. This achieves accurate adaptation of the weight benchmarks, while real-time network monitoring grasps the dynamic status of the transmission channel, providing a reliable basis for subsequent quantitative evaluation and ensuring that the quantitative results truly reflect the impact of multi-dimensional factors on the transmission strategy.

[0084] Secondly, based on the revised weighting benchmark, the urgency of the category identifier, the resource load status of the edge node, the network quality, and the cloud load status are dynamically quantified to obtain quantitative evaluation results. The urgency of the category identifier, the edge-cloud load status, and the network quality are all key variables affecting the offloading strategy. The attributes of each variable are different, and they cannot be directly evaluated comprehensively. However, the revised weighting benchmark can ensure that the quantification process can highlight the core influencing factors and improve the pertinence and rationality of the evaluation.

[0085] In the specific implementation process, for each evaluation dimension, an adaptive dynamic quantification logic is formulated based on its core attributes. For example, the urgency of the category identifier is converted into a corresponding quantification level based on the timeliness requirements of business response; the resource load status of edge nodes is converted into a load pressure level based on the core indicators of resource usage; network quality is converted into a transmission adaptation level based on indicators such as bandwidth and latency; and cloud load status is converted into a coordination capability level based on information such as task queue length. During the quantification process, the quantification results of each dimension are weighted and integrated based on the corrected weight benchmark to form a quantification evaluation result that can comprehensively reflect multiple dimensions of factors. This transforms the heterogeneous influencing factors of multiple dimensions into a unified quantification basis, ensuring the scientific nature of the subsequent offloading strategy generation. The output quantification evaluation result provides decision support for conflict reconciliation and the generation of the initial offloading strategy, avoiding the one-sidedness of offloading strategy formulation due to differences in the attributes of various factors.

[0086] Subsequently, when conflicts arise in the quantitative assessment results, the urgency of the category identifier is used to reconcile the conflicts, and an initial offloading strategy is generated based on the reconciled quantitative assessment results. In the process of multi-dimensional quantitative assessment, there may be contradictions in the assessment results of different dimensions. For example, data with high urgency corresponds to poor network quality. If the conflicts are not reconciled, the strategy formulation will be in a dilemma. The urgency of the category identifier is directly related to the timeliness requirements of core business. Using this as the core to reconcile conflicts can ensure the priority protection of core business and meet the core business requirements of edge-cloud collaboration.

[0087] The quantitative assessment results are used to identify conflicts and determine whether there are contradictions in the transmission requirements corresponding to different dimensions of the assessment results. When a conflict is identified, the urgency of the category is used as the reconciliation basis, prioritizing the transmission needs of high-urgency data. For example, even if high-urgency data faces poor network quality, transmission resources are allocated to ensure its transmission, and the transmission priority of low-urgency data is appropriately reduced to alleviate the conflict. Based on the reconciled quantitative assessment results, combined with the actual status of the transmission channel and the load-bearing capacity of the edge cloud, an initial offloading strategy is generated, covering transmission channel selection, data upload timing, and resource allocation schemes. This effectively resolves the conflict problem of multi-dimensional assessments, ensures the transmission priority of core business data, and provides specific assessment objects for subsequent verification stages, ensuring that the offloading strategy meets business requirements.

[0088] Finally, the impact of the initial offloading strategy on the resource load status of edge nodes and its consistency with the processing priority configuration of historical cloud distribution are verified. After verification, the offloading strategy is generated. The initial offloading strategy may have a mismatch with the resource carrying capacity of edge nodes, which may lead to overload of edge nodes after the offloading strategy is executed, affecting the overall system stability. At the same time, the initial offloading strategy must be consistent with the processing priority of historical cloud distribution to ensure the uniformity of edge-cloud collaboration and avoid data processing chaos due to processing priority conflicts. Therefore, double verification is required to ensure the feasibility and coordination of the offloading strategy.

[0089] Based on the current resource load status of the edge nodes, the execution process of the initial offloading strategy is simulated to evaluate the changes in the usage of resources such as CPU, memory, and transmission bandwidth after the offloading strategy is executed, and to determine whether there is a risk of resource overload. The processing priority configuration of the cloud distribution stored in the control channel is retrieved, and the consistency between the priority setting in the initial offloading strategy and the cloud configuration is compared to check for priority conflicts. If the check finds a risk of resource overload or a priority conflict, the initial offloading strategy is dynamically adjusted. If there is a risk of resource overload, low-urgency data is diverted, high-priority channel resources are released, and the fragment size is optimized to stagger data uploads to reduce concurrent resource usage, while temporarily reducing the transmission demand of low-urgency data. If there is a priority conflict, the historical cloud configuration is directly aligned, and the upload priority on the edge side is corrected. If high-priority data is dense, the upload interval is fine-tuned to match the cloud processing rhythm.

[0090] After adjustment, the verification is re-executed until both verifications pass. Once the verification passes, the unloading strategy content is solidified and an unloading strategy is generated. This fully ensures the feasibility of the unloading strategy and the consistency of edge-cloud collaboration, avoiding system failures or collaboration chaos caused by defects in the unloading strategy. The unloading strategy provides the execution basis for subsequent channel selection and upload control, ensuring that the data transmission process is efficient, stable, and meets the overall requirements of edge-cloud collaboration.

[0091] Specifically, as shown in Figure 2, selecting the transmission channel and controlling the uploading of edge features includes:

[0092] Based on the quantitative evaluation results in the offloading strategy, candidate transmission channels are matched, and the fluctuation trend of network quality in different candidate transmission channels is obtained simultaneously. Combining the matching of the feature quantity of the initial feature with the resource load status of the edge node, a group of transmission channels whose matching meets the matching threshold is selected.

[0093] The upload priority of the transmission channel group is dynamically configured based on the urgency of the category identifier, and the upload timing and fragmentation parameters of the edge features are dynamically adjusted in combination with the processing priority of the historical distribution in the cloud.

[0094] When uploading edge features, the upload progress and network quality of the transmission channel are monitored in real time. When the network quality does not meet the stability threshold, exception handling is performed according to the urgency of the category identifier and the handling information is recorded.

[0095] After the upload is completed, the upload status is fed back to the cloud through the control channel. After receiving the confirmation signal from the cloud, the current transmission channel is terminated and the transmission resources of the edge node are released.

[0096] First, candidate transmission channels are matched based on the quantitative evaluation results in the offloading strategy. Simultaneously, the network quality fluctuation trends of different candidate transmission channels are obtained. Combining the matching of the initial feature quantity with the resource load status of the edge nodes, transmission channel groups that meet the matching threshold are selected. The quantitative evaluation results in the offloading strategy have clearly defined the data transmission requirements for core indicators such as bandwidth and latency. Matching candidate channels based on this can ensure the basic adaptability of the channels. The fluctuation trend of network quality directly affects the transmission stability. Screening based solely on the current network status may easily overlook potential risks. The matching of the initial feature quantity with the resource load of the edge nodes determines whether the transmission process will cause the edge nodes to overload. Resource conflicts need to be avoided through screening.

[0097] In practice, based on the transmission requirements clearly defined in the quantitative evaluation results of the offloading strategy, such as bandwidth thresholds and latency limits, candidate transmission channels that meet the basic conditions are matched from the transmission channels accessible to the edge nodes. By retrieving recent historical network quality data, a trend fitting method is used to analyze the bandwidth fluctuations and latency jitter patterns of each candidate transmission channel, identifying transmission channels with smaller fluctuation amplitudes. Simultaneously, the transmission resource occupancy requirements corresponding to the initial feature values ​​are calculated and compared with the current remaining CPU, memory, and transmission bandwidth resources of the edge nodes. Transmission channels that would cause resource overload are eliminated, and finally, a group of transmission channels with basic adaptability, stability, and resource compatibility is selected. This achieves precise matching between transmission channels and transmission requirements, network status, and edge resources, avoiding transmission delays, data loss, or resource overload caused by improper channel selection. The output transmission channel group provides a reliable hardware foundation for subsequent upload priority configuration and parameter adjustment, ensuring the orderly execution of subsequent transmission processes.

[0098] Secondly, the upload priority of the transmission channel group is dynamically configured based on the urgency of the category identifier, and the upload timing and fragmentation parameters of the edge features are dynamically adjusted in conjunction with the processing priority of the historical distribution in the cloud. Different category identifiers of edge features correspond to different business timeliness requirements, and priority configuration is needed to ensure the transmission priority of core business data. The processing priority of the historical distribution in the cloud is the core agreement of edge-cloud collaboration. Adjusting the upload timing and fragmentation parameters can ensure that the transmission behavior on the edge side is compatible with the processing capacity of the cloud, and avoid data accumulation or resource waste caused by the mismatch between transmission and processing rhythm. Specifically, based on the urgency of the category identifier, differentiated upload priorities are assigned to the transmission channels within the transmission channel group. The transmission channels corresponding to high-urgency features are configured with the highest priority to ensure that they receive priority transmission resources.

[0099] The system retrieves the processing priorities of historical cloud distributions from the control channel cache, compares the correspondence between edge feature category identifiers and processing priorities, and adjusts the upload timing to be immediate if cloud processing resources for a certain feature are currently sufficient. If cloud processing resources are scarce, the upload timing for features other than those with high urgency is delayed. For edge features with a large number of features, the system dynamically adjusts the fragment size and fragment interval based on the bandwidth capacity of the transmission channel and the cloud fragment receiving configuration to ensure the integrity and efficiency of fragment transmission, avoiding transmission timeouts due to excessively large fragments or increased transmission overhead due to excessively small fragments. This achieves deep adaptation of transmission strategies to business needs and cloud processing capabilities, ensuring real-time transmission of core business data and optimizing the allocation efficiency of transmission resources. The output upload priority and adjusted upload parameters provide clear execution basis for subsequent transmission execution and monitoring, ensuring that the upload process is orderly and meets the needs of edge-cloud collaboration.

[0100] Subsequently, during the uploading of edge features, the upload progress and network quality of the transmission channel are monitored in real time. When the network quality does not meet the stability threshold, anomaly handling is performed according to the urgency of the category identifier, and the handling information is recorded. In the IoT scenario, the network environment is dynamic and fluctuates, and anomalies such as sudden bandwidth drops or latency spikes may occur during transmission. If not handled in time, they can easily lead to data transmission failure or severe delays. Edge features with different urgency levels have different tolerances for anomalies. Differentiated handling according to urgency can maximize the reliability of core data transmission, while recording the handling information can provide a basis for subsequent optimization. Specifically, the upload progress and network quality of the transmission channel are obtained in real time through the transmission monitoring module of the edge node, and an anomaly monitoring mechanism is established. The upload progress includes the number of bytes uploaded and the remaining transmission time.

[0101] When network quality exceeds a preset stability threshold, anomaly handling is initiated. For high-urgency edge features, transmission is immediately switched to a backup high-priority transmission channel within the transmission channel group to ensure transmission continuity. For low- to medium-urgency edge features, transmission can be paused and the network quality can be allowed to recover, or the transmission rate can be reduced to improve stability. All anomaly handling actions are recorded, including the time of occurrence, type of anomaly, handling measures, and results. This significantly improves the anti-interference capability of edge feature uploads, reduces the impact of network anomalies on data transmission, ensures the reliability of core business data transmission, and provides practical evidence for subsequent transmission strategy optimization. The completed upload process and recorded processing information lay the foundation for subsequent upload status feedback and resource release.

[0102] After the upload is completed, the upload status is fed back to the cloud through the control channel. Upon receiving confirmation from the cloud, the current transmission channel is terminated, and the transmission resources of the edge node are released. The cloud needs to know the upload status of the edge features to initiate subsequent processing and ensure a closed loop in the edge-cloud collaboration process. Transmission channels and edge transmission resources are limited resources. Timely release can avoid long-term resource occupation that may lead to subsequent transmission obstruction and improve resource utilization. After confirming that all edge features have been uploaded, the edge node sends upload status feedback to the cloud through the control channel, which includes information such as upload completion identifier, feature category, and data volume.

[0103] The system continuously monitors the confirmation signal returned by the cloud through the control channel. If no confirmation signal is received within a preset time, the feedback information is resent to ensure accurate reception by the cloud. Upon successful receipt of the cloud confirmation signal, the connection of the current transmission channel is terminated, releasing the occupied transmission bandwidth and port resources, and updating the resource occupancy status of the edge node. This ensures a complete closed loop of the edge-cloud collaborative transmission link, avoids cloud processing delays due to unclear upload status, and improves the turnover efficiency of edge node transmission resources, freeing up resources for the transmission of other edge features. The completion of resource release and status update marks the formal end of this edge feature transmission process, ensuring the smoothness of subsequent data processing and transmission by the edge node.

[0104] The cloud collaboration module is used to receive and analyze edge features to generate cloud features. Based on the resource load status of edge nodes and the cloud load status, it generates configuration parameters including feature extraction granularity and processing priority, which are then distributed to the corresponding edge nodes through the control channel.

[0105] Furthermore, the generation of cloud-based features includes:

[0106] Receive edge features and associated category identifiers and resource load status of edge nodes, and perform preprocessing on edge features based on the dimensional consistency between edge features and historical cloud features;

[0107] Based on the category identifier and the processing priority of historical distribution, core features are extracted from the preprocessed edge features, and the dimensionality deviation between the core features and the historical cloud features is simultaneously calibrated.

[0108] Retrieve historical difference records with a difference greater than the difference threshold, correct the core features, verify the adaptability of the corrected core features to the cloud load status, combine the feature extraction granularity configuration of the historical distribution with reverse calibration, and generate cloud features with associated category identifiers after the verification is passed.

[0109] First, the edge features, associated category identifiers, and resource load status of edge nodes are received. Preprocessing is then performed on the edge features based on the dimensional consistency between the edge features and historical cloud features. During the transmission process, minor data distortion or field loss may occur due to network fluctuations, directly affecting the accuracy of subsequent cloud processing. Furthermore, dimensional consistency between edge features and historical cloud features is a fundamental prerequisite for edge-cloud collaborative analysis; any dimensional deviation will prevent effective feature comparison and integration. The associated category identifiers and edge node resource load status provide a basis for the adaptation of preprocessing. Specifically, the received edge features and associated information are first subjected to integrity verification to check for transmission problems such as missing data and incorrect fields. For slightly missing fields, supplementation is performed based on the common patterns of historical edge features of the same category.

[0110] The system retrieves dimensional data of historical cloud features of the same category from local storage and compares the number of dimensions, field definitions, and data types of the current edge features with those of the historical cloud features. For differences in dimensional consistency, it performs format standardization and dimensional alignment processing. For example, it unifies the field names of edge features to the standard names of historical cloud features and performs lossless conversion on fields with incompatible data types to ensure that the preprocessed edge features are fully compatible with the historical cloud features at the dimensional level. This effectively eliminates the impact of transmission distortion and dimensional deviation on subsequent processing, ensuring the availability and compatibility of edge features. The preprocessed edge features provide a data foundation for subsequent core feature extraction, avoiding deviations in core feature extraction due to data defects.

[0111] Secondly, based on the processing priority of category identifiers and historical distribution, core features are extracted from the preprocessed edge features, and the dimensional deviation between the core features and historical cloud features is simultaneously calibrated. Edge features of different category identifiers correspond to different business analysis needs, and the extraction dimensions of core features need to fit the business scenario. The processing priority of historical distribution clarifies the cloud's focus on processing various edge features, and high-priority features need to extract more comprehensive core dimensions to support in-depth analysis. Even after preprocessing, there will still be slight dimensional deviations at the core feature level. Specifically, the core feature extraction rules are matched based on the category identifier. For example, fault warning features prioritize the extraction of core dimensions such as abnormal fluctuations and peaks, while regular monitoring features extract core dimensions related to trends and stability.

[0112] By adjusting the extraction depth based on the processing priority of historical distribution, high-priority features are extracted to reveal multi-dimensional core details, while low-priority features focus on key core dimensions to save cloud resources. After extracting the core features, the fields are precisely calibrated based on the dimensional benchmark of historical cloud features. Consistency corrections are made for numerical precision deviations, and the dimensional arrangement order is reordered to ensure that the core features are completely consistent with historical cloud features at the dimensional level. This achieves targeted and accurate extraction of core features, ensures compatibility between core features and historical cloud features, and provides high-quality processing objects for subsequent correction stages, ensuring that the correction process can accurately focus on core deviation issues.

[0113] Finally, historical difference records with a difference greater than the difference threshold are retrieved to correct the core features. The adaptability of the corrected core feature quantity to the cloud load status is verified. In conjunction with the historical feature extraction granularity configuration, reverse calibration is performed. After verification, cloud features with associated category identifiers are generated. Historical difference records carry the core issues of past edge-cloud feature differences. Correcting core features based on them can avoid repeated deviations and improve the reliability of core features. The core feature quantity must be adapted to the current cloud load status to avoid cloud processing overload due to excessive feature quantity. In conjunction with the reverse calibration of the historical feature extraction granularity configuration, it can ensure that the generated cloud features conform to the granularity agreement of edge-cloud collaboration and ensure the rationality of subsequent configuration parameter generation. Historical difference records of the same category and business scenario as the current feature are retrieved in a targeted manner. Frequently occurring deviation types and correction experience are extracted from them. Key dimensions of core features are adjusted in a targeted manner. For example, for feature amplitude deviations that frequently occur in history, precise adjustments are made with reference to historical correction logic.

[0114] By combining the current cloud load status, such as CPU utilization and memory usage, the resource requirements of the corrected core features on cloud processing are assessed to determine if there is an overload risk. Simultaneously, the feature extraction granularity of historical distributions is retrieved to perform reverse calibration of the core features, ensuring that the detail of the core features matches the feature extraction granularity. If any compatibility issues or granularity deviations are found during verification, the core features are readjusted until both verifications pass. After successful verification, the core features are associated with category identifiers to generate cloud features. This significantly improves the reliability and adaptability of cloud features, ensuring that they meet the overall requirements of edge-cloud collaboration. The generated cloud features provide a basis for subsequent cloud collaboration module configuration parameter generation, ensuring that the configuration parameters can adapt to the processing needs of edge nodes and strengthening the closed-loop logic of edge-cloud collaboration.

[0115] Specifically, the generated configuration parameters include:

[0116] Integrate the resource load status of edge nodes, cloud load status, and historical configuration parameters to establish a configuration baseline;

[0117] Based on the configuration baseline, the feature extraction granularity is dynamically generated by combining the urgency of the category identifier and the dimensionality of the cloud features. The feature extraction granularity is optimized based on historical difference records. At the same time, the processing priority is generated by associating the fluctuation trend of network quality with the processing complexity of cloud features.

[0118] Verify the compatibility of feature extraction granularity with processing priority, the degree of matching with the resource load status of edge nodes and the cloud load status, and the consistency with historical configuration parameters. After the verification is passed, configuration parameters are generated and distributed to the corresponding edge nodes through the control channel.

[0119] First, it is necessary to integrate the resource load status of edge nodes, cloud load status, and historical configuration parameters to establish a configuration baseline. The generation of configuration parameters must be supported by comprehensive and objective basic information. The load status of edge nodes and the cloud directly determines the boundary of edge-cloud processing division of labor, while historical configuration parameters carry effective configuration logic that has been verified in practice during past collaboration. Relying on only a single dimension of information can easily lead to configuration parameters being out of touch with the actual scenario, thereby affecting the efficiency of edge-cloud collaboration. By receiving the resource load status uploaded by edge nodes through the control channel, the local CPU utilization, memory usage, and task queue length and other cloud load status are obtained synchronously to ensure the real-time and completeness of load data.

[0120] Simultaneously, the system retrieves historical configuration parameter databases from local storage, filters historical configuration records corresponding to the current edge node and similar identifiers, and extracts well-adapted configuration logic and core configuration parameters. It then structurally integrates edge load, cloud load, and historical configuration parameters, eliminating conflicting and redundant information to form a configuration benchmark encompassing resource constraints and historical experience. This provides a comprehensive decision-making basis for subsequent configuration parameter generation, ensuring the comprehensiveness and rationality of the configuration benchmark and preventing configuration deviations due to missing basic information. The constructed configuration benchmark lays a reliable foundation for the subsequent dynamic generation of feature extraction granularity and processing priorities, ensuring that the subsequent generation process always revolves around the core requirements of edge-cloud collaboration.

[0121] Secondly, based on the configuration baseline, the feature extraction granularity is dynamically generated by combining the urgency of the category identifier with the dimensional importance of the cloud features. This granularity is optimized using historical difference records, and processing priorities are generated by associating network quality fluctuation trends with the processing complexity of cloud features. The feature extraction granularity directly determines the level of detail and resource consumption of edge-side feature processing, and needs to be dynamically adapted to business priorities and core cloud feature requirements. Historical difference records reflect the core issues of past edge-cloud feature differences, and optimizing the granularity based on them can avoid repetitive deviations. The processing priority needs to balance transmission stability and cloud processing efficiency. Network quality and processing complexity are key influencing factors. Ignoring these factors can easily lead to a disconnect between edge processing and cloud collaboration. Specifically, based on the configuration baseline, the category identifier of the current edge features is matched, and the basic granularity direction of feature extraction is determined by combining its urgency. High-urgency categories tend to use fine-grained extraction to retain core details, while low-urgency categories can use coarse-grained extraction to save resources.

[0122] Simultaneously, based on the dimensional importance of cloud features, the extraction requirements for core dimensions are strengthened, while the detailed standards for non-core dimensions are weakened. Historical difference records of the same category of identifiers are retrieved, and the differences caused by inappropriate granularity are analyzed. Granularity parameters are adjusted accordingly to optimize adaptability. In the priority generation stage, the network quality fluctuation trend of the recent transmission channel is obtained by controlling the channel. Combined with the processing complexity of cloud features, such as the number of feature dimensions and the computational cost of analysis and processing, processing priorities are assigned to features of different categories of identifiers. When the network quality is unstable, the priority of high-urgency features is appropriately increased to ensure the continuity of transmission and processing. When the cloud processing complexity is high, the priority is reasonably allocated to avoid cloud resource overload. This achieves precise adaptation between feature extraction granularity and processing priority, ensuring both the processing quality of core business data and the efficient utilization of edge cloud resources. The generated preliminary granularity and priority parameters provide specific evaluation objects for subsequent multi-verification, ensuring the scientific nature and adaptability of the final configuration parameters.

[0123] Finally, it is necessary to verify the adaptability of feature extraction granularity and processing priority, the degree of matching with the load status on both the edge and cloud sides, and the consistency with historical configuration parameters. After verification, configuration parameters are generated and distributed to the corresponding edge nodes through the control channel. The initially generated feature extraction granularity and processing priority may have inherent adaptation conflicts, mismatch with the edge and cloud load status, or contradictions with historical effective configurations. Direct distribution may easily lead to problems such as edge node resource overload and chaotic edge-cloud collaboration. Multiple verifications can comprehensively identify configuration defects and ensure the feasibility and collaborative consistency of configuration parameters. Specifically, first verify the inherent adaptability of feature extraction granularity and processing priority to determine whether there is a resource requirement conflict between granularity extraction and high-priority configuration, and ensure that the two are logically consistent. Then, combined with the real-time load status of edge nodes and the cloud, assess the resource consumption requirements corresponding to the current feature extraction granularity and processing priority to determine whether there is an overload risk.

[0124] By comparing the current configuration with historically valid configurations, the system verifies the consistency between the current configuration and the historically valid configurations to prevent system instability caused by sudden configuration changes. If problems are found during verification, the feature extraction granularity or processing priority is adjusted to address the specific defects, and the verification process is re-executed until all verification items pass. After verification, the feature extraction granularity and processing priority are integrated into configuration parameters and distributed to the corresponding edge nodes via encrypted transmission through the control channel to ensure the security and accuracy of configuration parameter transmission. This comprehensively ensures the feasibility, consistency, and stability of configuration parameters, preventing edge-cloud collaboration failures due to configuration defects. The generated and distributed configuration parameters provide a basis for subsequent edge processing logic updates, ensuring that edge-side processing logic can accurately match cloud collaboration requirements and strengthening the closed-loop logic of edge-cloud collaboration.

[0125] The feedback optimization module is used to update the edge processing logic after applying configuration parameters at the edge nodes, calculate the difference between edge features and cloud features received through the control channel, and optimize the local weights in the unloading strategy based on the difference and its corresponding category identifier when the difference exceeds the difference threshold for multiple consecutive periods.

[0126] Furthermore, the updated edge processing logic includes:

[0127] The configuration parameters distributed in the cloud are analyzed, and the resource load status of the edge nodes is combined to establish a mapping relationship between the configuration parameters and the preprocessing intensity, data dimension filtering and adaptive compression.

[0128] Based on the mapping relationship, the preprocessing intensity is refined according to the feature extraction granularity, the preprocessing intensity is adjusted according to the resource load status of the edge nodes, and the data dimension filtering rules are set according to the processing priority.

[0129] After updating the preprocessing intensity level, data dimension filtering rules, and compression ratio, a verification is performed. Once the verification passes, the updated edge processing logic is solidified, and the updated content and corresponding mapping relationships are recorded synchronously.

[0130] First, the configuration parameters distributed from the cloud are parsed. Combined with the resource load status of the edge nodes, a mapping relationship is established between the configuration parameters and preprocessing intensity, data dimension filtering, and adaptive compression. The configuration parameters distributed from the cloud primarily consist of abstract indicators such as feature extraction granularity and processing priority, which cannot be directly used as the execution basis for edge-side processing. Simultaneously, the resource load status of the edge nodes is a core constraint for the implementation of processing logic; a mapping relationship established without considering resource status can easily lead to ineffective operation of the processing logic. Specifically, after receiving the configuration parameters through the control channel, the configuration parameters are first structured and parsed to extract core indicators such as feature extraction granularity and processing priority, redundant fields are removed, and parameter integrity is verified.

[0131] The system synchronizes the real-time resource load status of edge nodes, such as CPU utilization and memory usage, to ensure that the mapping relationship adapts to resource constraints. Based on the parsed configuration parameters and real-time resource load status, a mapping relationship is established, directly linking the feature extraction granularity with the preprocessing intensity grading standard and the compression ratio of adaptive compression. It also links processing priority with the core dimension range and retention rules of data dimension filtering, ensuring that each configuration parameter corresponds to a specific edge processing stage, forming a clear mapping relationship. This achieves the transformation of abstract configuration parameters from the cloud to specific processing rules on the edge side, ensuring the adaptability of the mapping relationship to the edge resource status. The constructed mapping relationship provides a clear basis for subsequent refinement and adjustment of processing rules, preventing subsequent adjustments from deviating from cloud collaboration needs and the actual edge resources.

[0132] Secondly, based on the mapping relationship, the preprocessing intensity is refined according to the feature extraction granularity, and the preprocessing intensity is adjusted in combination with the resource load status of edge nodes. At the same time, the data dimension filtering rules are set according to the processing priority. The mapping relationship only clarifies the corresponding direction of configuration parameters and edge processing links, but does not refine the execution standards. It needs to be broken down into operable grading rules and filtering logic. Different requirements for feature extraction granularity correspond to different levels of preprocessing detail and compression accuracy. The processing priority determines the core focus of data dimension filtering and needs to be dynamically adjusted in combination with the real-time resource load status of the edge to avoid resource overload or substandard processing quality caused by fixed rules. Specifically, based on the mapping relationship, the preprocessing intensity grading standards are broken down according to the refinement requirements of feature extraction granularity. Fine-grained extraction corresponds to the enhanced preprocessing grading of multi-stage noise reduction and high-precision calibration, while coarse-grained extraction corresponds to the lightweight preprocessing grading of core noise reduction and simplified calibration.

[0133] Simultaneously, it matches the corresponding adaptive compression ratio, using low-loss or lossless compression ratios for fine-grained features and high-efficiency compression ratios for coarse-grained features; it dynamically fine-tunes the preprocessing intensity classification based on the current resource load status of the edge nodes, appropriately increasing the applicability of lightweight classifications and reducing the resource consumption of enhanced preprocessing if the edge is under high load; in setting data dimension filtering rules, it clarifies the retention range of core dimensions according to processing priority, retaining all core dimensions and key auxiliary dimensions for high-priority data, and retaining only core dimensions for low-priority data, eliminating unnecessary auxiliary dimensions, ensuring that processing resources are tilted towards high-priority business; thus, the mapping relationship is refined into processing rules that can be directly executed on the edge side, achieving deep adaptation between processing logic and configuration parameters and resource status, and the refined rules output provide specific objects for subsequent verification and solidification, ensuring that the updated processing logic is both targeted and feasible.

[0134] Finally, after updating the preprocessing intensity level, data dimension filtering rules, and compression ratio, a verification is performed. Once the verification passes, the updated edge processing logic is solidified, and the updated content and corresponding mapping relationships are recorded synchronously. The updated processing rules may have inherent logical conflicts and mismatches with edge resource load, and direct implementation may easily lead to edge processing failures. Verification can comprehensively identify defects and ensure the stability of the edge processing logic. Solidifying the edge processing logic and recording relevant information can ensure the consistency of subsequent processing and provide a basis for subsequent optimization or fault tracing. Specifically, the updated preprocessing intensity level, dimension filtering rules, and compression ratio are first loaded into a temporary processing unit to simulate the processing of typical IoT data scenarios and verify the logical compatibility between the rules, that is, to determine whether the preprocessing intensity level and compression ratio match and whether the dimension filtering rules are consistent with the processing priority.

[0135] Simultaneously, the resource consumption during the simulation process is assessed to determine if there is a risk of resource overload. If logical conflicts or resource mismatches are found during verification, the relevant rules are adjusted accordingly, and the simulation verification is re-executed until all verification items pass. After verification, the updated processing rules are solidified into the edge processing module, replacing the original edge processing logic. The update content is recorded synchronously, including the differences between the old and new rules, the corresponding mapping relationship, the update time, and the edge load status, forming a complete update file. This comprehensively ensures the stability and feasibility of the updated edge processing logic, avoids edge processing failures caused by rule defects, and the solidified edge processing logic provides the updated execution basis for subsequent edge feature generation, ensuring that edge-side processing behavior and cloud collaboration requirements are accurately matched. The recorded update file provides a traceability basis for subsequent feedback optimization and fault diagnosis, strengthening the closed-loop management logic of edge-cloud collaboration.

[0136] Furthermore, the calculation of the degree of difference includes:

[0137] The edge features are grouped and matched with the cloud features received through the control channel according to the category identifier. The core dimension data of the edge features and cloud features in each group are extracted, and the consistency of the core dimension data is verified.

[0138] By combining the dimensional importance of cloud features with the resource load status of edge nodes and the cloud load status, dynamic weights are assigned to each set of core dimension data.

[0139] The solution logic is adapted according to the type of core dimension data. Based on the solution logic, the deviation value between the core dimension data of edge features and cloud features is calculated. The deviation value is weighted and summed based on dynamic weights to obtain the single-period difference value.

[0140] The difference values ​​of a single period are accumulated by a sliding window over consecutive periods. At the same time, it is checked whether there are abnormal difference values ​​during the accumulation process. After removing abnormal difference values, the average difference value within the sliding window is calculated to obtain the difference degree.

[0141] First, edge features and cloud features received through the control channel are grouped and matched according to category identifiers. The core dimension data of the two in each group is extracted, and the consistency of the core dimension data is verified. Both edge features and cloud features are associated with category identifiers. The core dimensions and business meanings of features in different categories are significantly different. Direct comparison across categories will lead to distortion of the difference quantification. At the same time, edge and cloud features may have problems such as missing core dimensions and data type incompatibility during transmission and processing. If they are directly used for deviation calculation, it will affect the accuracy of the results. In specific implementation, the category identifiers carried by edge features and cloud features are parsed first. Features of the same category are matched and grouped one by one according to the identifier to ensure that the business attributes of the comparison objects are consistent.

[0142] From each set of matching features, predefined core dimension data is extracted, such as the abnormal fluctuation amplitude and peak duration of fault warning features. Then, consistency verification is performed by retrieving the core dimension data of historical cloud features and comparing the definitions, data types, and field formats of the current edge and cloud core dimensions. For minor inconsistencies, standardization transformation is performed. If there are serious inconsistencies such as missing core dimensions, the data set is marked and temporarily excluded from the calculation. This avoids bias and distortion caused by cross-category comparisons, eliminates consistency defects in core dimension data, and provides an accurate and consistent comparative data foundation for subsequent weight allocation and bias calculation, ensuring the rationality and reliability of the subsequent calculation process.

[0143] Secondly, by combining the dimensional importance of cloud features with the resource load status of edge nodes and the cloud load status, dynamic weights are assigned to each set of core dimension data. Among them, different core dimensions of the same category of features have different importance to business analysis, and the weight of the core dimension must match its practical value. At the same time, the edge-cloud load status reflects the current resource tension of the system. In high-load scenarios, it is necessary to focus on the deviation comparison of core dimensions and reduce the weight ratio of non-core dimensions to avoid unnecessary calculations consuming too many resources. Specifically, the cloud feature dimension importance level preset by the cloud collaboration module is first retrieved. For example, in the fault warning category, the peak duration dimension is the most important and the fluctuation frequency is of medium importance. The real-time resource load status of edge nodes and the cloud load status obtained through the control channel are obtained simultaneously.

[0144] Based on the above information, a dynamic weight allocation rule is established, assigning a high base weight to high-importance dimensions and a low base weight to medium- and low-importance dimensions. If edge nodes or the cloud are under high load, the weight ratio of medium- and low-importance dimensions is further reduced, while the dominant role of the weight of high-importance dimensions is strengthened. This ensures that the weight allocation aligns with both business needs and system resource status. Consequently, the deviation contribution of different core dimensions is accurately matched with business value and resource status, avoiding interference from minor deviations in non-core dimensions in the overall difference assessment. The output dynamic weights provide a reasonable weight basis for the accurate calculation of subsequent single-cycle difference values, ensuring that the difference values ​​truly reflect the deviation of key dimensions.

[0145] Subsequently, the solution logic is adapted according to the type of core dimension data. Based on the solution logic, the deviation value between the edge features and cloud features of the core dimension data is calculated. Then, the deviation values ​​of each dimension are weighted and summed based on dynamic weights to obtain the single-period difference value. Among them, the core dimension data has different types, such as time series data and numerical data. The deviation manifestation and calculation logic of different types of data are fundamentally different. Using a unified solution logic will lead to distortion of deviation calculation. The weighted summation is to comprehensively analyze the deviation of each core dimension to form a quantitative result that reflects the overall deviation of edge and cloud features within a single period. Specifically, the type of each group of core dimension data is first distinguished, and the corresponding solution logic is adapted for different types. Among them, the solution logic of trend consistency comparison is used for time series data, which focuses on analyzing the deviation of data change trend. Time series data includes continuously acquired device temperature data.

[0146] Numerical data employs a direct deviation comparison solution logic, focusing on the degree of deviation inherent in the data itself. Numerical data includes the rated voltage and current voltage of the equipment. After calculating the deviation values ​​of each core dimension through an adapted solution logic, a weighted summation is performed on the deviation values ​​of all core dimensions, combined with assigned dynamic weights, to obtain the overall deviation result of the edge cloud features within a single data processing cycle, i.e., the single-cycle difference value. This ensures the accuracy of the deviation calculation for each core dimension and avoids deviation distortion caused by improper data type adaptation. The generated single-cycle difference value provides the basic data for the cumulative analysis of the subsequent sliding window, ensuring that the subsequent difference calculation can reflect the deviation trend of continuous cycles.

[0147] Finally, the single-period difference values ​​of consecutive cycles are accumulated through a sliding window. Simultaneously, any abnormal difference values ​​are checked during the accumulation process. After removing abnormal difference values, the average difference value within the sliding window is calculated to obtain the difference degree. The difference value of a single cycle can be affected by accidental factors, such as instantaneous network fluctuations or single data processing errors, and cannot truly reflect the long-term deviation trend of edge cloud features. Abnormal difference values ​​can severely interfere with the overall difference assessment results and need to be removed through verification. Accumulating and calculating the average value through a sliding window can smooth out accidental fluctuations, making the final difference degree more closely reflect the true edge cloud feature deviation state. A fixed-length sliding window is first set, and the single-period difference values ​​of multiple consecutive data processing cycles are sequentially included in the window for accumulation.

[0148] During the accumulation process, the rationality of each single-cycle difference value is verified in real time. Combining the historical difference value distribution range with the preset anomaly judgment logic, abnormal difference values ​​are identified and marked, such as values ​​that have significant abrupt changes compared to adjacent cycle difference values. After removing the marked abnormal difference values, the average level of the remaining single-cycle difference values ​​within the sliding window is calculated. This average value is the final difference degree. This effectively filters out the interference of accidental factors and outliers, so that the difference degree can stably and truly reflect the long-term deviation trend of edge-cloud features. The generated difference degree provides the core decision basis for the local weights of the subsequent optimization unloading strategy, ensuring that the local weight optimization can accurately target the real deviation problem of edge-cloud features and strengthen the closed-loop optimization logic of edge-cloud collaboration.

[0149] Specifically, optimizing local weights in the unloading strategy includes:

[0150] Filter the category identifiers corresponding to the differences that exceed the difference threshold for multiple consecutive periods, and retrieve the historical difference records corresponding to the category identifiers, as well as the resource load status of the edge nodes and the cloud load status.

[0151] Optimization priorities are determined by the degree of difference and the urgency of the category identifier, and local weights are adjusted according to optimization priorities by combining historical difference records and the resource load status of edge nodes and cloud load status.

[0152] The weight benchmark is adjusted based on the optimized local weight, and the impact of the adjusted offloading strategy on the resource load status of edge nodes is verified to be within the allowable threshold. At the same time, the consistency with the configuration of the processing priority of the historical distribution in the cloud is verified.

[0153] After the verification is passed, the optimized local weights are fixed and the optimization record of the local weights is generated.

[0154] First, we filter out category identifiers whose difference exceeds the difference threshold for multiple consecutive periods. Then, we retrieve the historical difference records, edge node resource load status, and cloud load status corresponding to these category identifiers. Since the difference exceeding the threshold in a single period may be caused by accidental factors, we only optimize the category identifiers that exceed the threshold for multiple consecutive periods to avoid ineffective optimization that consumes system resources. The historical difference records carry optimization experience for similar deviations in the past, and the edge cloud load status reflects the current system resource constraints. Together, they provide a reliable basis for local weight adjustment and avoid blind adjustment. Specifically, we first analyze the difference data for multiple consecutive data processing periods, filter out the category identifiers whose difference continuously exceeds the preset threshold, and form a list of categories to be optimized.

[0155] The system retrieves historical discrepancy records corresponding to each category in the target list, extracting key information such as high-frequency deviation types and past adjustment experience. Simultaneously, it collects real-time resource load status through the resource monitoring unit of the edge node and obtains real-time cloud load status through the control channel. If no corresponding historical discrepancy record exists, it is marked as the first optimization and the status is retained. The retrieved historical records and real-time load data are structurally integrated, and redundant and conflicting information is removed to form a complete optimization base dataset. This accurately identifies the business categories that truly need optimization, providing a comprehensive and realistic decision-making basis for subsequent weight adjustments and avoiding deviations in optimization direction. The output list of categories to be optimized and the base dataset lay the core foundation for priority division and weight adjustment.

[0156] Secondly, optimization priorities are determined based on the degree of difference and the urgency of the category identifier. Local weights are then adjusted according to optimization priorities, taking into account historical difference records and the resource load status of edge nodes and the cloud load status. The severity of deviations and business importance vary among different categories to be optimized. Prioritizing optimization based on the degree of difference and urgency ensures that core business and severely biased categories receive priority optimization. Local weight adjustments must be based on historical experience and current load status to avoid repeating past ineffective adjustments and to prevent system resource overload, ensuring the accuracy and safety of optimization. Specifically, the logic for determining the degree of difference is first clarified. For example, a large continuous exceedance of the threshold is considered a high-level category, while a small exceedance is considered a medium-level category. Optimization priorities are then determined based on the urgency of the category identifiers to be optimized. Categories with both high degree of difference and high urgency are set to the highest priority, while categories with low degree of difference or low urgency are set to low priority.

[0157] Based on the priority division, and combined with the integrated historical difference records and edge-cloud load status, differentiated adjustment rules are formulated: For the highest priority category, the local weights of dimensions related to the difference deviation are adjusted, while the adjustment range is constrained by the edge-cloud load status, for example, the adjustment range is reduced when the edge-cloud is under high load to avoid resource fluctuations; For medium and low priority categories, the local weights are fine-tuned with reference to the adaptation and adjustment experience in the historical difference records to reduce trial and error costs; If it is the first optimization, the basic adjustment is performed based on the preset weight benchmark; In this way, precise differentiated optimization of local weights is achieved, which ensures that core business and serious deviation issues are resolved first, while also taking into account the stability of system resources. The optimized local weights output provide core adjustment parameters for the next step of weight benchmark correction and strategy verification.

[0158] Subsequently, the weight benchmark is corrected based on the optimized local weights, and the impact of the corrected offloading strategy on the resource load status of edge nodes is verified to be within the allowable threshold. At the same time, the consistency with the processing priority configuration of the historical distribution in the cloud is verified. The local weights are refined adjustment parameters of the weight benchmark. The optimized local weights must be integrated into the weight benchmark to be effective in generating the offloading strategy. However, the optimized weights may have adaptation defects. If applied directly, they may cause resource overload on edge nodes or conflict with cloud processing priorities, thus disrupting edge-cloud collaboration consistency. In specific implementation, the adjusted local weights are substituted into the weight benchmark correction process to update the corresponding weight benchmark parameters. Through the resource simulation unit of the edge nodes, the execution process of the offloading strategy generated based on the corrected weight benchmark is simulated to evaluate the changes in the usage of resources such as CPU, memory, and transmission bandwidth of the edge nodes after the strategy is executed, and to determine whether there is a risk of resource overload.

[0159] Simultaneously, the historical distribution processing priority configuration information in the control channel cache is retrieved from the cloud, and the consistency between the priority setting in the corrected unloading strategy and the cloud configuration is compared to check for any business priority conflicts. If the verification finds resource overload risks or priority conflicts, the local weights are fine-tuned in reverse for specific issues, and the correction and verification process is re-executed until both verifications pass. This ensures that the optimized local weights can be effectively integrated into the unloading strategy generation logic, guaranteeing the feasibility of the strategy and the consistency of edge-cloud collaboration, and avoiding system failures or collaboration chaos caused by weight optimization. The completed verification results provide a valid verification basis for the subsequent solidification of local weights.

[0160] After final verification, the optimized local weights are solidified and optimization records are generated. The solidified local weights are necessary to ensure stable application when subsequent unloading strategies are generated, and to avoid parameter drift that could cause the optimization effect to fail. The optimization records are generated to retain key information of the optimization process, providing historical experience for subsequent optimization and a basis for fault tracing. In practice, the feedback optimization module solidifies the verified local weight parameters to the local storage unit of the edge node, overwriting the original local weight parameters of the corresponding category, so that the optimized parameters can be directly called when subsequent unloading strategies are generated.

[0161] Simultaneously, optimization records for local weights are generated, including the local weight values ​​before and after optimization, the corresponding category identifier to be optimized, information on exceeding the difference limit, the edge-cloud load status during optimization, verification results, and optimization time. These records are then synchronized to cloud storage via the control channel. The local weight optimization record index of the edge nodes is updated for easy retrieval later. This achieves stable implementation and full-process traceability of the local weight optimization effect, forming a closed-loop management system of optimization, verification, solidification, and traceability. The solidified local weights provide optimized core parameters for the accurate generation of subsequent unloading strategies, while the synchronously generated optimization records enhance the iterative optimization capabilities of edge-cloud collaboration, providing important historical data support for subsequent weight benchmark correction and difference optimization.

[0162] Example 2

[0163] As shown in Figure 3, this embodiment provides a real-time data processing method for IoT with edge-cloud collaboration, the method including:

[0164] The system acquires the resource load status of edge nodes and receives the cloud load status broadcast by the control channel. It processes and analyzes IoT data through edge nodes to generate edge features including category identifiers.

[0165] Real-time monitoring of network quality of the transmission channel between edge nodes and the cloud, and comprehensive evaluation of the urgency of category identifiers, resource load status, network quality and cloud load status to generate offloading strategies, in order to select transmission channels and control the uploading of edge features;

[0166] Receive and analyze edge features to generate cloud features, and generate configuration parameters including feature extraction granularity and processing priority based on the resource load status of edge nodes and cloud load status, so as to distribute them to the corresponding edge nodes through the control channel;

[0167] After applying configuration parameters at the edge nodes, update the edge processing logic, calculate the difference between edge features and cloud features received through the control channel, and optimize the local weights in the offloading strategy based on the difference and its corresponding category identifier when the difference exceeds the difference threshold for multiple consecutive periods.

[0168] Since the principle of the method in this embodiment is similar to that of the system described in Embodiment 1, the implementation of the method is the same as that of the system, and the repeated parts will not be described again.

Claims

1. A real-time data processing system for the Internet of Things with edge-cloud collaboration, characterized in that, include: Edge processing module, dynamic transmission module, cloud collaboration module, and feedback optimization module; The edge processing module is used to obtain the resource load status of the edge nodes and receive the cloud load status broadcast by the control channel, and generate edge features including category identifiers by processing IoT data through the edge nodes; The dynamic transmission module is used to monitor the network quality of the transmission channel between the edge node and the cloud in real time, and to comprehensively evaluate the urgency of the category identifier, the resource load status of the edge node, the network quality and the cloud load status to generate an offloading strategy, so as to select the transmission channel and control the uploading of edge features. The cloud collaboration module is used to receive and analyze edge features to generate cloud features. Based on the resource load status of the edge nodes and the cloud load status, it generates configuration parameters including feature extraction granularity and processing priority, which are then distributed to the corresponding edge nodes through the control channel. The feedback optimization module is used to update the edge processing logic after the configuration parameters are applied at the edge nodes, calculate the difference between the edge features and the cloud features received through the control channel, and optimize the local weight of the unloading strategy based on the difference and its corresponding category identifier when the difference is greater than the difference threshold for multiple consecutive periods.

2. The edge-cloud collaborative IoT real-time data processing system as described in claim 1, characterized in that, Generating the edge features includes: after acquiring IoT data, dynamically adjusting the preprocessing intensity and filtering data dimensions based on the resource load status of edge nodes and the cloud load status broadcast by the control channel; labeling the initial category identifier of IoT data according to the business scenario, correcting the initial category identifier by combining historical cloud features, and determining the urgency of the category identifier; performing feature extraction on the preprocessed IoT data based on the corrected category identifier and urgency, and adaptively compressing it by combining the feature extraction granularity configuration of historical cloud distribution to obtain the initial features; verifying the matching of the feature quantity of the initial features with the resource load status of edge nodes, and the dimensional consistency of the initial features with historical cloud features; after passing the verification, generating edge features including category identifiers and associating them with the resource load status of edge nodes.

3. The edge-cloud collaborative IoT real-time data processing system as described in claim 2, characterized in that, The generated unloading strategy includes: real-time monitoring of the network quality of the transmission channel between edge nodes and the cloud; pre-setting a weight benchmark based on the dimensional consistency between edge features and historical cloud features; and correcting the weight benchmark by combining local weight optimization records; dynamically quantifying the urgency of category identifiers, the resource load status of edge nodes, network quality, and cloud load status based on the corrected weight benchmark to obtain quantitative evaluation results; when conflicts occur in the quantitative evaluation results, reconciling the conflicts by combining the urgency of category identifiers, and generating an initial unloading strategy based on the reconciled quantitative evaluation results; verifying the impact of the initial unloading strategy on the resource load status of edge nodes and its consistency with the configuration of historical cloud distribution processing priorities, and generating the unloading strategy after the verification is passed.

4. The edge-cloud collaborative IoT real-time data processing system as described in claim 3, characterized in that, The process of selecting transmission channels and controlling the upload of edge features includes: matching candidate transmission channels based on the quantitative evaluation results in the offloading strategy; simultaneously acquiring the fluctuation trend of network quality in different candidate transmission channels; combining the matching of the feature quantity of the initial feature with the resource load status of the edge node; selecting transmission channel groups whose matching meets the matching threshold; dynamically configuring the upload priority of the transmission channel group according to the urgency of the category identifier; and dynamically adjusting the upload timing and fragmentation parameters of the edge features in combination with the processing priority of the historical distribution in the cloud; when uploading edge features, monitoring the upload progress and network quality of the transmission channel in real time; when the network quality does not meet the stability threshold, performing abnormal handling according to the urgency of the category identifier and recording the processing information; after the upload is completed, feeding back the upload status to the cloud through the control channel; and after receiving the confirmation signal from the cloud, terminating the occupation of the current transmission channel and releasing the transmission resources of the edge node.

5. The edge-cloud collaborative IoT real-time data processing system as described in claim 1, characterized in that, The process of generating cloud features includes: receiving edge features and associated category identifiers and resource load status of edge nodes; performing preprocessing on edge features based on the dimensional consistency between edge features and historical cloud features; extracting core features from the preprocessed edge features according to the category identifier and the processing priority of historical distribution; synchronously calibrating the dimensional deviation between the core features and historical cloud features; retrieving historical difference records with a difference degree greater than the difference threshold; correcting the core features; verifying the adaptability of the feature quantity of the corrected core features to the cloud load status; performing reverse calibration based on the feature extraction granularity configuration of historical distribution; and generating cloud features associated with category identifiers after the verification is passed.

6. The edge-cloud collaborative IoT real-time data processing system as described in claim 5, characterized in that, The generation of the configuration parameters includes: integrating the resource load status of edge nodes, the cloud load status, and historical configuration parameters to establish a configuration baseline; based on the configuration baseline, combining the urgency of category identifiers and the dimensional importance of cloud features, dynamically generating feature extraction granularity, optimizing the feature extraction granularity based on historical difference records, and simultaneously associating the fluctuation trend of network quality with the processing complexity of cloud features to generate processing priorities; verifying the adaptability of feature extraction granularity and processing priorities, the degree of matching with the resource load status of edge nodes and the cloud load status, and the consistency with historical configuration parameters; after passing the verification, generating configuration parameters and distributing them to the corresponding edge nodes through the control channel.

7. The edge-cloud collaborative IoT real-time data processing system as described in claim 1, characterized in that, The updated edge processing logic includes: parsing the configuration parameters distributed from the cloud, and establishing a mapping relationship between the configuration parameters and preprocessing intensity, data dimension filtering, and adaptive compression, based on the resource load status of the edge nodes; refining the preprocessing intensity level and compression ratio according to the feature extraction granularity, adjusting the preprocessing intensity level according to the resource load status of the edge nodes, and setting data dimension filtering rules according to processing priority; performing verification after updating the preprocessing intensity level, data dimension filtering rules, and compression ratio, and solidifying the updated edge processing logic after the verification passes, while synchronously recording the updated content and the corresponding mapping relationship.

8. The edge-cloud collaborative IoT real-time data processing system as described in claim 7, characterized in that, The calculation of the difference includes: grouping and matching edge features with cloud features received through the control channel according to category identifiers, extracting core dimension data of edge features and cloud features in each group, and verifying the consistency of core dimension data; assigning dynamic weights to each group of core dimension data by combining the dimensional importance of cloud features with the resource load status of edge nodes and the cloud load status; adapting the solution logic according to the type of core dimension data, calculating the deviation value between the core dimension data of edge features and cloud features based on the solution logic, and performing a weighted summation of the deviation value based on the dynamic weights to obtain the single-period difference value; accumulating the single-period difference value of consecutive periods through a sliding window, simultaneously verifying whether there are abnormal difference values ​​during the accumulation process, removing abnormal difference values, and calculating the average difference value within the sliding window to obtain the difference degree.

9. The edge-cloud collaborative IoT real-time data processing system as described in claim 8, characterized in that, The local weights in the optimized unloading strategy include: filtering category identifiers corresponding to differences exceeding a difference threshold for multiple consecutive periods; retrieving historical difference records corresponding to the category identifiers, as well as the resource load status of edge nodes and the cloud load status; classifying optimization priorities according to the level of difference and the urgency of the category identifiers, and adjusting local weights according to optimization priorities based on historical difference records, the resource load status of edge nodes, and the cloud load status; correcting the weight benchmark based on the optimized local weights, and verifying whether the impact of the modified unloading strategy on the resource load status of edge nodes is within the allowable threshold, while verifying the consistency with the configuration of the processing priority of historical cloud distribution; and solidifying the optimized local weights after verification, and generating optimization records for the local weights.

10. A real-time data processing method for IoT with edge-cloud collaboration, implemented based on the real-time data processing system for IoT with edge-cloud collaboration as described in any one of claims 1-9, characterized in that, include: The system acquires the resource load status of edge nodes and receives the cloud load status broadcast by the control channel. It processes and analyzes IoT data through edge nodes to generate edge features including category identifiers. Real-time monitoring of network quality of the transmission channel between edge nodes and the cloud, and comprehensive evaluation of the urgency of category identifiers, resource load status, network quality and cloud load status to generate offloading strategies, in order to select transmission channels and control the uploading of edge features; The system receives and analyzes edge features to generate cloud features. Based on the resource load status of edge nodes and the cloud load status, it generates configuration parameters including feature extraction granularity and processing priority, which are then distributed to the corresponding edge nodes through the control channel. After applying the configuration parameters to the edge nodes, the edge processing logic is updated. The system calculates the difference between the edge features and the cloud features received through the control channel. When the difference exceeds the difference threshold for multiple consecutive periods, the system optimizes the local weights in the offloading strategy based on the difference and its corresponding category identifier.

Images