A cloud edge-end cooperative cloud Internet of Things intelligent linkage method

Abstract

The application relates to the technical field of Internet of Things, in particular to a cloud-edge-end cooperative cloud Internet of Things intelligent linkage method, which comprises the following steps: analyzing linkage demand description information, decoupling an event listening function and a response execution function logic, generating an event listening subtask and at least one response execution subtask; determining a first deployment device of the event listening subtask and a second deployment device of each response execution subtask according to the load state of each device, network connectivity and the principle of data source proximity. The linkage demand is split into an independent event listening subtask and multiple response execution subtasks, and is dynamically deployed to different edge nodes according to the load state, network connectivity and the principle of data source proximity, so that the listening task can be stably stationed near the trigger source to ensure the real-time performance of event capturing, and the execution task can be flexibly dispersed to multiple idle devices with corresponding capabilities and executed in parallel or sequentially.

Description

Technical Field

[0001] This invention relates to the field of Internet of Things (IoT) technology, specifically to a cloud-edge-device collaborative cloud IoT intelligent linkage method. Background Technology

[0002] With the rapid development of IoT and cloud-edge-device collaboration technologies, the linkage control between smart devices has been widely applied in scenarios such as smart manufacturing, smart parks, and unmanned warehouses. The combination of edge computing and cloud scheduling enables both device responsiveness and global decision-making capabilities to be taken into account. The linkage system has gradually evolved from a single local trigger-execution mode to a multi-level collaborative architecture that spans devices and levels. However, in actual deployment, the linkage logic is often pre-fixed on the central server or specific gateway devices. The listening and execution functions are highly coupled, which means that when adding linkage rules or changing execution devices, the global process needs to be reconfigured. At the same time, the multi-level action chain relies on fixed device addresses and sequential transmission. Once an intermediate node fails or the network is interrupted, the entire linkage process is interrupted, and there is a lack of dynamic recovery methods.

[0003] In related technologies, linkage methods typically employ centralized orchestration or point-to-point hard-coded scheduling to complete task chaining. The capture of trigger signals and the execution of actions are carried out by the same device or fixed link. This approach lacks real-time awareness of the resource status of edge nodes and cannot dynamically allocate tasks based on the load and network quality of each device, resulting in some devices being overloaded while others are idle. Furthermore, the transmission order and target address of the action chain are fixedly written into the configuration. When any executing device goes offline or the network is abnormal, there is no backup path planning mechanism, and manual intervention or restarting of the process is the only option. This leads to an increased failure rate and response latency in linkage tasks, making it difficult to meet the requirements of high availability and high throughput automated collaboration in dynamic and complex environments. Summary of the Invention

[0004] To achieve the above objectives, the present invention provides the following technical solution: a cloud-edge-device collaborative cloud IoT intelligent linkage method, comprising: Obtain the description of the linkage requirements and the registration information of multiple devices; The linkage requirement description information is parsed, the event listening function and the response execution function are logically decoupled, and an event listening subtask and at least one response execution subtask are generated. Based on the load status of each device, network connectivity and the principle of proximity of the data source, the first deployment device of the event listening subtask and the second deployment device of each response execution subtask are determined. A unique linkage token is assigned, which includes the trigger source identifier, the trigger source device address, the linkage transmission chain information, the address of the current response execution device, the address of the next response execution device, and the linkage execution parameters; the linkage transmission chain information defines the trigger initiating device, at least one response execution device, and the transmission order; The linkage token is sent to the first and second deployment devices, the event listening component and the response execution component are deployed, and a cross-device binding relationship is established based on the address and transmission chain information in the token; When the event listening component detects a target event that meets the triggering conditions, it generates a trigger signal and sends the trigger signal and linkage token to the response execution component corresponding to the current response execution device address. After the response execution component executes the response based on the token parameters, when it needs to be passed to the next device, it updates the trigger source identifier in the token to the current device identifier, updates the current response execution device address to the next device address, and sends the updated token and the next-level trigger instruction to the next device.

[0005] Preferably, the system obtains a description of the linkage requirements and registration information for multiple devices, including: Obtain linkage requirement description information from the user configuration interface or preset configuration file, parse the linkage requirement description information, and obtain the event source identifier, event triggering condition and response action type; You can query the registration information of all registered devices through the device registration center. The registration information includes device type, device identifier, and device access status. Based on the device access status, the devices are filtered for availability, and devices that are offline or in a faulty state are removed to form a list of available devices. Associate the list of available devices with the event source identifier and response action type, and output the results.

[0006] Preferably, the linkage requirement description information is parsed to decouple the event listening function from the response execution function, generating an event listening subtask and at least one response execution subtask, including: Extract the event source identifier and event triggering condition from the linkage requirement description information, and encapsulate the event source identifier and event triggering condition into an event listening subtask. The event listening subtask includes the listening object and the triggering condition expression. Extract the response action type from the linkage requirement description information and split the response action type into one or more independent response action items; For each response action item, a response execution subtask is generated. The response execution subtask includes the response action type and action parameters to be executed. Mark the response execution subtasks with sequence constraints or concurrency constraints. Sequence constraints indicate that response actions must be executed in a preset order, while concurrency constraints indicate that response actions can be executed simultaneously.

