Heterogeneous device adaptive cooperative control method and system based on edge AI

Abstract

The invention provides an edge AI-based heterogeneous device adaptive cooperative control method and system, and the method comprises the steps: obtaining and analyzing the cooperative scene description of a user at an edge gateway side, and generating a cooperative control intention; generating a collaborative executable degree for quantifying collaborative execution feasibility for each virtual service capability, and aggregating the collaborative executable degree of each virtual service capability with a preset threshold requirement to form a collaborative execution constraint set; calculating the permission margin of each virtual service capability; taking the minimum permission margin of all the virtual service capabilities as an overall judgment basis, and generating a collaborative execution permission; triggering and generating corresponding physical equipment to execute a coordination action; and if the cooperative execution permission fails, immediately blocking the execution of the subsequent virtual service capability which is not triggered. According to the method, the problems of inconsistent execution and difficulty in management and control of security risks in a complex edge collaboration scene are effectively solved.

Description

Technical Field

[0001] The present invention belongs to the field of intelligent control of building energy, and particularly relates to a heterogeneous device adaptive collaborative control method and system based on edge AI. Background Art

[0002] With the popularization of applications such as the Internet of Things, intelligent manufacturing, and intelligent buildings, more and more physical devices enter the same network in a local access manner and participate in automated control. However, these devices have significant differences in communication protocols, control interfaces, ability granularity, response timings, and trust levels, resulting in the long-term contradiction of "being able to connect, being difficult to use well, and being difficult to control stably" in the engineering implementation of multi-device collaborative control. Existing solutions mostly adopt rule engines, process choreography, or centralized scheduling strategies, relying on preset conditions to trigger actions of multiple devices to achieve linkage effects. Some systems further introduce cloud coordination or cloud-side intelligent decision-making to improve the scenario coverage. However, when the scenario develops from single-point linkage to a collaborative action chain across devices, protocols, rooms, or regions, the online status, controllable status, and occupancy status of devices change at any time, and the same type of ability may be driven and implemented by multiple protocols. Collaborative scheduling faces problems such as inconsistent interfaces, unpredictable timings, and local failure propagation. In the physical world, control actions often have irreversibility. Once triggered and executed under conditions that are not met or states that are not consistent, it is easy to cause safety risks, energy waste, or system instability. At the same time, the edge-side deployment requires low latency and local autonomy, and it is difficult to rely on frequent cloud interactions to complete the decision-making loop. Existing protections mostly focus on the access authentication and permission configuration levels, lacking a unified constraint mechanism that incorporates the real-time executability and heterogeneous complexity of devices into the collaborative execution entry, resulting in inconsistent results such as "some devices have already acted, while other devices have not acted due to being unavailable" in collaborative execution, or continuing to push subsequent actions after the device state changes, thus expanding the scope of influence. Therefore, how to establish an extensible collaborative control mechanism for heterogeneous devices on the edge side, enable the collaborative scenario to run with low latency locally, form a consistency determination and executable boundary before execution, and be able to block subsequent actions in a timely manner according to real-time state changes during execution, so as to avoid the implementation of inconsistent or unsafe collaborative behaviors, has become a key problem亟待解决 in the current technical system. Summary of the Invention

[0003] The object of the present invention is to propose a heterogeneous device adaptive collaborative control method and system based on edge AI to solve the above problems.

[0004] To achieve the above object, in the first aspect of the present invention, a heterogeneous device adaptive collaborative control method based on edge AI is provided. The method includes the following steps: S1. At the edge gateway, obtain and parse the user's collaborative scenario description, decompose it into multiple action-object fragments; based on the locally maintained virtual service capability table, match the corresponding virtual service capability for each action-object fragment, and encapsulate all the matched virtual service capability sets with the collaborative target description to generate a collaborative control intent; S2. Based on the set of virtual service capabilities in the collaborative control intent, obtain the set of candidate devices corresponding to each virtual service capability; based on the set of candidate devices, the real-time executable status of the devices and the protocol driver information, and combining the set of candidate devices and the discrete count of the drivers, generate a collaborative executability degree for each virtual service capability to quantify the feasibility of collaborative execution, and aggregate the collaborative executability degree of each virtual service capability with the preset threshold requirements to form a set of collaborative execution constraints; S3. Based on the collaborative execution constraint set, compare the collaborative executability of each virtual service capability with the threshold requirement, introduce a risk penalty term, and calculate the permission margin of each virtual service capability; use the minimum permission margin of all virtual service capabilities as the overall judgment basis to generate a collaborative execution license. S4. Using the collaborative execution license and the set of virtual service capabilities as execution gating signals, traverse each virtual service capability in the set of virtual service capabilities in a predetermined or configured order. If and only if the collaborative execution license is valid and the corresponding virtual service capability has not yet been executed, trigger the generation of the corresponding physical device to perform a collaborative action. If the collaborative execution license fails, immediately block the execution of any virtual service capabilities that have not yet been triggered.

