A heterogeneous logical entity orchestration method and system based on a semantic bus

Abstract

This invention discloses a heterogeneous logical entity orchestration method and system based on a semantic bus. The method includes: encapsulating multiple functional logics into logical entity containers with semantic description lists; actively registering these logical entity containers at runtime via a semantic service bus; abstracting each logical entity container as a software capability node and each hardware execution entity as a hardware capability node through the semantic service bus, forming a global capability mapping table; selecting a matching software capability node based on user intent using a task orchestration engine and constructing a dynamic task chain; and sequentially triggering the logical entity containers corresponding to the software capability nodes according to the task chain order. During execution, the triggered logical entity containers call their dependent hardware execution entities, progressing step-by-step until the task is completed. This invention achieves semantic encapsulation and hot-swappable management of logical entities, improving the flexibility and scalability of edge intelligent systems.

Description

Technical Field

[0001] This invention relates to the field of edge intelligent computing technology, and more specifically, to a method and system for orchestrating heterogeneous logical entities based on a semantic bus. Background Technology

[0002] With the rapid development of IoT and AI technologies, edge intelligence systems have been widely applied in smart homes, industrial automation, smart cities, and other fields. In a typical edge intelligence architecture, the smart gateway or edge controller is responsible for coordinating various sensor devices, actuator devices, and the AI ​​algorithm models running on them to provide users with automated and intelligent service experiences.

[0003] Currently, the mainstream approach to implementing automation logic in edge intelligence systems is to use rule engines, such as automation rule configuration based on the IFTTT (If This Then That) model. In this technical solution, automation rules are typically predefined by developers or users during the system development or deployment configuration phase and stored in the system's private database as structured data. During system runtime, the rule engine periodically polls or is triggered by events to check whether the rule conditions are met; if so, it executes the corresponding action sequence. The main advantages of this approach are high execution efficiency, clear and controllable logic, and suitability for automation scenarios with relatively fixed functional requirements.

[0004] However, as edge intelligence systems evolve towards openness, dynamism, and intelligence, the aforementioned existing technical solutions have revealed several significant technical defects, which are analyzed in detail below.

[0005] First, there's the issue of static logic. In existing technical solutions, automation rules are hardcoded during development or configuration, lacking dynamic extensibility at runtime. When adding new automation logic, modifying existing logic, or deleting unnecessary logic, it often requires modifying configuration files or even rewriting code, followed by restarting the entire business process for the changes to take effect. This static logic management severely restricts system flexibility and cannot meet the demands of rapid iteration and dynamic adaptation in edge computing scenarios. More importantly, the system kernel and the AI ​​agents running on it cannot dynamically perceive newly added complex capabilities at runtime, forcing the agents to make decisions based only on a pre-defined set of capabilities, making true autonomous intelligence difficult to achieve.

[0006] Second, there is the issue of a mismatch between software and hardware calls. In traditional edge intelligence system architectures, calling hardware drivers (e.g., reading sensor data, controlling actuator actions) and executing software workflows (e.g., running data analysis scripts, calling algorithm models) follow completely different technical paths. Hardware calls are typically implemented through hardware abstraction layers or device driver interfaces, while software calls are completed through inter-process communication or function calls. The consequence of this architectural design is that AI agents face logical confusion when orchestrating tasks—they cannot understand and schedule software and hardware capabilities in a unified way, leading to inherent obstacles in the overall scheduling of complex tasks. For example, a task that requires simultaneously calling temperature sensor reading capabilities and temperature data analysis capabilities would require the agent to handle two completely different call semantics in a traditional architecture, increasing orchestration complexity and the probability of errors.

[0007] Third, there is a lack of lifecycle management capabilities. In existing technical solutions, adding, modifying, or deleting logic scripts or rules usually requires restarting the entire business process to take effect, unlike the plug-and-play functionality of hardware devices. Hardware devices can be dynamically added or removed during system runtime through hot-swapping mechanisms, while changes to software logic require interrupting business operations. This asymmetrical lifecycle management capability limits the system's continuous service capabilities and dynamic evolution capabilities.

[0008] Fourth, there is a lack of self-healing mechanisms. In existing rule engine solutions, when a logical module fails due to an anomaly, the system lacks the ability to automatically find alternative solutions. For example, if a workflow script used for temperature control cannot be executed due to a corrupted algorithm model, the system typically only logs the error and terminates the task, without actively seeking other semantically similar logical entities to replace it in achieving the temperature control objective. This deficiency directly affects the service continuity and robustness of edge intelligent systems in complex environments.

[0009] In summary, existing technical solutions have significant shortcomings in terms of logical dynamic management, unified hardware and software scheduling, lifecycle management, and service self-healing, and a new technical solution is urgently needed to solve these problems. Summary of the Invention

[0010] This invention provides a heterogeneous logical entity orchestration method and system based on a semantic bus to solve the technical problems of static logic, asymmetric software and hardware calls, lack of lifecycle management, and lack of self-healing mechanism in the prior art.

[0011] To achieve the above objectives, on the one hand, the present invention provides a heterogeneous logical entity orchestration method based on a semantic bus. The method includes: S1, encapsulating multiple predefined functional logics into logical entity containers with semantic description lists, wherein the semantic description list of each logical entity container includes the intent fingerprint, resource dependency declaration, and interface protocol of the logical entity container; S2, the multiple logical entity containers actively registering themselves through a semantic service bus at runtime; S3, the semantic service bus abstracting each registered logical entity container into a software capability node and each hardware execution entity into a hardware capability node, wherein the software capability nodes and the hardware capability nodes together constitute... S4. The task orchestration engine performs intent matching in the global capability mapping table based on the received user intent. Based on the matching result, it selects a matching software capability node from the global capability mapping table and constructs a dynamic task chain based on the dependency relationship between the software capability node and its dependent hardware capability nodes. S5. The task orchestration engine triggers the logical entity containers corresponding to the software capability nodes in the dynamic task chain in sequence. During the execution of the triggered logical entity containers, the hardware execution entities corresponding to the hardware capability nodes that the dynamic task chain depends on call the hardware execution entities in the execution process. The process proceeds step by step according to the dependency relationship of the dynamic task chain until the complete task corresponding to the user intent is completed.

[0012] Optionally, when the matching result of the user intent returns multiple matching software capability nodes, the semantic service bus performs conflict arbitration based on preset semantic priorities and the current scenario context, and selects one software capability node from the multiple matching software capability nodes as the execution node. The task orchestration engine constructs a dynamic task chain based on the selected software capability node. The semantic priorities include system-level priorities, user-defined priorities, and dynamic priorities based on historical success rates. The scenario context includes the current time, user location, device status, and other task information being executed.

[0013] Optionally, when any software capability node in the dynamic task chain calls another software capability node during execution, the semantic service bus maintains a call stack for the dynamic task chain and checks whether the called software capability node already exists in the call stack before initiating the call. If it does not exist, the call is allowed and the called software capability node is pushed onto the call stack. If it already exists, it is determined to be a potential infinite loop, the call is rejected and an alarm is issued.

[0014] Optionally, each logical entity container supports heterogeneous forms, including Python script forms, JSON-described workflow forms, and C or C++ compiled algorithm module forms.

[0015] Optionally, before the triggered logical entity container calls the hardware execution entity corresponding to the hardware capability node that the dynamic task chain depends on during execution, the method further includes: the semantic service bus dynamically grants the logical entity container a temporary permission token to access the corresponding hardware execution entity based on the hardware permission requirements declared in the resource dependency declaration of the logical entity container; after the logical entity container completes the call with the token, the semantic service bus reclaims the temporary permission token.

