Device capability description method and apparatus, computer device, and storage medium

Abstract

This application relates to a device capability description method, apparatus, computer device, and storage medium. The method includes: acquiring a capability description language document for a target device; the capability description language document includes device type information, operability status information, operation method information, physical constraint information, and feedback format information; the physical constraint information includes at least one or more of time constraints, energy constraints, safety constraints, lifetime constraints, and mutual exclusion constraints; upon receiving an intent instruction from an upper-layer application, parsing the intent instruction to extract one or more execution targets; and performing capability matching on the one or more execution targets according to the capability description language document to determine target operations from the target device that can achieve the execution targets. This method enables automatic capability adaptation between upper-layer applications and heterogeneous devices, reducing development costs and improving execution security.

Description

Technical Field

[0001] This application relates to the field of AI intent execution technology, and in particular to a device capability description method, apparatus, computer device, and storage medium. Background Technology

[0002] A long-standing engineering problem exists in current smart home scenarios: when a user says "I'm a little hot" through a voice assistant, the system can recognize the intent as cooling, but it cannot automatically adapt to different devices. This is because the upper-layer application neither knows which specific operations each device supports, nor whether the air conditioner compressor has start-up interval protection or whether the fan is already at its highest setting. Existing technical solutions mostly remain at the level of fixed rules like IF-THIS-THEN-THAT, rather than true intent understanding and automatic adaptation.

[0003] This problem is even more pronounced in the Industrial Internet of Things (IIoT) field. For example, in a photovoltaic power station, the inverters and tracking brackets come from different manufacturers. When the goal is to optimize power generation efficiency, the system needs to coordinate the bracket angle adjustment and inverter parameter settings, while also meeting physical constraints such as the inverter output power not exceeding the transformer capacity limit and the bracket motor continuous operation interval not less than 30 seconds. Existing solutions typically require customized integration development for each power station project, which is costly and time-consuming.

[0004] Significant progress has been made in standardizing device communication layers. The Matter protocol unifies device discovery, pairing, and message transmission mechanisms. The W3C Web of Things Thing Description defines a standardized description format for device attributes, operations, and events. However, this standard focuses on describing the device's interaction interface, i.e., describing what input and output ports the device has, and does not include physical constraint information, nor does it have the ability to automatically match and degrade from abstract intents to specific operations. Therefore, upper-layer applications still need to know the specific operation names and parameter semantics of each device in advance.

[0005] In summary, the existing technology has the following specific gaps: (1) There is a lack of a standardized document format that simultaneously describes the device's operational capabilities and physical constraints, so that the system can automatically determine whether an operation can be safely performed under the current device state; (2) There is a lack of a multi-level automatic matching mechanism from abstract user intent to specific device operation, especially how to implement available downgrade alternatives when precise matching fails. Summary of the Invention

[0006] Therefore, it is necessary to provide a device capability description method, apparatus, computer device, and storage medium that can achieve automatic capability adaptation between upper-layer applications and heterogeneous devices to address the above-mentioned technical problems.

[0007] A method for describing equipment capabilities, the method comprising: Obtain a capability description language document for the target device; the capability description language document includes device type information, operability status information, operation method information, physical constraint information, and feedback format information; the physical constraint information includes at least one or more of time constraints, energy constraints, safety constraints, lifetime constraints, and mutually exclusive constraints, and the physical constraint information is used to limit the physical limitations that the target device cannot violate when performing operations; Upon receiving an intent instruction from an upper-layer application, the intent instruction is parsed to extract one or more execution targets; Based on the capability description language document, capability matching is performed on the one or more execution targets to determine the target operations from the target devices that can achieve the execution targets.

[0008] In one embodiment, the capability matching includes precise matching, parameter matching, constraint-aware matching, degraded matching, and combined matching; the method further includes: sequentially attempting precise matching, parameter matching, constraint-aware matching, degraded matching, and combined matching in descending order of matching accuracy until the target operation is matched or the matching fails; wherein, degraded matching means that when there is no operation that precisely corresponds to the execution target, a substitute operation with similar function is sought; and combined matching means that when a single device cannot achieve the execution target, a combination of operations from multiple devices is selected to jointly achieve the execution target.

[0009] In one embodiment, capability matching is performed on the one or more execution targets based on the capability description language document, including: for each execution target, performing precise matching; if an operation name corresponds to the execution target, the match is successful; if precise matching fails, performing parameter matching to find operations that support parameters matching the execution target; if parameter matching fails, performing constraint-aware matching to find operations that can achieve the execution target while satisfying the physical constraint information; if constraint-aware matching fails, initiating degraded matching to find alternative operations with similar functions; if degraded matching fails, for an execution target composed of multiple sub-targets, initiating combined matching to match operations for each sub-target and combine them into a cooperative execution sequence.

[0010] In one embodiment, the algorithm complexity of the exact matching is logarithmic; the downgrade matching includes finding alternative operations with similar functions based on a preset device capability similarity graph; and the combined matching includes arranging the cooperative execution sequence based on a directed acyclic graph.

[0011] In one embodiment, the time constraints in the physical constraint information include the shortest operation interval and the minimum duration; the energy constraints include peak power and maximum energy consumption per operation; the safety constraints include prohibiting operation when the user is present or disabling operation in a specific environment; the lifetime constraints include an upper limit on the number of operations; and the mutually exclusive constraints are used to identify operation pairs that cannot be activated simultaneously.

[0012] In one embodiment, the device type information is a standardized enumeration type that is compatible with the type set of existing IoT communication protocols; the device type information supports nested types and type inheritance; wherein, nested types are used to represent system-level devices containing multiple sub-devices, and type inheritance is used to enable the attributes of a general device type to be automatically passed to its specific device type.

