Cross-device cooperative linkage control system of smart home based on cloud platform

Abstract

The application discloses a cloud platform-based intelligent household cross-device cooperative linkage control system and relates to the technical field of intelligent household interconnection.The system comprises an intention understanding module, which is used for receiving a control request of a user, performing intention analysis on the control request based on a pre-constructed device ontology knowledge graph, obtaining an explicit intention node set, and constructing an intention graph based on the explicit intention node set and the device ontology knowledge graph, wherein each explicit intention node in the explicit intention node set is a device control target directly obtained by performing semantic analysis on the control request, and the intention graph further comprises an implicit dependency edge set and a constraint condition set between the explicit intention nodes.The application realizes decoupling adaptation and cooperative control of different brand devices through a multi-brand device agent and a unified semantic interface layer, and new brand access only needs to register mapping rules without modifying existing modules, so that the system has strong expansibility.

Description

Technical Field

[0001] This invention relates to the field of smart home interconnection technology, specifically to a cloud-based smart home cross-device collaborative control system. Background Technology

[0002] With the rapid development of IoT technology, the types and numbers of smart home devices have increased dramatically. Users often deploy smart devices from multiple brands simultaneously in their homes, such as Haier HomeGPT, Huawei Smart Home, and Xiaomi Mijia. Different brands use their own communication protocols and control interfaces, making cross-brand device coordination a critical issue that urgently needs to be addressed in the smart home field.

[0003] Existing smart home platforms have the following shortcomings in device collaborative control: First, the single-agent architecture is limited. Current platforms typically use a single module to complete intent understanding and device scheduling. Intent understanding and device scheduling are tightly coupled, failing to decouple the heterogeneous constraints of cross-brand devices. When a new brand device is connected, the entire control chain needs to be adapted and modified, resulting in poor scalability. Second, implicit dependencies are lacking. When a user expresses "watch a movie," the system only parses the explicit goal (turn on the TV, turn on the speakers), failing to automatically detect the execution sequence dependencies such as curtains closing → lights dimming → TV turning on. Existing solutions either rely on users to manually specify the execution order or completely ignore the implicit timing constraints between devices, leading to poor execution results or device state conflicts.

[0004] Furthermore, when multiple scenario rules are triggered simultaneously, existing platforms lack a prior conflict detection mechanism. They often only report errors or generate abnormal behavior when contradictory instructions are executed, resulting in a poor user experience. When device execution fails or the network is interrupted, existing solutions usually can only retry from the beginning or give up directly, lacking a graded degradation strategy. Moreover, some platforms use fixed scheduling strategies that cannot adapt to changes in user preferences. Some attempts have been made to use reinforcement learning for strategy optimization, but reinforcement learning has low sample efficiency, poor cold start performance, and lacks a safety fallback mechanism, posing risks in security-related intent scenarios (such as security and fire protection).

[0005] Therefore, this application proposes a cloud-based smart home cross-device collaborative control system to overcome the above-mentioned shortcomings. Summary of the Invention

[0006] To address the aforementioned technical issues, a cloud-based smart home cross-device collaborative control system is provided. This technical solution resolves the problems of the inability to decouple heterogeneous constraints and implicit dependencies between cross-brand devices.

[0007] To achieve the above objectives, the technical solution adopted by the present invention includes: The intent understanding module is used to receive the user's control request, perform intent parsing on the control request based on a pre-built device ontology knowledge graph, and obtain an explicit intent node set. Each explicit intent node in the explicit intent node set is a device control target directly obtained by semantic parsing the control request. An intent graph is constructed based on the explicit intent node set and the device ontology knowledge graph. The intent graph also includes an implicit dependency edge set and a constraint set between the explicit intent nodes. Each dependency edge in the implicit dependency edge set represents the execution order constraint between two intent nodes. The constraint set includes temporal constraints, spatial constraints, and priority constraints. Specifically, when the frequency of occurrence of explicit intent nodes in the historical execution record is lower than the preset data sufficiency threshold, the intent understanding module matches the current control request to the scene from the preset scene rule base of the device ontology knowledge graph, and obtains the set of dependency edges and constraints under that scene; when the frequency of occurrence of explicit intent nodes in the historical execution record reaches the preset data sufficiency threshold, the intent understanding module calculates implicit dependency edges based on the temporal dependency strength between explicit intent nodes. The preset data sufficiency threshold is determined as follows: when the frequency of occurrence of explicit intent nodes in the historical execution record makes the width of the binomial distribution information interval corresponding to that frequency less than the preset accuracy requirement, the data is deemed sufficient. The multi-brand device agent layer includes multiple device agents corresponding to each device brand. Each device agent is used to receive the intent subgraph distributed by the intent understanding module, match the intent nodes in the intent subgraph based on the capability vector of the agent brand device, generate a feasible execution plan and report it. The capability vector describes the controllable parameters of the agent brand device and the corresponding value range. Each device agent also maintains a local instruction cache, which is used to retrieve incomplete global execution plans from the cache for local degradation execution when the network is down. The collaborative scheduling module is used to receive feasible execution plans reported by each device agent, perform global timing orchestration on each feasible execution plan based on the implicit dependency edges in the intent graph, generate a global execution plan through multi-objective optimization within a preset solution time limit, and if the solution timeout occurs, it will degrade to greedy scheduling to generate a feasible execution plan. The global execution plan includes the execution sequence, execution parameters and alternative execution paths of each device. The execution monitoring module is used to monitor the execution progress of the global execution plan. When an execution deviation or execution failure is detected, the corresponding first-level alternative execution path or second-level degradation strategy is triggered. When the connection with the cloud platform is interrupted, each device agent is notified to retrieve the incomplete global execution plan from the local instruction cache for local degradation execution.

[0008] Preferably, the intent understanding module calculates the explicit intent node when the frequency of occurrence of the explicit intent node in the historical execution record reaches the preset data sufficiency threshold. Pointing to explicit intent node Temporal dependency strength in, For the first An explicit intent node. For the first An explicit intent node. for The context vector, by The semantic embedding vector of the target device category is concatenated with the current environment state vector. for The context vector is constructed in the same way as... , The cosine similarity function is used. For historical execution records exist The frequency of previous executions for Frequency of occurrence in historical execution records; when When the preset dependency threshold is exceeded, establish a dependency from point to Implicit dependency edges, representing Must be in Previously, when some explicit intent nodes meet the statistical conditions while others do not, the dependency edges discovered by the statistical method are combined with the dependency edges derived from the pre-defined scenario rules. The dependency edges discovered by the statistical method have a higher priority than the dependency edges derived from the pre-defined scenario rules.