[0005] Furthermore, the parsing of the user's collaborative scenario description specifically includes: The collaborative scene description in text form is obtained, and the text-based collaborative scene description is expanded by a pre-configured set of action keywords and a set of object keywords. Then, action fragments and object fragments are identified from the text by rule matching, and the two are combined to form an action-object fragment.

[0006] Furthermore, the locally maintained virtual service capability table matches the corresponding virtual service capability for each action-object fragment, specifically as follows: Both the action-object fragment and the virtual service capability are represented as feature sets. The degree of matching is evaluated by calculating the overlap between the two feature sets, and the virtual service capability whose matching result meets the preset threshold is included in the collaborative control intent.

[0007] Furthermore, the candidate device set is directly given by the capability table; the executable device set is obtained by screening the candidate device set device by device, and the screening condition is that the device is in an executable state and is allowed to enter the control path.

[0008] Furthermore, the driving discrete count is a discrete count at the protocol driving layer.

[0009] Furthermore, each collaborative execution constraint item in the collaborative execution constraint set includes at least a comparison requirement between the virtual service capability identifier and the collaborative executability.

[0010] Furthermore, the real-time executable status is reported by the device status acquisition module, and the protocol driver information is read from the device registry.

[0011] Furthermore, the principle for generating the collaborative execution license is as follows: When the capability coverage is higher, the threshold requirement is lower, and the driver is more concentrated, the margin is greater; when the coverage is lower or the driver is more dispersed, the margin is reduced and blocking is more likely to be triggered.

[0012] Furthermore, the virtual service capability is triggered and generated by calling a preset virtual service interface, and the protocol driver module maps the call to the control command of the corresponding physical device.

[0013] A second aspect of the invention provides a heterogeneous device adaptive collaborative control system based on edge AI, the system comprising: The intent generation module is used to acquire and parse the user's collaborative scenario description on the edge gateway side, decompose it into multiple action-object fragments; based on the locally maintained virtual service capability table, it matches the corresponding virtual service capability for each action-object fragment, and encapsulates all the matched virtual service capability sets with the collaborative target description to generate a collaborative control intent; The constraint generation module is used to obtain a set of candidate devices corresponding to each virtual service capability based on the set of virtual service capabilities in the collaborative control intent; based on the set of candidate devices, the real-time executable status of the devices and the protocol driver information, combined with the set of candidate devices and the discrete count of the drivers, generate a collaborative executability degree for each virtual service capability to quantify the feasibility of collaborative execution, and aggregate the collaborative executability degree of each virtual service capability with the preset threshold requirements to form a set of collaborative execution constraints; The license determination module is used to compare the collaborative executability of each virtual service capability with the threshold requirement based on the collaborative execution constraint set, introduce a risk penalty term, calculate the license margin of each virtual service capability, and use the minimum license margin of all virtual service capabilities as the overall determination basis to generate a collaborative execution license. The execution control module is used to use the collaborative execution license and the set of virtual service capabilities as execution gating signals, and to traverse each virtual service capability in the set of virtual service capabilities in a predetermined or configured order. If and only if the collaborative execution license is valid and the corresponding virtual service capability has not yet been executed, the module triggers the generation of the corresponding physical device to perform a collaborative action. If the collaborative execution license expires, the module immediately blocks the execution of any virtual service capabilities that have not yet been triggered.

