Cloud-edge collaborative task management method and related device

Abstract

This application discloses a cloud-edge collaborative task management method and related equipment, relating to the field of computer technology. The method includes: responding to a security registration request from a target edge system, sending a security configuration package to the target edge system to establish a secure communication channel; generating a self-contained task package based on an operation request from a business system, and sending the task package to the target edge system through a first message channel in the secure communication channel; updating the global task status based on the task execution result asynchronously sent by the target edge system through a second message channel in the secure communication channel; and when a preset synchronization event is detected, initiating a status query request to the target edge system, and aligning the global task status according to the status information returned by the query. This application can achieve a unified management effect of reliable communication, stable execution, efficient processing, and eventual consistency of task status during cloud-edge task execution.

Description

Technical Field

[0001] This application relates to the field of computer technology, and more specifically, to a cloud-edge collaborative task management method and related equipment. Background Technology

[0002] With the continuous development of cloud computing, edge computing, and distributed system technologies, cloud-edge collaborative architecture has gradually become an important technical means to support the operation of large-scale business systems and distributed applications. By centralizing functions such as business decision-making and task scheduling in the cloud and delegating specific execution operations to the edge, not only can the overall response efficiency of the system be improved, but the computing and communication pressure on the central node can also be reduced. Therefore, it has been widely used in scenarios such as industrial internet, smart operation and maintenance, and intelligent manufacturing. However, the secure delivery, reliable execution, and state consistency management of tasks in a cloud-edge collaborative environment place higher technical requirements on task management mechanisms.

[0003] In related technologies, cloud-edge collaborative task management typically involves a central system issuing tasks to the edge system via interface calls or message publishing, with the edge system then providing feedback on the execution results after completion. In practical applications, this approach often relies on fixed communication configurations or static credentials, resulting in incomplete security initialization processes and difficulty in ensuring communication security and identity trustworthiness when edge nodes dynamically connect or are deployed at scale. Furthermore, task issuance and result feedback often employ synchronous calls or single message channels, making them susceptible to network fluctuations and system load, leading to issues such as task blocking, decreased execution efficiency, or untimely result feedback. In other words, related technologies generally suffer from the technical challenge of simultaneously ensuring security, reliability, and consistency in cloud-edge collaborative task management. Summary of the Invention

[0004] In the summary section of this application, the relevant technical solutions are described in general terms, and a series of simplified concepts are introduced. These concepts will be further elaborated in the detailed embodiments section. This summary section should not be construed as limiting the key or essential technical features of the claimed solutions, nor is it intended to limit the scope of protection of the claimed solutions.

[0005] The cloud-edge collaborative task management method and related equipment provided in this application can establish a protected cloud-edge communication channel through secure registration. Combined with the asynchronous interaction mechanism of self-contained task packages and dual message channels, and supplemented by active status query alignment, it can achieve a unified management effect of reliable communication, stable execution, efficient processing, and eventual consistency of task status during the execution of cloud-edge tasks.

[0006] Firstly, this application provides a cloud-edge collaborative task management method applied to a central control system, comprising: responding to a security registration request from a target edge system, sending a security configuration package to the target edge system to establish a secure communication channel with the target edge system; generating a self-contained task package based on an operation request from a business system, and sending the task package to the target edge system through a first message channel in the secure communication channel, wherein the task package encapsulates a task identifier, an action type, and a data snapshot corresponding to a task target; updating the global task status based on the task execution result asynchronously sent by the target edge system through a second message channel in the secure communication channel; and when a preset synchronization event is detected, initiating a status query request to the target edge system, and aligning the global task status according to the status information returned by the query.

[0007] In some implementations, the step of sending a security configuration package to the target edge system in response to a security registration request from the target edge system includes: in response to a registration request sent by the target edge system, obtaining the hardware identifier of the target edge system carried in the registration request; after the hardware identifier passes a validity verification, generating a globally unique edge identity identifier, communication credentials, and subscription filter tag for the target edge system, wherein the subscription filter tag is associated with the edge identity identifier; and sending the security configuration package, including the edge identity identifier, the communication credentials, and the subscription filter tag, to the target edge system in encrypted form by calling a pre-built security configuration interface of the target edge system.

[0008] In some implementations, sending the task package to the target edge system via the first message channel in the secure communication channel includes: publishing the task package to a message queue as an instruction topic of the first message channel; and setting the subscription filter tag as a message attribute when publishing the task package, so that the target edge system filters and consumes the task package from the instruction topic based on the subscription filter tag.

[0009] In some implementations, generating a self-contained task package based on an operation request from a business system includes: parsing the operation request to determine the operation type of the target task and the associated target resource; extracting the status data of the target resource from a global database based on the operation type and generating a corresponding data snapshot; and constructing a structured task package based on the task identifier, the operation type, the data snapshot, and preset execution parameters, wherein the task package includes context information required to execute the target task.

[0010] In some implementations, updating the global task status based on the task execution result asynchronously sent by the target edge system through the second message channel in the secure communication channel includes: obtaining a signed result data packet sent by the target edge system from the callback topic message queue, which serves as the second message channel; verifying the signature of the result data packet based on pre-stored communication credentials; after successful verification, parsing the result data packet to obtain the task identifier and target execution status; locating the corresponding global task record according to the task identifier, and updating the global task status to the target execution status.

[0011] In some implementations, the step of initiating a status query request to the target edge system when a preset synchronization event is detected includes: periodically scanning the global task library to identify timed-out tasks whose status is in execution and whose status update time is earlier than a first preset time threshold; for each identified timed-out task, constructing an authenticated status query request based on a status query credential associated with the target edge system; and sending the status query request to a preset status query interface of the target edge system to obtain the current status of the timed-out task on the edge side.

[0012] In some implementations, aligning the global task status based on the status information returned by the query includes: receiving a response from the target edge system in response to the status query request, wherein the response carries the actual status of the timed-out task at the edge; comparing the actual status with the current status of the timed-out task recorded in the global task database; if the actual status is inconsistent with the current status, updating the record in the global task database to the actual status and generating a status synchronization log.

[0013] Secondly, this application also provides a cloud-edge collaborative task management device applied to a central control system, comprising: a channel establishment unit, configured to, in response to a security registration request from a target edge system, send a security configuration package to the target edge system to establish a secure communication channel with the target edge system; a task distribution unit, configured to, based on an operation request from a business system, generate a self-contained task package and send the task package to the target edge system through a first message channel in the secure communication channel, wherein the task package encapsulates a task identifier, an action type, and a data snapshot corresponding to a task target; a status update unit, configured to, based on a task execution result asynchronously sent by the target edge system through a second message channel in the secure communication channel, update the global task status; and a status alignment unit, configured to, when a preset synchronization event is detected, initiate a status query request to the target edge system and perform alignment processing on the global task status based on the status information returned by the query.

[0014] Thirdly, this application also provides an electronic device, including: a memory and a processor, wherein the processor is configured to implement the steps of the cloud-edge collaborative task management method described in the first aspect when executing a computer program stored in the memory.