[0013] In one embodiment, the capability description language document carries a hierarchical source marker and a verification status marker; the hierarchical source includes official manufacturer sources, community verification sources, and AI-assisted generation sources; the verification status marker is used to indicate whether the capability description language document has passed the consistency check.

[0014] A device capability description apparatus, the apparatus comprising: The document acquisition module is used to acquire the capability description language document of the target device; the capability description language document includes device type information, operability status information, operation method information, physical constraint information, and feedback format information; the physical constraint information includes at least one or more of time constraints, energy constraints, safety constraints, lifetime constraints, and mutually exclusive constraints, and the physical constraint information is used to limit the physical restrictions that the target device cannot violate when performing operations; The intent parsing module is used to parse the intent instruction issued by the upper-layer application to extract one or more execution targets when it receives the intent instruction. The capability matching module is used to perform capability matching on the one or more execution targets according to the capability description language document, so as to determine the target operation that can achieve the execution target from the target device.

[0015] A computer device includes a memory and a processor, the memory storing a computer program, the processor executing the computer program to implement the steps of any of the above-described device capability description methods.

[0016] A computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of any of the above-described device capability description methods.

[0017] The aforementioned device capability description method, apparatus, computer equipment, and storage medium introduce physical constraint information by acquiring a capability description language document containing five elements: device type, operational state, operation method, physical constraints, and feedback format. This defines the physical limitations that cannot be violated during device operation. When an intent instruction from an upper-layer application is received, the execution target is parsed and extracted, and capability matching is performed based on the document to determine the target operation. This method describes device capabilities in a standardized, machine-readable language, enabling upper-layer applications to automatically understand what a device can do and what physical limitations it is subject to without writing adaptation code for specific devices. This achieves automatic adaptation from intent to device operation, solving the problems of high adaptation costs for heterogeneous devices and the inability to automatically identify physical constraints in existing technologies. This significantly improves the interoperability efficiency and security between applications and devices in IoT systems. Attached Figure Description

[0018] Figure 1 This is an application scenario diagram of the device capability description method in one embodiment; Figure 2 This is a flowchart illustrating a device capability description method in one embodiment; Figure 3 This is a structural block diagram of a device capability description apparatus in one embodiment; Figure 4 This is an internal structural diagram of a computer device in one embodiment. Detailed Implementation

[0019] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0020] The device capability description method provided in this application can be applied to, for example... Figure 1In the application environment shown, terminal 102 communicates with server 104 via a network. Terminal 102 can be a smart home control center, mobile phone, tablet computer, or smart speaker, or other device with upper-layer application capabilities. Server 104 can be a cloud-based intent parsing server or device management server. In a real-world scenario, a user issues an intent command through a smart application on terminal 102, such as "adjust the bedroom lights to a warm mode." Terminal 102 or server 104 obtains the capability description language document of the target device, i.e., the smart bedroom light, which is pre-stored in a local or cloud-based device capability library. Then, it parses the intent command, extracting the execution target, such as setting the brightness within a certain range or setting the color temperature within a certain range. Next, based on the device type, operable state, operation method, physical constraints, and feedback format recorded in the capability description language document, capability matching is performed to ultimately determine the specific operation commands for the smart light, such as `set_brightness` and `set_color_temperature`, and then sends them to the device for execution. The terminal 102 can be, but is not limited to, various personal computers, laptops, smartphones, tablets, smart speakers, smart gateways and wearable devices, and the server 104 can be implemented by a standalone server or a server cluster composed of multiple servers.

[0021] In one embodiment, such as Figure 2 As shown, a device capability description method is provided, which can be applied to... Figure 1 Taking the server in the example, the following steps are included: Step 202: Obtain the capability description language document of the target device.

[0022] Capability Description Language (DCDL) documents are stored in a structured data format, and their complete structure is defined as follows. This embodiment uses an actual DCDL document of a smart air conditioner as an example for illustration.

[0023] The top-level structure of a DCDL document contains the following fields: document version number, device identifier, device type, protocol binding information, type hierarchy information, operational state set, operation set, physical constraint set, feedback format definition, and metadata.

[0024] (1) Operable state set The operable state set defines all perceptible and controllable state variables of the device. Each state is organized as a key-value pair of state name and state definition. The state definition includes the following subfields: data type (data_type), which can be Boolean, integer, floating-point, string, or enumeration; read / write access (rw_access), which can be read-only, write-only, or read / write; when the data type is numeric, it also includes the value range and step precision; when the data type is enumeration, it also includes a list of optional values. Each state can further include a default value and physical unit (such as degrees Celsius or watts).

[0025] For example, the operable state set of the smart air conditioner in this embodiment includes: power status (power, Boolean, readable and writable, default value is off), target temperature (target_temp, integer, value from 16 to 30 degrees Celsius, in 0.5-degree increments, default value is 24 degrees Celsius, readable and writable), operating mode (mode, enumeration type, selectable values ​​include cooling (COOL), heating (HEAT), fan (FAN), dehumidification (DRY), and automatic (AUTO), default value is AUTO, readable and writable), current room temperature (current_temp, floating-point type, read-only), and compressor speed (compressor_rpm, integer, value from 0 to 1200, read-only).

[0026] (2) Operations The operation set is an array of operation definitions. Each operation definition contains the following subfields: operation identifier (op_id), a globally unique string used as the primary key for the matching engine; operation display name (op_name); aliases, a list of synonyms for the operation name in both Chinese and English, used for natural language mapping during the intent parsing phase; parameter list (params), each parameter containing the parameter name, data type, value range or a list of optional values, and whether it is required; precondition, expressed as an assertion expression stored as a string, specifying the condition that must be met before the operation is executed; postcondition, expressed as an assertion expression, specifying the state that should be achieved after the operation is executed; and expected response time (expected_latency_ms), in milliseconds.