[0007] Preferably, based on the load status of each device, network connectivity, and the principle of proximity to the data source, the first deployment device for the event listening subtask and the second deployment device for each response execution subtask are determined, including: Collect real-time load status parameters and network connectivity metrics for each device in the available device list. Load status parameters include CPU utilization and memory utilization, and network connectivity metrics include round-trip latency and packet loss rate. Select the device from the list of available devices that is closest to the network of the event source device as the candidate first deployment device; Among the candidate first deployment devices, the device whose load status parameter is lower than the preset load threshold and whose network connectivity index meets the preset network quality conditions is selected as the first deployment device. For each response, execute a subtask and select a set of candidate devices with corresponding execution capabilities from the list of available devices based on the response action type; From the candidate device set, the optimal device is selected as the second deployment device for the corresponding response execution subtask based on load status parameters and network connectivity indicators.

[0008] Preferably, a unique linkage token is assigned, including: Generate a globally unique linkage token identifier; Based on the event source identifier and the event source device registration information, determine the trigger source identifier and the trigger source device address; Based on the sequential or concurrent constraints between the response execution subtasks, the linkage transmission chain information is determined. The linkage transmission chain information includes the trigger initiating device, each response execution device, and the transmission order. Based on the linkage transmission chain information, determine the address of the current response execution device and the address of the next response execution device. The address of the current response execution device is the address of the first response execution device in the transmission sequence, and the address of the next response execution device is the address of the second response execution device in the transmission sequence. Encapsulate the action parameters corresponding to each response execution subtask into linked execution parameters; The above information is assembled according to a preset data format and digitally signed to generate a unique linkage token.

[0009] Preferably, the linkage token is issued to the first and second deployment devices, an event listening component and a response execution component are deployed, and a cross-device binding relationship is established based on the address and transmission chain information in the token, including: The unique linkage token is sent to the first deployment device and each of the second deployment devices via a secure communication channel. Install and start the event listener component on the first deployment device. The event listener component loads the event source identifier and event triggering conditions from the token. Install and start the response execution component on each of the second deployment devices. The response execution component loads the linkage execution parameters in the token. Each device establishes a communication connection and address mapping to its neighboring device based on the trigger source device address, the current response execution device address, the next response execution device address, and the linkage transmission chain information in the token. After each device completes the communication connection and address mapping, it sends a binding completion confirmation to the management node. The management node summarizes the confirmation information and establishes a complete cross-device binding relationship.

[0010] Preferably, when the event listening component detects a target event that meets the triggering conditions, it generates a trigger signal and sends the trigger signal and a linkage token to the response execution component corresponding to the current response execution device address, including: The event listening component collects the output data stream of the event source device in real time and makes a matching judgment based on the event triggering conditions; When a target event that meets the event triggering conditions is matched, extract the target event data; A trigger signal is generated based on the target event data. The trigger signal includes the event type and event data. Obtain the unique linkage token, and encapsulate the trigger signal and the unique linkage token into a linkage trigger message; Through a pre-established communication connection, the linkage trigger message is sent to the response execution component corresponding to the current response execution device address in the token.

[0011] Preferably, after the response execution component executes the response according to the token parameters, when it needs to be passed to the next device, it updates the trigger source identifier in the token to the current device identifier, updates the current response execution device address to the next device address, and sends the updated token and the next-level trigger instruction to the next device, including: The response execution component receives the linkage trigger message and parses out the unique linkage token and trigger signal; Execute the corresponding response action based on the linkage execution parameters in the unique linkage token; After the response action is completed, check if the address of the next response execution device in the unique linkage token is empty; When the address of the next response execution device is not empty, the trigger source identifier in the unique linkage token is updated to the current device identifier, and the address of the current response execution device is updated to the address of the next response execution device. Based on the trigger signal and the already executed response action, generate the next level trigger command; The updated unique linkage token and the next-level trigger instruction are encapsulated into a next-level linkage trigger message and sent to the response execution component corresponding to the updated current response execution device address.

[0012] Preferably, the method further includes: If any response execution device malfunctions or network interruptions are detected, the device currently holding the token reports the anomaly to the cloud. The cloud then determines the next response execution device based on the device's availability, updates the transmission chain information and address in the token, and sends it to the currently holding device, enabling the linkage signal to continue execution along the updated transmission chain.

