A cloud-edge collaborative computing task dynamic offloading method and system

Abstract

The application relates to the technical field of cloud-edge collaborative computing, and particularly discloses a cloud-edge collaborative computing task dynamic unloading method and system, wherein original data is received at an edge node and real-time integrity verification is performed. When transmission anomalies are identified, anomaly labels with severity are generated according to preset criteria, and a central scheduling module dynamically adjusts task unloading decisions accordingly. The method solves the problem that the prior art does not fully consider data integrity, and avoids the decrease in decision accuracy caused by data damage. By introducing integrity verification and anomaly severity evaluation, tasks with high data integrity requirements can be prevented from being assigned to links with impaired quality, thereby ensuring end-to-end data quality. This improves the decision accuracy and operation stability of the cloud-edge collaborative system, and overcomes the problem that data damage caused by environmental factors affects system reliability.

Description

Technical Field

[0001] This application relates to the field of cloud-edge collaborative computing technology, and more specifically, to a method and system for dynamically unloading cloud-edge collaborative computing tasks. Background Technology

[0002] In cloud-edge collaborative computing environments, especially in applications like smart city traffic management where real-time performance and data integrity are paramount, efficiently and reliably allocating computing tasks has always been a significant technical challenge. Existing task offloading methods typically rely on assessing macro-level metrics such as computing resource usage and network transmission speed. However, when environmental factors (such as electromagnetic interference) cause hidden data transmission quality issues in network links, these traditional assessment methods often fail to accurately reflect the true situation, potentially compromising the data integrity of critical tasks and consequently affecting the accuracy of system decisions.

[0003] In complex urban or industrial environments, localized, intermittent environmental factors (such as electromagnetic interference or radio frequency noise) can cause significant packet loss and data corruption rates on specific network links, severely impacting data transmission integrity. Current strategies are insufficient because they fail to perceive and assess the actual data integrity status of network links in real-time and with fine-grained precision. When a disrupted link still appears "available" in traditional metrics such as bandwidth and average latency, the scheduler may mistakenly offload computationally intensive tasks with high data integrity requirements to these actually unreliable links.

[0004] This not only leads to the contamination or loss of transmitted data, making it impossible for receiving nodes to perform accurate analysis and processing, but also triggers a large number of retransmissions, further exacerbating network congestion and ultimately causing the entire cloud-edge collaborative system to make incorrect decisions.

[0005] Therefore, the current technical challenge is how to design an offloading method that can accurately and in real time perceive and quantify the integrity of network link data (e.g., packet error rate, data corruption indicators), and integrate these data integrity indicators with traditional computing resources and network performance indicators in task placement decisions. This would prevent critical tasks from being offloaded to links with compromised data transmission quality, ensuring end-to-end data quality and the decision-making accuracy and operational stability of the entire cloud-edge collaborative system. Summary of the Invention

[0006] The purpose of this application is to provide a method and system for dynamic task offloading in cloud-edge collaborative computing, which aims to solve the technical problem that existing task offloading methods in cloud-edge collaborative computing environments fail to perceive and evaluate the actual data integrity status of network links in real time and with fine granularity, resulting in damage to the data integrity of critical tasks and thus affecting the accuracy of system decisions.

[0007] To solve the above problems, the solution proposed in this application is as follows: As one aspect of this application, a method for dynamically offloading cloud-edge collaborative computing tasks is provided, which is applied to a cloud-edge collaborative computing system. The cloud-edge collaborative computing system includes at least one sensing device, at least one edge node with a verification module, and a cloud data center with a central scheduling module. The method includes: Step S1: In response to the computing task scheduling request issued by the central scheduling module, at the edge node, the verification module is used to receive the raw data collected from the sensing device, and the raw data is associated with the computing task. Step S2: Perform integrity verification on the original data to identify whether there are any data integrity anomalies in the original data; Step S3: When a data integrity anomaly is detected in the original data, an anomaly marker is generated based on a preset anomaly judgment benchmark and associated with the original data containing the data integrity anomaly. The anomaly marker includes an indication of the severity of the data integrity anomaly. Step S4: Based on the anomaly marker, the central scheduling module adjusts the unloading decision of the computing task.

[0008] Furthermore, the sensing device includes at least one of a video acquisition device, an acoustic sensor, and a thermal imaging sensor.

[0009] Furthermore, step S2 includes: Step S21: Identify the data type of the original data; Step S22: Perform verification using the preset verification rules corresponding to the data type of the original data, and obtain the verification result; Step S23: Identify whether there are any data integrity abnormalities in the original data based on the obtained verification results.