[0016] Optionally, the multiple logical entity containers actively registering themselves via the semantic service bus during runtime includes: each logical entity container sending a registration message to the semantic service bus containing its intent fingerprint, resource permission requirements, and interface protocol; upon receiving the registration message, the semantic service bus stores the intent fingerprint of the logical entity container in the global capability pool and establishes a mapping relationship between the intent fingerprint and the address of the logical entity container; when any logical entity container stops or updates, it sends a deregistration message to the semantic service bus, and upon receiving it, the semantic service bus deletes the intent fingerprint of the logical entity container from the global capability pool and cancels the mapping relationship between the intent fingerprint and the address of the logical entity container.

[0017] Optionally, the step-by-step progression according to the dependencies of the dynamic task chain until the complete task corresponding to the user intent is completed further includes: when the triggered logical entity container fails, the semantic service bus searches for the logical entity container corresponding to the alternative software capability node from the global capability mapping table based on semantic similarity to replace it for execution.

[0018] On the other hand, this invention provides a heterogeneous logical entity orchestration system based on a semantic bus. The system includes: an encapsulation unit for encapsulating multiple predefined functional logics into logical entity containers with semantic description lists, each logical entity container's semantic description list including its intent fingerprint, resource dependency declaration, and interface protocol; a registration unit for the multiple logical entity containers to actively register themselves via the semantic service bus at runtime; and an abstraction unit for the semantic service bus to abstract each registered logical entity container into a software capability node and each hardware execution entity into a hardware capability node, the software capability nodes and the hardware capability nodes together constituting a complete system. The system comprises: a global capability mapping table; a matching unit, used by the task orchestration engine to match received user intents in the global capability mapping table, select a matching software capability node from the global capability mapping table based on the matching result, and construct a dynamic task chain based on the dependency relationship between the software capability node and its dependent hardware capability nodes; and an execution unit, used by the task orchestration engine to sequentially trigger the logical entity containers corresponding to the software capability nodes in the dynamic task chain. During execution, the triggered logical entity containers call the hardware execution entities corresponding to the hardware capability nodes that the dynamic task chain depends on, and proceed step by step according to the dependency relationship of the dynamic task chain until the complete task corresponding to the user intent is completed.

[0019] Optionally, when the matching result of the user intent returns multiple matching software capability nodes, the semantic service bus performs conflict arbitration based on preset semantic priorities and the current scenario context, and selects one software capability node from the multiple matching software capability nodes as the execution node. The task orchestration engine constructs a dynamic task chain based on the selected software capability node. The semantic priorities include system-level priorities, user-defined priorities, and dynamic priorities based on historical success rates. The scenario context includes the current time, user location, device status, and other task information being executed.

[0020] Optionally, when any software capability node in the dynamic task chain calls another software capability node during execution, the semantic service bus maintains a call stack for the dynamic task chain and checks whether the called software capability node already exists in the call stack before initiating the call. If it does not exist, the call is allowed and the called software capability node is pushed onto the call stack. If it already exists, it is determined to be a potential infinite loop, the call is rejected and an alarm is issued.

[0021] The beneficial effects of this invention are: This invention provides a heterogeneous logical entity orchestration method and system based on a semantic bus. The method encapsulates multiple predefined functional logics into logical entity containers, each containing a semantic description list with intent fingerprints, resource dependency declarations, and interface protocols. These containers are then actively registered at runtime via a semantic service bus. This achieves semantic encapsulation and hot-swappable management of logical entities, enabling the system kernel and AI agents to dynamically perceive newly added complex capabilities at runtime. Adding, modifying, or deleting logic does not require restarting the business process, completely solving the shortcomings of static logic and lack of lifecycle management in existing technologies. Furthermore, this invention uses a semantic service bus to encapsulate registered logical entities... Logical entity containers are abstracted as software capability nodes, and hardware execution entities are abstracted as hardware capability nodes. Together, they form a global capability mapping table, realizing the equal abstraction of software logic and hardware capabilities. The task orchestration engine performs intent matching and scheduling in a unified manner, breaking down the barrier of separating software and hardware call paths in traditional architectures and solving the technical problem of asymmetric software and hardware calls. In addition, this invention constructs a dynamic task chain and advances execution step by step according to dependencies. When a logical entity fails, the semantic service bus can find alternative logical entities based on semantic similarity, providing logical self-healing capability for edge intelligent systems and ensuring service continuity and robustness. Attached Figure Description

[0022] Figure 1 This is a flowchart of a heterogeneous logical entity orchestration method based on a semantic bus provided by an embodiment of the present invention; Figure 2 This is a schematic diagram of the structure of a heterogeneous logical entity orchestration system based on a semantic bus, provided by an embodiment of the present invention. Detailed Implementation

[0023] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this invention, and not all of them. Based on the embodiments of this invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this invention.

[0024] Figure 1 This is a flowchart of a heterogeneous logical entity orchestration method based on a semantic bus, provided by an embodiment of the present invention; as follows: Figure 1 As shown, the method includes: S1. Encapsulate multiple predefined functional logics into logical entity containers with semantic description lists. The semantic description list of each logical entity container includes the intent fingerprint, resource dependency declaration, and interface protocol of the logical entity container. The purpose of this step is to encapsulate the functional logic, which is scattered across different locations and written using different technologies, into a unified logical entity container with a standardized semantic description list. In traditional solutions, functional logic exists as fragmented scripts, configuration files, or compiled libraries, which the semantic service bus and AI agents cannot understand what each can do, what resources it needs, or how to invoke. This invention uses semantic packaging encapsulation technology to create an "instruction manual," or semantic description list, for each functional logic, which is then encapsulated to form a logical entity container. The semantic description list of this logical entity container includes three core elements.

[0025] The first core element is the intent fingerprint. An intent fingerprint is a natural language description of what problem the logical entity container can solve, such as "assess the comfort of the living room environment and provide adjustment suggestions." The intent fingerprint can also be accompanied by a set of semantic tags, such as keywords like "environmental monitoring," "comfort assessment," and "living room," to support more granular semantic matching. Through intent fingerprints, the semantic service bus, task orchestration engine, and AI agents can understand the function of each logical entity container like a human.

[0026] The second core element is the resource dependency declaration. The resource dependency declaration specifies which hardware devices or software resources the logical entity container needs to access during execution, and what permission levels are required. For example, a comfort assessment logic might need read-only access to temperature and humidity sensors, while a humidification control logic might need read-write access to the humidifier's control interface. The resource dependency declaration can be further refined, such as declaring requirements for sensor sampling frequency or data accuracy. Through resource dependency declarations, the system can determine whether the logical entity's operating conditions are met before scheduling and dynamically grant the corresponding access permissions during execution.

[0027] The third core element is the interface protocol. The interface protocol defines how to invoke the logical entity container and what data will be returned after the invocation, including the definitions of input parameters and output parameters. The input parameter definition explicitly specifies the input data structure that the logical entity container expects to receive, including parameter name, data type, value range, and whether it can be omitted. The output parameter definition explicitly specifies the data structure returned after the invocation, including the type and meaning of the return value. Through the interface protocol, any caller can interact with the logical entity container in a unified manner.

[0028] Specific Implementation Example: A detailed explanation is provided using a smart home scenario as an example. Assume a modern smart home environment with the following hardware devices deployed: a living room temperature sensor, a living room humidity sensor, a bedroom temperature sensor, a bedroom humidity sensor, a smart air conditioner, a smart humidifier, and an air purifier. The developers have predefined three functional logics, each used for different environmental control scenarios. These three functional logics are encapsulated into three independent logical entity containers.