[0015] Fourthly, this application also provides a computer-readable storage medium storing computer-executable instructions or a computer program, wherein when the computer-executable instructions or the computer program are executed by a processor, the steps of the cloud-edge collaborative task management method described in the first aspect are implemented.

[0016] Fifthly, this application also provides a computer program product, including a computer program or computer executable instructions, which, when executed by a processor, implement the steps of the cloud-edge collaborative task management method provided in the embodiments of this application.

[0017] In summary, this application establishes a secure communication channel between the central control system and the target edge system by responding to the edge system's security registration request and issuing a security configuration package before task execution. This ensures that subsequent task package issuance, execution result feedback, and status queries all occur within a protected communication environment, effectively guaranteeing the credibility of the task instruction source and the authenticity of the task execution results, thus improving communication security and controllability during cloud-edge collaboration. The application generates a self-contained task package based on the business system's operation request, encapsulating a task identifier, action type, and a data snapshot corresponding to the task target. This allows the target edge system to independently complete task execution based on the information within the task package upon receipt, without frequent access to the central system or external data sources during execution. This reduces reliance on real-time network connectivity and the availability of the central system, improving the stability and continuity of the task execution process. Furthermore, by setting up a first message channel for task issuance and a second message channel for task execution within the secure communication channel, the application effectively safeguards the credibility of the task instruction source and the authenticity of the task execution results, thereby enhancing communication security and controllability during cloud-edge collaboration. The second message channel for asynchronous feedback of execution results ensures that task instruction transmission and execution result feedback are independent, avoiding blocking issues caused by synchronous calls. This improves the concurrency of task processing and the overall throughput performance of the system, while also facilitating the central control system to obtain task execution results in a timely manner and maintain the global task status. Based on the task execution results asynchronously sent by the edge system, the global task status is updated, enabling the central side to continuously monitor the execution progress and final results of each task, thereby forming a unified and manageable task status view, which facilitates subsequent business decisions, scheduling, and operation and maintenance management. When a preset synchronization event is detected, the central control system proactively initiates a status query request to the target edge system and aligns the global task status based on the status information returned by the query. Thus, even in the event of abnormal, delayed, or missing asynchronous result feedback, the true task status can still be obtained through supplementary queries, enhancing the ability to ensure the eventual consistency of cloud-edge task status and reducing the management risks caused by inconsistent task status. In summary, the cloud-edge collaborative task management method provided in this application establishes a protected cloud-edge communication channel through secure registration, combines an asynchronous interaction mechanism of self-contained task packages and dual message channels, and is supplemented by proactive state query alignment. This enables a unified management effect that ensures reliable communication, stable execution, efficient processing, and eventual consistency of task status during the execution of cloud-edge tasks. Attached Figure Description

[0018] Various other advantages and benefits will become apparent to those skilled in the art upon reading the following detailed description of preferred embodiments. The accompanying drawings are for illustrative purposes only and are not intended to limit this specification. Furthermore, the same reference numerals denote the same parts throughout the drawings. In the drawings: Figure 1 A flowchart illustrating a cloud-edge collaborative task management method provided in this application embodiment; Figure 2 A schematic diagram of the composition structure of a cloud-edge collaborative task management device provided in this application embodiment; Figure 3 This is a schematic diagram of the composition structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0019] The terms used in the specification, claims, and drawings of this application, such as "first," "second," "third," "fourth," etc. (if any), are used to distinguish similar objects and not to describe a specific order or sequence. Therefore, it is to be understood that these terms can be used interchangeably where appropriate, allowing the described embodiments to be used in different orders, unless specifically required by the illustrations or description. Furthermore, the terms "is" and "has," and any variations thereof, are intended to cover, non-exclusively, all possible constituent elements. For example, a process, method, system, product, or apparatus comprising several steps or units is not necessarily limited to the steps or units explicitly listed, but may also include other steps or units not explicitly listed, or steps or units inherent to the process, method, product, or apparatus.

[0020] In this application, a "module" or "unit" refers to a computer program or part of a computer program that has a specific function and works in conjunction with other related parts to achieve a predetermined goal. These modules or units can be implemented by software, hardware (e.g., processing circuitry or memory), or a combination of both. One or more processors or memories can implement one or more modules or units. Furthermore, each module or unit can also be part of a larger module or unit.

[0021] The technical solutions of this application will be described in detail below with reference to the accompanying drawings of the embodiments. It should be noted that the described embodiments are only a part of this application, and not all embodiments. In the following description, the "some embodiments" mentioned are only a subset of all possible embodiments, which may be the same or different subsets, and different embodiments can be combined with each other without conflict.

[0022] Figure 1 This is a flowchart illustrating a cloud-edge collaborative task management method provided in an embodiment of this application. For example, see [link to example]. Figure 1 The cloud-edge collaborative task management method provided in this application embodiment, applied to a central control system, may include the following steps 101 to 104: Step 101: In response to the security registration request from the target edge system, a security configuration package is sent to the target edge system to establish a secure communication channel with the target edge system.

[0023] In some examples, the target edge system, as an agent execution system deployed on remote distributed nodes, will proactively initiate a security registration request to the central control system after its first startup. This request carries a unique hardware identifier pre-set by the target edge system. This hardware identifier is an immutable identifier generated based on a trusted platform module certificate or a burned serial number, which is used to uniquely represent the physical identity of the edge node. Upon receiving the security registration request, the central control system first extracts the hardware identifier contained in the request and initiates a legitimacy verification process. This involves precisely comparing the hardware identifier with a pre-configured database of legitimate edge node hardware identifiers within the central control system to confirm whether the edge node is an authorized and legitimate node. If the comparison results are inconsistent, the registration request is rejected; otherwise, the edge node is deemed eligible for registration. Subsequently, the central control system dynamically generates the core content required for the security configuration package for the target edge system. This includes a globally unique edge identifier (edge_id), used to uniquely identify the edge node throughout the cloud-edge collaborative system; a time-sensitive and unique communication credential, used for authentication and data signature verification during subsequent bidirectional cloud-edge communication; a subscription filtering tag associated with the edge identifier, used for accurate task delivery; and a status query credential for the central control system to actively query the edge node's status. After the security configuration package is assembled, the central control system calls the security configuration interface pre-exposed by the target edge system during the initialization phase, employing Advanced Encryption Standard (AES). The security configuration package is encrypted using Advanced Execution System (AES) and then transmitted to the target edge system via a secure network link. Upon receiving and decrypting the security configuration package, the target edge system initializes its local communication components based on the parameters contained within. This establishes a secure communication channel between the central control system and the target edge system. This channel provides a reliable communication foundation for the subsequent transmission of task packages and the secure feedback of execution results, effectively mitigating security risks such as unauthorized access and data tampering.

[0024] By implementing step 101, a security registration request from the target edge system is responded to and a security configuration package is issued before the task is executed. This is used to establish a secure communication channel between the central control system and the target edge system, enabling the two parties to interact under the premise of trusted identity and protected communication. This provides a reliable security foundation for subsequent task instruction issuance, execution result feedback, and status query, reduces the risk of unauthorized access and communication tampering, and improves the security and controllability of cloud-edge collaborative communication.