[0010] Furthermore, step S22 includes: Step S221a: When the data type of the original data is identified as video data, the frame difference analysis method is used to check whether the image frames of the video data are continuous. Step S222a: When the image frames of the obtained video data are discontinuous, obtain the number of lost image frames and the frame length of the lost image frames in the video data; Step S223a: When the number of lost image frames exceeds the first preset threshold or the frame length deviation of the image frames exceeds the second preset threshold, it is identified as a data integrity abnormality and the verification result is output.

[0011] Furthermore, step S22 includes: Step S221b: When the data type of the original data is identified as audio data, calculate the amplitude characteristics of the audio data within multiple preset time windows and compare them with the preset normal amplitude range. Step S222b: When it is detected that the amplitude characteristics of the audio data in multiple preset time windows all exceed the normal amplitude range, it is identified as a data integrity abnormality and the verification result is output.

[0012] Furthermore, step S22 includes: Step S221c: When the data type of the raw data is identified as thermal imaging data, check whether the pixel value range of the thermal imaging data exceeds the preset temperature range. Step S222c: When it is confirmed that the pixel value range of the thermal imaging data exceeds the preset temperature range, it is identified as a data integrity abnormality and the verification result is output.

[0013] Furthermore, step S3 includes: Step S31: Use the set threshold judgment range to classify the anomaly level of the original data into the first severity level, the second severity level, or the third severity level, and establish an anomaly judgment benchmark; Step S32: Generate an anomaly marker associated with the original data that has an anomaly using an anomaly judgment benchmark, wherein the anomaly marker includes an indication of the severity of the anomaly, and the anomaly severity includes a first severity level, a second severity level, or a third severity level.

[0014] Furthermore, step S4 includes: When the anomaly flag indicates an anomaly severity level of 1 or no anomaly flag, the central scheduling module selects the offloading target for the computing task based on at least one of the following indicators: processor load, memory usage, and network bandwidth availability of the edge node or cloud data center. When the anomaly indicated by the anomaly flag is at the second severity level, the central scheduling module prioritizes offloading the computing task to the cloud data center for processing and adds a low confidence label to the generated processing result.

[0015] Furthermore, step S4 also includes: When the anomaly flag indicates an anomaly severity level of 3, the central scheduling module performs at least one of the following operations: Generate an alert for unrecoverable data; Prevent computing tasks associated with the raw data from being offloaded to the edge node or the cloud data center; Discard the original data.

[0016] As a second aspect of this application, a cloud-edge collaborative computing task dynamic offloading system is provided, comprising at least one sensing device, at least one edge node with a verification module, and a cloud data center with a central scheduling module. The system includes: The data receiving unit is used to respond to the computing task scheduling request issued by the central scheduling module. At the edge node, the verification module is used to receive the raw data collected from the sensing device, and the raw data is associated with the computing task. Integrity checking unit, which is used to perform integrity verification on the original data in order to identify whether there are any data integrity abnormalities in the original data; An anomaly identification unit is used to generate an anomaly marker associated with the original data with the data integrity anomaly based on a preset anomaly judgment benchmark when a data integrity anomaly is detected in the original data. The anomaly marker includes an indication of the severity of the data integrity anomaly. An unloading decision unit is used to adjust the unloading decision of the computing task by the central scheduling module according to the anomaly flag.

[0017] As can be seen from the above, the cloud-edge collaborative computing task dynamic offloading method and system disclosed in this application can identify potential integrity anomalies during data transmission in real time by receiving raw data and performing integrity verification at the edge node. When an anomaly is detected, an anomaly flag containing the severity of the anomaly is generated based on a preset anomaly judgment benchmark, and the central scheduling module dynamically adjusts the offloading decision of the computing task based on the anomaly flag. This method effectively solves the shortcomings of existing technologies where task offloading strategies fail to fully consider data integrity issues, leading to damage to critical task data and a decrease in the accuracy of system decisions. By introducing data integrity verification and anomaly severity assessment, this application can avoid offloading tasks with high data integrity requirements to links with compromised data transmission quality, thereby ensuring end-to-end data quality, improving the decision-making accuracy and operational stability of the cloud-edge collaborative system, and overcoming the problem in existing technologies where data integrity is compromised due to environmental factors, affecting system reliability. Attached Figure Description

[0018] Figure 1 A flowchart of a cloud-edge collaborative computing task dynamic unloading method provided in this application embodiment; Figure 2 A system architecture block diagram of a cloud-edge collaborative computing task dynamic offloading system provided in this application embodiment; Figure reference numerals: 100, Cloud-edge collaborative computing task dynamic unloading system; 101, Data receiving unit; 102, Integrity check unit; 103, Anomaly identification unit; 104, Unloading decision unit. Detailed Implementation

[0019] To better illustrate the present invention, the invention will now be described in further detail with reference to the accompanying drawings.