[0014] The beneficial technical effects of the present invention are at least as follows: This invention constructs a collaborative control mechanism for heterogeneous devices at the edge gateway side. It abstracts the control capabilities of multi-protocol physical devices into a unified virtual service capability and transforms user-defined collaborative scenarios (using natural language or graphical representations) into structured collaborative control intentions. This ensures subsequent processing revolves around a unified object, unaffected by specific protocol differences. Based on this, a collaborative execution constraint set is generated using real-time available device and service states. The objective conditions required for collaborative execution are made explicit and quantified, while the scheduling uncertainties arising from the dispersed nature of heterogeneous protocol drivers are incorporated into the constraint construction, allowing the constraints to reflect the real engineering challenges of edge-side collaborative execution. Subsequently, the constraint set is further converged into collaborative execution licenses that can be directly consumed by the execution module. Through license gating, complex constraint judgments are pre-fixed into unified execution entry conditions, giving clear boundaries to the triggering of device control actions. During the collaborative execution phase, the edge gateway drives virtual service interface calls based on execution licenses, thereby initiating collaborative actions of physical devices. When the license state is updated with changes in device state, subsequent actions are promptly blocked, ensuring that the non-rollbackable physical execution is always controlled within the license boundaries, reducing the risk of collaborative instability caused by local anomalies or state deviations. Through the above design, the present invention achieves unified abstraction of heterogeneous device collaborative control, consistency constraints before execution, and controlled advancement during execution under local low latency conditions, while taking into account scalable access and engineering feasibility, thereby more effectively solving the problems of inconsistent execution and difficult management of security risks in complex edge collaboration scenarios. Attached Figure Description

[0015] The present invention will be further described with reference to the accompanying drawings, but the embodiments in the drawings do not constitute any limitation on the present invention. For those skilled in the art, other drawings can be obtained based on the following drawings without creative effort.

[0016] Figure 1 This is a flowchart of an adaptive collaborative control method for heterogeneous devices based on edge AI according to the present invention. Detailed Implementation

[0017] Embodiments of the present invention are described in detail below. Examples of these embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and are only used to explain the present invention, and should not be construed as limiting the present invention.

[0018] like Figure 1 As shown in the figure, an embodiment of the present invention provides an adaptive collaborative control method for heterogeneous devices based on edge AI, the method comprising: S1. At the edge gateway, obtain and parse the user's collaborative scenario description, decompose it into multiple action-object fragments; based on the locally maintained virtual service capability table, match the corresponding virtual service capability for each action-object fragment, and encapsulate all the matched virtual service capability sets with the collaborative target description to generate collaborative control intent.

[0019] Specifically, this step processes the collaborative scenario description provided by the user at the edge, forming a collaborative control intent that is structurally stable, semantically clear, and can directly participate in subsequent calculations.

[0020] Among them, collaborative scenario description Data is collected by the human-machine interaction module of the edge gateway. Specifically, it can come from text commands input by the user on the local terminal, text results output by the speech recognition module, or scene configuration data generated by the graphical configuration interface. Regardless of the input form, its core content is regarded as a description of the collaborative behavior goal and is directly entered into the edge-side processing flow after collection.

[0021] Furthermore, on the edge gateway side, firstly... The original description is broken down into several action-object fragments through structured decomposition. For text-based descriptions... The parsing process unfolds based on a pre-configured set of action keywords and object keywords. It identifies action fragments and object fragments from the text through rule matching and combines them to form structured action-object fragments. For example, when the input is "turn on the living room light and start the air conditioner," the parsing result is two fragments: "turn on—light" and "start—air conditioner." For graphical drag-and-drop input, the system directly reads the type identifiers and connections of each node in the configuration file. Each node corresponds to an action-object fragment, ensuring a consistent structural representation for different input methods in subsequent processing.

[0022] Furthermore, after obtaining the action-object fragment, the edge gateway performs capability matching based on a locally maintained virtual service capability table. The virtual service capability table is generated and continuously maintained by the protocol-driven module during system deployment or device access. Each capability record contains a capability identifier and a set of features describing the scope of application of that capability. The system represents action-object fragments and virtual service capabilities as discrete feature sets and evaluates the coverage of the capability to the collaborative objective by the overlap ratio of these sets. This calculation is based on the classic definition of set similarity, and its form is as follows: ; in, This represents a certain virtual service capability, where 's' represents the description of a collaborative scenario. The resulting action-object fragment is obtained through decomposition. Indicates virtual service capabilities The feature set, which is derived from the structured description of the capability in the virtual service capability table, This represents the feature set of an action-object fragment s, which is derived from the action features and object features extracted during the parsing phase. Representational ability The matching result for fragment s is used to measure the coverage ratio of the capability feature to the collaborative target feature.

[0023] In a specific implementation scenario, suppose the feature set of action-object fragment s is as follows: This indicates the switching control of lighting equipment; a certain virtual service capability. The feature set is Another virtual service capability The feature set is According to the above calculation method, and The size of the feature intersection is , for The matching result obtained is ;and The feature intersection with s is empty, and the corresponding matching result is The system will then... Include the set of virtual service capabilities required for the current collaborative scenario, but not include In actual configuration, the threshold for determining this coverage ratio can be set through system parameters to adapt to collaborative scenarios of varying complexity.