[0025] Step 102: Based on the operation request from the business system, generate a self-contained task package and send the task package to the target edge system through the first message channel in the secure communication channel. The task package encapsulates the task identifier, action type and data snapshot corresponding to the task target.

[0026] In some examples, the business system, as the upper-layer application that initiates specific operation and maintenance requests, sends operation requests to the central control system containing core instructions required to achieve specific business objectives, such as specific operational requests like server configuration updates, container instance startup and shutdown, and resource status inspections. Upon receiving the operation request, the central control system first initiates a request parsing process. Using pre-defined syntax parsing rules, it extracts key information from the request, clarifying the action type and associated target resources corresponding to the target task. The action type defines the execution logic direction of the task, while the target resource specifically refers to the object that needs to be operated on on the edge system side, such as a server with a specified IP address or a container cluster with a specific name. Subsequently, based on the parsed action type and target resources, the central control system accesses its global database. This global database stores complete and authoritative state information of all resources associated with edge nodes, serving as the data benchmark source for the entire cloud-edge collaborative system. The system accurately extracts all current state data of the target resource, including resource configuration parameters, operational status indicators, and dependencies, and generates a corresponding data snapshot. This data snapshot is a frozen view of the target resource at the time the task package is generated, ensuring contextual consistency during task execution by the edge system and preventing subsequent updates to the central database. After generating the data snapshot, the central control system constructs a self-contained task package according to a pre-defined structured format. The task package uses JavaScript object notation. The task is encapsulated using JSON Notation. Besides containing a globally unique task identifier, a clearly defined action type, and a generated data snapshot, it also incorporates preset execution parameters required for task execution, such as execution timeout thresholds, retry limit, and operation priority. This information collectively constitutes the complete context of task execution, ensuring that the edge system can independently complete task execution without needing to query the central control system for any supplementary information. The first message channel here refers to the instruction topic built on a message queue (MQ). This message queue possesses core capabilities such as message persistence, asynchronous transmission, and fault retries, effectively mitigating transmission risks caused by network fluctuations and temporary node unavailability. When the central control system distributes the task package to the target edge system, it publishes the task package to the instruction topic in the message queue, i.e., the first message channel. During the publication process, the subscription filter tag assigned by the target edge system during the security registration phase is set as a message attribute. This subscription filter tag corresponds one-to-one with the edge identity identifier of the target edge system, ensuring that other edge systems in the message queue can only consume task packages matching their own tags, achieving precise task delivery.Meanwhile, the message queue's persistence mechanism stores the published task packages on stable storage media such as disks. Even if a network interruption or a temporary failure of the central control system occurs during the transmission of the task packages, the task packages will not be lost. Once communication is restored or the system is restarted, the transmission can continue, ensuring the reliability of the task distribution process and laying the foundation for the stable execution of the subsequent edge system.

[0027] By implementing step 102, a self-contained task package is generated based on the operation request of the business system. The task package encapsulates the task identifier, action type, and data snapshot corresponding to the task target. This allows the target edge system to independently complete the task execution based on the information in the task package after receiving it, without having to repeatedly access the central control system or external data source during the execution process. This reduces the dependence on real-time network connection and central system availability, and improves the stability and continuity of the task issuance and execution process.

[0028] Step 103: Update the global task status based on the task execution result asynchronously sent by the target edge system through the second message channel in the secure communication channel.

[0029] In some examples, the second message channel is a parallel and independent communication link with the first message channel. It is constructed as a callback topic based on a message queue. This callback topic shares the message queue's persistence, asynchronous transmission, and fault retry capabilities with the instruction topic, while simultaneously achieving logical isolation between instruction issuance and result feedback. This avoids interference between the two types of messages, ensuring the orderliness and reliability of bidirectional communication. After the target edge system completes task execution, it generates a task execution result containing complete information based on the execution process. This result includes not only the task identifier and final execution status (such as execution success, execution failure, partial execution completion, etc.), but also auxiliary information such as key log summaries and resource status change records during task execution. Subsequently, the edge system uses the communication credentials obtained during the secure registration phase to sign the task execution result. The signing method used is Hash-based Message Authentication Code (HMAC). By using the communication credentials as a key and performing a hash operation on the execution result data to generate a unique signature, it ensures that the execution result is not tampered with or forged during transmission, guaranteeing data integrity and authenticity. After signing, the edge system encapsulates the signature information and the original execution result into a result data packet and asynchronously sends it to the central control system via the second message channel. Asynchronous transmission means that the edge system can continue to execute other tasks without waiting for the central control system to receive and confirm, avoiding the impact of communication delays on the execution efficiency of edge nodes. At the same time, the message queue's persistence mechanism stores the result data packet in a stable storage medium. Even if there is a network interruption or a temporary failure of the edge system, the execution result will not be lost, and it can be automatically resent after communication is restored. The central control system deploys a dedicated callback processing service. This service continuously listens to the callback topic, i.e., the second message channel, and obtains the result data packet sent by the edge system in real time. After receiving it, it immediately initiates the signature verification process. The callback processing service calls the communication credentials pre-stored in the central system (which are completely consistent with the key used for signing by the edge system), recalculates the signature of the original execution result in the result data packet according to the same hash message authentication code algorithm, and compares the calculated result with the signature information in the data packet. If the comparison is inconsistent, the result data packet is determined to be at risk of tampering or forgery, and the data packet is directly discarded and a security alarm log is generated; if the comparison is consistent, the verification is passed, confirming the legality and authenticity of the result data packet.After successful verification, the callback processing service parses the result data packet according to preset structured parsing rules, accurately extracting the task identifier and the corresponding target execution state. Then, based on the task identifier, it retrieves the global task library of the central control system. The global task library is an authoritative database that stores the full lifecycle state of all tasks, recording the state information of each stage such as task generation, issuance, and execution. The callback processing service updates the current state of the corresponding task in the global task library to the parsed target execution state through database transaction operations. Database transaction operations can ensure the atomicity of state updates, that is, either the state update is completed completely, or it rolls back to the state before the update in case of an anomaly, avoiding incomplete state updates. At the same time, the system automatically generates a state update log, recording information such as update time, operation subject, original state and new state, providing traceability basis for subsequent fault investigation and auditing. Ultimately, it achieves real-time synchronization between the global task state and the actual execution state at the edge, ensuring the central control system's accurate control over the task execution results.

[0030] By implementing step 103, the target edge system asynchronously sends the task execution results through the second message channel in the secure communication channel, and updates the global task status accordingly. This decouples the task execution and result feedback process, avoids the blocking problem caused by synchronous calls, improves the system's concurrent processing capability and overall operating efficiency, and enables the central control system to keep abreast of the task execution progress and results in a timely and continuous manner.

[0031] Step 104: When a preset synchronization event is detected, a status query request is sent to the target edge system, and the global task status is aligned based on the status information returned by the query.