[0020] It should be understood that, in order to make the objectives, technical solutions, and advantages of the embodiments of this disclosure clearer, the technical solutions of the embodiments of this disclosure will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this disclosure, and not all embodiments. The components of the embodiments of this disclosure described and shown in the accompanying drawings can generally be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of this disclosure provided in the accompanying drawings is not intended to limit the scope of the claimed disclosure, but merely represents selected embodiments of this disclosure. All other embodiments obtained by those skilled in the art based on the embodiments of this disclosure without inventive effort are within the scope of protection of this disclosure.

[0021] The following description uses at least one specific embodiment as an example. In this embodiment: Firstly, such as Figure 1 As shown, a method for dynamically offloading cloud-edge collaborative computing tasks is provided, which is applied to a cloud-edge collaborative computing system. The cloud-edge collaborative computing system includes at least one sensing device, at least one edge node with a verification module, and a cloud data center with a central scheduling module. The method includes: Step S1: In response to the computing task scheduling request issued by the central scheduling module, at the edge node, the verification module is used to receive the raw data collected from the sensing device, and the raw data is associated with the computing task. Step S2: Perform integrity verification on the original data to identify whether there are any data integrity anomalies in the original data; Step S3: When a data integrity anomaly is detected in the original data, an anomaly marker is generated based on a preset anomaly judgment benchmark and associated with the original data containing the data integrity anomaly. The anomaly marker includes an indication of the severity of the data integrity anomaly. Step S4: Based on the anomaly marker, the central scheduling module adjusts the unloading decision of the computing task.

[0022] In this embodiment, by introducing a data integrity verification and anomaly severity assessment mechanism, the central scheduling module can dynamically adjust task offloading decisions based on the actual data integrity status, thereby effectively avoiding offloading critical tasks to links with compromised data transmission quality, ensuring end-to-end data quality and the decision-making accuracy and operational stability of the entire cloud-edge collaborative system.

[0023] Specifically, in step S1, when the central scheduling module issues a computation task scheduling request, the edge node responds to this request. At this time, the verification module in the edge node receives raw data collected by the sensing devices. This raw data is associated with a specific computation task; for example, a traffic flow analysis task may require video data from multiple intersection cameras. The raw data can be received in various ways; for example, the sensing devices can stream data to the edge node via wired or wireless networks, or upload data periodically in batches. The verification module is configured to continuously monitor the data stream from the sensing devices and receive new raw data immediately upon arrival.

[0024] In step S2, after receiving the raw data, the verification module performs integrity verification on this raw data to identify whether there are any data integrity anomalies. Data integrity verification is a critical step in ensuring data quality. For example, for video data, it can check the continuity of video frames, whether the image shows mosaic or screen tearing, etc.; for audio data, it can analyze its waveform characteristics to check for abnormal silence or noise; for sensor data, it can check whether the data values ​​are within a reasonable physical range. Verification methods may include, but are not limited to: calculating the checksum or hash value of the data and comparing it with the expected value; checking the sequence number of the data packets to identify whether there is packet loss; and analyzing the data structure to ensure that it conforms to the preset format specifications.

[0025] In step S3, when a data integrity anomaly is detected in the original data, the system generates an anomaly marker associated with the original data based on a preset anomaly judgment benchmark. This anomaly marker indicates the severity of the data integrity anomaly, quantifying the degree of the anomaly. For example, if the number of lost video frames is small, it may be marked as a minor anomaly; if the number of lost frames is large, or critical data fields are corrupted, it may be marked as a severe anomaly.

[0026] In step S4, the central scheduling module adjusts the offloading decision for computing tasks based on the aforementioned anomaly markers. The offloading target is no longer solely based on traditional metrics such as computing resources and network bandwidth, but also comprehensively considers data integrity. For example, if the anomaly marker indicates a low severity of data integrity issues, the central scheduling module may continue to offload the task to edge nodes for processing. However, if the anomaly marker indicates a high severity of data integrity issues, the central scheduling module may choose to offload the task to a cloud data center, as the cloud typically possesses stronger data recovery, cleaning, and fault tolerance capabilities, enabling better handling of damaged data, or it may directly prevent the task from being offloaded to avoid further processing of incomplete or erroneous data.

[0027] The overall working principle of this application lies in performing real-time, fine-grained integrity verification on the raw data collected by sensing devices at edge nodes, and generating anomaly tags with varying degrees of severity based on the verification results. This provides the central scheduling module with a more comprehensive basis for task offloading decisions. When the central scheduling module issues a computing task scheduling request, the edge node receives the raw data, and its verification module immediately initiates integrity verification. If anomalies are detected, the system quantifies the severity of the anomaly based on preset anomaly judgment criteria and generates corresponding anomaly tags. Subsequently, the central scheduling module no longer relies solely on traditional indicators such as processor load, memory usage, and network bandwidth availability for decisions, but rather considers these traditional indicators in conjunction with the severity of data integrity anomalies. For example, for tasks with extremely high data integrity requirements, even if the edge node has sufficient resources, if the raw data contains severe integrity anomalies, the central scheduling module may choose to offload the task to the cloud data center for more specialized processing, or directly prevent the task from executing, to avoid making decisions based on erroneous data. This ensures that only high-quality data is used for critical computing tasks, thereby significantly improving the decision-making accuracy of the cloud-edge collaborative computing system.