[0029] The first logical entity container implements a comprehensive assessment of the living room's environmental comfort. This container is implemented as a Python script and encapsulates a comfort assessment algorithm based on fuzzy logic. The algorithm's input parameters include the current temperature, humidity, and time in the living room, and its output is a comfort score and suggested adjustments. The developers created a semantic description list for this functional logic when encapsulating it.

[0030] The intent fingerprint of this logical entity container is defined as "assess the comfort of the living room environment and provide adjustment suggestions." To support more granular matching, the intent fingerprint also includes a set of semantic tags, including keywords such as "environmental monitoring," "comfort assessment," "living room," "temperature," and "humidity." When a user says "make the living room more comfortable," the system can quickly match this logical entity container using these semantic tags.

[0031] The resource dependency declarations for this logical entity container include: read-only access to the data interface of the living room temperature sensor, read-only access to the data interface of the living room humidity sensor, and the need to read the system clock to obtain the current time information. Furthermore, the resource dependency declarations further specify a minimum sampling frequency requirement of one hertz for the temperature sensor and a data accuracy requirement of ±3% for the humidity sensor.

[0032] The interface protocol of this logical entity container includes the following input parameters: Parameter 1 represents temperature, a floating-point number in degrees Celsius, ranging from 0 to 40 degrees Celsius, and is mandatory; Parameter 2 represents humidity, a floating-point number in percentage, ranging from 0% to 100%, and is mandatory; Parameter 3 represents time, a string in hour and minute format, and is optional, defaulting to the current system time when omitted. The output parameter is a composite data structure containing two fields: a comfort rating field, a floating-point number ranging from 0 to 100 points; and a suggested action list field, a string array where each string represents a suggested action description.

[0033] The second logical entity container implements automatic adjustment of the bedroom's environmental comfort. This logical entity container is implemented as a workflow described in JSON. The workflow describes the following sequence of operations: first, it reads data from the bedroom temperature and humidity sensors; then, it determines whether to activate the humidifier or air conditioner based on preset comfort thresholds; finally, it executes the adjustment operation by calling the control interfaces of the corresponding devices. For this logical entity container, its intent fingerprint is defined as "automatically adjust the bedroom temperature and humidity to a comfortable level." The resource dependency declaration lists the bedroom humidifier control interface and the bedroom air conditioner control interface, which require read-write access. The interface protocol defines the workflow's input parameters as optional comfort preference settings, and the output parameter as the execution result status.

[0034] The third logical entity container is for handling emergency situations in abnormal environments. This container is implemented as a C++ compiled algorithm module, internally encapsulating a fast-response anomaly detection and handling algorithm. This algorithm continuously monitors environmental data and automatically executes preset emergency measures when it detects a sudden drop in temperature or abnormal humidity. Its intent fingerprint is defined as "detect and handle abnormal environmental conditions," including semantic tags such as "anomaly detection," "emergency response," "abnormal temperature," and "abnormal humidity."

[0035] In one alternative implementation, each logical entity container supports heterogeneous forms, including Python script forms, JSON-described workflow forms, and C or C++ compiled algorithm module forms.

[0036] The three logical entity containers described above perfectly illustrate these three heterogeneous forms: the living room environment comfort assessment uses a Python script, the bedroom environment comfort automatic adjustment uses a JSON workflow, and the abnormal environment emergency handling uses a C++ algorithm module. Although they are implemented using different technologies, they share a unified external appearance after encapsulation—each logical entity container has an intent fingerprint, resource dependency declaration, and interface protocol. This heterogeneous encapsulation capability enables this invention to be compatible with functional logic from different sources and different technology stacks. Whether it's a newly developed Python algorithm, an existing JSON configuration file, or a legacy C++ module, they can all be seamlessly integrated into the system, greatly improving the system's openness.

[0037] After the semantic encapsulation described above, the three functional logics, originally scattered across different locations and written using different technologies, have been transformed into three logical entity containers with a unified semantic description list. These three logical entity containers are now ready to be registered with the system at runtime.

[0038] S2. The multiple logical entity containers actively register themselves through the semantic service bus during runtime. In an optional implementation, the plurality of logical entity containers actively registering themselves at runtime via the semantic service bus includes: Each logical entity container sends a registration message to the semantic service bus containing its intent fingerprint, resource permission requirements, and interface protocol. Upon receiving the registration message, the semantic service bus stores the intent fingerprint of the logical entity container in the global capability pool and establishes a mapping relationship between the intent fingerprint and the address of the logical entity container. When any logical entity container stops or is updated, it sends a deregistration message to the semantic service bus. Upon receiving the message, the semantic service bus deletes the intent fingerprint of the logical entity container from the global capability pool and cancels the mapping relationship between the intent fingerprint and the address of the logical entity container.

[0039] The purpose of this step is to enable the encapsulated logical entity container to dynamically register itself with the semantic service bus at system runtime, allowing the system to be aware of its existence. In traditional solutions, adding or modifying a functional logic requires modifying configuration files or even rewriting code, and then restarting the entire business process for the changes to take effect. This invention achieves "plug-and-play" software logic through a hot-swappable registration mechanism. After registration, the logical entity container becomes a visible capability node on the semantic service bus, and its intent fingerprint is stored in the global capability pool, allowing the AI ​​agent to perceive its existence in real time. When the logical entity container needs to be stopped or updated, it is removed from the bus by sending a deregistration message. The entire process does not require restarting any process, achieving true runtime hot-swapping.

[0040] The semantic service bus is the core infrastructure of this invention. It functions as a message middleware with semantic understanding capabilities, responsible for managing the registration information of all logical entity containers and hardware entities, maintaining the global capability pool, processing intent matching requests, and coordinating invocation relationships. When the edge intelligent gateway starts, the semantic service bus initializes, creating the global capability pool in system memory. The global capability pool is a container indexed by intent fingerprints, used for quickly retrieving logical entity containers with a specific capability description.

[0041] Specific Implementation: In this embodiment, after the edge intelligent gateway starts up, the semantic service bus is initialized, creating a global capability pool in system memory. Subsequently, the three logical entity containers mentioned above start up sequentially and send registration messages to the semantic service bus respectively.

[0042] Taking the living room environment comfort assessment logical entity container as an example, its registration message contains the following core information: the message type identifier is registration, the logical entity container name is living room comfort assessor, the implementation form identifier is Python script, the intent fingerprint is "assess living room environment comfort and provide adjustment suggestions", the semantic tag list includes "environmental monitoring", "comfort assessment", "living room", "temperature" and "humidity", the resource dependency declaration records the read-only permission required to access the living room temperature sensor and the living room humidity sensor, the interface protocol records the definition of input and output parameters, and the node address indicates the communication address of the logical entity container in the system.

[0043] After receiving the registration message, the Semantic Service Bus performs the following processing operations: First, the Semantic Service Bus parses the message content and extracts the intent fingerprint and semantic tag. Second, it stores the intent fingerprint and semantic tag in the global capability pool, establishing a mapping relationship from the semantic description to the address of the logical entity container. Specifically, the Semantic Service Bus creates an entry for the intent fingerprint "assess the comfort of the living room environment and provide adjustment suggestions," which points to the node address of the logical entity container. Simultaneously, for each semantic tag, an association is established from the tag to the logical entity container, so that even if the intent fingerprint does not match perfectly, the Semantic Service Bus can perform similarity matching through the semantic tag. Third, the Semantic Service Bus prepares to abstract the logical entity container into a software capability node; this step will be described in detail in step S3. Fourth, the Semantic Service Bus returns a registration success confirmation message to the logical entity container, along with the capability identifier assigned to it.