[0024] After completing the capability matching of all action-object fragments, the edge gateway will uniformly encapsulate the parsed collaborative target description and the filtered set of virtual service capabilities to generate a collaborative control intent, the structural relationship of which can be represented as follows: ; in, Indicates the intention to coordinate control. This indicates a collaborative scenario description. The collaborative goal description obtained by decomposing and combining the results originates from the combination of action-object fragments. ; This represents the set of virtual service capabilities obtained through the above matching calculation and filtering, where each capability... In this way, the edge gateway obtains a well-structured collaborative control intent that is independent of the device communication protocol, enabling the subsequent generation and execution control of collaborative execution constraints to revolve around the same input object.

[0025] S2. Based on the set of virtual service capabilities in the collaborative control intent, obtain the set of candidate devices corresponding to each virtual service capability; based on the set of candidate devices, the real-time executable status of the devices and the protocol driver information, and combining the set of candidate devices and the discrete count of the drivers, generate a collaborative executability degree for each virtual service capability to quantify the feasibility of collaborative execution, and aggregate the collaborative executability degree of each virtual service capability with the preset threshold requirements to form a set of collaborative execution constraints.

[0026] Specifically, the collaborative control intent is received at the edge gateway side. Next, this step focuses on the set of virtual service capabilities within it. Generate a set of cooperative execution constraints This allows subsequent steps to determine whether collaborative execution has an objective basis based on a set of determinable conditions. The key here is to translate the "realistic limitations of heterogeneous device collaborative execution" into a computationally achievable quantity: on the one hand, it's necessary to identify whether each capability has sufficient executable devices to support it at the current moment; on the other hand, it's necessary to identify the degree of dispersion of these executable devices at the protocol driver level. This is because when the same capability is dispersed across multiple driver types, edge-side scheduling and consistency gating become significantly more complex, and collaborative execution is more prone to uncontrollable state deviations. Both of these constraints are constructed solely from state data directly obtainable from the edge side, without relying on external data sources: candidate device information comes from the association index between the virtual service capability table and the device registry; the current executable state of the device comes from the reported status flags of the device status acquisition module; the protocol driver information to which the device belongs comes from the driver identifier field recorded in the device registry; and the "allow control" flag used for security isolation comes from the allowed operation result of the sandbox executor's control entry for that device. Through these inputs, the gateway determines the appropriate protocol driver for each capability. Construct a candidate device set With executable device set ,in The abilities are given directly from the ability table. From the The device was selected through a process of filtering, with the filtering criteria being "the device is in an executable state and is allowed to enter the control path".

[0027] Furthermore, in order to incorporate "cross-drive decentralization" into collaborative execution constraints, this step involves... Calculate its discrete count at the protocol driver level. This calculation originates from the classic definition of "duplicate counting" in set theory: given a set of elements, after projecting it onto another set via a mapping function, the result of the projection is deduplicated and its cardinality is counted. Here, this definition is applied to the "device-to-driver" projection: the device identifier is mapped to its protocol driver identifier, and then the number of different drivers is counted. The corresponding calculation is as follows: ; in, This indicates virtual service capabilities, derived from... Traversal; Representational ability The set of executable devices is derived from the candidate device set after filtering by device status flags and sandbox permission flags; Indicates the device identifier in the set; This indicates the process of reading the mapping from the device to the protocol driver identifier, which is implemented by indexing the driver identifier field in the device registry using the device identifier; This represents the discrete count of the drive in the drive dimension of the executable device. Both sides of the formula are count results, which are discrete quantities and can be directly used for subsequent threshold or proportional constraints.