[0013] Preferably, the device currently holding the token reports an anomaly to the cloud. The cloud then determines the next responding device based on the device's availability, updates the transmission chain information and address in the token, and sends it to the currently holding device, enabling the linkage signal to continue execution along the updated transmission chain. This includes: If the device currently holding the token does not receive an acknowledgment response within the preset response timeout period after sending a linkage trigger message to the address of the next response execution device, it will determine that the next response execution device is faulty or the network is interrupted. The device currently holding the token will retry sending the linkage trigger message. If the number of retries reaches the preset maximum number of retries and no acknowledgment is received, the device executing the next response will be confirmed as unreachable. The device currently holding the token generates an anomaly reporting message, which includes the current device identifier, the address of the unreachable device, and the unique linkage token currently held. The device currently holding the token will send an anomaly report message to the cloud; After receiving the anomaly report message in the cloud, the system obtains the current availability status information of all devices from the device registration center and removes faulty devices and devices with network interruptions. From the available devices that have been removed, the cloud determines the next response execution devices based on their matching degree with the execution capabilities of the subsequent response execution subtasks in the original delivery chain; Based on the newly determined subsequent response execution device, the cloud updates the linkage transmission chain information, the current response execution device address, and the next response execution device address in the unique linkage token, and generates an updated unique linkage token. The cloud will send the updated unique linkage token to the device currently holding the token; The device currently holding the token receives the updated unique linkage token and sends the next-level linkage trigger message to the corresponding response execution component based on the updated current response execution device address, so that the linkage signal continues to be executed along the updated transmission chain.

[0014] Compared with the prior art, the beneficial effects of the present invention are: 1. This invention breaks down linkage requirements into independent event listening subtasks and multiple response execution subtasks, and dynamically deploys them to different edge nodes based on load status, network connectivity, and proximity to the data source. This allows the listening task to remain stably stationed near the trigger source to ensure real-time event capture, while the execution task can be flexibly distributed to multiple idle devices with corresponding capabilities for parallel or sequential execution. When the number of linkage rules increases or the execution device changes, only the deployment strategy of the execution subtask needs to be adjusted, without modifying the listening-side logic, thereby effectively avoiding overload of a single device and improving system throughput and resource utilization. 2. This invention uses a linkage token that flows along the task transmission chain, carrying a complete execution context and a clear next-hop address. This allows each response execution component to focus only on its own node's actions and forwarding logic, without needing to maintain a global state. Simultaneously, when a downstream device failure or network interruption is detected, the device holding the token proactively reports to the cloud. The cloud then re-plans the remaining transmission chain based on the global device availability and updates the token issuance, enabling the linkage process to bypass failed nodes and continue execution. This mechanism effectively avoids overall linkage interruption caused by single-point failures, ensuring the orderly completion and traceability of cross-device long-link actions. Attached Figure Description

[0015] Figure 1 This is a schematic flowchart of the overall method in one embodiment of the present invention; Figure 2 This is a schematic diagram of the steps for generating subtasks in one embodiment of the present invention; Figure 3 This is a schematic diagram of the steps for determining the deployment device in one embodiment of the present invention. Detailed Implementation

[0016] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0017] Example 1, please refer to Figures 1-3 This invention provides a technical solution: a cloud-edge-device collaborative cloud IoT intelligent linkage method, comprising: Step S1: Obtain the linkage requirement description information and the registration information of multiple devices.

[0018] Among them, the linkage requirement description information is used to characterize the triggering conditions and set of execution actions for collaborative actions between devices in the business scenario. The registration information of multiple devices includes at least the communication address, capability attributes and current status parameters of each device.

[0019] For example, the linkage requirement description information is carried by a structured task message issued by the upper-layer business system. After parsing the message, the trigger source device identifier, trigger event type, target execution device list, and action timing constraints are extracted. The registration information of multiple devices is stored in the device management database. After receiving the linkage task, the network protocol address, supported control command set, current online status, and load margin of each device in the database are queried in batches according to the device identifier list involved in the task. For example, in a smart warehousing scenario, when the barcode scanner recognizes the barcode of goods, it is necessary to simultaneously trigger three actions: conveyor belt speed adjustment, robotic arm grasping, and lighting supplementary shooting. First, the barcode recognition event is obtained as the linkage requirement. Then, the IP address, speed range, joint angle limit, and current operating level of the corresponding conveyor belt controller, robotic arm driver, and lighting controller are read from the registration database as input for subsequent scheduling decisions. After successfully obtaining the above information, the linkage requirement is associated with the device registration data and cached, and the linkage session identifier is marked so that dynamic adjustments can be made based on real-time feedback during the execution phase.

[0020] For example, the linkage requirement description information is obtained from the user configuration interface or a preset configuration file. The linkage requirement description information is parsed to obtain the event source identifier, event triggering condition, and response action type. The registration information of all registered devices is queried through the device registration center. The registration information includes device type, device identifier, and device access status. The devices are filtered for availability based on their access status, and devices in offline or faulty states are removed to form a list of available devices. The list of available devices is associated with the event source identifier and response action type, and the obtained results are output.

[0021] In this embodiment, the system reads the user-pre-configured linkage rule file from the human-computer interaction interface or loads the preset linkage task template from the system configuration storage, extracting the device number, event type threshold, and expected response action category corresponding to the trigger event. Simultaneously, it calls the query interface provided by the device registration center to obtain the basic profiles of all certified devices, including device category number, unique network identifier, and current heartbeat reporting status code. Then, based on the status code, availability is determined, retaining devices that are normally online and excluding devices that report offline or have self-test anomalies, generating a candidate device list. Finally, a mapping relationship is established between this list and the trigger source device and action category to form a device resource pool required for linkage execution, and this resource pool is output for subsequent use.