[0044] The registration process for the automatic bedroom comfort adjustment logical entity container and the abnormal environment emergency handling logical entity container is similar. The registration message for the automatic bedroom comfort adjustment logical entity container includes the intent fingerprint "automatically adjust bedroom temperature and humidity to a comfortable level," and the resource dependency declaration lists the bedroom humidifier control interface and bedroom air conditioner control interface that require read-write access. The registration message for the abnormal environment emergency handling logical entity container includes the intent fingerprint "detect and handle abnormal environmental conditions" and related semantic tags. The three logical entity containers complete their registration independently, each with its own registration information and capability identifier.

[0045] When a logical entity container needs to be stopped or updated, it sends a deregistration message to the Semantic Service Bus. For example, suppose a user wants to adjust the comfort threshold in the automatic bedroom comfort adjustment logical entity container from 45% to 40%. The developer only needs to modify the JSON workflow configuration file inside the logical entity container and then send the deregistration and registration messages sequentially to complete the update. During this process, other functions of the system remain completely unaffected. Upon receiving the deregistration message, the Semantic Service Bus removes the intent fingerprint of the logical entity container from the global capability pool, cancels the mapping between the intent fingerprint and the logical entity container address, and releases related resources.

[0046] In addition, the Semantic Service Bus maintains awareness of the liveness of registered logical entity containers through a heartbeat monitoring mechanism. Each registered logical entity container needs to send a heartbeat message to the Semantic Service Bus at predetermined time intervals, such as every thirty seconds. If the Semantic Service Bus fails to receive a heartbeat message from a logical entity container three times consecutively, it will determine that the logical entity container has failed, automatically remove it from the global capability pool, and record the corresponding event log.

[0047] S3. The semantic service bus abstracts each registered logical entity container into a software capability node and each hardware execution entity into a hardware capability node. The software capability nodes and the hardware capability nodes together constitute a global capability mapping table. The purpose of this step is to unify the representation of software and hardware within the system, eliminating the differences in their calling paths. In traditional architectures, calling hardware drivers and executing software workflows follow completely different technical paths—hardware calls are implemented through a hardware abstraction layer or device driver interface, while software calls are completed through inter-process communication or function calls. The consequence of this architectural design is that AI agents face logical confusion when orchestrating tasks, unable to understand and schedule software and hardware capabilities in a unified way.

[0048] This invention completely solves this problem through peer-to-peer abstraction technology. The semantic service bus abstracts each registered logical entity container into a software capability node and each hardware execution entity into a hardware capability node. These software and hardware capability nodes together constitute a global capability mapping table. Each software and hardware capability node has the same data structure in the global capability mapping table, which includes a capability identifier, capability type label, intent fingerprint set, input / output tensor definitions, resource dependency list, and node address. The capability identifier is globally unique and used for addressing during scheduling; the capability type label distinguishes between software and hardware capabilities but is not used for path selection during scheduling; the intent fingerprint set records the intent types that the capability node can resolve; the input / output tensor definitions record the parameter format during invocation; the resource dependency list records other capability nodes that the capability node needs to access; and the node address records the actual communication endpoint.

[0049] After peer-to-peer abstraction, the global capability mapping table is composed of these software capability nodes and hardware capability nodes. The task orchestration engine does not distinguish between software and hardware capability nodes during scheduling, using capability identifiers for addressing and invocation. When a software capability node needs to invoke another capability node, it only needs to know the target capability node's capability identifier and send the invocation request according to a unified message format, without needing to know whether the invoked node is software or hardware.

[0050] In this invention, the "global capability pool" and the "global capability mapping table" have a clear inclusion relationship. The "global capability pool" is the underlying data structure maintained in memory by the semantic service bus, used to store the intent fingerprints and corresponding node addresses of all registered capability nodes. The "global capability mapping table" is a logical view oriented towards the task orchestration engine. It not only contains all the index information in the global capability pool, but also further encapsulates a complete semantic description list for each capability node, including capability identifiers, capability type labels, input / output tensor definitions, resource dependency lists, etc. In other words, the global capability mapping table is composed of the index mapping relationships stored in the global capability pool and the complete semantic description list corresponding to each capability node.

[0051] Specific Implementation: In this embodiment, the semantic service bus abstracts the three successfully registered logical entity containers as software capability nodes and each hardware execution entity as a hardware capability node. These software capability nodes and hardware capability nodes together constitute a global capability mapping table.

[0052] Taking the logical entity container for assessing living room environmental comfort as an example, it is abstracted as a software capability node. This software capability node contains the following complete information: the capability identifier is a globally unique identifier "SKILL_SOFT_001"; the capability type label is marked as "software capability"; the intent fingerprint set records the main intent fingerprint "assess living room environmental comfort and provide adjustment suggestions" and auxiliary semantic labels "environmental monitoring", "comfort assessment", "living room", "temperature", and "humidity"; the input and output tensor definition records the complete definition of the input parameters (temperature, humidity, time) and output parameters (comfort score, suggested operation list) in the interface protocol; the resource dependency list records the hardware capability nodes that need to be accessed, including references to the living room temperature sensor hardware capability node and references to the living room humidity sensor hardware capability node, with a read-only permission level; the node address points to the communication address of this logical entity container in the system.

[0053] Similarly, the logic entity container for automatic adjustment of bedroom environment comfort is abstracted as a software capability node, with the capability identifier "SKILL_SOFT_002" and the intent fingerprint "automatically adjust bedroom temperature and humidity to a comfortable level". The resource dependency list includes hardware capability nodes corresponding to the bedroom temperature sensor, bedroom humidity sensor, smart humidifier, and smart air conditioner. The logic entity container for emergency handling of abnormal environments is abstracted as a software capability node, with the capability identifier "SKILL_SOFT_003" and the intent fingerprint "detect and handle abnormal environmental conditions".

[0054] Meanwhile, the semantic service bus abstracts each hardware execution entity into a hardware capability node. Taking the living room temperature sensor as an example, it is abstracted as a hardware capability node, which includes: a capability identifier "SKILL_HW_001"; a capability type label marked as "hardware capability - sensor class"; an intent fingerprint defined as "get the current temperature value of the living room", and auxiliary semantic labels including "temperature", "sensor", "living room", and "read"; in the input-output tensor definition, the input parameter is empty, the output parameter is defined as the temperature value, the data type is a floating-point number, the unit is degrees Celsius, and the value range is 0 to 50 degrees Celsius; the resource dependency list is empty because the sensor itself is a resource provider rather than a consumer; and the node address points to the access interface of the device driver.

[0055] Similarly, the living room humidity sensor is abstracted as a hardware capability node, with the capability identifier "SKILL_HW_002" and the intent fingerprint "Get the current humidity value of the living room". The bedroom temperature sensor is abstracted as a hardware capability node, with the capability identifier "SKILL_HW_003" and the intent fingerprint "Get the current temperature value of the bedroom". The bedroom humidity sensor is abstracted as a hardware capability node, with the capability identifier "SKILL_HW_004" and the intent fingerprint "Get the current humidity value of the bedroom". The smart air conditioner is abstracted as a hardware capability node, with the capability identifier "SKILL_HW_005" and the intent fingerprint including "Adjust the living room temperature", and defines multiple operation interfaces, including setting the working mode, setting the target temperature, and setting the fan speed. The smart humidifier is abstracted as a hardware capability node, with the capability identifier "SKILL_HW_006" and the intent fingerprint "Adjust the humidity of the bedroom", and defines interfaces for on / off control, target humidity setting, and mist volume adjustment. The air purifier is abstracted as a hardware capability node, with the capability identifier "SKILL_HW_007" and the intent fingerprint "purify living room air". Interfaces such as switch control and mode selection are defined.