[0027] For example, the operation set of the smart air conditioner in this embodiment includes three operations: (a) a switch operation with the operation identifier set_power, aliases such as power on, power off, etc., the parameter on is a Boolean type and is required, and the prerequisite is that the device power status is not empty; (b) a temperature setting operation with the operation identifier set_temp, aliases such as temperature adjustment, temperature setting, etc., the parameter temp is a floating-point type with a value of 16.0 to 30.0 and is required, and the prerequisite is that the device power status is on; (c) a mode switching operation with the operation identifier set_mode, aliases including cooling, heating, ventilation, dehumidification, and the parameter mode is an enumeration type and is required.

[0028] (3) Physical constraint set (physical_constraints) The physical constraint set is the core distinguishing feature of this invention, organized as an array of constraint objects. Each constraint object contains the following subfields: constraint identifier (constraint_id); constraint type (constraint_type), which takes the value of TIME (time constraint), ENERGY (energy constraint), SAFETY (safety constraint), LIFETIME (lifetime constraint), or MUTUAL_EXCLUSION (mutually exclusive constraint); constraint subtype (subtype), used to further subdivide the constraint type; scope (scope), specifying which operations or the entire device the constraint applies to; threshold (threshold), specifying the upper or lower limit of the constraint quantization; and description field (description), which explains the meaning of the constraint in natural language.

[0029] (3a) Time Constraints (constraint_type is TIME): Subtypes include minimum operation interval (MIN_INTERVAL) and minimum duration (MIN_DURATION). The minimum operation interval constraint requires that the time interval between two similar operations on the same device is not less than a specified value, such as the air conditioner compressor switching interval being not less than 500 milliseconds, and the cooling mode running for at least 3 minutes after startup before switching, to prevent damage from frequent compressor start-stop. The minimum duration constraint requires that after an operation takes effect, the state must be maintained for at least a specified duration before the opposite operation can be performed.

[0030] (3b) Energy Constraints (constraint_type is ENERGY): Subtypes include peak power (PEAK_POWER) and single operation energy consumption (PER_OP_ENERGY). Peak power constraints limit the instantaneous power of the device during operation to a specified threshold, such as the air conditioner's peak power not exceeding 2200 watts in this example. Single operation energy consumption constraints are for battery-powered devices, limiting the total energy consumption limit for a single operation.

[0031] (3c) Safety constraints (constraint_type is SAFETY): Subtypes include prohibiting operation when the user is present (PROHIBIT_WHEN_USER_PRESENT) and prohibiting operation under specific environmental conditions (PROHIBIT_WHEN_ENV_CONDITION). For example, in this case, the air conditioner is defined to prohibit automatically turning on the heating mode when the user is present to prevent scalding.

[0032] (3d) Lifetime Constraint (constraint_type is LIFETIME): The subtype is Maximum Operation Count (MAX_OPERATION_COUNT), which records the upper limit of the number of operations and the current cumulative number of executions. For example, in this case, the upper limit of the air conditioning mode switching operation is 50,000 times, and 12,453 times have been accumulated so far. When the remaining lifetime is less than 10%, the matching engine returns the operation and attaches a lifetime alarm flag.

[0033] (3e) Mutually exclusive constraints (constraint_type is MUTUAL_EXCLUSION): Used to identify combinations of operations that cannot be active simultaneously. The constraint object defines two mutually exclusive operation groups, group_A and group_B, through the scope field. When all operations in group_A are active, no operation in group_B can be executed. For example, in this case, the cooling mode and heating mode of the air conditioner are mutually exclusive.

[0034] (4) Feedback format definition (feedback_format) The feedback format defines standardized result fields returned after a device operation is executed, which must include at least: execution status (exec_status), with values ​​of SUCCESS, FAILURE, or PARTIAL; actual latency (actual_latency_ms); final state snapshot (final_states), which returns the current state of the device after the operation as a key-value pair of state name and state value; error code (error_code), which can be empty; and energy consumption for this operation (energy_joule), etc.

[0035] (5) Metadata Metadata records the document's own attributes, including: document source marker (source), which can be one of MANUFACTURER (official source from the manufacturer), COMMUNITY (source verified by the community), or AI_GENERATED (source generated by AI); digital signature (signature), used to verify the document's integrity and source authenticity; verification status marker (verification_status), which can be one of PASSED (passed consistency verification), PENDING (pending verification), or FAILED (verification failed); and last update time, etc.

[0036] Step 204: Upon receiving an intent instruction from an upper-layer application, parse the intent instruction to extract one or more execution targets.

[0037] In this embodiment, the input format of intent commands is uniformly a structured intent object, which includes the following fields: intent identifier (intent_id), used to globally and uniquely identify an intent; intent type (intent_type), which takes the value of one of the following: device control class (DEVICE_CONTROL), scene linkage class (SCENE_TRIGGER), or query class (QUERY); target area (target_area), which specifies the space where the device is located by the type and value pair, such as the type being ROOM and the value being living room; target device hint (target_device_hint), which gives the type of device the user expects to control in a string; target list (targets), which is an array of execution targets, each execution target containing a target category (goal), action description (action), and parameter set (params); priority (priority) and timeout duration (timeout_ms).

[0038] Taking a typical intent to turn on the living room air conditioner and set it to 24 degrees Celsius cooling mode as an example, the target list of its structured intent object contains three execution targets: (Target 1) goal is POWER_CONTROL, action is turn on, and parameter is empty; (Target 2) goal is TEMPERATURE_SET, action is set temperature, and parameter temp is 24; (Target 3) goal is MODE_SET, action is cooling mode, and parameter mode is COOL.