[0028] Preferably, the sensing device includes at least one of a video acquisition device, an acoustic sensor, and a thermal imaging sensor, thereby enabling the effective acquisition of multiple types of raw data and broadening the applicability of the cloud-edge collaborative computing system in different application scenarios. For example, in the field of intelligent security, video acquisition devices and acoustic sensors can be used to acquire multimodal data; in the field of industrial monitoring, thermal imaging sensors can be used to monitor equipment temperature anomalies. This diversified data acquisition capability enables the system to handle a wider range of computing tasks and provides more specific data type information for subsequent data integrity verification, thereby improving the practicality of the overall cloud-edge collaborative computing task dynamic offloading method.

[0029] In this embodiment, step S2 includes: Step S21: Identify the data type of the original data; Step S22: Perform verification using the preset verification rules corresponding to the data type of the original data, and obtain the verification result; Step S23: Identify whether there are any data integrity abnormalities in the original data based on the obtained verification results.

[0030] Specifically, step S21 aims to identify the specific type of raw data collected by the sensing devices. The raw data may originate from various sensing devices, such as video acquisition devices, acoustic sensors, or thermal imaging sensors, and therefore its data type may include video data, audio data, thermal imaging data, or other types of data.

[0031] Step S22 refers to the system calling a preset verification rule that matches the data type after identifying the data type of the original data. For example, for video data, it may be necessary to check the continuity of the frame sequence; for audio data, it may be necessary to analyze its amplitude characteristics; for thermal imaging data, it may be necessary to check its pixel value range. The preset verification rules are predefined and configured according to the characteristics and potential anomaly patterns of different data types, and their purpose is to effectively detect any integrity anomalies that may exist in that type of data.

[0032] Step S23 refers to determining whether there are any data integrity anomalies in the original data based on the verification results obtained in step S22. The verification results may include a series of indicators or states, such as the number of frames lost, amplitude deviation, and pixel values ​​out of range. By comparing these verification results with preset anomaly judgment criteria, it can be finally determined whether the original data is complete or whether there is some form of integrity anomaly.

[0033] By refining the raw data integrity verification process into three sub-steps—identifying the data type, applying the corresponding verification rules, and identifying anomalies based on the verification results—refined management of data integrity verification is achieved. This step-by-step approach allows the verification process to be customized according to the characteristics of different data sources, avoiding missed detections or false positives that might occur when using a single, universal verification method. By first clearly defining the data type, the system can intelligently select the most suitable verification algorithm and standard, thereby ensuring the accuracy of the verification.

[0034] Furthermore, in some of the embodiments described above in this application, performing integrity verification on the original data is a crucial step in ensuring the reliability of the computing task. Specifically, when step S22 is identified as video data, it can be performed as follows.

[0035] As one method, step S22 includes: Step S221a: When the data type of the original data is identified as video data, the frame difference analysis method is used to check whether the image frames of the video data are continuous. Step S222a: When the image frames of the obtained video data are discontinuous, obtain the number of lost image frames and the frame length of the lost image frames in the video data; Step S223a: When the number of lost image frames exceeds the first preset threshold or the frame length deviation of the image frames exceeds the second preset threshold, it is identified as a data integrity abnormality and the verification result is output.

[0036] Specifically, frame difference analysis is a commonly used video processing technique that detects motion or change by comparing pixel differences between adjacent image frames in a video sequence. Here, this method is used to check the continuity of image frames in video data, i.e., to determine if there are missing frames or frame sequence errors in the video stream. When discontinuous image frames are detected in the video data, the system further obtains the number of missing image frames and the frame length of each missing frame. The number of missing image frames refers to the actual number of frames missing in an expected continuous video stream, while the frame length refers to the duration of these missing frames in time. A first preset threshold and a second preset threshold are pre-defined criteria used to quantify the severity of video data integrity anomalies. The first preset threshold can be set as the maximum allowed number of missing frames, and the second preset threshold can be set as the allowed frame length deviation range. When the number of missing image frames exceeds the first preset threshold or the frame length deviation exceeds the second preset threshold, the video data is considered to have integrity anomalies, and the corresponding verification result is output.

[0037] As a second method, step S22 includes: Step S221b: When the data type of the original data is identified as audio data, calculate the amplitude characteristics of the audio data within multiple preset time windows and compare them with the preset normal amplitude range. Step S222b: When it is detected that the amplitude characteristics of the audio data in multiple preset time windows all exceed the normal amplitude range, it is identified as a data integrity abnormality and the verification result is output.