[0056] After the aforementioned equalization and abstraction, the global capability mapping table consists of three software capability nodes and seven hardware capability nodes. All capability nodes have identical data structures, containing six core fields: capability identifier, capability type label, intent fingerprint set, input / output tensor definition, resource dependency list, and node address. When the task orchestration engine needs to acquire temperature data, it calls the living room temperature sensor hardware capability node using the capability identifier "SKILL_HW_001"; when it needs to assess comfort, it calls the living room comfort evaluator software capability node using the capability identifier "SKILL_SOFT_001". The calling methods are completely consistent, with no path differences between software and hardware calls. The direct benefit of this design is that when the AI ​​agent completes complex tasks, it can discover and call the temperature sensor (hardware) and temperature data analysis algorithm (software) using the exact same semantics and calling methods, without needing to distinguish the calling path, greatly simplifying the complexity of task orchestration.

[0057] Regarding the correspondence between logical entity containers and hardware execution entities, it is important to note that peer-to-peer abstraction does not require one logical entity container to correspond to one hardware execution entity, nor does it limit one logical entity container to only one hardware execution entity. In fact, a logical entity container can declare through its resource dependency list that it needs to access multiple hardware capability nodes. For example, the living room comfort evaluator logical entity container may need to access two hardware capability nodes (temperature sensor and humidity sensor). Similarly, multiple logical entity containers can share the same hardware capability node; for example, both the living room comfort evaluator logical entity container and the abnormal environment emergency processor logical entity container may need to access the living room temperature sensor. This flexible many-to-many relationship is one of the key advantages of the technical solution of this invention.

[0058] S4. The task orchestration engine performs intent matching in the global capability mapping table based on the received user intent, selects a matching software capability node from the global capability mapping table based on the matching result, and constructs a dynamic task chain based on the dependency relationship between the software capability node and its dependent hardware capability nodes. The purpose of this step is to translate the user's natural language intent into a specific execution plan. This is a crucial step in the interaction between the AI ​​agent and the system. In traditional solutions, user intent needs to be hard-coded into specific rule triggering conditions, which cannot handle ambiguous, natural language instructions. This invention uses semantic matching technology to enable the system to understand the user's natural language intent and automatically orchestrate the necessary capability nodes.

[0059] The task orchestration engine matches received user intents against a global capability mapping table. The matching algorithm employs semantic similarity calculation based on a vector space model. The semantic service bus maintains a pre-trained semantic embedding model capable of mapping natural language text to a high-dimensional semantic vector space. For each intent fingerprint in the global capability pool, the semantic service bus calculates the cosine similarity between its semantic vector and the query intent vector. Intent fingerprints with a similarity higher than a preset threshold (e.g., 0.75) are considered a match.

[0060] Based on the matching results, the task orchestration engine selects a matching software capability node from the global capability mapping table and constructs a dynamic task chain according to the dependencies between the software capability node and its dependent hardware capability nodes. Here, dependency means that the execution of a software capability node requires the output of certain hardware capability nodes as input, and its execution result may trigger calls to other hardware capability nodes. For example, the comfort evaluator logical entity container relies on data provided by temperature and humidity sensors; therefore, the evaluator node needs to acquire sensor data before execution. The suggested operations returned after the evaluator's execution will trigger calls to the air conditioner and air purifier. Based on these dependencies, the task orchestration engine constructs an ordered dynamic task chain, with the selected software capability node at its core, specifying the hardware capability nodes to be called during execution and their calling order.

[0061] Specific Implementation: In this embodiment, the user says "Make the living room more comfortable" through a smart speaker. The speech recognition module converts the user's speech into text and passes it to the AI ​​agent. The AI ​​agent performs natural language understanding on the text, extracting the core intent elements: the target area is the living room, the desired result is to make the environment comfortable, and the implicit operations include assessing the current environmental state and performing adjustment operations. After semantic analysis, the AI ​​agent transforms this user intent into a structured intent query request, which contains the following fields: the intent description is "make the environment comfortable," the target area is "living room," and the priority is normal.

[0062] The AI ​​agent sends this intent query request to the semantic service bus. Upon receiving the request, the semantic service bus initiates the intent matching process. First, the semantic service bus searches its global capability pool for intent fingerprints semantically similar to "make the environment comfortable." The semantic service bus maintains a pre-trained semantic embedding model that maps natural language text to a high-dimensional semantic vector space. For each intent fingerprint in the global capability pool, the semantic service bus calculates the cosine similarity between its semantic vector and the query intent vector. Intent fingerprints with a similarity higher than a preset threshold of 0.75 are considered a match.

[0063] In this example, after semantic similarity calculation, the semantic service bus discovered several matching intent fingerprints, including the intent fingerprint of the living room comfort evaluator software capability node, "Evaluate the comfort of the living room environment and provide adjustment suggestions" (similarity 0.93), and the intent fingerprint of the bedroom environment comfort automatic adjustment software capability node, "Automatically adjust the bedroom temperature and humidity to a comfortable level" (similarity 0.71). Among them, the similarity of the living room comfort evaluator software capability node is higher than the preset threshold of 0.75, and the target area "living room" perfectly matches "living room" in the user's intent. Therefore, the task orchestration engine selects a matching software capability node from the global capability mapping table—the living room comfort evaluator software capability node (SKILL_SOFT_001).

[0064] The task orchestration engine constructs a dynamic task chain based on the dependencies between selected software capability nodes and their dependent hardware capability nodes. Specifically, the resource dependency list of the living room comfort evaluator software capability node declares the need to access the living room temperature sensor and the living room humidity sensor; therefore, the execution of this software capability node depends on the output data of these two hardware capability nodes. Simultaneously, according to the interface protocol of this software capability node, its output parameters are a list of suggested operations, which may trigger calls to the smart air conditioner and air purifier upon execution. Based on this dependency, the task orchestration engine constructs the following dynamic task chain: This task chain, with the living room comfort evaluator software capability node at its core, specifies that execution requires first accessing the living room temperature sensor and the living room humidity sensor to obtain data, then executing the evaluator, and finally calling the smart air conditioner and air purifier based on the evaluation results.

[0065] In an optional implementation, when the matching result of the user intent returns multiple matching software capability nodes, the semantic service bus performs conflict arbitration based on preset semantic priorities and the current scenario context, and selects one software capability node from the multiple matching software capability nodes as the execution node. The task orchestration engine constructs a dynamic task chain based on the selected software capability node. The semantic priorities include system-level priorities, user-defined priorities, and dynamic priorities based on historical success rates. The scenario context includes the current time, user location, device status, and other task information being executed.

[0066] The purpose of a conflict arbitration mechanism is to resolve the selection problem when multiple software capability nodes simultaneously match the same user intent. In practical applications, a user's same ambiguous intent may correspond to multiple software capability nodes with similar functions but different specific behaviors. For example, if a user says "the bedroom is too dry," this can be resolved by either a comprehensive software capability node that adjusts both temperature and humidity, or by a specialized software capability node that only adjusts humidity. Both solutions may satisfy the user's intent, but the execution results will differ. The conflict arbitration mechanism automatically selects the most suitable software capability node as the execution node through multi-dimensional priority judgment.

[0067] The semantic priorities include the following three types: First, system-level priorities, which are the system's preset default priorities. For example, security-related software capability nodes are assigned the highest priority to ensure that security-related logic is executed first. Second, user-defined priorities, which allow users to specify priority values ​​when registering logical entity containers. The higher the value, the higher the priority, reflecting the user's preference for different functions. Third, dynamic priorities based on historical success rates, which are priorities automatically adjusted by the system based on the historical execution success rate of the software capability node. Nodes with higher success rates receive higher dynamic priorities, reflecting the system's pursuit of reliability.