[0028] Furthermore, in obtaining the drive discrete count of the executable device in the drive dimension... Next, this step further generates a capability-level "Collaborative Executability" to characterize the current capability support strength, and incorporates driver dispersion as a penalty term into the same metric. The original form of this metric can be traced back to the classic definition of coverage ratio, which expresses the degree of coverage as the ratio of the size of the executable subset to the size of the candidate full set. Based on this, to reflect the special characteristics of heterogeneous collaboration, the driver dispersion count is introduced into the denominator with an additive penalty, so that capabilities with "high coverage but large dispersion" receive a more conservative executability in collaborative scenarios. Additive penalty is a common regularization / smoothing construction method in mathematics: superimposing a non-negative term related to the risk factor onto the original denominator, thereby suppressing overly optimistic assessments caused by unfavorable structures while maintaining the interpretability of the metric. The corresponding calculation is as follows: ; in, Indicates virtual service capabilities The degree of collaborative executability; The number of elements in the executable device set is indicated by the gateway. Counting yields the result; The number of elements in the candidate device set is indicated by the gateway. Counting yields the result; This indicates the discrete count of the drive, derived from the deduplication count result of the previous equation. Both sides of this equation are ratios, which are dimensionless proportions, suitable for comparison with the configuration threshold; moreover, the two equations have a clear sequential relationship: first, the deduplication is performed on the projection from the device to the drive to obtain the result. Then, it is substituted as a penalty term into the executability calculation to obtain the collaborative executability. Ultimately, this will improve the collaborative executability. As the core quantitative basis for constraint terms, it is written into the constraint set. .

[0029] In one specific embodiment, the cooperative control intent Capability set Includes lighting capabilities Environmental adjustment ability .right The size of the candidate device set is obtained from the capability table. The size of the executable device set is obtained after collecting device status data and filtering by sandbox permission flags. Further, the driver identifiers of these three devices are read from the device registry to obtain the driver set, for example, ... Then the deduplicated driver set is ,therefore Substituting the above results into the collaborative executability formula, we obtain... .right Obtained from the ability table After filtering Read the driver identifier to get The size of the driver set after deduplication is ,therefore Substituting into the equation yields... The gateway is based on the collaborative goal description. The corresponding scenario strategy configuration is for each capability. Form constraints, which must include at least "virtual service capability identifier". "and collaborative executability" The comparison requirements are used to aggregate all capability constraints into a collaborative execution constraint set. This enables subsequent steps to make gating decisions on collaborative execution using the same input object.

[0030] S3. Based on the collaborative execution constraint set, compare the collaborative executability of each virtual service capability with the threshold requirement, introduce a risk penalty term, and calculate the permission margin of each virtual service capability; use the minimum permission margin of all virtual service capabilities as the overall judgment basis to generate a collaborative execution license.

[0031] Specifically, the edge gateway side obtains the collaborative execution constraint set output in step two. Generate a collaborative execution license afterward. This enables subsequent execution phases to use a unified permission object for granting and blocking. (Constraint set) It consists of several capability-level constraints, each of which corresponds to a collaborative control intent. A certain virtual service capability And carry the collaborative executability calculated in step two. With driving discrete counting It also includes a scenario strategy configuration module based on collaborative goals. The given threshold and strategy parameters .in This is derived from the counting relationship between the candidate device set and the executable device set, and has already been formed in step two; This is derived from deduplication of the executable device set after reading the driver identifier from the device registry; and The scenario policy configuration configured by the gateway is written when the collaborative scenario is established and is read by this step. This step combines this quantitative information into a permission determination link, so that common issues in heterogeneous collaborative scenarios such as "insufficient coverage" and "cross-driver dispersion" can simultaneously enter the same permission logic.

[0032] Furthermore, for each virtual service capability The edge gateway first calculates the permission margin. The capability coverage and threshold preference are differencing, and then a driving dispersion penalty term is superimposed to form a single scalar for subsequent aggregation. This construction is based on the mathematical concept of "margin," which is the difference between "availability" and "required value" to obtain the distance. It also borrows from classical regularization, incorporating risk-related non-negative terms into the difference expression in a weighted form, making the margin more conservative when facing unfavorable structures. The risk term here is taken from the driving discrete counting in step two. and using set counting normalization form Discrete counts are mapped to a stable proportion range, making comparisons possible across different scales. The allowable margin is calculated as follows: ; in, Representational ability Permission margin; This represents the collaborative executability obtained in step two; This indicates the threshold requirement for this capability; This represents the discrete count of the driving force obtained in step two; This represents the dispersion penalty coefficient. Both sides of the formula are linear combinations of dimensionless quantities and proportional terms, therefore they can be directly used for subsequent judgment and comparison. This is a risk penalty item; its logical meaning is: when the capability coverage is higher, the threshold requirement is lower, and the driving force is more concentrated, the margin is greater; when the coverage is lower or the driving force is more dispersed, the margin is reduced and it is more likely to trigger blocking.