[0038] Specifically, when the verification module identifies the raw data as audio data, feature extraction and comparison are required to assess its integrity. Audio data may be affected by noise interference, signal attenuation, or partial data loss during transmission or acquisition, leading to abnormal amplitude characteristics. These anomalies can be effectively captured by calculating the amplitude characteristics of the audio data within multiple preset time windows. Amplitude characteristics can be understood as the intensity or energy of the audio signal; for example, the root mean square (RMS) amplitude, peak amplitude, or mean absolute amplitude can be calculated for each time window. These calculated amplitude characteristics are then compared to a preset normal amplitude range. This normal amplitude range is derived from statistical analysis of a large number of normal audio data samples and is used to define the amplitude fluctuation range of audio data under normal conditions.

[0039] When the verification module detects that the amplitude characteristics of audio data exceed the preset normal amplitude range within multiple preset time windows, this indicates that the audio data may have suffered severe integrity damage or abnormal interference. For example, if the amplitude characteristics remain too low, it may mean signal loss or severe attenuation; if they remain too high, it may mean the presence of strong noise or clipping distortion. In this case, the verification module will identify a data integrity anomaly and output the corresponding verification results for subsequent anomaly marker generation and offloading decision adjustments.

[0040] As a third method, step S22 includes: Step S221c: When the data type of the raw data is identified as thermal imaging data, check whether the pixel value range of the thermal imaging data exceeds the preset temperature range. Step S222c: When it is confirmed that the pixel value range of the thermal imaging data exceeds the preset temperature range, it is identified as a data integrity abnormality and the verification result is output.

[0041] Specifically, the pixel value range refers to the set of temperature or intensity values ​​represented by each pixel in a thermal imaging image. A preset temperature range refers to the temperature interval within which a thermal imaging device or system is designed to accurately measure and display data for a specific application scenario. For example, in industrial equipment monitoring, the preset normal operating temperature range might be 0°C to 100°C. Checking whether the pixel value range of the thermal imaging data exceeds the preset temperature range means analyzing the received thermal imaging data to determine whether the temperature information it contains falls within the expected or permissible physical range. When pixel values ​​exceed the preset range, it indicates potential problems such as data acquisition errors, sensor malfunctions, or environmental anomalies. In this case, it should be marked as abnormal data, and the verification result should be output.

[0042] By leveraging the characteristics of thermal imaging data, the integrity of the raw data is verified. Specifically, thermal imaging data typically reflects the temperature distribution of an object, and its pixel values ​​should fall within a physically reasonable temperature range. If the pixel value range of thermal imaging data exceeds the preset temperature range—for example, by exhibiting extremely high or low abnormal temperature values—it indicates potential problems such as acquisition errors, sensor malfunctions, transmission corruption, or drastic environmental changes, rendering the data inaccurate and unreliable. By checking whether the pixel value range exceeds the preset range, such data integrity anomalies can be effectively identified, ensuring that subsequent computational tasks are processed based on reliable thermal imaging data.

[0043] In this embodiment, step S3 includes: Step S31: Use the set threshold judgment range to classify the anomaly level of the original data into the first severity level, the second severity level, or the third severity level, and establish an anomaly judgment benchmark; Step S32: Generate an anomaly marker associated with the original data that has an anomaly using an anomaly judgment benchmark, wherein the anomaly marker includes an indication of the severity of the anomaly, and the anomaly severity includes a first severity level, a second severity level, or a third severity level.

[0044] Specifically, in step S31, the set threshold judgment range refers to a series of pre-determined numerical intervals or condition sets used to quantify and distinguish the severity of data integrity anomalies. For example, these thresholds can be set based on indicators such as data loss rate, data deviation, and anomaly duration. The first severity level can represent a minor, tolerable anomaly with little impact on data processing; the second severity level can represent a moderate anomaly requiring attention, which may have some impact on the data processing results; and the third severity level represents a severe, unacceptable anomaly that may lead to data processing failure or severely distorted results. By clearly defining these levels, a systematic anomaly judgment benchmark can be established, providing a basis for subsequent anomaly labeling. In step S32, the anomaly judgment benchmark is used to evaluate the identified data integrity anomalies and classify them into the corresponding severity level. For example, when an anomaly indicator falls within the first threshold judgment range, the anomaly is labeled as the first severity level; when it falls within the second threshold judgment range, it is labeled as the second severity level, and so on. Therefore, the generated anomaly markers not only indicate the existence of anomalies in the data, but also clearly indicate the severity of the anomalies, thus providing richer information for subsequent decision-making.