[0068] The scenario context includes the following information: Current time, used to determine whether it is within a specific time period (e.g., late at night, weekday, etc.); User location, used to determine the user's current location; Device status, used to determine the current working status of the relevant hardware device (e.g., whether it is online, whether it is performing other tasks, etc.); Information on other tasks being executed, used to determine whether there are task conflicts or resource contention.

[0069] The basic process of conflict arbitration is as follows: First, collect all matching software capability nodes; second, calculate the priority score of each node according to semantic priority, with user-defined priority having the highest weight, followed by system-level priority, and dynamic priority as an auxiliary reference; then, combine conflict-related information in the scenario context (such as whether the current device status supports the execution of a certain node); finally, make a comprehensive judgment to select the most suitable software capability node for the current scenario as the execution node.

[0070] Specific Implementation: Suppose a user says, "The bedroom is too dry," with the intent to increase the bedroom humidity. During intent matching, the semantic service bus identifies two matching software capability nodes. The first is a software capability node for automatically adjusting bedroom environmental comfort, with the intent fingerprint "automatically adjust bedroom temperature and humidity to a comfortable level." This node adjusts both temperature and humidity simultaneously, and its user-defined priority is five. The second is a dedicated software capability node for bedroom humidification, with the intent fingerprint "increase bedroom humidity to a set value." This node only adjusts humidity, and its user-defined priority is eight.

[0071] The conflict arbitration module first compares user-defined priorities: the priority of the bedroom humidification software capability node is eight, which is higher than the priority of the bedroom environmental comfort automatic adjustment software capability node (five). Simultaneously, the arbitration module also considers scenario context information: the current bedroom temperature sensor shows a temperature of 24 degrees Celsius, already within the preset comfort range (20 to 26 degrees Celsius). In this case, the temperature is already comfortable and requires no adjustment; adjusting only the humidity is more suitable than adjusting both temperature and humidity simultaneously, saving energy and avoiding unnecessary temperature fluctuations.

[0072] Taking into account priority and scenario context, the conflict arbitration selects the bedroom humidification-specific software capability node as the execution node. The task orchestration engine constructs a dynamic task chain based on the selected software capability node. This task chain is centered on the bedroom humidification-specific software capability node, and its dependent hardware capability nodes include a bedroom humidity sensor (for acquiring current humidity data) and a smart humidifier (for performing humidification operations).

[0073] S5. The task orchestration engine triggers the logical entity container corresponding to the software capability node in the dynamic task chain. During execution, the triggered logical entity container calls the hardware execution entity corresponding to the hardware capability node that the dynamic task chain depends on, and advances step by step according to the dependency relationship of the dynamic task chain until the complete task corresponding to the user's intent is completed. When the triggered logical entity container fails, the semantic service bus searches for the logical entity container corresponding to the alternative software capability node from the global capability mapping table based on semantic similarity to replace it for execution.

[0074] The purpose of this step is to actually execute tasks according to the constructed task chain, providing various security safeguards and fault tolerance mechanisms during execution. The task orchestration engine triggers the logical entity containers corresponding to the software capability nodes in the dynamic task chain sequentially. During execution, the triggered logical entity containers call the hardware execution entities corresponding to the hardware capability nodes that the dynamic task chain depends on, based on their resource dependency declarations, and advance step by step according to the dependencies of the dynamic task chain until the complete task corresponding to the user's intent is completed.

[0075] During implementation, this invention provides three important enhancement mechanisms. The first is an access control mechanism, ensuring that logical entity containers can only access hardware resources authorized in their resource dependency declarations. The second is an infinite loop detection mechanism, preventing circular calls between software capability nodes from exhausting system resources. The third is a self-healing replacement mechanism, enabling the system to automatically find alternative solutions to continue executing tasks when a logical entity container fails.

[0076] Specific Implementation: In this embodiment, the task orchestration engine triggers the logical entity containers corresponding to the software capability nodes in the dynamic task chain sequentially. Specifically, the dynamic task chain is centered on the living room comfort evaluator software capability node, and the task orchestration engine triggers the living room comfort evaluator logical entity container corresponding to this software capability node.

[0077] Once triggered, the logical entity container begins execution. During execution, according to the task chain dependencies, it first needs to obtain the current temperature and humidity data of the living room. Therefore, it initiates calls to the living room temperature sensor hardware capability node (SKILL_HW_001) and the living room humidity sensor hardware capability node (SKILL_HW_002). These two hardware capability nodes correspond to the living room temperature sensor and the living room humidity sensor hardware execution entities, respectively. After the calls are completed, the evaluator obtains the temperature and humidity data, continues to execute the comfort assessment algorithm, and calculates the comfort score and a list of recommended actions.

[0078] Then, the task orchestration engine determines the hardware execution entities to be invoked based on the suggested operation list returned by the evaluator. Assuming the suggested operation list includes "set the air conditioner temperature to 24 degrees Celsius cooling mode" and "turn the air purifier on automatic mode," the task orchestration engine invokes the smart air conditioner hardware capability node (SKILL_HW_005) and the air purifier hardware capability node (SKILL_HW_007) respectively. These two hardware capability nodes correspond to the smart air conditioner and the air purifier hardware execution entities, respectively.

[0079] The entire execution process proceeds step by step according to dependencies: sensor nodes are called first to acquire data, evaluator nodes perform evaluations next, and executor nodes perform adjustment operations last. The task orchestration engine monitors the execution status of each node in real time until all nodes have completed their execution, at which point the complete task corresponding to the user's intention to "make the living room more comfortable" is completed.

[0080] In an optional implementation, before the triggered logical entity container calls the hardware execution entity corresponding to the hardware capability node that the dynamic task chain depends on during execution, the method further includes: the semantic service bus dynamically grants the logical entity container a temporary permission token to access the corresponding hardware execution entity based on the hardware permission requirements declared in the resource dependency declaration of the logical entity container; after the logical entity container completes the call with the token, the semantic service bus reclaims the temporary permission token.

[0081] In this embodiment, before calling the living room temperature sensor hardware execution entity, the living room comfort evaluator logical entity container explicitly declares in its resource dependency declaration that it needs to "access the living room temperature sensor's data interface with read-only permissions." Based on this declaration, the semantic service bus dynamically grants the logical entity container a temporary permission token with a validity period, for example, thirty seconds. The living room comfort evaluator logical entity container uses this token to call the living room temperature sensor. Upon receiving the call request, the semantic service bus verifies the token's validity, allowing access only after successful verification. After the call is completed, the semantic service bus immediately revoks the temporary permission token. If the logical entity container attempts to call again subsequently, it needs to reapply for a token. This semantic-based access control mechanism ensures that only properly authorized logical entity containers can access sensitive hardware resources, preventing permission abuse and enhancing system security. Similarly, the same permission control process is followed when the living room comfort evaluator calls the living room humidity sensor, and when the task orchestration engine calls the smart air conditioner and air purifier.

[0082] In an optional implementation, when any software capability node in the dynamic task chain calls another software capability node during execution, the semantic service bus maintains a call stack for the dynamic task chain and checks whether the called software capability node already exists in the call stack before initiating the call. If it does not exist, the call is allowed and the called software capability node is pushed onto the call stack. If it already exists, it is determined to be a potential infinite loop, the call is rejected and an alarm is issued.