[0032] In some examples, the preset synchronization event is a consistency guarantee mechanism triggered by a state synchronizer deployed in the central control system. This state synchronizer is an independent functional module specifically responsible for monitoring the global task status and correcting cloud-edge state deviations. Its triggering logic includes periodic triggering and abnormal scenario triggering. Periodic triggering can be achieved by configuring a fixed time interval (e.g., every 3 hours), while abnormal scenario triggering is for special tasks that have not received callback results and have exceeded the task execution timeout threshold. After detecting the preset synchronization event, the central control system first initiates a scanning process of the global task library. The global task library stores the full lifecycle status records of all tasks. During the scanning process, it filters tasks based on their current status identifier and status update timestamp, accurately identifying timeout tasks whose status is "in execution" and whose status update time is earlier than a first preset time threshold. The first preset time threshold is a state synchronization judgment standard preset according to business scenario requirements, used to distinguish between tasks that are executing normally and tasks that may have abnormal statuses, avoiding the accidental triggering of unnecessary query operations. For each identified timeout task, the central control system constructs an authenticated status query request based on the status query credential allocated to the target edge system during the security registration phase. The status query credential is a time-sensitive access token used to verify the legitimacy and credibility of the query request. During construction, the status query credential is embedded in the request header information, and the entire request is encrypted using Transport Layer Security (TLS) to prevent interception or tampering. Subsequently, the central control system sends this status query request to the pre-configured status query interface of the target edge system. This interface is a dedicated internal interface exposed during the edge system's initialization phase; it only responds to requests carrying valid status query credentials and rejects unauthorized access, ensuring that edge-side task status data is not illegally obtained. Upon receiving the status query request, the target edge system first verifies the validity of the status query credential in the request header. If verification is successful, it extracts the actual execution status of the timeout task from its local task database. The local task database is a stable storage medium used by the edge system to persistently store task information and execution status; the recorded status information directly reflects the actual execution status of the task at the edge. The edge system encapsulates the extracted actual status into structured response data and feeds it back to the central control system via an encrypted link.After receiving the feedback status information, the central control system immediately initiates a status alignment process. It first compares the actual status returned by the edge with the current recorded status of the timed-out task in the global task database, field by field. If the comparison results match, the cloud-edge status synchronization is considered normal, and only a status consistency log is generated for auditing. If the comparison results do not match, it indicates a status deviation. The central control system updates the recorded status of the task in the global task database to the actual status reported by the edge through database transaction operations. Database transaction operations ensure the atomicity, consistency, isolation, and durability of status updates, avoiding incomplete updates or data conflicts. Simultaneously, a detailed status synchronization log is generated, recording key information such as deviation type, update time, and operation subject, providing a traceability basis for subsequent fault investigation and system optimization. Ultimately, through this proactive query and alignment mechanism, the system systematically resolves status inconsistencies caused by scenarios such as lost callback messages and abnormal edge processes, ensuring the accuracy and reliability of the global task status.

[0033] By implementing step 104, when a preset synchronization event is detected, a status query request is proactively initiated to the target edge system, and the global task status is aligned based on the status information returned by the query. This enables the central control system to obtain the true execution status of the task even if there is a delay, anomaly, or missing asynchronous result feedback. This enhances the ability to ensure the consistency of cloud-edge task status and reduces the management and scheduling risks caused by inconsistent status.

[0034] In summary, this application's embodiments establish a secure communication channel between the central control system and the target edge system by responding to the edge system's security registration request and issuing a security configuration package before task execution. This ensures that subsequent task package issuance, execution result feedback, and status queries all occur within a protected communication environment, effectively guaranteeing the credibility of the task instruction source and the authenticity of the task execution results, thus improving communication security and controllability during cloud-edge collaboration. A self-contained task package is generated based on the business system's operation request, and this task package encapsulates a task identifier, action type, and a data snapshot corresponding to the task target. This allows the target edge system to independently complete task execution based on the information within the task package upon receipt, without frequently accessing the central system or external data sources during execution. This reduces reliance on real-time network connectivity and the availability of the central system, improving the stability and continuity of the task execution process. By setting up a first message channel for task issuance and a second message channel for task execution within the secure communication channel, the application further enhances the security and controllability of communication during task execution. The second message channel, which asynchronously transmits execution results, makes task instruction transmission and execution result feedback independent of each other, avoiding the blocking problems caused by synchronous calls. This improves the concurrency capability of task processing and the overall throughput performance of the system, while also facilitating the central control system to obtain task execution results in a timely manner and maintain the global task status. Based on the task execution results asynchronously sent by the edge system, the global task status is updated, enabling the central side to continuously monitor the execution progress and final results of each task, thereby forming a unified and manageable task status view, which facilitates subsequent business decisions, scheduling, and operation and maintenance management. When a preset synchronization event is detected, the central control system proactively initiates a status query request to the target edge system and aligns the global task status based on the status information returned by the query. Thus, even in the event of abnormal, delayed, or missing asynchronous result feedback, the true task status can still be obtained through supplementary queries, enhancing the ability to ensure the eventual consistency of cloud-edge task status and reducing the management risks caused by inconsistent task status. In summary, the cloud-edge collaborative task management method provided in this application establishes a protected cloud-edge communication channel through secure registration, combines an asynchronous interaction mechanism of self-contained task packages and dual message channels, and is supplemented by proactive state query alignment. This enables a unified management effect that ensures reliable communication, stable execution, efficient processing, and eventual consistency of task status during the execution of cloud-edge tasks.

[0035] In some embodiments, the aforementioned response to a security registration request from a target edge system, sending a security configuration package to the target edge system, may include: in response to a registration request sent by the target edge system, obtaining the hardware identifier of the target edge system carried in the registration request; after the hardware identifier passes legality verification, generating a globally unique edge identity identifier, communication credentials, and subscription filter tag for the target edge system, wherein the subscription filter tag is associated with the edge identity identifier; and, by calling a pre-built security configuration interface of the target edge system, encrypting and sending the security configuration package, which may include the edge identity identifier, communication credentials, and subscription filter tag, to the target edge system.