[0022] Step S2: Parse the linkage requirement description information, decouple the event listening function from the response execution function, and generate an event listening subtask and at least one response execution subtask; determine the first deployment device for the event listening subtask and the second deployment device for each response execution subtask based on the load status of each device, network connectivity, and the principle of proximity of the data source.

[0023] Among them, the event listening subtask is responsible for continuously monitoring the trigger source signal, and the response execution subtask is responsible for driving the target device to complete specific actions after the trigger. The two are separated at the scheduling level so that running nodes can be allocated independently.

[0024] For example, the linkage rules are split into two logical units: the listening unit contains the trigger source device address, event type, and filtering conditions, and the execution unit contains the target device instruction sequence, timeout retry policy, and rollback operation; the real-time load rate, round-trip latency, and physical location of the data collection nodes under the jurisdiction of all online devices are queried; for the listening subtask, the edge gateway with the lowest historical packet loss rate and located in the same network segment as the trigger source device is selected as the first deployment device to ensure the real-time response of the event; for each response execution subtask, the CPU utilization, memory availability, and network hop count to the target execution device of each candidate device are evaluated, and the controller with a load of less than 70% and located in the same rack or switch group as the target execution device is selected as the second deployment device according to the principle of proximity of data source; if a single device cannot meet the resource requirements of multiple subtasks at the same time, the different execution subtasks are distributed to multiple idle devices, and a deployment decision table is finally generated for subsequent task distribution.

[0025] For example, S201, extract the event source identifier and event triggering condition from the linkage requirement description information, and encapsulate the event source identifier and event triggering condition into an event listening subtask. The event listening subtask includes a listening object and a triggering condition expression. S202, extract the response action type from the linkage requirement description information, and split the response action type into one or more independent response action items. S203, generate a response execution subtask for each response action item. The response execution subtask includes the response action type to be executed and action parameters. S204, mark the response execution subtasks with sequence constraints or concurrency constraints. Sequence constraints indicate that response action items must be executed in a preset order, and concurrency constraints indicate that response action items can be executed simultaneously.

[0026] In this embodiment, the event source device number and trigger condition threshold are extracted from the linkage requirements and encapsulated as a monitoring subtask, specifying the monitoring target address and condition criteria. Simultaneously, the response action type is broken down into multiple independent action items, such as switch commands, speed settings, and status feedback, and a corresponding execution subtask is generated for each action item, specifying its action type and parameters. Subsequently, based on the logical relationship between action items, sequential or concurrent execution constraints are marked, such as powering on before speed adjustment, or adjusting multiple parameters simultaneously. After subtask generation, the current load rate, network round-trip latency, and physical proximity to the trigger source or target execution device of each candidate device are queried. The monitoring subtask is assigned to the edge node with the lowest load in the same network segment as the trigger source, and each execution subtask is assigned to the controller closest to the corresponding execution device with the fewest network hops, ensuring that the load of all deployed devices is below 80%. Finally, a subtask deployment mapping table is generated for subsequent execution.

[0027] Further, for example, real-time load status parameters and network connectivity metrics are collected for each device in the available device list. The load status parameters include CPU utilization and memory utilization, and the network connectivity metrics include round-trip latency and packet loss rate. The device closest to the event source device in the available device list is selected as a candidate first deployment device. Among the candidate first deployment devices, the device with load status parameters below a preset load threshold and network connectivity metrics that meet preset network quality conditions is selected as the first deployment device. For each response execution subtask, a set of candidate devices with corresponding execution capabilities is selected from the available device list according to the response action type. Among the candidate device set, the optimal device is selected as the second deployment device for the corresponding response execution subtask based on the load status parameters and network connectivity metrics.

[0028] In this embodiment, the CPU utilization, memory utilization, round-trip latency, and packet loss rate of each device in the available device list are collected. Several nodes in the same subnet as the event source device and with the fewest routing hops are selected from the available devices as candidate first deployment devices. Then, devices with loads below 70%, round-trip latency less than 10 milliseconds, and packet loss rates below 1% are selected as the deployment locations for the monitoring subtasks. For each response execution subtask, a set of candidate devices with corresponding control capabilities is selected from the available devices based on its action type. Then, load and network indicators are comprehensively compared within this set, and the device with the lowest load and the best network quality is selected as the second deployment device for the execution subtask. Finally, independent running nodes are determined for all subtasks, and the deployment results are recorded.

[0029] Step S3: Assign a unique linkage token. The linkage token includes the trigger source identifier, the trigger source device address, the linkage transmission chain information, the current response execution device address, the next response execution device address, and the linkage execution parameters. The linkage transmission chain information defines the trigger initiating device, at least one response execution device, and the transmission order.

[0030] Among them, the linkage token serves as the status carrier of the entire linkage process. It flows between devices along with the task and is used to identify ownership, record the current execution node, and guide the subsequent transmission path.