[0045] The above approach enables refined management and identification of data integrity anomalies. By classifying anomalies into different severity levels, the system can adopt more appropriate and efficient response strategies based on the actual impact of the anomalies, thereby significantly improving the flexibility of dynamic offloading of cloud-edge collaborative computing tasks. This hierarchical processing mechanism helps optimize resource allocation, ensures the reliable execution of critical tasks, and effectively reduces potential risks and losses caused by data anomalies.

[0046] In some preferred embodiments, a specific example is given below. Suppose that during video data integrity verification, frame difference analysis reveals discontinuities in the video data's image frames. In this case, a threshold range can be set based on the number of missing image frames or the frame length deviation. For example, it can be set as follows: when the number of missing image frames is between 1 and 5, or the frame length deviation is between 1% and 5%, the anomaly is classified as a first severity level (minor anomaly); when the number of missing image frames is between 6 and 10, or the frame length deviation is between 5% and 10%, the anomaly is classified as a second severity level (moderate anomaly); and when the number of missing image frames exceeds 10, or the frame length deviation exceeds 10%, the anomaly is classified as a third severity level (severe anomaly). Therefore, when the verification module detects that 7 frames of video data are missing, an anomaly marker is generated based on the above anomaly judgment criteria, indicating an anomaly severity level of the second severity level. The anomaly flag is then sent to the central scheduling module so that it can adjust the offloading decision for computing tasks based on the strategy for moderate anomalies.

[0047] In this embodiment, step S4 includes: When the anomaly flag indicates an anomaly severity level of 1 or no anomaly flag, the central scheduling module selects the offloading target for the computing task based on at least one of the following indicators: processor load, memory usage, and network bandwidth availability of the edge node or cloud data center. When the anomaly indicated by the anomaly flag is at the second severity level, the central scheduling module prioritizes offloading the computing task to the cloud data center for processing and adds a low confidence label to the generated processing result.

[0048] When the anomaly flag indicates an anomaly severity level of 2, it means that the original data has a moderate level of data integrity anomaly. Although the data may still have some usability, its reliability has been affected. In this case, to ensure that the computing task can be processed more stably and reliably, the central scheduling module will prioritize offloading the computing task to the cloud data center. The cloud data center usually has more powerful computing capabilities and can better handle data with moderate anomalies, and attempt to repair or compensate for them. In addition, to alert subsequent data users or processing procedures to the potential defects in the data, the central scheduling module will also add a low-confidence label to the processing results generated by the cloud data center. This label is intended to indicate that the processing result is based on the original data with moderate anomalies, and its confidence level is lower than that of the result based on complete data, thus providing a reference for subsequent decision-making.

[0049] In some preferred embodiments, an intelligent traffic monitoring system is assumed, wherein the sensing devices include video acquisition devices deployed at intersections. These devices continuously collect traffic video data and send it to edge nodes for preliminary processing.

[0050] Specifically, when the edge node receives video data, the verification module will perform an integrity check on it.

[0051] Scenario 1: If the video data is complete or there are only very short frame drops (judged as the highest severity level), the central scheduling module will dynamically decide to offload the video analysis task to a less loaded edge node based on real-time indicators such as processor load, memory usage, and network bandwidth availability at the current edge nodes and cloud data center. This ensures rapid response and low-latency analysis. For example, if an edge node currently has a low processor load, the task will be offloaded to that edge node for traffic flow statistics or anomaly detection.

[0052] Scenario 2: If the video data has moderate frame loss or partial image blurring (classified as Level 2 severity), the edge node verification module will generate an anomaly marker indicating Level 2 severity. In this case, the central scheduling module will prioritize offloading the video analysis task to the cloud data center. The cloud data center, utilizing its powerful computing capabilities and more sophisticated image processing algorithms, attempts to interpolate and restore the lost frames or enhance the blurred images to compensate for data defects as much as possible. Simultaneously, after cloud processing, the generated traffic flow report or event recognition result will be accompanied by a "low confidence" label to indicate to traffic management personnel that the result is based on video data with moderate anomalies and may require further manual review or verification using other data sources.

[0053] Through the above examples, the solution of this application can flexibly adjust the offloading strategy of computing tasks according to the severity of data integrity anomalies.

[0054] Furthermore, step S4 also includes: When the anomaly flag indicates an anomaly severity level of 3, the central scheduling module performs at least one of the following operations: Generate an alert for unrecoverable data; Prevent computing tasks associated with the raw data from being offloaded to the edge node or the cloud data center; Discard the original data.

[0055] Specifically, generating an unrecoverable data alert means that when the central scheduling module identifies a data integrity anomaly of level three severity in the original data, it sends a notification to the system administrator, relevant operators, or upper-level application systems, warning that the batch of original data is severely damaged and cannot be effectively processed or recovered. This alert may include information such as the identifier of the abnormal data, the type of anomaly, the severity of the anomaly, and suggested handling measures. Its purpose is to promptly inform relevant parties of the data's unavailability and avoid making decisions based on erroneous data.