[0009] Preferably, each device agent maintains the capability matrix and execution constraint set of the brand devices it represents, wherein each row of the capability matrix corresponds to a device, and each column corresponds to a controllable parameter and its value range; After the device agent receives the intent subgraph, it matches the control objectives of each intent node in the intent subgraph with the capability matrix, checks whether the current device status meets the preconditions and constraints in the execution constraint set, and generates a feasible execution plan containing execution parameters and estimated execution time if it does not meet the requirements. If it does not meet the requirements, it reports the constraint information that is not met. When the device agent sends control commands to the physical device, it adopts an exponential backoff retry strategy. The initial interval is preset to 1 to 2 seconds. The waiting time for each retry is doubled. The maximum number of retries is 3. After all retries fail, the execution failure is reported to the execution monitoring module.

[0010] Preferably, device agents from different brands communicate through a unified semantic interface layer. The semantic interface layer converts the control commands of each brand's proprietary protocol into standard semantic actions. The standard semantic actions include four fields: device identifier, target parameter, parameter value, and time window. When a new brand device is added, only the capability matrix of the brand device agent and the mapping rules from the private protocol to the semantic interface layer need to be registered. There is no need to modify other device agents or collaborative scheduling modules.

[0011] Preferably, the collaborative scheduling module generates the global execution plan through multi-objective optimization in the following way: using the global execution plan... To optimize variables, solve a multi-objective optimization problem. in, To normalize the total execution time, To normalize conflict penalties, To normalize the total energy consumption, the normalization method for each objective function is to divide the objective function value by the corresponding theoretical maximum value, so that the range of values ​​for each normalized objective function is [missing value]. ; In the formula, To perform the action Execution time To perform the action From completion to execution of action Waiting time before starting For a set of action pairs that have waiting constraints; In the formula, This refers to the set of action pairs with overlapping time windows in the global execution plan. This is the conflict penalty coefficient. For indicator functions; In the formula, To perform the action Estimated energy consumption; The constraints include the temporal order constraints corresponding to the implicit dependency edges, the parameter value range constraints in the capability vector, and the device state transition constraints; the normalized multi-objective is transformed into a single objective using a weighted summation method, and the mapping rule for the weight coefficients is as follows: the objective function corresponding to the safety intention has the highest weight coefficient, followed by the comfort intention, and the entertainment intention has the lowest weight coefficient. The weight coefficients of each objective function within the same category are allocated according to the ratio of execution time: conflict: energy consumption = 2:3:1. If the solution is not completed within the preset time limit, the algorithm will be downgraded to greedy scheduling: First, the intent graph will be topologically sorted to obtain the global execution order. Then, the intent nodes will be traversed from high to low priority. For intent nodes of the same priority, they will be arranged in topological order. Each execution action will be scheduled to the earliest available time slot that satisfies its dependency constraints. If the time slot is occupied, it will be postponed to the next free time slot until all execution actions have been scheduled.

[0012] Preferably, the collaborative scheduling module is further used for conflict detection and resolution: for any two execution actions in the global execution plan and A conflict is determined when any of the following conditions are met: the target devices of the two actions are the same but the target states are different; the time windows of the two actions overlap and they compete for shared resources; the combined effect of the two actions violates the pre-stored physical constraints. The pre-stored physical constraints are physical mutual exclusion constraints between devices, including that the cooling mode and the heating mode cannot be turned on at the same time in the same space, and the same audio device cannot output audio from two scenes at the same time. The conflict resolution method is as follows: weighted negotiation is performed based on the priority of each intent node, and the execution action with higher priority is retained first. When the priorities are the same, the execution action with the earlier completion time of the dependency chain is retained.

[0013] Preferably, the collaborative scheduling module pre-generates a primary alternative execution path and a secondary degradation strategy for each execution action in the global execution plan; the primary alternative execution path is generated as follows: for each execution action... Target equipment The following steps are performed in sequence: First, check if there is a functionally equivalent and currently available alternative device combination in the same space. If so, select the functionally equivalent alternative. If it does not exist, check if the target parameter has a reachable degradation value that is closest to the target value; The option with the smallest deviation from the original execution action and which is available on the device is selected as the primary alternative execution path. The deviation is measured by the deviation metric. Calculation, where These are the original target parameter values. As alternative target parameter values, This refers to the width of the value range for this parameter. For parameter deviation weights, Replace the weights for the devices; The functional equivalence relationship is defined by the functional complementarity relationship in the device ontology knowledge graph; the secondary degradation strategy is as follows: when the primary alternative execution path is unavailable, if the priority of the intent node corresponding to the execution action is non-necessary, the execution action is skipped and the user is notified; if the priority is necessary, it is marked as execution failure and the user is notified to intervene manually. The security-related intentions include those related to security, fire protection, and gas equipment control; intentions other than those related to security are considered non-security-related intentions.

[0014] Preferably, the deviation detection method of the execution monitoring module is as follows: for each executed action in the global execution plan, calculate the state deviation between the actual device state and the expected device state. in For the first The actual device state vector after each execution action is performed. For the first The expected device state vector for each action to be performed; when When the preset deviation threshold is exceeded, the execution action is determined to have an execution deviation, triggering the corresponding first-level alternative execution path. If the first-level alternative is unavailable, a second-level degradation strategy is triggered. The execution monitoring module also sets a dynamic timeout threshold for each execution action. in To perform the action The estimated execution time is reported by the device agent based on the median historical execution time of the device. To determine the execution duration tolerance factor, This represents the current average network latency from the cloud to the device. The standard deviation of the current network latency. and Based on the statistical calculation of the round-trip time of command issuance and response based on the most recent preset number of commands; when the execution action exceeds... If no device status update is received, it is determined that the execution has timed out, triggering the first-level alternative execution path or the second-level degradation strategy.