[0031] For example, after the subtask deployment is completed, a globally unique sequence number is generated as a token identifier for this linkage based on the deployment mapping table; the number and network address of the trigger source device are filled into the token; the first deployment device where the listening subtask is located is designated as the trigger initiating device, and the second deployment devices are arranged in the order of execution of the response execution subtasks or in parallel groups to form a transmission chain; at the same time, the token records the address of the response execution device that needs to be executed now and the address of the next device to be forwarded after completion, and includes action parameters such as speed value and on / off state; the token is initially set to pending trigger and persisted to the memory database so that the current node and the next node are updated in real time during the link transmission until all response actions are completed.

[0032] For example, S301, generate a globally unique linkage token identifier; S302, determine the trigger source identifier and trigger source device address based on the event source identifier and event source device registration information; S303, determine the linkage transmission chain information based on the sequential constraints or concurrency constraints between response execution subtasks, the linkage transmission chain information including the trigger initiating device, each response execution device, and the transmission order; S304, determine the current response execution device address and the next response execution device address based on the linkage transmission chain information, the current response execution device address being the address of the first response execution device in the transmission order, and the next response execution device address being the address of the second response execution device in the transmission order; S305, encapsulate the action parameters corresponding to each response execution subtask into linkage execution parameters; assemble the above information according to a preset data format, perform digital signature, and generate a unique linkage token.

[0033] In this embodiment, a globally unique sequence number is generated as the token identifier for this linkage; the trigger source identifier and address are written according to the event source identifier and registration information; the transmission order of the trigger initiating device and each response execution device is arranged according to the order constraints or concurrency constraints of the response execution subtasks to form a linkage transmission chain; the first response execution device in the transmission chain is determined as the current execution address, and the second is determined as the next execution address; the action parameters of each subtask are summarized into an execution parameter field; finally, all fields are assembled according to the predetermined message structure and a digital signature is attached to form an immutable linkage token, which is stored in the memory database for updating during link flow.

[0034] Step S4: Send the linkage token to the first deployment device and the second deployment device, deploy the event listening component and the response execution component, and establish a cross-device binding relationship based on the address and transmission chain information in the token.

[0035] For example, the linkage token is delivered to the first deployment device where the listening subtask is located and the second deployment device where all the response execution subtasks are located. After each device receives the token, the first deployment device starts the event listening component and begins to monitor the signal according to the triggering conditions in the token. Each second deployment device starts the response execution component to prepare to receive action instructions. At the same time, the first deployment device is notified to point the current execution address in the token to the first response execution device, and each second deployment device is informed of its previous hop address and next hop address. Each device maintains an adjacency routing table on its local machine accordingly, forming a unidirectional transmission link from the triggering source through each execution device in sequence. The devices confirm the binding effect through a heartbeat handshake, and after completion, they send back a deployment success status.

[0036] For example, a unique linkage token is sent to the first deployment device and each of the second deployment devices via a secure communication channel; an event listening component is installed and started on the first deployment device, and the event listening component loads the event source identifier and event triggering conditions from the token; a response execution component is installed and started on each of the second deployment devices, and the response execution component loads the linkage execution parameters from the token; each device establishes a communication connection and address mapping to the adjacent device locally based on the trigger source device address, the current response execution device address, the next response execution device address, and the linkage transmission chain information from the token; after completing the communication connection and address mapping, each device sends a binding completion confirmation to the management node, and the management node summarizes the confirmation information to establish a complete cross-device binding relationship.

[0037] In this embodiment, the management node delivers a unique linkage token to the first deployment device and all second deployment devices via an encrypted transmission channel. Upon receiving the token, the first deployment device installs an event listening component, which loads the event source device address and trigger condition expression from the token and begins signal monitoring. Each second deployment device installs a response execution component, extracts action parameters from the token, and prepares for execution. Subsequently, each device establishes a communication connection to the previous and next hop devices locally based on the trigger source address, current execution device address, next execution device address, and transmission chain information in the token, and maintains an address mapping table. After all devices have established connections, they each send a binding confirmation message back to the management node. The management node summarizes all confirmation information, confirms that the entire transmission chain is ready, and completes the establishment of the cross-device binding relationship.

[0038] Step S5: When the event listening component detects a target event that meets the triggering conditions, it generates a trigger signal and sends the trigger signal and linkage token to the response execution component corresponding to the current response execution device address.

[0039] The monitoring component is responsible for sensing the status of the trigger source in real time. Once the conditions are met, it sends a start signal and passes the token to the first executing device to activate the subsequent response chain.

[0040] For example, the event monitoring component continuously receives status data reported by the triggering source device on the deployment node and performs conditional comparison on the data fields. When it detects that the value crosses a preset threshold or the event type matches successfully, it determines that the triggering condition is met and then constructs a trigger signal, which includes the time of event occurrence and the triggering type. The monitoring component reads the current response execution device address from the locally stored linkage token, packages the trigger signal and the token together, and sends it to the response execution component pointed to by the address through a reliable transmission protocol. After sending, the monitoring component updates the token status to triggered and reports the trigger log to the management node.