[0056] Specifically, preventing computational tasks associated with the aforementioned raw data from being offloaded to the aforementioned edge nodes or cloud data centers can be understood as the central scheduling module immediately interrupting or refusing to assign any computational tasks to the raw data upon receiving raw data with an anomaly flag indicating a severity level of 3. This means that the raw data will not be sent to edge nodes or cloud data centers for subsequent computational processing, thereby avoiding the unnecessary occupation of computing resources and the generation of potential erroneous results.

[0057] In practical applications, discarding the aforementioned raw data specifically means that after the central scheduling module confirms that the raw data has a data integrity anomaly of level three severity, it removes the raw data from the storage or transmission queue and no longer performs any form of storage, transmission, or processing. For example, it can be cleared from the cache or not written to persistent storage. The purpose is to completely eliminate the potential negative impact of severely corrupted data on the system and free up storage and network resources.

[0058] By introducing a special processing mechanism for anomalous data at the third severity level, the potential resource waste and propagation of erroneous results in the basic solution are effectively addressed. When raw data is identified as having a severe integrity anomaly at the third severity level, it means the data is severely corrupted, and the information it contains may be completely distorted or missing, rendering it unusable for any meaningful computation. Attempting to process it at this point not only consumes valuable computing resources (such as processor time, memory, and network bandwidth), but also results in extremely low reliability of the processing results, potentially leading the system to make incorrect decisions based on erroneous information. By generating an unrecoverable data alert, the system can promptly notify relevant personnel or systems, preventing them from relying on or waiting for this invalid data. By preventing the offloading of computational tasks, the path of severely anomalous data entering the computation process can be cut off at the source, thus preventing edge nodes or cloud data centers from processing this useless data and saving significant computing and transmission resources. Furthermore, by discarding the original data, this severely corrupted data can be completely removed, preventing it from remaining in the system and potentially being misused, while simultaneously freeing up storage space and ensuring the effective utilization of system resources.

[0059] Secondly, such as Figure 2 As shown, a cloud-edge collaborative computing task dynamic offloading system 100 is provided, which includes at least one sensing device, at least one edge node with a verification module, and a cloud data center with a central scheduling module. The system includes: The data receiving unit 101 is used to respond to the computing task scheduling request issued by the central scheduling module. At the edge node, the verification module is used to receive the raw data collected from the sensing device, and the raw data is associated with the computing task. Integrity checking unit 102 is used to perform integrity verification on the original data in order to identify whether there is any data integrity abnormality in the original data; An anomaly identification unit 103 is used to generate an anomaly marker associated with the original data with the data integrity anomaly based on a preset anomaly judgment benchmark when an anomaly is detected in the original data. The anomaly marker includes an indication of the severity of the anomaly. Unloading decision unit 104 is used to adjust the unloading decision of computing tasks by the central scheduling module according to the anomaly flag.

[0060] As can be seen from the above, the cloud-edge collaborative computing task dynamic offloading method and system disclosed in this application can identify potential integrity anomalies during data transmission in real time by receiving raw data and performing integrity verification at the edge node. When an anomaly is detected, an anomaly flag containing the severity of the anomaly is generated based on a preset anomaly judgment benchmark, and the central scheduling module dynamically adjusts the offloading decision of the computing task based on the anomaly flag. This method effectively solves the shortcomings of existing technologies where task offloading strategies fail to fully consider data integrity issues, leading to damage to critical task data and a decrease in the accuracy of system decisions. By introducing data integrity verification and anomaly severity assessment, this application can avoid offloading tasks with high data integrity requirements to links with compromised data transmission quality, thereby ensuring end-to-end data quality, improving the decision-making accuracy and operational stability of the cloud-edge collaborative system, and overcoming the problem in existing technologies where data integrity is compromised due to environmental factors, affecting system reliability.

[0061] Finally, it should be noted that the above-described embodiments are merely specific implementations of this disclosure, used to illustrate the technical solutions of this disclosure, and not to limit them. The protection scope of this disclosure is not limited thereto. Although this disclosure has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that any person skilled in the art can still modify or easily conceive of changes to the technical solutions described in the foregoing embodiments, or make equivalent substitutions for some of the technical features within the scope of the technology disclosed in this disclosure. Such modifications, changes, or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this disclosure, and should all be covered within the protection scope of this disclosure.

Claims