[0036] In some examples, after the target edge system completes its local basic environment initialization upon initial startup, it automatically sends a registration request to the central control system. This registration request is encrypted and transmitted via a transport layer security protocol to ensure that it is not intercepted or tampered with during network transmission. The request carries a hardware identifier pre-installed on the target edge system at the factory. This hardware identifier is a unique identifier generated based on a Trusted Platform Module (TPM) certificate or a chip-level programming serial number, possessing the characteristics of being immutable and strongly bound to the hardware, and can serve as the core credential for the physical identity of the edge node. The registration receiving service deployed in the central control system listens to the registration request port in real time. Upon receiving the registration request sent by the target edge system, it extracts the hardware identifier carried within the request through a preset request parsing logic, and then immediately initiates the hardware identifier validity verification process. The central control system retrieves its own pre-built database of legitimate edge node hardware identifiers. This database stores the hardware identifier information of all authorized edge nodes. It uses a precise string comparison algorithm to match the extracted hardware identifiers with the records in the database one by one. If the matching result is that there is no corresponding record, the registration request is deemed illegal, and the registration receiving service will directly return a registration failure response and generate a security alarm log. If the matching is successful, it confirms that the target edge system has legitimate registration qualifications, the verification process is passed, and the system proceeds to the subsequent configuration generation stage. After successful verification, the identity configuration generation module of the central control system creates a unique identity and communication-related configuration for the target edge system. First, it generates a globally unique edge identity identifier. This identifier uses a Distributed Unique Identifier (UUID) algorithm to ensure no duplication throughout the cloud-edge collaborative system, serving as the core identifier for identifying the edge node during subsequent cloud-edge interactions. Simultaneously, it generates communication credentials for authentication in two-way cloud-edge communication. These credentials can be JSON Web Tokens (JWT) or time-sensitive access tokens, containing core fields such as the edge identity identifier, validity period, and permission scope, effectively preventing unauthorized nodes from impersonating the edge. Furthermore, it generates subscription filter tags. These tags, encoded as strings, establish a unique association with the generated edge identity identifier through preset mapping rules, providing a matching basis for the accurate delivery of subsequent task packages. The identity configuration generation module integrates edge identity identifiers, communication credentials, subscription filter tags, and necessary communication parameters (such as message queue connection ports, heartbeat interval thresholds, etc.) into a secure configuration package. Subsequently, the central control system initiates a configuration distribution request by calling the secure configuration interface pre-exposed by the target edge system during the initialization phase. This secure configuration interface is an internal interface specifically designed by the edge system for receiving initialization configurations. It is only briefly enabled during the registration phase and automatically closed after registration is completed, effectively reducing the risk of the interface being illegally invoked.Before distributing the security configuration package, the central control system uses advanced encryption standards to perform symmetric encryption on the security configuration package. The encryption key is dynamically generated by the key management service of the central control system and bound to the hardware identifier of the target edge system. The encrypted security configuration package is then sent back to the target edge system through the aforementioned encrypted registration request link. After receiving the package, the target edge system uses a locally pre-set decryption algorithm and an initial key to decrypt it, obtain the contents of the security configuration package, and persistently store them in a local secure storage medium (such as an encrypted solid-state drive). This ensures the security of the local storage of configuration information and lays the foundation for subsequent secure communication and precise interaction between the cloud and the edge.

[0037] Through the implementation of the above embodiments, the legitimacy of the target edge system is verified based on hardware identification. After successful verification, a globally unique edge identity identifier, communication credential, and subscription filter tag are dynamically generated. The above information is then encrypted and sent to the edge system, so that each edge node has a unique, reliable, and distinguishable digital identity when accessing the cloud-edge collaboration system. This effectively prevents unauthorized node access and identity impersonation. At the same time, by associating the subscription filter tag with the edge identity, a foundation is provided for the accurate delivery of subsequent tasks, which can improve the security and controllability of cloud-edge communication and solve the problem of insufficient security of static configuration in traditional cloud-edge collaboration.

[0038] In some embodiments, the aforementioned distribution of the task package to the target edge system via the first message channel in the secure communication channel may include: publishing the task package to a message queue as an instruction topic of the first message channel; and setting a subscription filter tag as a message attribute when publishing the task package, so that the target edge system filters and consumes the task package from the instruction topic based on the subscription filter tag.

[0039] In some examples, the first message channel is a dedicated communication link built on a message queue. Its core carrier is the instruction topic, which is a logical partition within the message queue specifically designed to carry task packages from the central control system to the edge system. It possesses core capabilities such as message persistence, asynchronous transmission, and automatic retry in case of failure, effectively isolating communication traffic between task distribution and result feedback, ensuring the orderliness and reliability of task transmission. After the central control system completes the construction of its self-contained task package, it publishes the task package to the instruction topic through the message queue's producer client. The producer client serializes the task package according to the message queue's transmission protocol, converting the JavaScript object representation format task package into a binary data stream. Simultaneously, it enables the message queue's persistence strategy, storing the serialized task package on the message queue's stable storage medium (such as a distributed disk array). This ensures that even in the event of a temporary failure of the central control system or a network interruption, the task package will not be lost and can continue transmission after the system recovers. During the task package deployment process, the central control system retrieves the subscription filter tag assigned to the target edge system during the security registration phase from the security configuration library. This tag is a unique string encoding that corresponds one-to-one with the edge identity. The central control system embeds this subscription filter tag into the message metadata as a message attribute. Message metadata is additional information that accompanies message transmission and does not participate in the business logic of the core task package data; it is only used for message routing and filtering. During initialization, the target edge system has already configured its message queue consumer client using parameters in the security configuration package. This consumer client continuously subscribes to command topics and pre-sets a message filtering mechanism based on the subscription filter tag. This mechanism supports flexible filtering rules such as exact matching and prefix matching, and the edge system can choose the appropriate rule type according to its actual business needs. Once a task package is published to the instruction topic, the message queue will push the message to all consumer clients subscribed to that topic according to a preset routing strategy. When a consumer client of the target edge system receives a message, it will first parse the subscription filter tag in the message metadata and compare it with its own subscription filter tag stored locally. If the tags match, the task package is determined to be the target task, and then the task package is received and deserialized. If the tags do not match, the message is ignored to avoid irrelevant task packages occupying the edge system's computing resources and network bandwidth.

[0040] By implementing the above embodiments, the task package is published to the instruction topic of the message queue, and the subscription filter tag is used as a message attribute during publication. This enables the target edge system to accurately filter and consume the task package from the instruction topic based on the filter tag corresponding to its own identity. This avoids the problem of misdelivery or duplicate consumption of tasks in a multi-edge node environment. While ensuring the reliability of task delivery, it can achieve the accuracy and scalability of task delivery, which is conducive to reducing the complexity of message distribution and improving the overall operating efficiency of the system in large-scale cloud-edge collaboration scenarios.

[0041] In some embodiments, the aforementioned generation of a self-contained task package based on an operation request from a business system may include: parsing the aforementioned operation request to determine the operation type of the target task and the associated target resource; extracting the status data of the target resource from a global database based on the operation type and generating a corresponding data snapshot; and constructing a structured task package based on the task identifier, operation type, data snapshot, and preset execution parameters, wherein the task package may include context information required to execute the target task.

[0042] In some examples, the business system, acting as the upper-layer application initiating cloud-edge collaborative task requests, sends operation requests to the central control system containing core requirements for achieving specific business objectives, such as server configuration updates, container lifecycle management, and edge resource monitoring data collection. Upon receiving the operation request, the central control system activates a dedicated request parsing engine. This engine, based on preset syntax parsing rules and a business field mapping table, decomposes the structured data of the operation request layer by layer, accurately extracting key information to determine the operation type of the target task and the associated target resource. The operation type clarifies the task's execution logic, such as the specific action direction (create, delete, modify, query, etc.); the target resource specifically refers to the specific object on the edge system side that requires operation, which may be a server with a specified number, a container instance in a specific namespace, or a sensor device with a preset identifier.