[0033] Furthermore, upon obtaining all abilities Subsequently, the edge gateway generates an overall collaborative execution license based on the aggregation principle that "the weakest link determines the overall feasibility". This principle originates from the numerical domain equivalent of the classical constraint conjunction concept: when multiple necessary conditions jointly determine overall feasibility, the overall margin is constrained by the minimum margin. The edge gateway will aggregate capabilities. The minimum allowance margin is taken and compared with zero to obtain the allowance result: ; in, Indicates permission for collaborative execution; This represents the minimum allowable margin of all capabilities; square brackets indicate the result of the comparison decision. The logical relationship between this formula and the previous formula is as follows: the previous formula gives the individual margin for each capability, while this formula aggregates the individual margins into the overall allowable margin, therefore... The calculation results are directly used as input for this aggregation decision. In engineering implementation, the edge gateway uses the constraint set... Item-by-item traversal, by ability Read , , and ,calculate And maintain the current minimum value; perform a comparison after the traversal is complete to obtain the result. and will It is bound to the control context of this collaborative control instance, allowing it to be directly read during the execution phase.

[0034] Taking a collaborative scenario of a home edge gateway as an example, the collaborative control intent includes lighting capabilities. Environmental adjustment ability Step two is given. , ,as well as , The scenario strategy configuration is given. , and give Substituting into the first equation, we get... , The minimum margin is Substituting into the second equation, we get... The device is in a non-relevant state. If the equipment status changes and the lighting capability is updated in step two... and If unchanged, then At this point, the minimum margin is Substituting into the second equation, we get This indicates a passable state. Through the above calculations, the edge gateway obtains the unified permission object using the quantization results from the constraint set as input. and will Write a control context accessible to the execution control module so that subsequent collaborative execution can be triggered and blocked with permission as the entry point.

[0035] S4. Using the collaborative execution license and the set of virtual service capabilities as execution gating signals, traverse each virtual service capability in the set of virtual service capabilities in a predetermined or configured order. If and only if the collaborative execution license is valid and the corresponding virtual service capability has not yet been executed, trigger the generation of the corresponding physical device to perform a collaborative action. If the collaborative execution license fails, immediately block the execution of any virtual service capabilities that have not yet been triggered.

[0036] Specifically, obtain the collaborative execution license output in step three on the edge gateway side. Subsequently, this step drives the collaborative execution of heterogeneous devices based on the permission result, and implements termination control based on changes in the permission status during execution. The design goal of this process is to transform the abstract judgment of "whether execution is allowed" formed in the preceding steps into deterministic scheduling of actual physical device control actions, while ensuring that subsequent execution can be blocked at minimal cost when permission conditions change. Therefore, this step does not recalculate collaborative execution constraints or capability coverage, but rather... As the sole execution gating signal, the execution logic converges to the determination of "whether to continue triggering the next capability".

[0037] Furthermore, at the start of execution, the edge gateway's execution module reads the license status bound to the current collaborative control instance. and from the intention of collaborative control Acquire virtual service capabilities The execution module uses the capability index table to assign each capability... The mapping is applied to corresponding virtual service interfaces, which are further mapped to the control entry points of specific devices via a protocol driver module. This mapping relationship is established during system deployment or device access; the execution phase only involves table lookups and invocations, thus ensuring the determinism of the execution path. The execution module also maintains an execution status set to record which capabilities have been triggered and which have not. This status set is updated by the execution module after each successful invocation of a virtual service interface.

[0038] Furthermore, to unify "permission release" and "execution progress" within the same decision framework, this step constructs an execution trigger decision within the execution module. Its origins can be traced back to the "gating condition" concept in classical control theory, which states that a system input signal must simultaneously satisfy both global permission conditions and local state conditions before passing through the actuator. In this scheme, this concept is concretized for each capability... Execution triggering conditions Its calculation form is as follows: ; in, Representational ability Whether execution is allowed to be triggered at the current moment; This indicates the collaborative execution permission status, the value of which is given by the calculation result of step three and stored in the control context; Representational ability The execution completion flag is set to true by the execution module after successfully calling the virtual service interface corresponding to the capability. This formula originates from the conjunction and negation rules in Boolean logic, with both sides being logical judgment results, thus avoiding any issue of inconsistent dimensions. Its derivation process can be understood as: Capability The execution of this capability requires both conditions to be met: "overall coordination is still permitted" and "the capability has not yet been executed." Neither condition can be omitted.