[0083] To illustrate this mechanism, this embodiment introduces a more complex scenario. Assume that, based on the automatic environmental comfort adjustment system, the user adds a new logical entity container named the Intelligent Energy-Saving Coordinator. The intent fingerprint of this logical entity container is "coordinate the operating states of various devices to achieve energy-saving goals." Its function is to: assess the current energy consumption before performing any adjustment operation; if the energy consumption is too high, prioritize the low-power adjustment scheme; simultaneously, it updates the system's energy consumption assessment model based on the adjustment results. This logical entity container is abstracted as a software capability node, which, together with other software and hardware capability nodes, constitutes a global capability mapping table.

[0084] Now consider the following calling relationship. During execution, if the living room comfort evaluator logic entity container detects a low comfort score, it calls the smart energy-saving coordinator logic entity container to assess the energy feasibility of the current adjustment scheme. During this assessment, to obtain a more accurate environmental prediction, the smart energy-saving coordinator logic entity container then calls the living room comfort evaluator logic entity container again to predict future comfort trends. This forms a potential circular calling chain: the living room comfort evaluator calls the smart energy-saving coordinator, and the smart energy-saving coordinator in turn calls the living room comfort evaluator.

[0085] The call stack monitoring mechanism operates as follows. When the task orchestration engine starts executing a task, the semantic service bus creates an empty call stack for that dynamic task chain. The call stack is a last-in-first-out (LIFO) data structure used to record the currently executing capability node call chain. Whenever a software capability node calls another software capability node, the semantic service bus performs the following operations before executing the call.

[0086] First, it checks whether the called software capability node already exists in the current call stack. If the called software capability node is not in the call stack, it indicates a valid call. The semantic service bus pushes the called software capability node onto the top of the call stack and then executes the call. If the called software capability node already exists in the call stack, it indicates an impending circular call. The semantic service bus immediately rejects the call, issues an infinite loop warning, and decides, based on the configured policy, whether to terminate the current task or attempt to find an alternative path.

[0087] Taking the cyclical call between the living room comfort evaluator logical entity container and the smart energy-saving coordinator logical entity container as an example, the specific process is as follows: First, the task orchestration engine begins executing the user intent, and the living room comfort evaluator logical entity container is triggered as a software capability node in the task chain. The semantic service bus pushes the identifier of the living room comfort evaluator logical entity container onto the call stack, at which point the call stack is: [living room comfort evaluator]. During execution, the living room comfort evaluator logical entity container calls the smart energy-saving coordinator logical entity container. The semantic service bus checks whether the smart energy-saving coordinator is in the call stack. Currently, the call stack does not contain the smart energy-saving coordinator, so the call is allowed. The semantic service bus pushes the smart energy-saving coordinator onto the call stack, and the call stack becomes: [living room comfort evaluator, smart energy-saving coordinator]. The smart energy-saving coordinator logical entity container begins execution. During the evaluation process, it needs to predict future comfort trends, so it calls the living room comfort evaluator logical entity container. At this point, the semantic service bus checks whether the called node, the living room comfort evaluator, exists in the current call stack. The current call stack is [living room comfort evaluator, intelligent energy-saving coordinator], and the living room comfort evaluator is already at the bottom of the call stack. Upon detecting this, the semantic service bus immediately determines that this is a potential circular call, rejects the call request, and issues a dead loop alarm. The alarm information contains the complete path of the circular call. Through this call stack monitoring mechanism, this invention effectively prevents dead loops caused by recursive calls, ensuring the stable operation of the system.

[0088] In an optional implementation, when the triggered logical entity container fails, the semantic service bus searches for the logical entity container corresponding to the alternative software capability node in the global capability mapping table based on semantic similarity to replace it.

[0089] In this embodiment, it is assumed that during execution, the living room comfort evaluator logical entity container crashes due to an internal anomaly (such as a corrupted algorithm module or memory overflow). The semantic service bus detects that the logical entity container has stopped sending heartbeat messages through a heartbeat monitoring mechanism and determines that it has failed. At this point, the task is not yet complete, and the user intent needs to continue to be executed.

[0090] Based on the semantic context of the current task—namely, the user's intent to "make the living room more comfortable"—and the steps already performed, the semantic service bus determines that the capability type to be replaced is "comfort assessment." Then, the semantic service bus searches the global capability map for other software capability nodes semantically similar to "comfort assessment." The semantic similarity is calculated using the same semantic embedding model as intent matching, calculating the cosine similarity between the intent fingerprint and the target semantics of each candidate software capability node.

[0091] Suppose a simplified comfort evaluator software capability node exists in the global capability mapping table, with the intent fingerprint "quickly assess living room comfort" and a semantic similarity of 0.85, higher than the preset replacement threshold of 0.7. The semantic service bus selects this software capability node as a candidate and instructs the task orchestration engine to use the candidate logical entity container to replace the original failed logical entity container and continue executing the task. The task orchestration engine uses the candidate node as the core node of the task chain and continues to advance according to the dependencies. That is, it first calls the temperature and humidity sensors to obtain data, then executes the candidate evaluator, and finally calls the air conditioner and air purifier based on the evaluation results, until the complete task corresponding to the user's intent is completed. This self-healing replacement mechanism realizes the logical self-healing of the edge intelligent system. Even if a logical entity container fails, the system can automatically find a replacement solution to ensure the continuity and robustness of the service.

[0092] Through the above steps S1 to S5, the present invention realizes semantic encapsulation of logical entity containers, hot-pluggable registration, software and hardware parity abstraction, dynamic task chain construction and execution, as well as enhanced functions such as access control, dead loop detection and self-healing replacement, which significantly improves the flexibility, scalability and robustness of edge intelligent systems and solves the technical problems of logical staticization, software and hardware asymmetry, lack of lifecycle management and lack of self-healing mechanism in the prior art.

[0093] Figure 2 This is a schematic diagram of the structure of a heterogeneous logical entity orchestration system based on a semantic bus, provided by an embodiment of the present invention; as shown below. Figure 2 As shown, the system includes: The encapsulation unit 201 is used to encapsulate multiple predefined functional logics into logical entity containers with semantic description lists. The semantic description list of each logical entity container includes the intent fingerprint, resource dependency declaration and interface protocol of the logical entity container. Registration unit 202 is used for the plurality of logical entity containers to actively register themselves through the semantic service bus at runtime; Abstraction unit 203 is used for the semantic service bus to abstract each registered logical entity container into a software capability node and each hardware execution entity into a hardware capability node. The software capability nodes and the hardware capability nodes together constitute a global capability mapping table. The matching unit 204 is used by the task orchestration engine to perform intent matching in the global capability mapping table according to the received user intent, select a matching software capability node from the global capability mapping table according to the matching result, and construct a dynamic task chain according to the dependency relationship between the software capability node and its dependent hardware capability nodes. The execution unit 205 is used by the task orchestration engine to sequentially trigger the logical entity containers corresponding to the software capability nodes in the dynamic task chain. During the execution process, the triggered logical entity containers call the hardware execution entities corresponding to the hardware capability nodes that the dynamic task chain depends on, and proceed step by step according to the dependency relationship of the dynamic task chain until the complete task corresponding to the user intent is completed.

[0094] In an optional implementation, when the matching result of the user intent returns multiple matching software capability nodes, the semantic service bus performs conflict arbitration based on preset semantic priorities and the current scenario context, and selects one software capability node from the multiple matching software capability nodes as the execution node. The task orchestration engine constructs a dynamic task chain based on the selected software capability node. The semantic priorities include system-level priorities, user-defined priorities, and dynamic priorities based on historical success rates. The scenario context includes the current time, user location, device status, and other task information being executed.