[0039] After receiving the structured intent object, the intent parsing module executes the following parsing process in sequence: Rule 1, Device Location: A candidate device set is filtered from the device registry based on the target region and target device hints. The device registry maintains the device identifier, device type enumeration value, region, and DCDL document storage path for each connected device. The filtering criteria are: the device's region exactly matches the target region, and the device type's alias list contains the target device hint or its synonym.

[0040] Rule 2, Target Splitting: Iterate through the target list array and generate an execution target object for each target element. This object contains three fields: target type (goal_type), directly taken from the target element's goal field; required parameters (required_params), directly taken from the target element's params field, with parameter values ​​standardized according to Rule 3; and priority, inherited from the intent object's priority field or a default value. Dependencies between multiple execution targets are implicitly represented by their order in the target list; targets appearing earlier are executed first, and the preconditions of subsequent targets can reference the result state of the preceding target.

[0041] Rule 3, Parameter Standardization: Convert parameter values ​​expressed in natural language by the user side into standard enumerated values ​​by the device side. For example, map the cooling mode to the enumerated value COOL, and compare the temperature value 24 with the range of target temperatures in the device's operable states to confirm it is within the acceptable range. Parameter standardization relies on an inverted index built from the list of aliases defined in the operation's DCDL document for each device. When the action description text in the intent matches an alias of an operation, an initial mapping relationship is established between the intent and that operation. The inverted index uses the alias string as the key and the list of operation identifiers as the value, supporting multi-word matching after Chinese word segmentation.

[0042] Following the above analysis process, this example outputs three execution target objects: Execution Target 1 (target category: POWER_CONTROL, required parameter: on=true), Execution Target 2 (target category: TEMPERATURE_SET, required parameter: temp=24.0), and Execution Target 3 (target category: MODE_SET, required parameter: mode=COOL). These three targets will be sequentially input into the capability matching process in subsequent step 206.

[0043] Step 206: Based on the capability description language document, perform capability matching on one or more extracted execution targets to determine the target operations from the target device that can achieve the execution targets.

[0044] The capability matching engine has five built-in matchers, organized in a cascaded pipeline in descending order of matching accuracy: precise matcher, parameter matcher, constraint-aware matcher, degradation matcher, and combinatorial matcher. The overall control logic of the matching engine is as follows: each execution target is sequentially fed into the pipeline; if the current matcher returns a non-empty result, the pipeline terminates and outputs the result; if it returns empty, the execution target is automatically fed to the next level matcher; if all five levels return empty, the execution target is determined to have failed to match in the current device set.

[0045] (a) Exact matcher The exact matcher uses all operations in the operation set of the DCDL document as its search space and the target category field of the execution target as the key. In this embodiment, the operation set is preprocessed into a hash index structure when the DCDL document is loaded. The hash index structure uses the operation identifier as the key and the operation definition object as the value. The matching rule of the exact matcher is: to search in the hash index for an operation whose operation identifier is exactly the same as the target category field of the execution target, and the alias list of the operation contains the action description field of the execution target. If both conditions are met, the exact match is successful, and the operation definition is returned directly.

[0046] For example, if the target category of Target 1 is POWER_CONTROL, and the operation identifier set_power is matched in the DCDL document of the smart air conditioner, and the action description of Target 1 is opened, which appears in the alias list of the set_power operation (including power on, turn on, turn_on, etc.), the exact match is successful, and the set_power operation is returned.

[0047] The average time complexity of the exact matcher is constant. In scenarios where the hash index fails, it degenerates into a linear traversal search of the operation set array, with the worst-case time complexity being linearly related to the number of operations in the operation set. To improve the success rate of exact matches, the alias list for each operation should cover as many common expressions for that operation as possible in both Chinese and English contexts.

[0048] (b) Parameter Matcher When the exact matcher returns null, the parameter matcher is invoked. The parameter matcher does not require the target category field to be exactly the same as the operation identifier. Instead, it iterates through each operation definition in the DCDL document operation set and checks whether its parameter signature is compatible with the parameters required by the target. The parameter compatibility judgment rules are: (1) The number of parameters of the target is equal to the length of the parameter list of the operation; (2) For each parameter at a corresponding position, the data type of the target parameter is the same as or can be implicitly converted to the data type of the operation parameter. Among them, integers can be implicitly promoted to floating-point types, and enumerated parameters require that the value of the target parameter belongs to one of the optional value sets of the operation enumerated parameters; (3) If the target parameter is numeric, its value must be within the range of values ​​defined by the operation parameter.

[0049] Let's take executing target two (target category TEMPERATURE_SET, parameter temp=24.0) as an example. If the exact matcher fails to match the set_temp operation (e.g., due to inconsistent operation identifier naming), the parameter matcher traverses the entire operation set and finds that the set_temp operation accepts a floating-point parameter temp with a value range of 16.0 to 30.0. The parameter temp=24.0 of target two is completely compatible, so the parameter match is successful, and the set_temp operation is returned.

[0050] (c) Constraint-aware matcher If the parameter matcher also returns null, or if further verification is required even after a successful parameter match, the constraint-aware matcher is invoked. The constraint-aware matcher applies five additional layers of physical constraint checks to the candidate operation obtained from the parameter match: time constraint check, energy constraint check, safety constraint check, lifetime constraint check, and mutual exclusion constraint check. These five checks are executed sequentially; if any check fails, subsequent checks are terminated, and the constraint-aware match is deemed a failure.

[0051] (c1) Time Constraint Validation: Filter all constraints with the major category "TIME" from the physical constraint set in the DCDL document. For the shortest operation interval subtype, retrieve the last execution timestamp of the same type of operation specified in the constraint's scope field from the device's operation history, and calculate the interval between the current time and the last execution time; if this interval is less than the constraint's threshold, the validation fails. For the minimum duration subtype, check whether the current device is in the active state of the operation and whether the duration has not reached the threshold.