[0015] Preferably, the execution monitoring module is also used to collect user feedback and drive the gradual adjustment of the collaborative scheduling strategy: user feedback includes explicit feedback and implicit feedback, the explicit feedback is the user's evaluation of the execution result, and the implicit feedback is the user's record of manually adjusting the device parameters after automated execution; When the system starts, the weight coefficient of the collaborative scheduling module adopts a preset security rule strategy. The weight coefficient of security-related intentions is fixed at the highest level and cannot be adjusted. The security-related intentions include intentions involving security, fire protection, and gas equipment control. Once the cumulative number of feedback samples reaches the preset adjustment threshold, the comprehensive score is statistically analyzed by grouping according to the scenario category. For scenarios whose scores are consistently lower than the average, the weight coefficient of non-safety intents in that scenario is finely adjusted with a fixed step size. After each adjustment, verify whether the overall score has improved. If the score does not improve after a preset number of consecutive adjustments, revert to the previous weight. The single adjustment range of the weight coefficient shall not exceed the preset maximum step size, and the cumulative adjustment range shall not exceed the preset total range limit. If it exceeds the limit, the weight shall be locked until the user explicitly confirms the unlock. When the success rate of the adjusted operation drops below a preset percentage, it will automatically revert to the security rule policy. The progressive adjustment also includes an upper limit on the cumulative number of adjustments for a single scenario and a cooling-off period between two adjacent adjustments. When the cumulative number of adjustments for a single scenario reaches the upper limit, the weight adjustment for that scenario is stopped and a cooling-off period begins. If the overall score is still lower than the average after the cooling-off period, the adjustment is resumed.

[0016] Preferably, the device ontology knowledge graph is constructed as follows: an initial graph is constructed with device categories as nodes and functional relationships between device categories as edges. The functional relationships include spatial co-location relationships, functional complementary relationships, functional equivalence relationships, and operational mutual exclusion relationships. The device ontology knowledge graph also includes a pre-set typical scenario rule base, which stores the dependency edge set and constraint conditions of device operations under typical scenarios, and is used for implicit dependency discovery during the cold start phase. When the matching degree between a certain device operation sequence in the user's historical execution record and the existing scenario rule is lower than a preset threshold and the frequency of this deviation exceeds a preset number, a new execution order pattern is added to the knowledge graph as a candidate rule. The candidate rule is converted into a formal rule after being confirmed by the user. When a new device type is added, a corresponding node is automatically created in the knowledge graph through the mapping rules of the semantic interface layer, and functional association edges are automatically established based on the structured functional description of the device. The structured functional description includes four fields: device category, list of controllable parameters, belonging space, and functional label. The rules for establishing functional association edges are as follows: establish complementary functional edges with nodes whose functional labels intersect with existing nodes; establish spatial co-location edges with nodes belonging to the same space; establish mutually exclusive operation edges with nodes whose functional labels are mutually exclusive; and establish functional equivalent edges with nodes whose functional labels completely contain each other.

[0017] A cloud-based smart home cross-device collaborative control system includes: Compared with the prior art, the beneficial effects of the present invention are as follows: This application achieves decoupled adaptation and collaborative control of different brand devices through multi-brand device proxy and a unified semantic interface layer. New brand access only requires registration of mapping rules, without modifying existing modules, resulting in strong scalability. A two-stage strategy (cold start pre-set rules as a fallback + runtime statistical methods) is adopted to solve the dependency inference problem when there is no data during the cold start phase. The temporal dependency strength formula introduces a temporal direction factor to accurately distinguish dependency directions and avoid dependency direction confusion caused by symmetrical co-occurrence frequencies.

[0018] By employing time-limited solution and greedy scheduling with timeout degradation, response timeliness is ensured in complex scenarios. Multi-objective optimization first normalizes and then weights the data to eliminate the lack of physical meaning caused by inconsistent dimensions. A two-level alternative execution path (functional equivalent substitution → parameter reachability degradation → skip / notify) is adopted to achieve rapid fault-tolerant switching in execution failures. Exponential backoff retries, dynamic timeout thresholds, and local degradation execution in the event of network outages ensure system availability in scenarios with unstable networks.

[0019] By replacing reinforcement learning with incremental weight adjustment, a safety rule strategy is initially adopted. After data accumulates to a threshold, the strategy is gradually fine-tuned. The weights of safety-related intentions cannot be overridden. Multiple safeguards are set up, including an upper limit on the adjustment range, an upper limit on the cumulative range, a success rate rollback, an upper limit on the number of adjustments, and a cooldown period, to avoid security issues caused by strategy adjustments. Attached Figure Description

[0020] Figure 1 This is a block diagram of the overall architecture of the system of the present invention; Figure 2 This is a flowchart illustrating the implicit dependency discovery process of the module intended to be understood in this invention. Figure 3 This is a flowchart illustrating the multi-objective optimization and degradation process of the collaborative scheduling module in this invention. Figure 4 This is a flowchart illustrating the deviation detection and degradation process of the monitoring module in this invention. Figure 5 This is a flowchart illustrating the user feedback-driven progressive weight adjustment process of the present invention. Figure 6 This is a diagram illustrating the multi-brand device agency and semantic interface layer architecture of this invention. Figure 7 This is an example diagram illustrating the construction of the consciousness graph for this invention. Detailed Implementation

[0021] The following description is intended to disclose the invention and enable those skilled in the art to implement it. The preferred embodiments described below are merely examples, and other obvious variations will occur to those skilled in the art.

[0022] Reference Figure 1As shown, the smart home cross-device collaborative control system based on the cloud platform is deployed on the cloud platform, with the cloud and edge gateways working together. The cloud handles computationally intensive tasks such as intent understanding and global scheduling, while the edge gateway handles command issuance, status reporting, and local degradation execution when the network is down. The system includes four core modules: intent understanding module, multi-brand device proxy layer, collaborative scheduling module, and execution monitoring module.

[0023] The intent understanding module receives user control requests and performs intent parsing on the control requests based on a pre-built device ontology knowledge graph to obtain a set of explicit intent nodes. Each explicit intent node in the set is a device control target directly obtained through semantic parsing of the control request. For example, if a user says "watch a movie," the semantic parsing directly yields "TV: On" and "Sound: On," which are explicit intent nodes. The intent understanding module also constructs an intent graph based on the set of explicit intent nodes and the device ontology knowledge graph. ,in, For a set of intent nodes, each intent node Includes target device category Control objectives and priority ; For each implicitly dependent edge set, ... express Must Completed previously; It is a set of constraints, including temporal constraints, spatial constraints, and priority constraints.