1. A method for dynamically offloading cloud-edge collaborative computing tasks, applied to a cloud-edge collaborative computing system, the cloud-edge collaborative computing system comprising at least one sensing device, at least one edge node with a verification module, and a cloud data center with a central scheduling module, characterized in that, The method includes: Step S1: In response to the computing task scheduling request issued by the central scheduling module, at the edge node, the verification module is used to receive the raw data collected from the sensing device, and the raw data is associated with the computing task. Step S2: Perform integrity verification on the original data to identify whether there are any data integrity anomalies in the original data; Step S3: When a data integrity anomaly is detected in the original data, an anomaly marker is generated based on a preset anomaly judgment benchmark and associated with the original data containing the data integrity anomaly. The anomaly marker includes an indication of the severity of the data integrity anomaly. Step S4: Based on the anomaly marker, the central scheduling module adjusts the unloading decision of the computing task.

2. The cloud-edge collaborative computing task dynamic offloading method according to claim 1, characterized in that, The sensing device includes at least one of a video acquisition device, an acoustic sensor, and a thermal imaging sensor.

3. The cloud-edge collaborative computing task dynamic offloading method according to claim 1, characterized in that, Step S2 includes: Step S21: Identify the data type of the original data; Step S22: Perform verification using the preset verification rules corresponding to the data type of the original data, and obtain the verification result; Step S23: Identify whether there are any data integrity abnormalities in the original data based on the obtained verification results.

4. The cloud-edge collaborative computing task dynamic offloading method according to claim 3, characterized in that, Step S22 includes: Step S221a: When the data type of the original data is identified as video data, the frame difference analysis method is used to check whether the image frames of the video data are continuous. Step S222a: When the image frames of the obtained video data are discontinuous, obtain the number of lost image frames and the frame length of the lost image frames in the video data; Step S223a: When the number of lost image frames exceeds the first preset threshold or the frame length deviation of the image frames exceeds the second preset threshold, it is identified as a data integrity abnormality and the verification result is output.

5. The cloud-edge collaborative computing task dynamic offloading method according to claim 3, characterized in that, Step S22 includes: Step S221b: When the data type of the original data is identified as audio data, calculate the amplitude characteristics of the audio data within multiple preset time windows and compare them with the preset normal amplitude range. Step S222b: When it is detected that the amplitude characteristics of the audio data in multiple preset time windows all exceed the normal amplitude range, it is identified as a data integrity abnormality and the verification result is output.

6. The cloud-edge collaborative computing task dynamic offloading method according to claim 3, characterized in that, Step S22 includes: Step S221c: When the data type of the raw data is identified as thermal imaging data, check whether the pixel value range of the thermal imaging data exceeds the preset temperature range. Step S222c: When it is confirmed that the pixel value range of the thermal imaging data exceeds the preset temperature range, it is identified as a data integrity abnormality and the verification result is output.

7. The cloud-edge collaborative computing task dynamic offloading method according to claim 1, characterized in that, Step S3 includes: Step S31: Use the set threshold judgment range to classify the anomaly level of the original data into the first severity level, the second severity level, or the third severity level, and establish an anomaly judgment benchmark; Step S32: Generate an anomaly marker associated with the original data that has an anomaly using an anomaly judgment benchmark, wherein the anomaly marker includes an indication of the severity of the anomaly, and the anomaly severity includes a first severity level, a second severity level, or a third severity level.

8. The cloud-edge collaborative computing task dynamic offloading method according to claim 7, characterized in that, Step S4 includes: When the anomaly flag indicates an anomaly severity level of 1 or no anomaly flag, the central scheduling module selects the offloading target for the computing task based on at least one of the following indicators: processor load, memory usage, and network bandwidth availability of the edge node or cloud data center. When the anomaly indicated by the anomaly flag is at the second severity level, the central scheduling module prioritizes offloading the computing task to the cloud data center for processing and adds a low confidence label to the generated processing result.

9. The cloud-edge collaborative computing task dynamic offloading method according to claim 8, characterized in that, Step S4 further includes: When the anomaly flag indicates an anomaly severity level of 3, the central scheduling module performs at least one of the following operations: Generate an alert for unrecoverable data; Prevent computing tasks associated with the raw data from being offloaded to the edge node or the cloud data center; Discard the original data.

10. A cloud-edge collaborative computing task dynamic offloading system, comprising at least one sensing device, at least one edge node with a verification module, and a cloud data center with a central scheduling module, characterized in that, The system includes: The data receiving unit is used to respond to the computing task scheduling request issued by the central scheduling module. At the edge node, the verification module is used to receive the raw data collected from the sensing device, and the raw data is associated with the computing task. Integrity checking unit, which is used to perform integrity verification on the original data in order to identify whether there are any data integrity abnormalities in the original data; An anomaly identification unit is used to generate an anomaly marker associated with the original data with the data integrity anomaly based on a preset anomaly judgment benchmark when a data integrity anomaly is detected in the original data. The anomaly marker includes an indication of the severity of the data integrity anomaly. An unloading decision unit is used to adjust the unloading decision of the computing task by the central scheduling module according to the anomaly flag.

Images