[0052] (c2) Energy Constraint Verification: Select constraint items with the major category ENERGY from the physical constraint set. For the peak power subtype, obtain the current instantaneous power of the device (collected in real time by the current sensor or read from the device status as the cumulative power of the operations performed in this session), and sum it with the estimated additional power of the operation to be performed; if the sum exceeds the peak power threshold, the verification fails.

[0053] (c3) Safety Constraint Verification: Filter constraints from the physical constraint set that fall under the SAFETY category. For the subtype "Operation Prohibited in User Presence," read the current data from sensors indicating the presence of a human in the environment; if a user is detected and the operation to be performed falls within the scope of this constraint, the verification fails. For the subtype "Operation Prohibited under Specific Environmental Conditions," read environmental sensor data (e.g., temperature sensor, carbon monoxide sensor); if the current environmental state satisfies the conditional expression defined in the constraint, the verification fails.

[0054] (c4) Lifetime Constraint Verification: Filter constraints with the major category LIFETIME from the physical constraint set. Read the current count field and threshold field of the constraint and calculate the remaining lifetime percentage. In this embodiment, two judgment thresholds are set: if the remaining lifetime percentage is less than 10%, the matcher still returns the operation, but adds a lifetime alarm flag to the returned result; if the current count has reached the threshold, the verification fails.

[0055] (c5) Mutually Exclusive Constraint Verification: Filter constraints in the physical constraint set that fall under the category of MUTUAL_EXCLUSION. Obtain all currently active operation combinations on the device (i.e., combinations of operation identifiers and active parameters, determined jointly by the device status snapshot and operation history). Perform set inclusion checks on the currently active operation combination and the two mutually exclusive groups defined in the constraints: If the currently active operation combination is completely contained in group A, while the operation to be executed belongs to group B, then there is a mutual exclusion conflict, and the verification fails.

[0056] Candidate operations that pass all five layers of verification are returned by the constraint-aware matcher.

[0057] (d) Degradation Matcher When the constraint-aware matcher returns null, the degradation matcher is invoked. The degradation matcher does not require a return value that exactly corresponds to the execution target; instead, it searches for the most similar alternative operation by querying a pre-defined device capability similarity graph.

[0058] The device capability similarity graph is a weighted undirected graph data structure denoted as G=(V,E,W), where vertex V represents an atomic operation capability, uniquely identified by the combination of device type::operation identifier; edge E indicates that there is functional similarity between two operation capabilities; and weight W is a real value between 0 and 1, with a larger value indicating higher similarity.

[0059] In this embodiment, the construction rules for the device capability similarity graph are as follows: Rule A: Based on ontology hierarchical similarity, using the inheritance tree structure of device types, the similarity weight between sibling type nodes is 0.3, and the similarity weight between parent and child type nodes is 0.5; Rule B: Based on the similarity of operation effects, calculate the Jaccard coefficient (i.e., intersection size divided by union size) of the state variable sets modified by each of the two operations. If the coefficient is greater than or equal to 0.5, the similarity weight is taken from this coefficient value; Rule C: Based on the similarity of parameter signatures, if the input parameter type vectors of the two operations are completely identical, the similarity weight is taken as 0.4; if the parameter types are compatible but not completely identical, it is taken as 0.2. The final edge weight is the weighted sum of the weights obtained from the above rules A, B, and C, with weighting coefficients of 0.3, 0.4, and 0.3, respectively.

[0060] The matching process of the downgrade matcher is as follows: First, construct a query node in the device capability similarity graph corresponding to the current execution target. The device type of this node is taken from the device type field of the current DCDL document, and the operation category is taken from the target category field of the execution target. Second, query all neighbor nodes of this node in the graph, filter neighbor nodes with similarity weight greater than or equal to a preset threshold (0.4 in this embodiment), and sort them in descending order of similarity weight. Then, traverse the list of neighbor nodes in turn. For each neighbor node, check whether there is a corresponding operation definition in the operation set of the current DCDL document. If there is, call the five-layer verification logic of the constraint-aware matcher to verify the feasibility of the operation. Finally, return the first operation that passes the feasibility verification as the replacement operation, and attach a downgrade mark to the returned result. This mark includes the original execution target category, the similarity weight of the downgraded operation, and the downgrade reason explanation text, such as downgrade matching: functional approximation replacement.

[0061] Taking a typical downgraded matching scenario as an example: The user's intent is to adjust the color temperature (target category is COLOR_TEMP_ADJUST), but the target bulb's DCDL document operation set does not include color temperature adjustment. In the device capability similarity graph, using the vertex LIGHT::COLOR_TEMP_ADJUST as the query node, its nearest neighbor is found to be LIGHT::BRIGHTNESS_ADJUST (similarity weight 0.6, derived from operation effect similarity calculation; both affect the ambient effect state). The downgraded matcher finds that the bulb supports brightness adjustment and passes constraint verification, therefore returning the set_brightness operation with a downgraded flag, so that the intent to adjust the color temperature is approximately achieved in the form of adjusting brightness.

[0062] (e) Combination Matcher When an execution target is marked as a composite target (i.e., its target category field indicates that the target consists of multiple sub-targets), and the first four level matchers all return null, the composite matcher is invoked. The composite matcher breaks the composite target into a list of sub-targets, independently invokes the first four level matchers for each sub-target, and arranges the matching results of each sub-target into a cooperative execution sequence with execution order constraints.