[0039] Furthermore, during execution, the edge gateway is configured according to its capability set. Traverse the capability elements in a predetermined or configured order, for each calculate .when When established, the execution module triggers capabilities. The corresponding virtual service interface, and sends control commands to the corresponding physical device through the protocol driver module; when If the condition is not met, the execution module skips the capability and enters the termination process. Simultaneously, the device status acquisition module and the sandbox actuator continuously write state change results to the control context. When these state changes cause the conditions used in step three to generate... When the condition is no longer met, the control context It will be updated to a non-executable state. Because yes The direct input will cause the change to take effect immediately upon the next ability trigger determination, thus blocking abilities that have not yet been executed.

[0040] In one specific embodiment, it is assumed that the cooperative control intent includes a set of capabilities. The initial license status generated in step three is At the initial execution state , The execution module first calculates... Therefore, the virtual service interface corresponding to the lighting capability is triggered and executed, and then... Set as Preparing to trigger Previously, the device status acquisition module detected a change in the status of critical equipment and triggered a license update, enabling the control context to... Updated to At this point, the execution module calculates... This prevents the execution of environmental adjustment capabilities from being triggered, and the collaborative execution process terminates naturally at the edge. In this embodiment, changes in the permission state directly affect the execution path through a simple Boolean decision, without requiring additional rollback or compensation operations.

[0041] Throughout the execution process, the execution module ultimately generates a collaborative execution result status. This is used to characterize whether the coordinated control was fully executed or terminated midway. The result is determined by the execution state set. With final license status The conditions are jointly determined and recorded or reported as the final output of the collaborative control process. By formalizing the execution triggering conditions into a conjunction decision between the permission state and the execution state, and directly coupling the update of the permission state with the execution decision, this step realizes the integration of collaborative execution and termination control of heterogeneous devices, enabling the execution decision in the preceding steps to be directly and controllably implemented at the physical device level.

[0042] This invention also provides an adaptive collaborative control system for heterogeneous devices based on edge AI, the system comprising: The intent generation module is used to acquire and parse the user's collaborative scenario description on the edge gateway side, decompose it into multiple action-object fragments; based on the locally maintained virtual service capability table, it matches the corresponding virtual service capability for each action-object fragment, and encapsulates all the matched virtual service capability sets with the collaborative target description to generate a collaborative control intent; The constraint generation module is used to obtain a set of candidate devices corresponding to each virtual service capability based on the set of virtual service capabilities in the collaborative control intent; based on the set of candidate devices, the real-time executable status of the devices and the protocol driver information, combined with the set of candidate devices and the discrete count of the drivers, generate a collaborative executability degree for each virtual service capability to quantify the feasibility of collaborative execution, and aggregate the collaborative executability degree of each virtual service capability with the preset threshold requirements to form a set of collaborative execution constraints; The license determination module is used to compare the collaborative executability of each virtual service capability with the threshold requirement based on the collaborative execution constraint set, introduce a risk penalty term, calculate the license margin of each virtual service capability, and use the minimum license margin of all virtual service capabilities as the overall determination basis to generate a collaborative execution license. The execution control module is used to use the collaborative execution license and the set of virtual service capabilities as execution gating signals, and to traverse each virtual service capability in the set of virtual service capabilities in a predetermined or configured order. If and only if the collaborative execution license is valid and the corresponding virtual service capability has not yet been executed, the module triggers the generation of the corresponding physical device to perform a collaborative action. If the collaborative execution license expires, the module immediately blocks the execution of any virtual service capabilities that have not yet been triggered.

[0043] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0044] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection of apparatuses or units may be electrical, mechanical, or other forms.

[0045] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0046] Although embodiments of the invention have been shown and described, those skilled in the art will understand that various changes, modifications, substitutions and variations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the claims and their equivalents.

Claims

1. A heterogeneous device adaptive cooperative control method based on edge AI, characterized in that, The method includes: S1. At the edge gateway, obtain and parse the user's collaborative scenario description, decompose it into multiple action-object fragments; based on the locally maintained virtual service capability table, match the corresponding virtual service capability for each action-object fragment, and encapsulate all the matched virtual service capability sets with the collaborative target description to generate a collaborative control intent; S2. Based on the set of virtual service capabilities in the collaborative control intent, obtain the set of candidate devices corresponding to each virtual service capability; based on the set of candidate devices, the real-time executable status of the devices and the protocol driver information, and combining the set of candidate devices and the discrete count of the drivers, generate a collaborative executability degree for each virtual service capability to quantify the feasibility of collaborative execution, and aggregate the collaborative executability degree of each virtual service capability with the preset threshold requirements to form a set of collaborative execution constraints; S3. Based on the collaborative execution constraint set, compare the collaborative executability of each virtual service capability with the threshold requirement, introduce a risk penalty term, and calculate the permission margin of each virtual service capability; use the minimum permission margin of all virtual service capabilities as the overall judgment basis to generate a collaborative execution license. S4. Using the collaborative execution license and the set of virtual service capabilities as execution gating signals, traverse each virtual service capability in the set of virtual service capabilities in a predetermined or configured order. If and only if the collaborative execution license is valid and the corresponding virtual service capability has not yet been executed, trigger the generation of the corresponding physical device to perform a collaborative action. If the collaborative execution license fails, immediately block the execution of any virtual service capabilities that have not yet been triggered.