[0043] After identifying the operation type and target resource, the central control system triggers a data extraction process based on the operation type, accessing its own global database. The global database is the core data storage center storing authoritative status information for all resources in the entire cloud-edge collaborative system. It covers complete data such as resource configuration parameters, operational status indicators, dependencies, and historical operation records, providing consistent and accurate data source support for task execution. The central control system uses Structured Query Language (SQL) statements or a distributed data query interface to accurately extract all status data related to the target resource from the global database, and then generates a corresponding data snapshot based on this data. The data snapshot is a frozen data view of the target resource at the time the task package is generated. It uses a data consistency verification algorithm to ensure the completeness and accuracy of the extracted data, and once generated, it does not change with subsequent updates to the global database. This provides a stable and consistent context benchmark for edge system task execution, preventing task execution deviations caused by real-time data changes.

[0044] After the data snapshot is generated, the central control system enters the task package construction phase. First, a globally unique task identifier is generated using a Distributed Unique Identifier (UUID) algorithm. This identifier is used to uniquely distinguish the task throughout its entire lifecycle, facilitating subsequent status tracking, result matching, and log auditing. Simultaneously, the system retrieves a preset execution parameter template. This template is pre-configured based on different business scenarios and operation types, including key parameters such as task execution timeout thresholds, maximum number of retry attempts, operation priority weights, and resource usage quotas. These parameters provide constraints for the standardized execution of tasks on the edge system. Subsequently, the central control system integrates and assembles the task identifier, operation type, data snapshot, and preset execution parameters into a self-contained task package according to a unified structured format. The task package uses JavaScript object representation for data encapsulation. This format is lightweight, easy to parse, and cross-platform compatible, which can reduce the parsing cost of the edge system. The context information contained in the task package covers all the data required to execute the target task. The edge system does not need to make additional data query requests to the central control system during the execution process, which ensures that the edge system can complete the task execution independently. This effectively eliminates the dependence of task execution on the real-time network and provides support for offline edge operations.

[0045] Through the implementation of the above embodiments, the operation requests of the business system are parsed to clarify the operation type and target resource. Based on the operation type, the status data of the target resource is extracted from the global database to generate a data snapshot. Then, a self-contained task package is constructed by combining the task identifier and execution parameters. This enables the task to have complete and independent execution context information after it is sent to the edge system. This can avoid the edge system repeatedly accessing the central database or external systems during task execution, thereby reducing the runtime coupling between the cloud and the edge, reducing the dependence on real-time network connection, and improving the stability and reliability of the task execution process. It is especially suitable for edge scenarios with complex or unstable network environments.

[0046] In some embodiments, step 103 may include: obtaining a signed result data packet sent by the target edge system from the callback topic message queue, which serves as a second message channel; verifying the signature of the result data packet based on pre-stored communication credentials; after successful verification, parsing the result data packet to obtain the task identifier and target execution status; locating the corresponding global task record based on the task identifier, and updating the global task status to the target execution status.

[0047] In some examples, the core carrier of the second message channel is a callback topic message queue. This queue is built on the same message queue as the instruction topic message queue of the first message channel. The two are logically independent and traffic-isolated. They share the basic capabilities of message queues, such as persistent storage, asynchronous transmission, and automatic retry, while also handling the communication needs of result feedback and task issuance, respectively, avoiding interference between the two types of messages. After the target edge system completes task execution, it integrates the key information during the task execution process into a result data packet. This data packet not only contains a globally unique task identifier and the final target execution status (such as execution success, execution failure due to parameter errors, or execution interruption due to insufficient resources), but also includes auxiliary information such as task execution duration, details of resource status changes, and key operation log fragments. Subsequently, the edge system uses the communication credentials obtained during the security registration phase to sign the result data packet. The signing method used is a hash message authentication code. By using the communication credentials as a key and hashing the original data of the result data packet, a unique and irreversible signature is generated. This signature can effectively prove the legitimacy of the source and the integrity of the result data packet. The central control system deploys a dedicated callback message consumption service. This service continuously listens to the callback topic message queue through a message queue consumer client, capturing in real time the signed result data packets sent by the target edge system. Upon receiving the data packet, the consumption service immediately triggers a signature verification process. During verification, the callback message consumption service retrieves the pre-stored communication credentials corresponding to the target edge system from the central control system's security configuration library. These credentials are identical to the key used by the edge system for signing. Subsequently, using the same hash message authentication code algorithm as the edge system, the service recalculates the signature of the original data in the result data packet and compares the newly generated signature bit by bit with the signature information carried in the data packet. If the comparison result is inconsistent, it indicates that the result data packet may be at risk of being tampered with, forged, or of illegal origin. The callback message consumption service will directly discard the data packet and generate a security alarm log, recording the alarm time, data packet identifier, comparison result, and other information to facilitate subsequent investigation by maintenance personnel. If the comparison result is consistent, the signature verification is deemed successful, confirming the legality and authenticity of the result data packet. After successful verification, the callback message consumption service initiates the data packet parsing process. Relying on preset structured parsing rules, it parses the result data packet, which is encapsulated in JavaScript object representation format, layer by layer, accurately extracting the task identifier and target execution status. Subsequently, based on the extracted task identifier, the system quickly retrieves the global task library of the central control system through an index query mechanism. The global task library is an authoritative data storage center that stores the full lifecycle status information of all tasks, recording the complete status trajectory of tasks from generation and issuance to execution.After retrieving the corresponding global task record, the callback message consumption service updates the current state in the global task record to the parsed target execution state through database transaction operations. Database transaction operations ensure the atomicity of the state update; either the state update is completed completely and persisted, or if an exception occurs during the update process, it rolls back to the state before the update, avoiding incomplete state updates and data inconsistencies. Simultaneously, the system automatically generates a state update log, recording detailed information such as task identifier, update time, state before update, state after update, and the entity executing the operation. This provides a traceable basis for subsequent task auditing and troubleshooting, ultimately achieving precise synchronization between the global task state and the actual execution state of the edge system.

[0048] By implementing the above embodiments, the signed result data packets sent by the edge system are obtained from the callback topic, and the signature is verified based on the pre-stored communication credentials before updating the global task status. This ensures that the source of the task execution result is credible and the content has not been tampered with, thereby effectively preventing forged results or malicious backhaul from interfering with the global task status. At the same time, by accurately locating and updating the global task record based on the task identifier, the central control system can grasp the task execution result in a timely and accurate manner, improving the security and reliability of status updates during cloud-edge task management.

[0049] In some embodiments, the aforementioned initiation of a status query request to the target edge system when a preset synchronization event is detected may include: periodically scanning the global task library to identify timed-out tasks whose status is in execution and whose status update time is earlier than a first preset time threshold; for each identified timed-out task, constructing an authenticated status query request based on the status query credential associated with the target edge system; and sending the status query request to a preset status query interface of the target edge system to obtain the current status of the timed-out task on the edge side.

[0050] In some examples, the state synchronizer deployed in the central control system serves as the core triggering module for preset synchronization events. Its built-in Timer Task Scheduler initiates a global task database scan process at pre-configured time intervals (which can be flexibly adjusted according to business scenarios, such as every 1 hour or every 3 hours). The global task database is an authoritative data center storing the full lifecycle status information of all cloud-edge collaborative tasks, covering key fields such as task identifier, current execution status, status update timestamp, and associated edge identity. To ensure scanning efficiency, the system uses an index acceleration mechanism to create a joint index on the status field and timestamp field, avoiding the performance loss caused by full table scans. During the scan, the state synchronizer verifies task records one by one according to preset filtering conditions, accurately identifying tasks marked as executing and whose status update timestamp is earlier than a first preset time threshold, and classifying them as timed-out tasks. The first preset time threshold is a reasonable threshold (such as 2 hours) set after comprehensive calculation based on factors such as average task execution time and network transmission latency, used to distinguish between tasks that are executing normally and tasks that may have abnormal status feedback, preventing invalid query operations caused by misjudgment.