[0063] The matching process of the composite matcher is as follows: First, sub-target splitting: Read the list of sub-targets of the composite target. Each sub-target has an independent target category and required parameters; the order of the sub-targets implies the execution priority. Second, independent matching: For each sub-target, sequentially call the exact matcher, parameter matcher, constraint-aware matcher, and degraded matcher, forming a <device, operation, parameter> triple with the matched operation and device identifier. If any sub-target returns null in the first four levels of matchers, the entire composite matching fails. Third, construct a directed acyclic graph (DAG) for... For each successfully matched sub-target, a node is created in the graph. The data payload of the node is a triple of <device identifier, operation identifier, execution parameters>. Directed edges are added according to the order of the sub-targets in the original list. If sub-target A is in the list before sub-target B, a directed edge is added from the node corresponding to A to the node corresponding to B, indicating that A must be executed before B. The fourth step is topological sorting. The directed acyclic graph is topologically sorted using the Kahn algorithm or depth-first search to generate a linear execution sequence. Nodes in this sequence that do not have dependencies can be marked as parallel execution.

[0064] Let's take the complex intention of creating a movie-watching atmosphere as an example. This complex goal includes three sub-goals: sub-goal one, turn off the main light; sub-goal two, turn on the backlight strip and set it to warm yellow light; and sub-goal three, lower the projection screen. The combined matcher performs independent matching on each of the three sub-goals: sub-goal one matches the `set_power` operation of the main light device (parameter `on` is false); sub-goal two matches two operation sequences of the backlight strip device, `set_power` (parameter `on` is true) and `set_color` (parameters `hue` value 30, saturation value 80); and sub-goal three matches the `lower` operation of the projection screen device. After constructing a directed acyclic graph, the topological sorting outputs the execution sequence: first, the command to lower the screen is issued (taking about 3 seconds, prioritized to utilize the mechanical action time); after the screen is in place, the command to turn off the main light is issued (turning off the light after the screen is obscured does not affect the user experience); simultaneously, the commands to turn on the backlight strip and set the color are issued in parallel (these two do not depend on the screen and main light states).

[0065] After completing the five-level matching process, the matching engine returns the matched target operation to the upper-layer application, which then distributes it to the target device for execution via a device communication protocol (such as Matter, MQTT, etc.). Once the device completes execution, it returns the execution result to the matching engine according to the standard fields defined in the feedback format in the DCDL document. The matching engine updates the device status snapshot and operation history based on the execution result, providing the latest device status information for subsequent matching.

[0066] The aforementioned device capability description method introduces a standardized capability description document containing five elements of physical constraints. Based on this document, it performs a matching process from intent to device operation, enabling upper-layer applications to automatically understand the device's capability boundaries and security limitations without hard-coding adaptation logic. Compared to existing technologies where each application needs to develop a separate driver for each device, this method significantly reduces integration costs. Compared to protocols such as Matter that only describe the operation interface, this method additionally considers physical constraints, avoiding security incidents or device damage caused by ignoring physical limitations. This method decouples the intent layer from the device layer, providing a standardized bridge for large-scale artificial intelligence control of physical devices.

[0067] In one embodiment, capability matching includes five strategies: exact matching, parameter matching, constraint-aware matching, degraded matching, and combined matching. The matching engine attempts these five strategies sequentially, from highest to lowest matching precision, until a target operation is successfully matched or a matching failure is determined. Degraded matching means that when no operation exactly corresponds to the execution target exists, a similar functional alternative operation is sought; combined matching means that when a single device cannot achieve the execution target, operations from multiple devices are combined to jointly achieve the execution target.

[0068] In one embodiment, for each execution target, exact matching is performed. If an operation name corresponds to the execution target, the match is successful. If the exact matching fails, parameter matching is performed to find operations that support parameters that match the execution target. If parameter matching fails, constraint-aware matching is performed to find operations that can achieve the execution target while satisfying physical constraint information. If constraint-aware matching fails, degraded matching is initiated to find alternative operations with similar functions. If degraded matching fails, for an execution target consisting of multiple sub-targets, combined matching is initiated to match operations for each sub-target and combine them into a cooperative execution sequence.

[0069] In another embodiment, the algorithm complexity of exact matching is logarithmic; downgrade matching includes searching for alternative operations with similar functions based on a preset device capability similarity graph; and combination matching includes arranging the cooperative execution sequence based on a directed acyclic graph.

[0070] In one embodiment, physical constraint information is described in detail. Time constraints include a minimum operation interval and a minimum duration. The minimum operation interval represents the minimum time a device must wait between two identical or mutually exclusive operations; for example, an air conditioner compressor needs at least 3 minutes to restart after being stopped. This constraint prevents equipment damage. The minimum duration represents the minimum time an operation, once performed, must remain in that state before a subsequent reverse operation can be performed; for example, an oven preheating operation needs to last at least 30 seconds to reach a stable temperature.

[0071] Energy constraints include peak power and maximum single-use power consumption. Peak power constraints prevent the instantaneous power consumption of a device from exceeding a certain threshold during operation. For example, if a smart socket has a maximum load of 2200 watts, and an intent command requests the simultaneous operation of two appliances with a combined power exceeding this value, the constraint-aware matching will reject the operation or prompt the user to divert power. Maximum single-use power consumption constraints are used for battery-powered devices. For example, the energy consumption of a complete vacuuming operation must not exceed 20% of the battery capacity to prevent the device from being unable to maintain basic communication due to depleting the battery in a single task.

[0072] Safety constraints include prohibiting operation in the presence of a user or disabling operation in specific environments. For example, a robot vacuum cleaner should not start automatic cleaning when a user is present and their feet are close, to prevent tangling or collisions. Similarly, a gas water heater should not start heating operation if it detects excessive indoor carbon monoxide levels.