[0041] For example, the event listening component collects the output data stream of the event source device in real time and performs matching judgment based on the event triggering conditions; when a target event that meets the event triggering conditions is matched, the target event data is extracted; a trigger signal is generated based on the target event data, the trigger signal including the event type and event data; a unique linkage token is obtained, and the trigger signal and the unique linkage token are encapsulated into a linkage trigger message; the linkage trigger message is sent to the response execution component corresponding to the current response execution device address in the token through a pre-established communication connection.

[0042] In this embodiment, the event monitoring component receives the data stream output by the event source device in real time on the deployment node, parses the data fields frame by frame and compares them with preset trigger conditions; once a target event is matched, the key information of the event is immediately extracted and a trigger signal containing the event type and event data is generated; subsequently, the monitoring component obtains the unique token corresponding to the linkage from the local storage, encapsulates the trigger signal and the token into a linkage trigger message; finally, through the established communication connection pointing to the current response execution device, the message is sent to the response execution component corresponding to the current response execution device address recorded in the token, and the local status log is updated for traceability.

[0043] Step S6: After the response execution component executes the response according to the token parameters, when it needs to be passed to the next device, it updates the trigger source identifier in the token to the current device identifier, updates the current response execution device address to the next device address, and sends the updated token and the next-level trigger instruction to the next device.

[0044] Among them, after the response execution component completes the action of its own node, if there are subsequent nodes in the linkage transmission chain, it is responsible for moving the token state forward and forwarding it along the link to ensure that multi-level actions are executed in sequence.

[0045] For example, after receiving the linkage trigger message, the response execution component parses the action parameters in the token and drives the device to execute the corresponding control command. After execution, the component reads the address of the next response execution device in the token. If the address is not empty, the trigger source identifier in the token is modified to the device number, the current response execution device address is updated to the address of the next device, and the previous hop information is cleared. Subsequently, the component obtains the pre-established communication connection based on the address of the next device, packages the updated token together with the next-level trigger command, and sends it to the next device. If the next address is empty, it is determined to be the end of the link, and the component sends a linkage completion report back to the management node.

[0046] For example, the response execution component receives the linkage trigger message, parses out the unique linkage token and trigger signal; executes the corresponding response action according to the linkage execution parameters in the unique linkage token; after the response action is executed, it checks whether the next response execution device address in the unique linkage token is empty; if the next response execution device address is not empty, it updates the trigger source identifier in the unique linkage token to the current device identifier, and updates the current response execution device address to the next response execution device address; based on the trigger signal and the executed response action, it generates the next-level trigger instruction; it encapsulates the updated unique linkage token and the next-level trigger instruction into a next-level linkage trigger message, and sends it to the response execution component corresponding to the updated current response execution device address.

[0047] In this embodiment, after receiving the linkage trigger message, the response execution component parses out the unique linkage token and trigger signal, and drives the device to complete the corresponding action according to the linkage execution parameters in the token. After the action is completed, the component reads the next response execution device address field in the token. If the address is not empty, the trigger source identifier in the token is modified to the device number, the current response execution device address is updated to the next address, and the next-level trigger instruction is generated according to the original trigger signal and the execution result of the current node. Subsequently, the updated token and the next-level instruction are encapsulated into a new linkage trigger message and sent to the component pointed to by the updated current response execution device address through the established communication connection. If the next address is empty, it is determined to be the end of the link, and the component sends a linkage completion report back to the management node and releases the token resources.

[0048] Furthermore, for example, if any response execution device malfunctions or network interruptions are detected, the device currently holding the token reports the anomaly to the cloud. The cloud then determines the next response execution device based on the device's availability, updates the transmission chain information and address in the token, and sends it to the currently holding device, so that the linkage signal continues to execute along the updated transmission chain.

[0049] Furthermore, exemplarily, if the device currently holding the token does not receive an acknowledgment within a preset response timeout period after sending a linkage trigger message to the address of the next response execution device, it determines that the next response execution device is faulty or the network is interrupted. The device currently holding the token retryes sending the linkage trigger message. If it still does not receive an acknowledgment after the number of retries reaches a preset maximum number of retries, it confirms that the next response execution device is unreachable. The device currently holding the token generates an exception reporting message, which includes the current device identifier, the address of the unreachable device, and the unique linkage token it currently holds. The device currently holding the token sends the exception reporting message to the cloud. After receiving the exception reporting message, the cloud obtains the availability status of all devices from the device registration center. Information is collected to remove faulty and network-interrupted devices. From the remaining available devices, the cloud determines the next response execution device based on its matching capability with the execution capabilities of subsequent response execution subtasks in the original transmission chain. Based on the newly determined next response execution device, the cloud updates the linkage transmission chain information, the current response execution device address, and the next response execution device address in the unique linkage token, generating an updated unique linkage token. The cloud distributes the updated unique linkage token to the device currently holding the token. Upon receiving the updated unique linkage token, the device sends the next-level linkage trigger message to the corresponding response execution component based on the updated current response execution device address, enabling the linkage signal to continue execution along the updated transmission chain.