[0051] For each identified timeout task, the state synchronizer first retrieves the state query credential corresponding to the target edge system associated with the task from the security configuration library. This state query credential is an access token specifically generated by the central control system for the target edge system during the security registration phase. It contains core information such as edge identity, credential validity period, and query permission scope, possessing timeliness and uniqueness, effectively verifying the legitimacy and source credibility of the query request. Subsequently, the state synchronizer initiates the state query request construction process, embedding the state query credential into the authorization field of the request header, and encapsulating key information such as the globally unique task identifier and query timestamp of the timeout task in the request body, ensuring that the target edge system can accurately locate the task to be queried. To ensure the security of the request during network transmission, the constructed state query request is encrypted using a transport layer security protocol. This protocol establishes a secure end-to-end communication link, preventing request data from being intercepted, tampered with, or forged, ensuring the security of the query process.

[0052] Once the status query request is constructed, the central control system sends it to the target edge system's pre-defined status query interface via a pre-set network communication link. This status query interface is a dedicated internal interface designed by the edge system during the initialization phase specifically for receiving central status query requests. It is only open to the central control system and only responds to requests carrying valid status query credentials. Requests without credentials, with expired credentials, or with mismatched credentials will be directly rejected and an error response will be returned, effectively preventing unauthorized query attacks. During the interface call, the system will enable a request retry mechanism. If the request fails due to network fluctuations or temporary high load on the edge system, it will automatically retry within a pre-set maximum number of retries (e.g., 3 times), with the retry interval gradually increasing (e.g., 10 seconds, 30 seconds, 60 seconds) to ensure that the request reaches the target edge system to the greatest extent possible. After receiving the status query request, the target edge system will extract the current actual execution status of the timed-out task on the edge side based on the task identifier in the request, providing accurate data support for the central control system's subsequent status alignment processing.

[0053] Through the implementation of the above embodiments, the global task library is periodically scanned and tasks that have timed out are identified. Then, an authenticated status query request is constructed based on the status query credentials associated with the target edge system and sent to the edge system. This enables the central control system to actively obtain the actual execution status of the task even if the edge system does not return the execution result in a timely manner. This can effectively make up for the problem of possible delay or loss of result return in asynchronous communication mode, and can enhance the controllability and reliability of cloud-edge collaborative task management in abnormal scenarios.

[0054] In some embodiments, the aforementioned alignment processing of the global task status based on the status information returned by the query may include: receiving a response from the target edge system in response to the status query request, wherein the response carries the actual status of the timed-out task on the edge side; comparing the actual status with the current status of the timed-out task recorded in the global task library; if the actual status is inconsistent with the current status, updating the record in the global task library to the actual status and generating a status synchronization log.

[0055] In some examples, the central control system's state synchronization processing module continuously monitors the response feedback from the target edge system. Upon receiving a response to a state query request, it first decrypts the response data using a transport layer security protocol to ensure the data is not tampered with or stolen during transmission. The response is encapsulated in a structured format, containing not only the core real state of the timeout task but also auxiliary information such as the task identifier, response timestamp, and edge system state checksum. The real state details the actual execution status of the timeout task at the edge, including execution progress, final result (e.g., successful execution, failed execution, task interruption), and reasons for failure (if any), providing a complete basis for state alignment. The state synchronization processing module calls a preset response parsing engine to decompose the response data layer by layer according to the field mapping rules agreed upon with the edge system, accurately extracting the real state of the timeout task and its corresponding task identifier, avoiding parsing errors caused by format differences.

[0056] Subsequently, the status synchronization processing module, based on the extracted task identifier, quickly locates the current record of the timed-out task in the global task database through an index query mechanism. The global task database, as the core data center storing the authoritative status of all tasks, records the current status of tasks in a way that reflects the task execution status previously maintained by the central control system. To ensure the accuracy of the comparison results, the system employs a field-by-field comparison mechanism, comprehensively verifying the actual status fed back from the edge side against the current status in the global task database. The comparison scope covers all core fields such as task execution status code, progress percentage, result identifier, and timestamps of key operation nodes, rather than a single-dimensional status judgment, thus avoiding comparison deviations caused by missing partial information.

[0057] If the comparison results show that the actual state is completely consistent with the current state, it indicates that the task state synchronization on both the cloud and edge sides is normal. The state synchronization processing module only generates a state consistency log, recording information such as task identifier, comparison time, and consistency result for subsequent auditing and system monitoring. If the comparison results are inconsistent, that is, if there is a difference between the current state in the global task database and the actual state on the edge side, the state synchronization processing module will immediately trigger the state update process. During the update process, the system enables the database transaction mechanism, which ensures the atomicity, consistency, isolation, and durability of the state update operation. That is, either the state update is completed completely and persisted to the global task database, or if an exception occurs during the update process (such as database connection interruption), it is rolled back to the state before the update, avoiding problems such as incomplete state updates and data conflicts. Meanwhile, the status synchronization processing module automatically generates detailed status synchronization logs. The logs contain key information such as task identifier, synchronization time, status before update, actual status after update, analysis of the reasons for status deviation (such as lost callback messages, temporary failures of edge systems), and the entity that performed the operation. These logs are persistently stored in the system log library, providing a traceable basis for subsequent troubleshooting and system optimization. Ultimately, this precise comparison and standardized update process is achieved.

[0058] By implementing the above embodiments, the actual task status returned by the edge system is compared with the status recorded in the global task library. When the two are inconsistent, the global task status is updated and a status synchronization log is generated, so that the task status on both sides of the cloud and the edge can eventually be kept consistent. This not only corrects the status deviation caused by communication abnormalities or system failures, but also enables the traceability of status changes through log recording. It can improve the ability to ensure the consistency of task status during cloud-edge collaborative task management and reduce the scheduling and operation and maintenance risks caused by inconsistent status.

[0059] Furthermore, as an implementation of the aforementioned method embodiments, this application also provides a cloud-edge collaborative task management device for implementing the aforementioned method embodiments. This device embodiment corresponds to the aforementioned method embodiments. For ease of reading, this cloud-edge collaborative task management device embodiment will not repeat the details of the aforementioned method embodiments one by one, but it should be understood that the device in this application embodiment can correspondingly implement all the contents of the aforementioned method embodiments. For example... Figure 2As shown, the cloud-edge collaborative task management device 20 includes: a channel establishment unit 201, a task distribution unit 202, a status update unit 203, and a status alignment unit 204. The channel establishment unit 201 is used to distribute a security configuration package to the target edge system in response to a security registration request from the target edge system, thereby establishing a secure communication channel with the target edge system. The task distribution unit 202 is used to generate a self-contained task package based on an operation request from the business system, and distribute the task package to the target edge system through a first message channel in the secure communication channel. The task package encapsulates a task identifier, an action type, and a data snapshot corresponding to the task target. The status update unit 203 is used to update the global task status based on the task execution result asynchronously sent by the target edge system through a second message channel in the secure communication channel. The status alignment unit 204 is used to initiate a status query request to the target edge system when a preset synchronization event is detected, and perform alignment processing on the global task status based on the status information returned by the query.