2. The heterogeneous device adaptive collaborative control method based on edge AI according to claim 1, characterized in that, The description of the collaborative scenario of the parsed user is specifically as follows: The collaborative scene description in text form is obtained, and the text-based collaborative scene description is expanded by a pre-configured set of action keywords and a set of object keywords. Then, action fragments and object fragments are identified from the text by rule matching, and the two are combined to form an action-object fragment.

3. The heterogeneous device adaptive collaborative control method based on edge AI according to claim 1, characterized in that, The locally maintained virtual service capability table matches a corresponding virtual service capability for each action-object fragment, specifically as follows: Both the action-object fragment and the virtual service capability are represented as feature sets. The degree of matching is evaluated by calculating the overlap between the two feature sets, and the virtual service capability whose matching result meets the preset threshold is included in the collaborative control intent.

4. The heterogeneous device adaptive collaborative control method based on edge AI according to claim 1, characterized in that, The candidate device set is given directly by the capability table; the executable device set is obtained by screening the candidate device set device by device, and the screening condition is that the device is in an executable state and is allowed to enter the control path.

5. The heterogeneous device adaptive cooperative control method based on edge AI according to claim 1, characterized in that, The driver discrete count is a discrete count at the protocol driver layer.

6. The heterogeneous device adaptive collaborative control method based on edge AI according to claim 1, characterized in that, Each collaborative execution constraint item in the collaborative execution constraint set includes at least a comparison requirement between the virtual service capability identifier and the collaborative executability.

7. The heterogeneous device adaptive cooperative control method based on edge AI according to claim 1, characterized in that, The real-time executable status is reported by the device status acquisition module, and the protocol driver information is read from the device registry.

8. The adaptive collaborative control method for heterogeneous devices based on edge AI according to claim 1, characterized in that, The principle for generating collaborative execution licenses is as follows: When the capability coverage is higher, the threshold requirement is lower, and the driver is more concentrated, the margin is greater; when the coverage is lower or the driver is more dispersed, the margin is reduced and blocking is more likely to be triggered.

9. The heterogeneous device adaptive cooperative control method based on edge AI according to claim 1, characterized in that, The virtual service capability is triggered and generated by calling a preset virtual service interface, and the protocol driver module maps the call to the control command of the corresponding physical device.

10. A heterogeneous device adaptive collaborative control system based on edge AI, characterized in that, The system includes: The intent generation module is used to acquire and parse the user's collaborative scenario description on the edge gateway side, decompose it into multiple action-object fragments; based on the locally maintained virtual service capability table, it matches the corresponding virtual service capability for each action-object fragment, and encapsulates all the matched virtual service capability sets with the collaborative target description to generate a collaborative control intent; The constraint generation module is used to obtain a set of candidate devices corresponding to each virtual service capability based on the set of virtual service capabilities in the collaborative control intent; based on the set of candidate devices, the real-time executable status of the devices and the protocol driver information, combined with the set of candidate devices and the discrete count of the drivers, generate a collaborative executability degree for each virtual service capability to quantify the feasibility of collaborative execution, and aggregate the collaborative executability degree of each virtual service capability with the preset threshold requirements to form a set of collaborative execution constraints; The license determination module is used to compare the collaborative executability of each virtual service capability with the threshold requirement based on the collaborative execution constraint set, introduce a risk penalty term, calculate the license margin of each virtual service capability, and use the minimum license margin of all virtual service capabilities as the overall determination basis to generate a collaborative execution license. The execution control module is used to use the collaborative execution license and the set of virtual service capabilities as execution gating signals, and to traverse each virtual service capability in the set of virtual service capabilities in a predetermined or configured order. If and only if the collaborative execution license is valid and the corresponding virtual service capability has not yet been executed, the module triggers the generation of the corresponding physical device to perform a collaborative action. If the collaborative execution license expires, the module immediately blocks the execution of any virtual service capabilities that have not yet been triggered.

Images