[0073] Lifespan constraints are used to record the maximum number of operations. For example, the motor of an electric curtain is designed to last for 20,000 opening and closing cycles. This constraint is recorded in the capability description document. When the limit is approached, the matching engine can prioritize alternative operations or issue a maintenance reminder to the user.

[0074] Mutually exclusive constraints are used to identify pairs of operations that cannot be performed simultaneously. For example, the cooling and heating modes of the same air conditioner cannot be turned on at the same time; the cool white light and warm yellow light of the same lamp cannot be output at 100% brightness at the same time. When an intent command requires the simultaneous execution of mutually exclusive operations, the matching engine will serialize the processing or indicate a conflict.

[0075] In one embodiment, the extended characteristics of device type information are described. Device type information uses standardized enumeration types, such as LIGHT, AC, and AIR_PURIFIER, and is compatible with existing IoT communication protocols such as the device type set defined in Matter, ensuring interoperability with the existing ecosystem. Device type information supports nested types to represent system-level devices containing multiple sub-devices. For example, a smart home hub device may contain three sub-devices: a gateway, an infrared transmitter, and an environmental sensor. The capability description document can define the hub device type as a nested type, with each sub-device describing its own capabilities. A type inheritance mechanism allows attributes of general device types to be automatically passed to specific device types. For example, a general device type "Light" is defined, containing the basic operations `set_on` and `set_brightness`; a specific device type "Colored Light" inherits from "Light," automatically acquiring these two operations and adding the `set_color` operation. This inheritance mechanism significantly reduces the workload of redundant descriptions and ensures consistency in device capability descriptions.

[0076] In one embodiment, the capability description language document carries a hierarchical source tag and a verification status tag. The hierarchical source includes three categories: official manufacturer source, community-verified source, and AI-assisted generated source. Official manufacturer sources refer to documents officially released and digitally signed by the device manufacturer, with the highest credibility. Community-verified sources refer to documents written by open-source communities or third-party developers based on device reverse engineering or public documentation, and verified by multiple reviewers, with medium credibility. AI-assisted generated sources refer to documents automatically generated by an artificial intelligence system based on device behavior observations, with lower credibility but serving as a starting point for rapid integration. Each document also carries a verification status tag to indicate whether the document has passed consistency checks. Consistency checks include syntax checks (e.g., conforming to DCDL format specifications), logic checks (e.g., whether declared operations match state variables), and practical test checks (e.g., sampling execution on a real device and verifying feedback). When matching capabilities, the matching engine can prioritize documents with higher source tags and verification statuses based on the application's reliability requirements. For example, for security-critical operations, only documents from official manufacturer sources that have passed verification are allowed.

[0077] In one embodiment, such as Figure 3As shown, a device capability description apparatus is provided, which includes a document acquisition module 302, an intent parsing module 304, and a capability matching module 306.

[0078] The document acquisition module 302 is used to acquire the capability description language document of the target device. This capability description language document includes device type information, operability status information, operation method information, physical constraint information, and feedback format information. The physical constraint information includes at least one or more of time constraints, energy constraints, safety constraints, lifetime constraints, and mutually exclusive constraints, used to define the physical limitations that the target device cannot violate when performing operations.

[0079] The intent parsing module 304 is used to parse the intent instruction issued by the upper layer application to extract one or more execution targets when it receives the intent instruction.

[0080] The capability matching module 306 is used to perform capability matching on the execution target based on the capability description language document, so as to determine the target operation that can achieve the execution target from the target device.

[0081] Specific limitations regarding the device capability description apparatus can be found in the limitations of the device capability description method described above, and will not be repeated here. Each module in the aforementioned device capability description apparatus can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in the computer device in hardware form, or stored in the memory of the computer device in software form, so that the processor can call and execute the operations corresponding to each module.

[0082] In one embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 4 As shown, the computer device includes a processor, memory, network interface, and database connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and database. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage media. The database stores a device capability description language document library. The network interface communicates with external terminals via a network connection. When executed by the processor, the computer program implements a device capability description method.

[0083] Those skilled in the art will understand that Figure 4The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0084] In one embodiment, a computer device is provided, including a memory and a processor. The memory stores a computer program, and the processor executes the computer program to perform the following steps: obtaining a capability description language document of a target device; the capability description language document includes device type information, operability status information, operation method information, physical constraint information, and feedback format information; the physical constraint information includes at least one or more of time constraints, energy constraints, security constraints, lifetime constraints, and mutual exclusion constraints; upon receiving an intent instruction from an upper-layer application, parsing the intent instruction to extract one or more execution targets; and performing capability matching on the execution targets according to the capability description language document to determine the target operation from the target device that can achieve the execution target.

[0085] In one embodiment, when the processor executes the computer program, it further performs the following steps: in descending order of matching precision, it attempts exact matching, parameter matching, constraint-aware matching, degraded matching, and combined matching until the target operation is matched or the matching fails; wherein degraded matching means that when there is no operation that exactly corresponds to the execution target, it searches for a substitute operation with similar function; combined matching means that when a single device cannot achieve the execution target, it selects a combination of operations from multiple devices to jointly achieve the execution target.

[0086] In one embodiment, when the processor executes the computer program, it further performs the following steps: for each execution target, it performs exact matching; if there is an operation whose name corresponds to the execution target, the match is successful; if exact matching fails, it performs parameter matching to find an operation that supports the parameters required by the execution target; if parameter matching fails, it performs constraint-aware matching to find an operation that can achieve the execution target while satisfying the physical constraint information; if constraint-aware matching fails, it initiates degraded matching to find a substitute operation with similar function; if degraded matching fails, for an execution target consisting of multiple sub-targets, it initiates combined matching to match operations for each sub-target and combine them into a cooperative execution sequence.