[0060] This application also provides a computer-readable storage medium storing computer-executable instructions or computer programs, which, when executed by a processor, will cause the processor to perform any step of the cloud-edge collaborative task management method provided in this application.

[0061] In some embodiments, the computer-readable storage medium may be a random access memory (RAM), a read-only memory (ROM), flash memory, a magnetic surface memory, an optical disc, or a compact disc read-only memory (CD-ROM); or it may be a variety of devices that include one or any combination of the above-mentioned memories.

[0062] In some embodiments, computer-executable instructions may take the form of programs, software, software modules, scripts, or code, written in any form of programming language (including compiled or interpreted languages, or declarative or procedural languages), and may be deployed in any form, including as stand-alone programs or as modules, components, subroutines, or other units suitable for use in a computing environment.

[0063] In some embodiments, computer-executable instructions may, but do not necessarily, correspond to files in a file system, and may be stored as part of a file that holds other programs or data, for example, in one or more scripts in a HyperText Markup Language (HTML) document, in a single file dedicated to the program in question, or in multiple co-located files (e.g., files that store one or more modules, subroutines, or code sections).

[0064] In some embodiments, computer-executable instructions may be deployed to execute on an electronic device, or on multiple electronic devices located at one location, or on multiple electronic devices distributed across multiple locations and interconnected via a communication network.

[0065] like Figure 3 As shown, this application also provides an electronic device 30, including a memory 310, a processor 320, and a computer program 311 stored in the memory 310 and executable on the processor. When the processor 320 executes the computer program 311, it implements any step of the cloud-edge collaborative task management method described above.

[0066] This application also provides a computer program product comprising a computer program or computer-executable instructions stored in a computer-readable storage medium. A processor of an electronic device reads the computer program or computer-executable instructions from the computer-readable storage medium and executes the computer program or computer-executable instructions, causing the electronic device to perform any step of the cloud-edge collaborative task management method described above.

[0067] The above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications 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 application.

Claims

1. A cloud-edge collaborative task management method, characterized in that, Applications in central control systems include: In response to a security registration request from a target edge system, a security configuration package is sent to the target edge system to establish a secure communication channel with the target edge system. Based on the operation request from the business system, a self-contained task package is generated, and the task package is sent to the target edge system through the first message channel in the secure communication channel. The task package encapsulates a task identifier, an action type, and a data snapshot corresponding to the task target. The global task status is updated based on the task execution results asynchronously sent by the target edge system through the second message channel in the secure communication channel. When a preset synchronization event is detected, a status query request is initiated to the target edge system, and the global task status is aligned based on the status information returned by the query.

2. The cloud-edge collaborative task management method according to claim 1, characterized in that, In response to the security registration request from the target edge system, a security configuration package is sent to the target edge system, including: In response to a registration request sent by the target edge system, obtain the hardware identifier of the target edge system carried in the registration request; After the hardware identifier passes the legality verification, a globally unique edge identity identifier, communication credential, and subscription filter tag are generated for the target edge system, wherein the subscription filter tag is associated with the edge identity identifier; By calling the security configuration interface pre-set in the target edge system, the security configuration package, including the edge identity identifier, the communication credentials, and the subscription filter tag, is encrypted and sent to the target edge system.

3. The cloud-edge collaborative task management method according to claim 2, characterized in that, The step of sending the task package to the target edge system through the first message channel in the secure communication channel includes: The task package is published to the message queue as the instruction subject of the first message channel; When publishing the task package, the subscription filter tag is set as a message attribute so that the target edge system filters and consumes the task package from the instruction topic based on the subscription filter tag.

4. The cloud-edge collaborative task management method according to claim 1, characterized in that, The process of generating a self-contained task package based on operation requests from the business system includes: Parse the operation request to determine the operation type of the target task and the associated target resources; Based on the operation type, extract the status data of the target resource from the global database and generate a corresponding data snapshot; Based on the task identifier, the operation type, the data snapshot, and the preset execution parameters, a structured task package is constructed, wherein the task package includes context information required to execute the target task.

5. The cloud-edge collaborative task management method according to claim 1, characterized in that, The update of the global task status based on the task execution result asynchronously sent by the target edge system through the second message channel in the secure communication channel includes: Retrieve the signed result data packet sent by the target edge system from the callback topic message queue, which serves as the second message channel; The signature of the resulting data packet is verified based on the pre-stored communication credentials; After successful verification, the result data packet is parsed to obtain the task identifier and target execution status; Locate the corresponding global task record based on the task identifier, and update the global task status to the target execution status.

6. The cloud-edge collaborative task management method according to claim 1, characterized in that, When a preset synchronization event is detected, initiating a status query request to the target edge system includes: Periodically scan the global task library to identify timed-out tasks whose status is "in execution" and whose status update time is earlier than the first preset time threshold; For each identified timeout task, an authenticated status query request is constructed based on the status query credentials associated with the target edge system; Send the status query request to the pre-set status query interface of the target edge system to obtain the current status of the timeout task on the edge side.

7. The cloud-edge collaborative task management method according to claim 6, characterized in that, The step of aligning the global task status based on the status information returned by the query includes: Receive the response returned by the target edge system in response to the status query request, wherein the response carries the actual status of the timeout task at the edge; The actual state is compared with the current state of the timed-out task recorded in the global task library; If the actual state is inconsistent with the current state, the records in the global task library will be updated to the actual state, and a state synchronization log will be generated.

8. A cloud-edge collaborative task management device, characterized in that, Applications in central control systems include: The channel establishment unit is used to send a security configuration package to the target edge system in response to the security registration request of the target edge system, so as to establish a secure communication channel with the target edge system; The task distribution unit is used to generate a self-contained task package based on the operation request from the business system, and distribute the task package to the target edge system through the first message channel in the secure communication channel. The task package encapsulates a task identifier, an action type, and a data snapshot corresponding to the task target. The status update unit is used to update the global task status based on the task execution result asynchronously sent by the target edge system through the second message channel in the secure communication channel; The state alignment unit is used to initiate a state query request to the target edge system when a preset synchronization event is detected, and to perform alignment processing on the global task state based on the state information returned by the query.

9. An electronic device, comprising: The memory and processor are characterized in that the processor, when executing a computer program stored in the memory, implements the steps of the cloud-edge collaborative task management method as described in any one of claims 1 to 7.

10. A computer-readable storage medium having stored thereon computer-executable instructions or a computer program, characterized in that, When the computer-executable instructions or the computer program are executed by a processor, the steps of the cloud-edge collaborative task management method as described in any one of claims 1 to 7 are implemented.

Images