[0095] In an optional implementation, when any software capability node in the dynamic task chain calls another software capability node during execution, the semantic service bus maintains a call stack for the dynamic task chain and checks whether the called software capability node already exists in the call stack before initiating the call. If it does not exist, the call is allowed and the called software capability node is pushed onto the call stack. If it already exists, it is determined to be a potential infinite loop, the call is rejected and an alarm is issued.

[0096] In one alternative implementation, each logical entity container supports heterogeneous forms, including Python script forms, JSON-described workflow forms, and C or C++ compiled algorithm module forms.

[0097] In an optional implementation, before the triggered logical entity container invokes the hardware execution entity corresponding to the hardware capability node dependent on the dynamic task chain during execution, the method further includes: The semantic service bus dynamically grants a temporary permission token to the logical entity container to access the corresponding hardware execution entity based on the hardware permission requirements declared in the resource dependency declaration of the logical entity container. After the logical entity container completes the call with the token, the semantic service bus reclaims the temporary permission token.

[0098] In an optional implementation, the registration unit includes: Each logical entity container sends a registration message to the semantic service bus containing its intent fingerprint, resource permission requirements, and interface protocol. Upon receiving the registration message, the semantic service bus stores the intent fingerprint of the logical entity container in the global capability pool and establishes a mapping relationship between the intent fingerprint and the address of the logical entity container. When any logical entity container stops or is updated, it sends a deregistration message to the semantic service bus. Upon receiving the message, the semantic service bus deletes the intent fingerprint of the logical entity container from the global capability pool and cancels the mapping relationship between the intent fingerprint and the address of the logical entity container.

[0099] In an optional implementation, the step-by-step progression according to the dependencies of the dynamic task chain until the complete task corresponding to the user intent is completed further includes: when the triggered logical entity container fails, the semantic service bus searches for the logical entity container corresponding to the alternative software capability node from the global capability mapping table based on semantic similarity to replace it in execution.

[0100] The system of the present invention corresponds to the method described above, and the specific implementation of the system will not be repeated here.

[0101] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A heterogeneous logical entity orchestration method based on a semantic bus, characterized in that, include: S1. Encapsulate multiple predefined functional logics into logical entity containers with semantic description lists. The semantic description list of each logical entity container includes the intent fingerprint, resource dependency declaration, and interface protocol of the logical entity container. S2. The multiple logical entity containers actively register themselves through the semantic service bus at runtime; S3. The semantic service bus abstracts each registered logical entity container into a software capability node and each hardware execution entity into a hardware capability node. The software capability nodes and the hardware capability nodes together constitute a global capability mapping table. S4. The task orchestration engine performs intent matching in the global capability mapping table based on the received user intent, selects a matching software capability node from the global capability mapping table based on the matching result, and constructs a dynamic task chain based on the dependency relationship between the software capability node and its dependent hardware capability nodes. S5. The task orchestration engine triggers the logical entity containers corresponding to the software capability nodes in the dynamic task chain in sequence. During the execution of the triggered logical entity containers, the hardware execution entities corresponding to the hardware capability nodes that the dynamic task chain depends on call the hardware execution entities. The process proceeds step by step according to the dependency relationship of the dynamic task chain until the complete task corresponding to the user's intent is completed.

2. The method according to claim 1, characterized in that: When the matching result of the user intent returns multiple matching software capability nodes, the semantic service bus performs conflict arbitration based on the preset semantic priority and the current scenario context, selects one software capability node from the multiple matching software capability nodes as the execution node, and the task orchestration engine constructs a dynamic task chain based on the selected software capability node. The semantic priority includes system-level priority, user-defined priority, and dynamic priority based on historical success rate; the scenario context includes current time, user location, device status, and other task information being executed.

3. The method according to claim 1, characterized in that: When any software capability node in the dynamic task chain calls another software capability node during execution, the semantic service bus maintains a call stack for the dynamic task chain and checks whether the called software capability node already exists in the call stack before initiating the call. If it does not exist, the call is allowed and the called software capability node is pushed onto the call stack. If it already exists, it is determined to be a potential infinite loop, the call is rejected and an alarm is issued.

4. The method according to claim 1, characterized in that: Each logical entity container supports heterogeneous forms, including Python script forms, JSON-described workflow forms, and C or C++ compiled algorithm module forms.

5. The method according to claim 1, characterized in that, Before the triggered logical entity container invokes the hardware execution entity corresponding to the hardware capability node that the dynamic task chain depends on during execution, the process also includes: The semantic service bus dynamically grants a temporary permission token to the logical entity container to access the corresponding hardware execution entity based on the hardware permission requirements declared in the resource dependency declaration of the logical entity container. After the logical entity container completes the call with the token, the semantic service bus reclaims the temporary permission token.

6. The method according to claim 1, characterized in that, The multiple logical entity containers actively register at runtime via the semantic service bus, including: Each logical entity container sends a registration message to the semantic service bus containing its intent fingerprint, resource permission requirements, and interface protocol. Upon receiving the registration message, the semantic service bus stores the intent fingerprint of the logical entity container in the global capability pool and establishes a mapping relationship between the intent fingerprint and the address of the logical entity container. When any logical entity container stops or is updated, it sends a deregistration message to the semantic service bus. Upon receiving the message, the semantic service bus deletes the intent fingerprint of the logical entity container from the global capability pool and cancels the mapping relationship between the intent fingerprint and the address of the logical entity container.

7. The method according to claim 1, characterized in that, The process of proceeding step by step according to the dependencies of a dynamic task chain until the complete task corresponding to the user's intent is completed also includes: When the triggered logical entity container fails, the semantic service bus searches the global capability mapping table for the logical entity container corresponding to the alternative software capability node based on semantic similarity to replace it.

8. A heterogeneous logical entity orchestration system based on a semantic bus, characterized in that: The encapsulation unit is used to encapsulate multiple predefined functional logics into logical entity containers with semantic description lists. The semantic description list of each logical entity container includes the intent fingerprint, resource dependency declaration, and interface protocol of the logical entity container. A registration unit is used for the multiple logical entity containers to actively register themselves at runtime via the semantic service bus. Abstraction unit, used by the semantic service bus to abstract each registered logical entity container into a software capability node, and each hardware execution entity into a hardware capability node, the software capability node and the hardware capability node together constitute a global capability mapping table; The matching unit is used by the task orchestration engine to perform intent matching in the global capability mapping table based on the received user intent, select a matching software capability node from the global capability mapping table based on the matching result, and construct a dynamic task chain based on the dependency relationship between the software capability node and its dependent hardware capability nodes. The execution unit is used by the task orchestration engine to sequentially trigger the logical entity containers corresponding to the software capability nodes in the dynamic task chain. During the execution process, the triggered logical entity containers call the hardware execution entities corresponding to the hardware capability nodes that the dynamic task chain depends on, and advance step by step according to the dependency relationship of the dynamic task chain until the complete task corresponding to the user's intent is completed.

9. The system according to claim 8, characterized in that: When the matching result of the user intent returns multiple matching software capability nodes, the semantic service bus performs conflict arbitration based on the preset semantic priority and the current scenario context, selects one software capability node from the multiple matching software capability nodes as the execution node, and the task orchestration engine constructs a dynamic task chain based on the selected software capability node. The semantic priority includes system-level priority, user-defined priority, and dynamic priority based on historical success rate; the scenario context includes current time, user location, device status, and other task information being executed.

10. The system according to claim 8, characterized in that: When any software capability node in the dynamic task chain calls another software capability node during execution, the semantic service bus maintains a call stack for the dynamic task chain and checks whether the called software capability node already exists in the call stack before initiating the call. If it does not exist, the call is allowed and the called software capability node is pushed onto the call stack. If it already exists, it is determined to be a potential infinite loop, the call is rejected and an alarm is issued.

Images