[0050] In this embodiment, when the response execution component currently holding the token attempts to send a linkage trigger message to the next device, if multiple handshake timeouts occur or a connection rejection response is received, it determines that the target device is faulty or the network is interrupted. It then constructs an anomaly report, including the device identifier, the faulty target address, and the error type, and reports it to the cloud through an independent management channel. Upon receiving the anomaly, the cloud queries the device registry to obtain all currently online devices with the same execution capabilities, removes the faulty node, rearranges the execution order of the remaining response execution devices, and updates the transmission chain information and the current and next addresses in the token. The cloud then sends the corrected token back to the original holding device. Upon receiving the corrected token, the device replaces its local token and resends the linkage trigger message according to the new address, allowing subsequent actions to continue along the updated link. Simultaneously, the cloud records the link change log for auditing purposes.

[0051] The embodiments of the present invention have been described in detail above with reference to the accompanying drawings. However, the present invention is not limited thereto. Various changes can be made within the scope of knowledge possessed by those skilled in the art without departing from the spirit of the present invention.

Claims

1. A cloud-edge-device collaborative intelligent linkage method for the Internet of Things, characterized in that, include: Obtain the description of the linkage requirements and the registration information of multiple devices; The linkage requirement description information is parsed, the event listening function and the response execution function are logically decoupled, and an event listening subtask and at least one response execution subtask are generated. Based on the load status of each device, network connectivity, and the principle of proximity of the data source, determine the first deployment device for the event listening subtask and the second deployment device for each response execution subtask. Assign a unique linkage token, which includes the trigger source identifier, trigger source device address, linkage transmission chain information, current response execution device address, next response execution device address, and linkage execution parameters; The linkage transmission chain information defines the triggering initiating device, at least one response execution device, and the transmission order; The linkage token is sent to the first and second deployment devices, the event listening component and the response execution component are deployed, and a cross-device binding relationship is established based on the address and transmission chain information in the token; When the event listening component detects a target event that meets the triggering conditions, it generates a trigger signal and sends the trigger signal and linkage token to the response execution component corresponding to the current response execution device address. After the response execution component executes the response based on the token parameters, when it needs to be passed to the next device, it updates the trigger source identifier in the token to the current device identifier, updates the current response execution device address to the next device address, and sends the updated token and the next-level trigger instruction to the next device.

2. The cloud-edge-device collaborative cloud IoT intelligent linkage method according to claim 1, characterized in that, Obtain the description of the linkage requirements and the registration information of multiple devices, including: Obtain linkage requirement description information from the user configuration interface or preset configuration file, parse the linkage requirement description information, and obtain the event source identifier, event triggering condition and response action type; You can query the registration information of all registered devices through the device registration center. The registration information includes device type, device identifier, and device access status. Based on the device access status, the devices are filtered for availability, and devices that are offline or in a faulty state are removed to form a list of available devices. Associate the list of available devices with the event source identifier and response action type, and output the results.

3. The cloud-edge-device collaborative cloud IoT intelligent linkage method according to claim 2, characterized in that, The system parses the description information of the linkage requirements, decouples the event listening function from the response execution function, and generates an event listening subtask and at least one response execution subtask, including: Extract the event source identifier and event triggering condition from the linkage requirement description information, and encapsulate the event source identifier and event triggering condition into an event listening subtask. The event listening subtask includes the listening object and the triggering condition expression. Extract the response action type from the linkage requirement description information and split the response action type into one or more independent response action items; For each response action item, a response execution subtask is generated. The response execution subtask includes the response action type and action parameters to be executed. Mark the response execution subtasks with sequence constraints or concurrency constraints. Sequence constraints indicate that response actions must be executed in a preset order, while concurrency constraints indicate that response actions can be executed simultaneously.

4. The cloud-edge-device collaborative cloud IoT intelligent linkage method according to claim 3, characterized in that, Based on the load status of each device, network connectivity, and the principle of proximity of the data source, the first deployment device for the event listening subtask and the second deployment device for each response execution subtask are determined, including: Collect real-time load status parameters and network connectivity metrics for each device in the available device list. Load status parameters include CPU utilization and memory utilization, and network connectivity metrics include round-trip latency and packet loss rate. Select the device from the list of available devices that is closest to the network of the event source device as the candidate first deployment device; Among the candidate first deployment devices, the device whose load status parameter is lower than the preset load threshold and whose network connectivity index meets the preset network quality conditions is selected as the first deployment device. For each response, execute a subtask and select a set of candidate devices with corresponding execution capabilities from the list of available devices based on the response action type; From the candidate device set, the optimal device is selected as the second deployment device for the corresponding response execution subtask based on load status parameters and network connectivity indicators.

5. The cloud-edge-device collaborative cloud IoT intelligent linkage method according to claim 4, characterized in that, Assign a unique linkage token, including: Generate a globally unique linkage token identifier; Based on the event source identifier and the event source device registration information, determine the trigger source identifier and the trigger source device address; Based on the sequential or concurrent constraints between the response execution subtasks, the linkage transmission chain information is determined. The linkage transmission chain information includes the trigger initiating device, each response execution device, and the transmission order. Based on the linkage transmission chain information, determine the address of the current response execution device and the address of the next response execution device. The address of the current response execution device is the address of the first response execution device in the transmission sequence, and the address of the next response execution device is the address of the second response execution device in the transmission sequence. Encapsulate the action parameters corresponding to each response execution subtask into linked execution parameters; The above information is assembled according to a preset data format and digitally signed to generate a unique linkage token.