[0087] In one embodiment, a computer-readable storage medium is provided, on which a computer program is stored. When the computer program is executed by a processor, it performs the following steps: obtaining a capability description language document of a target device; the capability description language document includes device type information, operability status information, operation method information, physical constraint information, and feedback format information; the physical constraint information includes at least one or more of time constraints, energy constraints, safety constraints, lifetime constraints, and mutual exclusion constraints; upon receiving an intent instruction from an upper-layer application, parsing the intent instruction to extract one or more execution targets; and performing capability matching on the execution targets according to the capability description language document to determine the target operation from the target device that can achieve the execution target.

[0088] In one embodiment, when the computer program is executed by the processor, it further performs the following steps: in descending order of matching precision, it attempts exact matching, parameter matching, constraint-aware matching, degraded matching, and combined matching until the target operation is matched or the matching fails; wherein degraded matching means that when there is no operation that exactly corresponds to the execution target, it searches for a substitute operation with similar function; combined matching means that when a single device cannot achieve the execution target, it selects a combination of operations from multiple devices to jointly achieve the execution target.

[0089] In one embodiment, when the computer program is executed by the processor, it further implements the following steps: for each execution target, perform exact matching; if there is an operation whose name corresponds to the execution target, the match is successful; if exact matching fails, perform parameter matching to find an operation that supports the parameters required by the execution target; if parameter matching fails, perform constraint-aware matching to find an operation that can achieve the execution target while satisfying the physical constraint information; if constraint-aware matching fails, initiate degraded matching to find a substitute operation with similar function; if degraded matching fails, for an execution target consisting of multiple sub-targets, initiate combined matching to match operations for each sub-target and combine them into a cooperative execution sequence.

[0090] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the embodiments provided in this application can include both non-volatile and volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), Rambus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.

[0091] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0092] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of the invention. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A method for describing equipment capabilities, characterized in that, The method includes: Obtain a capability description language document for the target device; the capability description language document includes device type information, operability status information, operation method information, physical constraint information, and feedback format information; the physical constraint information includes at least one or more of time constraints, energy constraints, safety constraints, lifetime constraints, and mutually exclusive constraints, and the physical constraint information is used to limit the physical limitations that the target device cannot violate when performing operations; Upon receiving an intent instruction from an upper-layer application, the intent instruction is parsed to extract one or more execution targets; Based on the capability description language document, capability matching is performed on the one or more execution targets to determine the target operations from the target devices that can achieve the execution targets.

2. The method according to claim 1, characterized in that, The capability matching includes precise matching, parameter matching, constraint-aware matching, degradation matching, and combined matching; The method further includes: sequentially attempting precise matching, parameter matching, constraint-aware matching, degraded matching, and combined matching in descending order of matching accuracy, until the target operation is matched or the matching fails; The downgrade matching refers to finding a similar alternative operation when there is no operation that exactly corresponds to the execution target; The combination matching means that when a single device cannot achieve the execution goal, a combination of operations from multiple devices is selected to jointly achieve the execution goal.

3. The method according to claim 2, characterized in that, Based on the capability description language document, capability matching is performed on the one or more execution targets, including: For each execution target, perform the exact match; if there is an operation whose name corresponds to the execution target, the match is successful. If the exact match fails, then the parameter matching is performed to find operations that support the parameters required by the execution target; If the parameter matching fails, the constraint-aware matching is performed to find an operation that can achieve the execution goal, provided that the physical constraint information is satisfied. If the constraint-aware matching fails, then the degradation matching is initiated to find alternative operations with similar functions; If the downgrade matching fails, then for the execution target consisting of multiple sub-targets, the combination matching is initiated, matching operations are performed on each sub-target separately, and combined into a collaborative execution sequence.

4. The method according to claim 3, characterized in that, The algorithm for precise matching has a logarithmic complexity. The downgrade matching includes searching for alternative operations with similar functions based on a preset device capability similarity graph; The combined matching includes orchestrating the cooperative execution sequence based on a directed acyclic graph.

5. The method according to claim 1, characterized in that, The time constraints in the physical constraint information include the shortest operation interval and the minimum duration. The energy constraints include peak power and maximum energy consumption per operation; the safety constraints include prohibiting operation in the presence of the user or disabling operation in specific environments. The lifetime constraint includes an upper limit on the number of operations; the mutual exclusion constraint is used to identify operation pairs that cannot be started simultaneously.

6. The method according to claim 1, characterized in that, The device type information is a standardized enumeration type and is compatible with the existing IoT communication protocol type set; The device type information supports nested types and type inheritance; nested types are used to represent system-level devices that contain multiple sub-devices, and type inheritance is used to automatically pass the attributes of a general device type to its specific device type.

7. The method according to claim 1, characterized in that, The capability description language document carries a hierarchical source marker and a verification status marker; the hierarchical source includes official manufacturer sources, community verification sources, and AI-assisted generation sources; the verification status marker is used to indicate whether the capability description language document has passed the consistency check.

8. A device for describing equipment capabilities, characterized in that, The device includes: The document acquisition module is used to acquire the capability description language document of the target device; the capability description language document includes device type information, operability status information, operation method information, physical constraint information, and feedback format information; the physical constraint information includes at least one or more of time constraints, energy constraints, safety constraints, lifetime constraints, and mutually exclusive constraints, and the physical constraint information is used to limit the physical restrictions that the target device cannot violate when performing operations; The intent parsing module is used to parse the intent instruction issued by the upper-layer application to extract one or more execution targets when it receives the intent instruction. The capability matching module is used to perform capability matching on the one or more execution targets according to the capability description language document, so as to determine the target operation that can achieve the execution target from the target device.

9. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 7.

Images