[0024] Implicit dependency discovery employs a two-phase strategy, based on the frequency of explicit intent nodes appearing in historical execution records. Below the preset data sufficiency threshold At that time, the intent understanding module matches the current control request to the scenario from the pre-set scenario rule base of the device ontology knowledge graph, and obtains the set of dependency edges and constraints under that scenario. The preset data sufficiency threshold is determined as follows: when the frequency of occurrence of explicit intent nodes in historical execution records makes the width of the binomial distribution information interval corresponding to that frequency less than the preset accuracy requirement, the data is considered sufficient. Specifically, let explicit intent nodes... The frequency of occurrence is At the significance level Down, co-occurrence probability The confidence interval width is: in, For the maximum likelihood estimate of co-occurrence frequency, This represents the two-tailed quantile of the standard normal distribution. When ( When the preset precision is 0.1 (typical value), the determination is made. The data sufficiency threshold is met. When the frequency of occurrence of explicit intent nodes in the historical execution records reaches the preset data sufficiency threshold, the intent understanding module calculates implicit dependency edges based on the temporal dependency strength between explicit intent nodes.

[0025] The multi-brand device proxy layer includes multiple device proxies corresponding to various device brands. Each device proxy receives the intent subgraph distributed by the intent understanding module, matches the intent nodes in the intent subgraph based on the capability vector of the proxied brand device, generates a feasible execution plan, and reports it. The capability vector describes the controllable parameters of the proxied brand device and its corresponding value range. Each device proxy also maintains a local instruction cache, which is used to retrieve incomplete global execution plans from the cache for local degradation execution when the network is disconnected.

[0026] The collaborative scheduling module receives feasible execution plans reported by each device agent, performs global timing orchestration on each feasible execution plan based on implicit dependency edges in the intent graph, and generates a global execution plan through multi-objective optimization within a preset solution time limit. If the solution times out, it degrades to greedy scheduling to generate a feasible execution plan. The global execution plan includes the execution sequence, execution parameters, and alternative execution paths for each device.

[0027] The execution monitoring module monitors the execution progress of the global execution plan. When an execution deviation or failure is detected, it triggers the corresponding first-level alternative execution path or second-level degradation strategy. When a connection interruption with the cloud platform is detected, it notifies each device agent to retrieve the incomplete global execution plan from the local instruction cache for local degradation execution.

[0028] like Figure 7 The following example illustrates the system workflow using a user saying "I want to watch a movie". The intent understanding module performs semantic parsing on the control request to obtain the explicit intent node. (TV: On) and (Audio: On). If the system is in the cold start phase (insufficient historical data), it matches the viewing scenario from the pre-set scene rule base to obtain dependency edges (curtains closed → lights dimmed → TV on → audio on) and corresponding constraints. If the system is in the running phase (sufficient historical data), it automatically discovers the same dependency direction based on temporal dependency strength calculation. The intent graph constructed by the intent understanding module is distributed to the device agents of each brand. The device agents match the capability matrix to generate feasible execution plans and report them. The collaborative scheduling module receives the feasible execution plans of each device agent, performs global temporal orchestration based on the intent graph, generates a global execution plan through multi-objective optimization within the solution time limit, and pre-generates alternative execution paths for each execution action. The execution monitoring module monitors the execution progress. If an anomaly is detected, it triggers alternative paths or degradation strategies.

[0029] like Figure 2 As shown, this embodiment details the implicit dependency discovery process of the intent understanding module.

[0030] When the frequency of explicit intent nodes in the historical execution record reaches a preset data sufficiency threshold, the intent understanding module calculates the explicit intent nodes. Pointing to explicit intent node Temporal dependency strength in For the first An explicit intent node. For the first An explicit intent node. for The context vector, by The semantic embedding vector of the target device category is concatenated with the current environment state vector. for The context vector is constructed in the same way as... , The cosine similarity function is used. For historical execution records exist The frequency of previous executions for Frequency of occurrence in historical execution records.

[0031] The core design of this formula lies in the introduction of a time-series direction factor. : Molecules adopt exist The frequency of previous executions and the asymmetric co-occurrence frequency made and The values ​​are generally not equal, thus distinguishing the direction of the dependency. Taking a movie-watching scenario as an example, the frequency of "closing the curtains" is much higher than the frequency of "dimming the lights" before the latter, therefore... Greater than The dependency direction "the curtains must be closed before the lights are dimmed" was correctly established.

[0032] when Exceeding the preset dependency threshold At that time, establish from point to Implicit dependency edges, representing Must be in Previously executed.

[0033] When some explicit intent nodes meet the statistical conditions while others do not, the union of dependency edges discovered by the statistical method and those derived from pre-defined scenario rules is taken, with the dependency edges discovered by the statistical method having higher priority than those derived from pre-defined scenario rules. When two rule edges conflict with statistical edges, the dependency edges discovered by the statistical method take precedence. This hybrid transition mechanism ensures that the system can provide implicit dependency reasoning capabilities at any stage: the cold start stage relies entirely on pre-defined rules, the transition stage uses a combination of rules and statistics, and the mature stage relies primarily on statistics.

[0034] Simultaneously, based on the mutually exclusive relationships of operations in the device ontology knowledge graph (such as the mutual exclusion of "heating" and "cooling"), mutually exclusive constraints are automatically added to the constraint condition set. .

[0035] In this embodiment, as Figure 6 As shown, in this embodiment, in the architecture of the multi-brand device agent layer, each device agent maintains the capability matrix of the brand devices it represents. and execution constraint set Each row of the capability matrix corresponds to a device, and each column corresponds to a controllable parameter and its value range, such as "brightness: [0, 100]%" and "color temperature: [2700, 6500]K". The execution constraint set includes the execution prerequisites for the brand of device (such as "the screen must be lowered before the projector is turned on"), cooling time (such as "air conditioning mode switching interval ≥ 30 seconds"), and preheating time (such as "the bulb needs 2 seconds to reach stable brightness").

[0036] After the device agent receives the intent subgraph, it matches the control objectives of each intent node in the intent subgraph with the capability matrix, finds the device corresponding to the controllable parameters and control objectives, and checks whether the current device status meets the preconditions and constraints in the execution constraint set. If it does, it generates a feasible execution plan that includes execution parameters and estimated execution time (the median of the device's historical execution time). If it does not meet the requirements, it reports the unmet constraint information (such as "projector is currently malfunctioning" or "air conditioner is cooling, please wait 15 seconds").

[0037] When the device agent sends control commands to the physical device, it adopts an exponential backoff retry strategy: the preset initial interval is 1 to 2 seconds. After the first failure, it waits for the initial interval to retry. The waiting time for each retry doubles, and it can be retried up to 3 times. After all failures, the execution failure is reported to the execution monitoring module. During the retry period, the sending of commands to other devices is not blocked, so as to ensure the efficiency of parallel execution.

[0038] Device agents from different brands communicate through a unified semantic interface layer. This layer converts control commands from each brand's proprietary protocols into standard semantic actions, which include four fields: device identifier (device_id), target parameter (param_name), parameter value (target_value), and time window (time_window). When a new brand device is added, only the capability matrix and the mapping rules from the proprietary protocol to the semantic interface layer for that brand's device agent need to be registered. No modification to other device agents or the collaborative scheduling module is required, enabling plug-and-play functionality across different brands.

[0039] When the edge gateway detects a connection interruption with the cloud platform, the device agent retrieves the currently incomplete global execution plan from the local instruction cache and executes the control instructions for its own brand of devices sequentially according to the timing in the cached plan. After the cached plan is completed, new control requests from users are downgraded to direct control of the single-brand device (without going through the intent understanding module and the collaborative scheduling module) until the network is restored. After the network is restored, the device status and user operation records during the network outage are synchronized to the cloud platform.

[0040] In this embodiment, as Figure 3 As shown, the multi-objective optimization and degradation process of the collaborative scheduling module is as follows: After receiving the feasible execution plans reported by each device agent, the collaborative scheduling module first performs global temporal orchestration based on the implicit dependency edges in the intent graph. The implicit dependency edges are transformed into a directed acyclic graph (DAG), and the global temporal sequence of each execution action is determined through topological sorting. If a loop exists (which should not occur but requires fault tolerance), the edge with the weakest dependency strength is removed to break the loop, and this information is fed back to the intent understanding module to correct the intent graph.

[0041] Global execution plan To optimize variables, solve a multi-objective optimization problem. Each objective function is first calculated as its original value and then normalized: To perform the action Execution time To perform the action From completion to execution of action Waiting time before starting This is the set of action pairs that have waiting constraints.

[0042] This refers to the set of action pairs with overlapping time windows in the global execution plan. This is the conflict penalty coefficient. For indicator functions, when and If there is a conflict, take 1; otherwise, take 0.

[0043] To perform the action The estimated energy consumption.

[0044] The normalization method involves dividing each objective function by its corresponding theoretical maximum value, ensuring that the range of values ​​for each normalized objective function is within the theoretical maximum value. : in The total time for all actions to be executed sequentially. This is the sum of penalties when all actions conflict. This represents the total energy consumption of all devices operating at maximum power simultaneously. Normalization eliminates dimensional differences, ensuring that each objective function has comparable physical meaning when weighted and summed.

[0045] The constraints include the temporal order constraints corresponding to implicitly dependent edges. ,in ), parameter value range constraints in the capability vector and equipment state transition constraints (such as air conditioners cannot cool and heat at the same time).

[0046] The normalized multi-objective model is transformed into a single objective using a weighted summation method. The mapping rule for the weight coefficients is as follows: the objective function corresponding to the safety category has the highest weight coefficient, followed by the comfort category, and the entertainment category has the lowest weight coefficient; within the same category, the weight coefficients of each objective function are allocated according to the ratio of execution time: conflict: energy consumption = 2:3:1.

[0047] Time-limited solution and degradation strategy: setting a solution time limit (Default 3 seconds). In The algorithm performs multi-objective optimization and outputs an optimized global execution plan. If the optimization times out, it degrades to a greedy scheduling algorithm: First, it performs topological sorting on the intent graph to obtain the global execution order. Then, it traverses the intent nodes from highest to lowest priority, arranging intent nodes of the same priority in topological order. Each execution action is then assigned to the earliest available time slot that satisfies its dependency constraints. If the time slot is already occupied, it is postponed to the next available time slot until all execution actions have been scheduled. The plan generated by the greedy scheduling algorithm still needs to pass conflict detection to ensure that there are no contradictory instructions.

[0048] Conflict detection and resolution: For any two execution actions in the global execution plan and A conflict is identified when any of the following conditions are met: The target devices for the two actions are the same but their target states are different (e.g., an air conditioner simultaneously receives "cooling 26℃" and "heating 22℃"); the time windows of the two actions overlap and they compete for shared resources (e.g., two scenarios simultaneously require the use of the same audio output); the combined effect of the two actions violates pre-stored physical constraints, which are mutual exclusion constraints between devices, including that cooling and heating modes cannot be activated simultaneously in the same space, and that the same audio device cannot simultaneously output audio from two scenarios. The conflict resolution method is as follows: weighted negotiation is performed based on the priority of each intent node, prioritizing the actions with higher priority. When priorities are the same, the action with the earlier completion time in the dependency chain is retained. After resolution, the discarded actions are recorded as "pending confirmation," and the user is prompted to confirm whether they need to be overwritten.

[0049] In this embodiment, the primary alternative execution path is generated as follows: for the execution action... Target equipment Check them in the following order.

[0050] First, check if there are functionally equivalent and currently available alternative equipment combinations within the same space. Functional equivalence is defined by the functional complementarity relationships in the equipment ontology knowledge graph, rather than requiring the equipment types to be exactly the same. For example, if the main light is unavailable, an ambient light + table lamp combination can provide equivalent lighting; if the air conditioner is malfunctioning, a fan + window opening combination can provide cooling.

[0051] If no functionally equivalent alternative exists, check if the target parameter has a achievable degraded value that is closest to the target value. When the target parameter value is unattainable, select the closest achievable value within the parameter's range as the degraded parameter value. For example, if the target brightness of 20% is unattainable, and the closest achievable value is 25%, then the value will be degraded to 25%.

[0052] The option with the smallest deviation from the original execution action and which is available on the equipment is selected as the primary alternative execution path. The deviation is measured by the deviation metric. Calculation, where These are the original target parameter values. As alternative target parameter values, This refers to the width of the value range for this parameter. For parameter deviation weights, Replace the weights for the device. This is an indicator function for whether the device needs to be replaced.

[0053] The secondary degradation strategy is as follows: When the primary alternative execution path is unavailable, the intent nodes are categorized and processed according to their priority. Intents other than those related to security (intents involving security, fire protection, and gas equipment control) are considered non-security intents. If the priority of the intent node corresponding to the execution action is non-essential (non-security intent), the execution action is skipped, marked as "skipped," and the user is notified. If the priority of the intent node corresponding to the execution action is essential (security intent), the action is not skipped, marked as "execution failed," and the user is immediately notified to intervene manually.

[0054] like Figure 4 As shown in the figure, this embodiment details the deviation detection and dynamic timeout mechanism of the execution monitoring module.

[0055] For each executed action in the global execution plan, the execution monitoring module calculates the state deviation between the actual device state and the expected device state. in, For the first The actual device state vector after each execution action is performed. For the first The expected device state vector for each action to be performed, when When the preset deviation threshold is exceeded, it is determined that there is an execution deviation in the execution action, and the corresponding first-level alternative execution path is triggered; if the first-level alternative is unavailable, the second-level degradation strategy is triggered.

[0056] To accommodate differences in execution time across different devices and fluctuations in network latency, the execution monitoring module sets dynamic timeout thresholds for each execution action: in, To perform the action The estimated execution time is reported by the device agent based on the median historical execution time of the device. The execution duration tolerance factor (default 1.5). This represents the current average network latency from the cloud to the device. The standard deviation of the current network latency. and The round-trip time (RTT) for commands is calculated based on the most recent preset number of times (default 20). When network latency fluctuates significantly (…), the calculation is affected. When the network jitter occurs, the dynamic timeout threshold automatically increases to avoid false timeouts caused by network jitter.

[0057] When the action is issued, more than If no device status update is received, it is determined that the execution has timed out and the first-level alternative execution path is triggered; if the first level is unavailable, the second-level degradation strategy is triggered.

[0058] If the target device is detected as offline before the execution plan is issued, the execution action corresponding to the device is skipped and the first-level alternative execution path is used instead; if the first-level alternative is unavailable, the second-level degradation strategy is triggered; if there is no alternative, the device is marked as "device unreachable" and the user is notified.

[0059] like Figure 5 As shown in the figure, this embodiment details the mechanism by which the execution monitoring module collects user feedback and drives the gradual adjustment of the collaborative scheduling strategy.

[0060] User feedback includes two categories: explicit feedback, which is the user's evaluation of the execution result (satisfied / unsatisfied / partially adjusted); and implicit feedback, which is the record of the user manually adjusting the device parameters after automated execution.

[0061] When the system starts, the weight coefficients of the collaborative scheduling module adopt a preset safety rule strategy: the weight coefficients of safety-related intentions are fixed at the highest level and cannot be adjusted. The safety-related intentions include intentions involving security, fire protection, and gas equipment control; the weight coefficients of comfort-related and entertainment-related intentions adopt empirical default values; the priority of alternative execution paths is sorted according to "functional equivalent substitution > parameter reachability degradation > skip".

[0062] When the cumulative number of feedback samples reaches the preset adjustment threshold After (default 50 times), enable data-driven weight fine-tuning. Build three evaluation metrics based on user feedback: user satisfaction. (Obtained by inverse quantification of explicit feedback scores and the magnitude of manual adjustments in implicit feedback), Execution success rate (Percentage of successfully executed actions in the global execution plan), energy efficiency (The total energy consumption for this execution was normalized). The three factors were then weighted and combined to form a comprehensive score. in This is the satisfaction weighting coefficient. This is the success rate weighting coefficient. This is the energy consumption weighting coefficient. A comprehensive score is calculated and grouped by scenario category. For scenarios with scores consistently below the average, a fixed step size is applied. (Default 0.05) Fine-tune the weighting coefficients of non-safe intents in this scenario. Verify after each adjustment: When new feedback arrives, check if the overall score of the adjusted scenario has improved. If it continues... If the score does not improve after 5 attempts (default), it will revert to the previous weight.

[0063] The security boundary settings are as follows: the weight coefficient of security intents cannot be adjusted and is always at the highest level; the single adjustment of the weight coefficient shall not exceed [a certain value]. (Default 0.1); The cumulative adjustment of the weighting coefficient shall not exceed (Default 0.3) If the value is exceeded, the weight will be locked and can only be unlocked with explicit user confirmation; if the success rate drops by more than 10% after adjustment, it will automatically revert to the security rule policy.

[0064] Convergence guarantee mechanism: Set an upper limit on the cumulative number of adjustments per scenario. (Default 10 times) When the cumulative number of adjustments in a single scene reaches... Stop adjusting the weights for that scenario; set a cooldown period between two consecutive adjustments. (Default 24 hours) to avoid frequent adjustments that could cause oscillations. After the cooldown period ends, if the overall score for the scenario is still below the average, adjustments will resume and the adjustment counter will be reset.

[0065] The device ontology knowledge graph is constructed as follows: Initial graphs are built using device categories as nodes (e.g., "TV", "Air Conditioner", "Curtains", "Lights", "Audio") and functional relationships between device categories as edges. Functional relationships include: spatial co-location (e.g., "TV" and "Audio" are usually in the same room), complementary functions (e.g., "Closing Curtains" and "Dim Lights" are complementary in a movie-watching scenario), functional equivalence (e.g., "Main Light" and "Ambient Light + Table Lamp" are equivalent in lighting function), and mutually exclusive operations (e.g., "Heating Mode" and "Cooling Mode" are mutually exclusive).

[0066] The device ontology knowledge graph also includes a pre-built typical scenario rule base, which stores the dependency edge set and constraint conditions of device operations under typical scenarios (watching movies, sleeping, leaving home, getting up, meeting guests, etc.), for implicit dependency discovery during the cold start phase. The pre-built scenario rules are constructed from domain knowledge, covering common home scenarios, ensuring that the system can provide basic implicit dependency reasoning capabilities from zero startup.

[0067] Dynamic update mechanism: When the matching degree between a certain device operation sequence in a user's historical execution record and existing scenario rules is lower than a preset threshold (e.g., the actual execution order of the user deviates from the preset rule by more than 30%), and the frequency of this deviation exceeds a preset number (default 10 times), a new execution order pattern is added to the knowledge graph as a candidate rule. Candidate rules must be confirmed by the user before becoming formal rules to avoid polluting the knowledge graph with noisy data.

[0068] When a new device type is added, a corresponding node is automatically created in the knowledge graph through the mapping rules of the semantic interface layer, and functional association edges are automatically established based on the structured functional description of the device. The structured functional description includes four fields: device category (such as "lighting", "air conditioning", "curtains"), list of controllable parameters (such as "brightness [0,100]%, color temperature [2700,6500]K" for lighting), space (such as "living room" or "bedroom"), and functional tags (such as "lighting", "temperature control", or "shading").

[0069] The rules for establishing functional association edges are as follows: establish complementary functional edges with nodes whose functional labels intersect with existing nodes; establish spatial co-location edges with nodes belonging to the same space; establish mutually exclusive operation edges with nodes whose functional labels are mutually exclusive; and establish functionally equivalent edges with nodes whose functional labels completely contain each other.

[0070] The foregoing has shown and described the basic principles, main features, and advantages of the present invention. Those skilled in the art should understand that the present invention is not limited to the above embodiments. The embodiments and descriptions in the specification are merely principles of the invention. Various changes and modifications can be made to the invention without departing from its spirit and scope, and all such changes and modifications fall within the scope of the claimed invention. The scope of protection claimed by the appended claims and their equivalents is defined.

Claims

1. A cloud-based smart home cross-device collaborative control system, characterized in that, include: The intent understanding module is used to receive the user's control request, perform intent parsing on the control request based on a pre-built device ontology knowledge graph, and obtain an explicit intent node set. Each explicit intent node in the explicit intent node set is a device control target directly obtained by semantic parsing the control request. An intent graph is constructed based on the explicit intent node set and the device ontology knowledge graph. The intent graph also includes an implicit dependency edge set and a constraint set between the explicit intent nodes. Each dependency edge in the implicit dependency edge set represents the execution order constraint between two intent nodes. The constraint set includes temporal constraints, spatial constraints, and priority constraints. Specifically, when the frequency of occurrence of explicit intent nodes in the historical execution record is lower than the preset data sufficiency threshold, the intent understanding module matches the current control request to the scene from the preset scene rule base of the device ontology knowledge graph, and obtains the set of dependency edges and constraints under that scene; when the frequency of occurrence of explicit intent nodes in the historical execution record reaches the preset data sufficiency threshold, the intent understanding module calculates implicit dependency edges based on the temporal dependency strength between explicit intent nodes. The preset data sufficiency threshold is determined as follows: when the frequency of occurrence of explicit intent nodes in the historical execution record makes the width of the binomial distribution information interval corresponding to that frequency less than the preset accuracy requirement, the data is deemed sufficient. The multi-brand device agent layer includes multiple device agents corresponding to each device brand. Each device agent is used to receive the intent subgraph distributed by the intent understanding module, match the intent nodes in the intent subgraph based on the capability vector of the agent brand device, generate a feasible execution plan and report it. The capability vector describes the controllable parameters of the agent brand device and the corresponding value range. Each device agent also maintains a local instruction cache, which is used to retrieve incomplete global execution plans from the cache for local degradation execution when the network is down. The collaborative scheduling module is used to receive feasible execution plans reported by each device agent, perform global timing orchestration on each feasible execution plan based on the implicit dependency edges in the intent graph, generate a global execution plan through multi-objective optimization within a preset solution time limit, and if the solution timeout occurs, it will degrade to greedy scheduling to generate a feasible execution plan. The global execution plan includes the execution sequence, execution parameters and alternative execution paths of each device. The execution monitoring module is used to monitor the execution progress of the global execution plan. When an execution deviation or execution failure is detected, the corresponding first-level alternative execution path or second-level degradation strategy is triggered. When the connection with the cloud platform is interrupted, each device agent is notified to retrieve the incomplete global execution plan from the local instruction cache for local degradation execution.

2. The cloud-based smart home cross-device collaborative control system according to claim 1, characterized in that: When the frequency of explicit intent nodes appearing in the historical execution records reaches the preset data sufficiency threshold, the intent understanding module calculates the explicit intent nodes. Pointing to explicit intent node Temporal dependency strength in, For the first An explicit intent node. For the first An explicit intent node. for The context vector, by The semantic embedding vector of the target device category is concatenated with the current environment state vector. for The context vector is constructed in the same way as... , The cosine similarity function is used. For historical execution records exist The frequency of previous executions for Frequency of occurrence in historical execution records; when When the preset dependency threshold is exceeded, establish a dependency from point to Implicit dependency edges, representing Must be in Previously, when some explicit intent nodes meet the statistical conditions while others do not, the dependency edges discovered by the statistical method are combined with the dependency edges derived from the pre-defined scenario rules. The dependency edges discovered by the statistical method have a higher priority than the dependency edges derived from the pre-defined scenario rules.

3. The cloud-based smart home cross-device collaborative control system according to claim 1, characterized in that: Each device agent maintains the capability matrix and execution constraint set of the brand devices it represents. Each row of the capability matrix corresponds to a device, and each column corresponds to a controllable parameter and its value range. After the device agent receives the intent subgraph, it matches the control objectives of each intent node in the intent subgraph with the capability matrix, checks whether the current device status meets the preconditions and constraints in the execution constraint set, and generates a feasible execution plan containing execution parameters and estimated execution time if it does not meet the requirements. If it does not meet the requirements, it reports the constraint information that is not met. When the device agent sends control commands to the physical device, it adopts an exponential backoff retry strategy. The initial interval is preset to 1 to 2 seconds. The waiting time for each retry is doubled. The maximum number of retries is 3. After all retries fail, the execution failure is reported to the execution monitoring module.

4. The cloud-based smart home cross-device collaborative control system according to claim 3, characterized in that: Device agents from different brands communicate through a unified semantic interface layer. This semantic interface layer converts the control commands of each brand's proprietary protocol into standard semantic actions. The standard semantic actions include four fields: device identifier, target parameter, parameter value, and time window. When a new brand device is added, only the capability matrix of the brand device agent and the mapping rules from the private protocol to the semantic interface layer need to be registered. There is no need to modify other device agents or collaborative scheduling modules.

5. The cloud-based smart home cross-device collaborative control system according to claim 1, characterized in that: The collaborative scheduling module generates a global execution plan through multi-objective optimization in the following way: using the global execution plan... To optimize variables, solve a multi-objective optimization problem. in, To normalize the total execution time, To normalize conflict penalties, To normalize the total energy consumption, the normalization method for each objective function is to divide the objective function value by the corresponding theoretical maximum value, so that the range of values ​​for each normalized objective function is [missing value]. ; In the formula, To perform the action Execution time To perform the action From completion to execution of action Waiting time before starting For a set of action pairs that have waiting constraints; In the formula, This refers to the set of action pairs with overlapping time windows in the global execution plan. This is the conflict penalty coefficient. For indicator functions; In the formula, To perform the action Estimated energy consumption; The constraints include the temporal order constraints corresponding to the implicit dependency edges, the parameter value range constraints in the capability vector, and the device state transition constraints; the normalized multi-objective is transformed into a single objective using a weighted summation method, and the mapping rule for the weight coefficients is as follows: the objective function corresponding to the safety intention has the highest weight coefficient, followed by the comfort intention, and the entertainment intention has the lowest weight coefficient. The weight coefficients of each objective function within the same category are allocated according to the ratio of execution time: conflict: energy consumption = 2:3:

1. If the solution is not completed within the preset time limit, the algorithm will be downgraded to greedy scheduling: First, the intent graph will be topologically sorted to obtain the global execution order. Then, the intent nodes will be traversed from high to low priority. For intent nodes of the same priority, they will be arranged in topological order. Each execution action will be scheduled to the earliest available time slot that satisfies its dependency constraints. If the time slot is occupied, it will be postponed to the next free time slot until all execution actions have been scheduled.

6. The cloud-based smart home cross-device collaborative control system according to claim 5, characterized in that: The collaborative scheduling module is also used for conflict detection and resolution: for any two execution actions in the global execution plan... and A conflict is determined when any of the following conditions are met: the target devices of the two actions are the same but the target states are different; the time windows of the two actions overlap and they compete for shared resources; the combined effect of the two actions violates the pre-stored physical constraints. The pre-stored physical constraints are physical mutual exclusion constraints between devices, including that the cooling mode and the heating mode cannot be turned on at the same time in the same space, and the same audio device cannot output audio from two scenes at the same time. The conflict resolution method is as follows: weighted negotiation is performed based on the priority of each intent node, and the execution action with higher priority is retained first. When the priorities are the same, the execution action with the earlier completion time of the dependency chain is retained.

7. The cloud-based smart home cross-device collaborative control system according to claim 1, characterized in that: The collaborative scheduling module pre-generates a primary alternative execution path and a secondary degradation strategy for each execution action in the global execution plan; the primary alternative execution path is generated as follows: for each execution action... Target equipment The following steps are performed in sequence: First, check if there is a functionally equivalent and currently available alternative device combination in the same space. If so, select the functionally equivalent alternative. If it does not exist, check if the target parameter has a reachable degradation value that is closest to the target value; The option with the smallest deviation from the original execution action and which is available on the device is selected as the primary alternative execution path. The deviation is measured by the deviation metric. Calculation, where These are the original target parameter values. As alternative target parameter values, This refers to the width of the value range for this parameter. For parameter deviation weights, Replace the weights for the devices; The functional equivalence relationship is defined by the functional complementarity relationship in the device ontology knowledge graph; the secondary degradation strategy is as follows: when the primary alternative execution path is unavailable, if the priority of the intent node corresponding to the execution action is non-necessary, the execution action is skipped and the user is notified; if the priority is necessary, it is marked as execution failure and the user is notified to intervene manually. The security-related intentions include those related to security, fire protection, and gas equipment control; intentions other than those related to security are considered non-security-related intentions.

8. The cloud-based smart home cross-device collaborative control system according to claim 1, characterized in that: The deviation detection method of the execution monitoring module is as follows: for each executed action in the global execution plan, calculate the state deviation between the actual device state and the expected device state. in For the first The actual device state vector after each execution action is performed. For the first The expected device state vector for each action to be performed; when When the preset deviation threshold is exceeded, the execution action is determined to have an execution deviation, triggering the corresponding first-level alternative execution path. If the first-level alternative is unavailable, a second-level degradation strategy is triggered. The execution monitoring module also sets a dynamic timeout threshold for each execution action. in To perform the action The estimated execution time is reported by the device agent based on the median historical execution time of the device. To determine the execution duration tolerance factor, This represents the current average network latency from the cloud to the device. The standard deviation of the current network latency. and Based on the statistical calculation of the round-trip time of command issuance and response based on the most recent preset number of commands; when the execution action exceeds... If no device status update is received, it is determined to be an execution timeout, triggering the first-level alternative execution path or the second-level degradation strategy.

9. The cloud-based smart home cross-device collaborative control system according to claim 8, characterized in that: The execution monitoring module is also used to collect user feedback and drive the gradual adjustment of the collaborative scheduling strategy: user feedback includes explicit feedback and implicit feedback. The explicit feedback is the user's evaluation of the execution result, and the implicit feedback is the user's record of manually adjusting the device parameters after automated execution. When the system starts, the weight coefficient of the collaborative scheduling module adopts a preset security rule strategy. The weight coefficient of security-related intentions is fixed at the highest level and cannot be adjusted. The security-related intentions include intentions involving security, fire protection, and gas equipment control. Once the cumulative number of feedback samples reaches the preset adjustment threshold, the comprehensive score is statistically analyzed by grouping according to the scenario category. For scenarios whose scores are consistently lower than the average, the weight coefficient of non-safety intents in that scenario is finely adjusted with a fixed step size. After each adjustment, verify whether the overall score has improved. If the score does not improve after a preset number of consecutive times, revert to the previous weight. The single adjustment of the weight coefficient shall not exceed the preset maximum step size, and the cumulative adjustment shall not exceed the preset total limit. If it exceeds the limit, the weight shall be locked until the user explicitly confirms the unlock. When the success rate of the adjusted operation drops below a preset percentage, it will automatically revert to the security rule policy. The progressive adjustment also includes an upper limit on the cumulative number of adjustments for a single scenario and a cooling-off period between two adjacent adjustments. When the cumulative number of adjustments for a single scenario reaches the upper limit, the weight adjustment for that scenario is stopped and a cooling-off period begins. If the overall score is still lower than the average after the cooling-off period, the adjustment is resumed.

10. The cloud-based smart home cross-device collaborative control system according to claim 1, characterized in that: The device ontology knowledge graph is constructed as follows: an initial graph is constructed with device categories as nodes and functional relationships between device categories as edges. The functional relationships include spatial co-location relationships, functional complementary relationships, functional equivalence relationships, and operational mutual exclusion relationships. The device ontology knowledge graph also includes a pre-set typical scenario rule base, which stores the dependency edge set and constraint conditions of device operations under typical scenarios, and is used for implicit dependency discovery during the cold start phase. When the matching degree between a certain device operation sequence in the user's historical execution record and the existing scenario rule is lower than a preset threshold and the frequency of this deviation exceeds a preset number, a new execution order pattern is added to the knowledge graph as a candidate rule. The candidate rule is converted into a formal rule after being confirmed by the user. When a new device type is added, a corresponding node is automatically created in the knowledge graph through the mapping rules of the semantic interface layer, and functional association edges are automatically established based on the structured functional description of the device. The structured functional description includes four fields: device category, list of controllable parameters, belonging space, and functional label. The rules for establishing functional association edges are as follows: establish complementary functional edges with nodes whose functional labels intersect with existing nodes; establish spatial co-location edges with nodes belonging to the same space; establish mutually exclusive operation edges with nodes whose functional labels are mutually exclusive; and establish functional equivalent edges with nodes whose functional labels completely contain each other.

Images