6. The cloud-edge-device collaborative cloud IoT intelligent linkage method according to claim 5, characterized in that, The linkage token is issued to the first and second deployment devices, an event listening component and a response execution component are deployed, and a cross-device binding relationship is established based on the address and transmission chain information in the token, including: The unique linkage token is sent to the first deployment device and each of the second deployment devices via a secure communication channel. Install and start the event listener component on the first deployment device. The event listener component loads the event source identifier and event triggering conditions from the token. Install and start the response execution component on each of the second deployment devices. The response execution component loads the linkage execution parameters in the token. Each device establishes a communication connection and address mapping to its neighboring device based on the trigger source device address, the current response execution device address, the next response execution device address, and the linkage transmission chain information in the token. After each device completes the communication connection and address mapping, it sends a binding completion confirmation to the management node. The management node summarizes the confirmation information and establishes a complete cross-device binding relationship.

7. The cloud-edge-device collaborative cloud IoT intelligent linkage method according to claim 6, characterized in that, When the event listening component detects a target event that meets the triggering conditions, it generates a trigger signal and sends the trigger signal and linkage token to the response execution component corresponding to the current response execution device address, including: The event listening component collects the output data stream of the event source device in real time and makes a matching judgment based on the event triggering conditions; When a target event that meets the event triggering conditions is matched, extract the target event data; A trigger signal is generated based on the target event data. The trigger signal includes the event type and event data. Obtain the unique linkage token, and encapsulate the trigger signal and the unique linkage token into a linkage trigger message; Through a pre-established communication connection, the linkage trigger message is sent to the response execution component corresponding to the current response execution device address in the token.

8. The cloud-edge-device collaborative cloud IoT intelligent linkage method according to claim 7, characterized in that, After the response execution component executes the response based on the token parameters, when it needs to be passed to the next device, it updates the trigger source identifier in the token to the current device identifier, updates the current response execution device address to the next device address, and sends the updated token and the next-level trigger instruction to the next device, including: The response execution component receives the linkage trigger message and parses out the unique linkage token and trigger signal; Execute the corresponding response action based on the linkage execution parameters in the unique linkage token; After the response action is completed, check if the address of the next response execution device in the unique linkage token is empty; When the address of the next response execution device is not empty, the trigger source identifier in the unique linkage token is updated to the current device identifier, and the address of the current response execution device is updated to the address of the next response execution device. Based on the trigger signal and the already executed response action, generate the next level trigger command; The updated unique linkage token and the next-level trigger instruction are encapsulated into a next-level linkage trigger message and sent to the response execution component corresponding to the updated current response execution device address.

9. A cloud-edge-device collaborative cloud IoT intelligent linkage method according to claim 8, characterized in that, The method further includes: If any response execution device malfunctions or network interruptions are detected, the device currently holding the token reports the anomaly to the cloud. The cloud then determines the next response execution device based on the device's availability, updates the transmission chain information and address in the token, and sends it to the currently holding device, enabling the linkage signal to continue execution along the updated transmission chain.

10. A cloud-edge-device collaborative cloud IoT intelligent linkage method according to claim 9, characterized in that, The device currently holding the token reports an anomaly to the cloud. The cloud, based on the device's availability, re-determines the subsequent response execution device, updates the transmission chain information and address in the token, and sends it to the currently holding device, enabling the linkage signal to continue execution along the updated transmission chain, including: If the device currently holding the token does not receive an acknowledgment response within the preset response timeout period after sending a linkage trigger message to the address of the next response execution device, it will determine that the next response execution device is faulty or the network is interrupted. The device currently holding the token will retry sending the linkage trigger message. If the number of retries reaches the preset maximum number of retries and no acknowledgment is received, the device executing the next response will be confirmed as unreachable. The device currently holding the token generates an anomaly reporting message, which includes the current device identifier, the address of the unreachable device, and the unique linkage token currently held. The device currently holding the token will send an anomaly report message to the cloud; After receiving the anomaly report message in the cloud, the system obtains the current availability status information of all devices from the device registration center and removes faulty devices and devices with network interruptions. From the available devices that have been removed, the cloud determines the next response execution devices based on their matching degree with the execution capabilities of the subsequent response execution subtasks in the original delivery chain; Based on the newly determined subsequent response execution device, the cloud updates the linkage transmission chain information, the current response execution device address, and the next response execution device address in the unique linkage token, and generates an updated unique linkage token. The cloud will send the updated unique linkage token to the device currently holding the token; The device currently holding the token receives the updated unique linkage token and sends the next-level linkage trigger message to the corresponding response execution component based on the updated current response execution device address, so that the linkage signal continues to be executed along the updated transmission chain.

Images