Device linkage method, electronic device, vehicle, storage medium, and program product

Abstract

The application provides a device linkage method, an electronic device, a vehicle, a storage medium and a program product, and relates to the field of vehicles. The method determines a rule description file in response to a user's custom editing operation on a linkage rule, compiles the rule description file into an edge linkage package including bytecode, a capability whitelist, a private protocol codec script and a signature, performs semantic level difference processing on the edge linkage package according to an old version edge linkage package corresponding to the linkage rule to obtain a difference package, and sends the difference package to a host side device. The linkage rule can be generated, verified and incrementally issued in a form more suitable for edge side execution, thereby reducing resource occupation and maintenance cost in the process of rule updating and deployment, and improving the reliability of continuous execution of the linkage rule in a complex edge scene and the adaptation capability to multi-brand and multi-protocol devices.

Description

Technical Field

[0001] This invention relates to the technical field of edge computing for the Internet of Things, specifically to a device linkage method, electronic device, vehicle, storage medium, and program product. Background Technology

[0002] Related IoT linkages often employ cloud-based rule engines, page script execution, or native host integration to achieve automated control across devices.

[0003] However, the above methods are generally constrained by network conditions and host operation status in edge scenarios such as vehicle cockpits and home gateways. The continuity of linkage is insufficient when the network is weak or disconnected, and the stability of rule execution decreases after the host goes to the background or the screen is turned off. At the same time, when facing devices of multiple brands and protocols, adaptation and changes often rely on a heavy operating environment or redeployment, making it difficult to balance resource consumption, maintenance costs and expansion efficiency.

[0004] Therefore, how to improve the continuous execution reliability of IoT linkage rules in complex edge scenarios, while taking into account resource consumption and heterogeneous device adaptability, has become a technical problem that needs to be solved. Summary of the Invention

[0005] This application provides a device linkage method, electronic device, vehicle, storage medium, and program product. The method is aimed at the cloud side to uniformly generate and manage the version of linkage rules, and converts user-defined linkage logic into rule results suitable for execution and updating on the edge side for distribution. This enables linkage rules to be deployed and evolved more efficiently in edge scenarios, and takes into account the reliability, resource consumption, and heterogeneous adaptation requirements of linkage execution under complex network environments and multi-type device access conditions.

[0006] Firstly, this application provides a device linkage method applied to cloud-side devices, the method comprising:

[0007] In response to the user's custom editing of the linkage rules, determine the rule description file;

[0008] The rule description file is compiled into an edge linkage package, which includes bytecode, capability whitelist, private protocol encoding / decoding script and signature;

[0009] Based on the old version edge linkage package corresponding to the linkage rule, semantic-level differential processing is performed on the edge linkage package to obtain the differential package of the linkage rule;

[0010] Send differential packets to the host device.

[0011] In one possible implementation, the rule description file is compiled into an edge linkage package, including:

[0012] Perform field validation on the rule description file to obtain the validation results, which include validation passed and validation failed.

[0013] If the verification result is successful, the rule description file is sequentially subjected to de-visualization stripping and abstract syntax tree generation to obtain the rule abstract syntax tree.

[0014] The rule abstract syntax tree is converted into a sequence of semantic bytecode instructions for the object model to obtain the corresponding bytecode;

[0015] Based on the rules, abstract the syntax tree and bytecode to generate edge linkage packages.

[0016] In one possible implementation, an edge-linked package is generated based on the rule abstract syntax tree and bytecode, including:

[0017] The rule abstract syntax tree is processed to identify capability fields, resulting in a capability whitelist.

[0018] The private protocol device field in the rule abstract syntax tree is identified, and the identified private protocol device field is compiled to obtain the private protocol encoding / decoding script;

[0019] Signature processing is performed on multiple first data segments to obtain a signature. The multiple first data segments include at least one of bytecode, capability whitelist, private protocol encoding / decoding script, preset bytecode instruction set and preset mapping index table.

[0020] Based on multiple first data segments and signatures, an edge linkage package is generated.

[0021] In one possible implementation, based on the old version edge linkage package corresponding to the linkage rule, semantic-level differential processing is performed on the edge linkage package to obtain a differential package, including:

[0022] Based on the old version edge linkage package corresponding to the linkage rules, determine multiple second data segments;

[0023] Based on multiple second data segments, semantic-level difference comparison processing is performed on multiple first data segments in the edge linkage package to obtain difference data;

[0024] The difference data is encapsulated to obtain a difference package.

[0025] Secondly, this application provides a device linkage method applied to a host-side device, the method comprising:

[0026] Receive differential packets sent by cloud-side devices, and determine edge linkage packets based on differential packets. Edge linkage packets include bytecode, capability whitelist, private protocol encoding / decoding scripts, and signatures.

[0027] Device status events are received via the virtual device bus, and the device status events are processed according to rules based on the edge linkage packets to generate device control commands.

[0028] Perform link arbitration on the device control commands to obtain the target link;

[0029] Device control commands are sent through the target link.

[0030] In one possible implementation, based on the edge linkage packet, the device status events are processed according to rules to generate device control commands, including:

[0031] In response to receiving a device status event, dynamically load the private protocol encoding / decoding script;

[0032] Execute the private protocol encoding / decoding script to encode and decode the protocol data carried in the device status event to obtain the standard object model field;

[0033] Based on standard object model fields, rule execution processing is performed on device status events to generate device control commands.

[0034] In one possible implementation, based on standard object model fields, rule execution processing is performed on device status events to generate device control instructions, including:

[0035] Determine whether the standard product model field exists in the capability whitelist;

[0036] If so, based on the standard object model fields, perform rule execution processing on the device status events to generate device control commands;

[0037] If not, record the interception command information, call stack information, timestamp information, and device information, generate an audit log, and upload the audit log to the cloud.

[0038] In one possible implementation, link arbitration is performed on the device control commands to obtain the target link, including:

[0039] Based on the device control instructions, the score values ​​corresponding to multiple links are determined respectively. These multiple links include cloud links, local area network links, and near-field links.

[0040] The link with the highest score among multiple links is identified as the target link.

[0041] In one possible implementation, the method further includes, prior to rule enforcement processing of device status events:

[0042] Obtain a directed acyclic graph (DAG), which is constructed by using multiple object model attributes as nodes and the read / write dependencies between attributes as edges.

[0043] Based on the directed acyclic graph, detect write conflicts caused by multiple linkage rules in the host device targeting the same object model attribute;

[0044] Based on the rule priority declaration and physical mutex lock, arbitration is performed on linkage rules with write conflicts to determine the target linkage rule.

[0045] Thirdly, this application provides a device linkage apparatus, the apparatus comprising:

[0046] The determination module is used to determine the rule description file in response to the user's custom editing operation on the linkage rules;

[0047] The compilation module is used to compile the rule description file into an edge linkage package, which includes bytecode, capability whitelist, private protocol encoding and decoding scripts, and signatures.

[0048] The processing module is used to perform semantic-level differential processing on the edge linkage package based on the old version edge linkage package corresponding to the linkage rule, so as to obtain the differential package of the linkage rule.

[0049] The sending module is used to send differential packets to the host-side device.

[0050] In one possible implementation, the compilation module is specifically used for:

[0051] Perform field validation on the rule description file to obtain the validation results, which include validation passed and validation failed.

[0052] If the verification result is successful, the rule description file is sequentially subjected to de-visualization stripping and abstract syntax tree generation to obtain the rule abstract syntax tree.

[0053] The rule abstract syntax tree is converted into a sequence of semantic bytecode instructions for the object model to obtain the corresponding bytecode;

[0054] Based on the rules, abstract the syntax tree and bytecode to generate edge linkage packages.

[0055] In one possible implementation, the compilation module is specifically used for:

[0056] The rule abstract syntax tree is processed to identify capability fields, resulting in a capability whitelist.

[0057] The private protocol device field in the rule abstract syntax tree is identified, and the identified private protocol device field is compiled to obtain the private protocol encoding / decoding script;

[0058] Signature processing is performed on multiple first data segments to obtain a signature. The multiple first data segments include at least one of bytecode, capability whitelist, private protocol encoding / decoding script, preset bytecode instruction set and preset mapping index table.

[0059] Based on multiple first data segments and signatures, an edge linkage package is generated.

[0060] In one possible implementation, the sending module is specifically used for:

[0061] Based on the old version edge linkage package corresponding to the linkage rules, determine multiple second data segments;

[0062] Based on multiple second data segments, semantic-level difference comparison processing is performed on multiple first data segments in the edge linkage package to obtain difference data;

[0063] The difference data is encapsulated to obtain a difference package.

[0064] Fourthly, this application provides a device linkage apparatus applied to a host-side device, the apparatus comprising:

[0065] The determination module is used to receive differential packets sent by cloud-side devices and determine edge linkage packets based on the differential packets. The edge linkage packets include bytecode, capability whitelist, private protocol encoding and decoding scripts, and signatures.

[0066] The processing module is used to receive device status events through the virtual device bus, and perform rule execution processing on the device status events according to the edge linkage packet to generate device control commands.

[0067] The arbitration module is used to perform link arbitration on device control commands to obtain the target link;

[0068] The sending module is used to send device control commands through the target link.

[0069] In one possible implementation, the processing module is specifically used for:

[0070] In response to receiving a device status event, dynamically load the private protocol encoding / decoding script;

[0071] Execute the private protocol encoding / decoding script to encode and decode the protocol data carried in the device status event to obtain the standard object model field;

[0072] Based on standard object model fields, rule execution processing is performed on device status events to generate device control commands.

[0073] In one possible implementation, the processing module is specifically used for:

[0074] Determine whether the standard product model field exists in the capability whitelist;

[0075] If so, based on the standard object model fields, perform rule execution processing on the device status events to generate device control commands;

[0076] If not, record the interception command information, call stack information, timestamp information, and device information, generate an audit log, and upload the audit log to the cloud.

[0077] In one possible implementation, the arbitration module is specifically used for:

[0078] Based on the device control instructions, the score values ​​corresponding to multiple links are determined respectively. These multiple links include cloud links, local area network links, and near-field links.

[0079] The link with the highest score among multiple links is identified as the target link.

[0080] In one possible implementation, the device further includes a detection module before performing rule enforcement processing on device status events. The detection module is used to:

[0081] Obtain a directed acyclic graph (DAG), which is constructed by using multiple object model attributes as nodes and the read / write dependencies between attributes as edges.

[0082] Based on the directed acyclic graph, detect write conflicts caused by multiple linkage rules in the host device targeting the same object model attribute;

[0083] Based on the rule priority declaration and physical mutex lock, arbitration is performed on linkage rules with write conflicts to determine the target linkage rule.

[0084] Fifthly, this application provides an electronic device, including: a memory and a processor;

[0085] The memory stores instructions that the computer executes;

[0086] The processor executes computer execution instructions stored in memory, causing the processor to perform the method as described in any of the first aspects.

[0087] Sixthly, this application provides a vehicle including a vehicle body, an onboard air conditioner, and a controller, the controller being used to perform the method of any of the first aspects.

[0088] In a seventh aspect, this application provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the method as described in any of the first aspects.

[0089] Eighthly, this application provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the method as described in any of the second aspects.

[0090] Ninthly, this application provides a computer program product, including a computer program that, when executed by a processor, implements the method of any one of the first aspects.

[0091] In a tenth aspect, this application provides a computer program product, including a computer program that, when executed by a processor, implements the method of any one of the first aspects.

[0092] The beneficial effects of this invention are:

[0093] This application provides a device linkage method, electronic device, vehicle, storage medium, and program product. The method determines a rule description file in response to a user's custom editing operation on linkage rules, compiles the rule description file into an edge linkage package including bytecode, capability whitelist, private protocol encoding / decoding script, and signature, and then performs semantic-level differential processing on the edge linkage package according to the old version edge linkage package corresponding to the linkage rule to obtain a differential package and sends it to the host device. This enables the linkage rules to be generated, verified, and incrementally distributed in a form more suitable for edge execution, thereby reducing resource consumption and maintenance costs during rule updates and deployment, improving the reliability of continuous execution of linkage rules in complex edge scenarios, and enhancing the adaptability to multi-brand and multi-protocol devices. Attached Figure Description

[0094] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0095] Figure 1 This application provides a schematic diagram of the architecture of a device linkage system.

[0096] Figure 2 A flowchart illustrating a device linkage method provided in this application Figure 1 ;

[0097] Figure 3 A flowchart illustrating a device linkage method provided in this application Figure 2 ;

[0098] Figure 4 A flowchart illustrating a device linkage method provided in this application Figure 3 ;

[0099] Figure 5 A schematic diagram of a conflict detection and arbitration process provided for this application;

[0100] Figure 6 A flowchart illustrating a device linkage method provided in this application Figure 4 ;

[0101] Figure 7is a schematic flowchart of a device linkage method provided in the present application Figure 5 ;

[0102] Figure 8 is a schematic structural diagram of a device linkage apparatus provided in an embodiment of the present application;

[0103] Figure 9 is a schematic structural diagram of another device linkage apparatus provided in an embodiment of the present application;

[0104] Figure 10 is a schematic structural diagram of an electronic device provided in an embodiment of the present application.

[0105] The foregoing drawings have clearly illustrated the embodiments of the present application, which will be described in more detail hereinafter. These drawings and written descriptions are not intended to limit the scope of the concept of the present application in any manner, but to explain the concept of the present application to those skilled in the art by reference to specific embodiments. Detailed Description of the Preferred Embodiments

[0106] Hereinafter, the embodiments of the present invention will be described with reference to the accompanying drawings and preferred embodiments, and those skilled in the art can readily appreciate other advantages and effects of the present invention from the disclosure of the present specification. The present invention may also be implemented or applied in other different specific embodiments, and various modifications and alterations to the details in the present specification may be made based on different viewpoints and applications without departing from the spirit of the present invention. It should be understood that the preferred embodiments are merely provided to illustrate the present invention, not to limit the protection scope of the present invention.

[0107] Internet of Things linkage control technology is usually applied in edge scenarios such as vehicle-mounted smart cabins and smart home gateways, to realize automatic linkage between sensing, judgment and control after a host device accesses multi-brand and multi-protocol terminals. Such scenarios usually involve data interaction and rule distribution among cloud-side devices, host-side devices and controlled terminals at the same time.

[0108] Related Internet of Things linkage solutions are mainly implemented through a cloud rule engine, page script execution or native host integration. After a user configures a linkage rule on the platform side, the cloud usually parses the rule and issues a control instruction to the terminal, or binds the linkage logic to a visualized page operating environment for execution, or directly solidifies the rule logic into the host program.

[0109] The above solutions can achieve basic linkage when the network is stable and the device type is simple. However, in scenarios with weak networks, network outages, or when the host is moved to the background, such as in vehicle cockpits or home gateways, the continuity of rule execution is prone to decline. In particular, when the linkage logic relies on cloud-based online processing, network interruptions will cause the control link to fail; when the logic relies on the page runtime environment, linkage is difficult to continue after the page exits, the screen is turned off, or resources are recycled; when using the host's native integration method, the access of multi-protocol devices and rule changes often require re-adaptation or redeployment.

[0110] The resulting impact is that linkage control in edge scenarios struggles to simultaneously ensure continuous and reliable execution, controllable resource consumption, and rapid adaptation to heterogeneous devices. Rule update efficiency is also easily limited, which in turn affects the automation experience and system maintenance costs.

[0111] In view of this, how to improve the reliability of continuous execution of linkage rules in complex edge scenarios, while taking into account the efficiency of rule updates and the ability to adapt to heterogeneous protocols, has become an urgent technical problem to be solved.

[0112] To address the aforementioned issues, a device linkage method is provided. After the cloud-side device responds to the user's custom editing operation on the linkage rules, it determines the rule description file and compiles it into an edge linkage package including bytecode, a capability whitelist, a private protocol encoding / decoding script, and a signature. Subsequently, based on the older version of the edge linkage package corresponding to the linkage rule, semantic-level differential processing is performed on the edge linkage package to obtain a differential packet of the linkage rule, which is then sent to the host-side device. In scenarios such as in-vehicle smart cockpits, smart home gateways, and industrial edge gateways, the host device typically needs to connect to devices with different links and protocols, such as Bluetooth, Wireless Fidelity (Wi-Fi), Message Queuing Telemetry Transport (MQTT), and Controller Area Network (CAN). This technical approach, by completing the compilation and differential generation of the rule description file to the edge linkage package on the cloud side, enables the linkage rules to be distributed to the host-side device in a form more suitable for edge execution and updates, thus providing a foundation for stable linkage control in complex network and heterogeneous device environments.

[0113] Below, in conjunction with Figure 1 The system architecture corresponding to the device linkage method is illustrated with an example.

[0114] Figure 1 This is a schematic diagram of the architecture of a device linkage system provided in an embodiment of this application. Please refer to [link / reference]. Figure 1 , Figure 1This can include cloud-side devices, host-side devices, host virtual device buses, and IoT devices.

[0115] The cloud-side device can be deployed on a cloud server and includes a visual editor, rule compiler, object model repository, incremental packaging service, and signature and key modules. The cloud-side device can receive user-configured device linkage rules, compile and process these rules, extract permissions, compile protocol modules, sign and incrementally package them to generate edge rule packages, and then distribute them to the host-side device.

[0116] The host-side device can run locally on the host device and is equipped with an edge headless execution engine. The host-side device can include an event bus subscription module, a bytecode interpreter, a channel routing module, an access control sandbox, a state snapshot module, an incremental merging module, and a conflict-oriented directed acyclic graph (DOA) module. The host-side device can receive edge rule packets from the cloud, parse the semantic bytecode of the object model, detect write conflicts between linkage rules and complete rule arbitration based on the DOA module, and execute the linkage rule logic through the bytecode interpreter, completing device linkage scheduling under the permission control of the access control sandbox.

[0117] The host virtual device bus can be implemented based on a preset interface definition language or inter-process communication mechanism, serving as a data interaction channel between the host device and IoT devices, and completing instruction forwarding and transparent transmission of device-reported data.

[0118] IoT devices can include heterogeneous terminals such as Bluetooth Low Energy smart thermos cups, Wi-Fi / message queue telemetry transmission ambient lights, and Controller Area Network (CAN) vehicle body equipment. Each IoT device can receive linkage control commands via the host virtual device bus and report its own status and event data to the host device.

[0119] The edge rule packages generated by the cloud-side device can be distributed to the host-side device; the host-side device can establish communication with various IoT devices through the host virtual device bus to achieve coordinated execution of local offline devices.

[0120] The technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will now be described with reference to the accompanying drawings.

[0121] Figure 2 A flowchart illustrating a device linkage method provided in this application Figure 1 .like Figure 2As shown, this method can be executed by a cloud-side device, which can be a business server providing linked rule management capabilities, a rule orchestration server, or an edge rule service node integrated with a device management platform. The method includes:

[0122] S201. In response to the user's custom editing operation on the linkage rules, determine the rule description file.

[0123] Users can customize and edit the linkage rules from the management backend, mobile application, vehicle configuration interface, or low-code orchestration page.

[0124] The user's custom editing operations on the linkage rules can include trigger conditions, judgment logic, execution actions, target device identifiers, device attribute items, event types, service call parameters, and timing constraints. The rule description file is used to carry the editing results of the linkage rules. It is not a runtime file directly facing the host-side execution environment, but rather a source data file for subsequent compilation and processing.

[0125] In practice, after receiving the rule configuration data submitted by the user, the cloud-side device can preprocess the rule configuration data and retain the semantic data related to the linkage execution to form a rule description file.

[0126] The rule description file can be saved in a structured text format.

[0127] For example, the rule description file can be in JavaScript ON format, Extensible Markup Language (XML) format, or an intermediate representation format defined within the platform, and must include at least a unique rule identifier, rule version number, trigger source definition, condition expression, action sequence, variable reference table, and device capability mapping information.

[0128] Based on the above analysis, it can be seen that the process of determining the rule description file not only includes saving the user's editing results, but also includes converting the rule configuration content for human-computer interaction into standardized input that can be processed by the compiler.

[0129] In one possible embodiment, after receiving an editing request, the cloud-side device can semantically organize the linkage logic formed by the user in the interface based on relevant context information and generate a rule description file.

[0130] In another possible embodiment, if the user's current edit is an operation to add, delete, or modify existing linkage rules, the cloud-side device will update the changed configuration content based on reading the historical versions of the rules and regenerate the rule description file, so that the subsequent compilation process always uses a consistent source data structure as input.

[0131] It should be understood that the above examples are for illustrative purposes only and are not intended to be limiting.

[0132] The rule description file involved in this step is the input file obtained after the user customizes and edits the linkage rules, and is used to carry the original rule configuration content.

[0133] Specifically, after responding to the user's editing operation, the system organizes, summarizes, and standardizes the content of the linkage rules, and generates a data file that can be directly read by subsequent compilation modules.

[0134] Based on this processing method, the cloud-side device transforms the original page-based and interactive configuration results into semantically clear and structurally stable rule description files, providing a consistent data foundation for the subsequent compilation of linkage logic into edge execution payloads, thereby enabling rule updates to be independent of changes to the host program's built-in logic.

[0135] S202. Compile the rule description file into an edge linkage package.

[0136] The edge linkage package includes bytecode, capability whitelist, private protocol encoding / decoding scripts, and signature.

[0137] Bytecode can serve as the execution representation of linkage rules.

[0138] Bytecode can be used to be executed on the host side instead of directly running the original rule description file.

[0139] Bytecode can contain event monitoring instructions, variable loading instructions, comparison operation instructions, logical jump instructions, delay scheduling instructions, and action call instructions, and can be organized into function segments, constant pools, and control flow tables so that the host-side interpretation and execution environment can parse them sequentially.

[0140] A capability whitelist can be used to limit the range of resources that can be accessed by linkage rules. After being encapsulated, it serves as the basis for permission verification when the host side executes the rules. Before executing each action call or attribute read, the host side interpreter can use the whitelist to confirm whether the access is authorized.

[0141] The interpreter includes a built-in resource counter to constrain resource consumption during a single rule trigger. A hard limit of 10,000 instructions can be executed within a single trigger. The maximum allowed duration for delay and hold instructions is 3600 seconds, estimated based on the maximum trip duration in a vehicle-mounted scenario, to prevent the execution engine from blocking the device state machine for extended periods due to rule configuration errors. Typical usage duration is recommended to not exceed 300 seconds. The recursion and loop depth of rule execution cannot exceed 32 levels. If any resource metric exceeds the preset threshold, the current rule execution is immediately terminated, and the corresponding audit log is reported.

[0142] Private protocol encoding and decoding scripts can be used to adapt to communication between devices with private protocols, enabling linkage rules to drive devices from different manufacturers or with different protocols.

[0143] Private protocol encoding and decoding scripts can be represented using platform-defined scripting languages ​​or restricted execution script formats, and include uplink data parsing functions and downlink control message encoding functions, so that the host side can call them as needed during bytecode execution.

[0144] Signatures can be used to ensure the integrity and source trustworthiness of edge-linked packet data.

[0145] After obtaining the rule description file, the cloud-based device can call the rule compiler to perform the compilation process.

[0146] Edge linkage packets can be used to carry linkage rules and send them to the host side. They are self-contained rule execution units, integrating rule execution logic, access control content, protocol adaptation scripts, and integrity verification data, so that the host-side device can complete linkage execution without relying on the original rule editing environment after receiving them.

[0147] In practice, the rule compiler compiles the rule description file to obtain bytecode and generates a capability whitelist and private protocol encoding / decoding scripts. Then, the rule compiler signs the edge linkage packet to obtain a signature. Specifically, a digest value is generated based on a digest algorithm, and then signed using the signing private key held by the cloud-side device. This signature is then verified on the host side using the corresponding public key. After signing, the rule compiler generates the edge linkage packet and subsequently writes it to the object model repository on the cloud side.

[0148] Optionally, the edge linkage package may also include a package version number, the adapted host runtime version number, rule identifier, dependency table, and timestamp information.

[0149] Based on the above analysis, it can be seen that this step converts the rule description file into an edge linkage package that can be independently distributed, independently executed, and has permission constraints and protocol adaptation capabilities. The core is to unify and solidify the execution semantics, permission boundaries, and device communication methods of the linkage logic.

[0150] It should be understood that the above examples are for illustrative purposes only and are not intended to be limiting.

[0151] The edge linkage packet involved in this step can be a self-contained rule execution unit used to carry linkage rules and send them to the host side; the bytecode can be an execution representation obtained by compiling the rule description file; the capability whitelist can be permission control content used to limit the scope of resources that linkage rules can access; the private protocol encoding and decoding script can be script content used to adapt to communication of private protocol devices; and the signature can be verification data generated after signing the edge linkage packet.

[0152] Based on this compilation and encapsulation method, the host device receives a rule payload adapted to the edge execution environment, rather than the original rule text that relies on real-time interpretation in the cloud. Therefore, in scenarios with weak network, network outage, or page exit, the linkage logic can still be continuously executed by the host device's local runtime, and the permission boundaries and protocol adaptation relationships have been clearly solidified within the package.

[0153] S203. Based on the old version edge linkage package corresponding to the linkage rule, perform semantic-level differential processing on the edge linkage package to obtain the differential package of the linkage rule.

[0154] After generating a new edge linkage package, the cloud-side device can read the old version of the edge linkage package corresponding to the same rule identifier from the object model repository, and perform semantic-level differential processing based on the two edge linkage packages. The differential processing is not simply based on byte-level file comparison, but rather on identifying the changed content based on rule semantic units and generating a differential package containing only the necessary change information.

[0155] In practice, cloud-side devices can perform semantic comparisons between the old and new edge linkage packages to identify changes in the linkage rules. For content that has not changed, it is not written into the differential package; for content that has changed, the corresponding change information is written into the differential package.

[0156] After completing the difference identification, the cloud-side device assembles the difference package according to the predetermined difference format.

[0157] Differential packets can be used to carry changes in linkage rules and send them to the host device.

[0158] A differential packet may include a base version identifier, a target version identifier, a set of differential records, a rollback flag, a compatibility flag, and signature information regenerated for the differential content.

[0159] In semantic-level differential processing, if only a certain action parameter changes, the differential packet will only carry the corresponding changed content and will not carry the unchanged content again; if the capability whitelist does not change, the differential packet will not contain the corresponding content.

[0160] For example, when the linkage rule is changed from "turn on the interior lighting after the door lock is opened" to "turn on the interior lighting after a two-second delay after the door lock is opened", differential processing can only identify the changes related to the delay, without retransmitting the unchanged trigger content and target action content.

[0161] After the differential package is assembled, the cloud-side device performs a consistency check on the differential package to ensure that the differential record can reconstruct the target new version edge linkage package based on the specified old version edge linkage package.

[0162] Based on the above analysis, it can be seen that semantic-level differential processing, compared to directly sending the complete edge linkage packet, compresses the unchanged rule semantic content rather than arbitrary byte sequences. Therefore, differential packets are more suitable for scenarios with continuous rule iteration.

[0163] In one possible embodiment, the cloud-side device can construct a rule semantic tree to perform node-level comparison between the old and new versions. Each node is bound to a type, device object, resource object, and parameter object, and the node hash value is used to help identify changes, thereby improving the accuracy of differential positioning.

[0164] In another possible embodiment, after generating the differential package, the cloud-side device can also simulate the patch synthesis process on the host side, and perform a pre-simulation synthesis of the old version edge linkage package and the differential package. If the summary value of the synthesis result is consistent with the summary value of the new edge linkage package, the differential package is confirmed to be valid.

[0165] It should be understood that the above examples are for illustrative purposes only and are not intended to be limiting.

[0166] The differential packets involved in this step are updated packets obtained by semantic-level differential processing of the old version edge linkage packets corresponding to the linkage rules, which are used to reduce the overhead of retransmitting the entire packet.

[0167] Based on this processing method, cloud-side devices no longer repeatedly send unchanged bytecode, capability whitelists, or private protocol encoding / decoding scripts. Instead, they send the necessary difference content that can drive the host side to complete the version update, so that the rule update process matches the network bandwidth constraints in heterogeneous device access scenarios and maintains the consistency of the evolution of linked rule versions.

[0168] In one possible implementation, the edge linkage package can be semantically differentially processed based on the old version edge linkage package corresponding to the linkage rule to obtain a differential package in the following manner: Based on the old version edge linkage package corresponding to the linkage rule, multiple second data segments are determined; based on the multiple second data segments, multiple first data segments in the edge linkage package are semantically differentially compared to obtain differential data; the differential data is encapsulated to obtain a differential package.

[0169] In the specific implementation, after generating the current edge linkage packet, the cloud-side device first obtains the old version of the edge linkage packet corresponding to the linkage rule and parses its packet structure to identify data units such as bytecode segments, capability whitelist segments, private protocol encoding / decoding script segments, and signature segments. The parsed data units are organized into multiple second data segments, and a semantic mapping relationship is established with multiple first data segments in the current edge linkage packet. Subsequently, the system compares the corresponding data segments based on this semantic mapping relationship. If the data expression in the current packet differs from the old version in terms of additions, deletions, replacements, or parameter changes, the corresponding changed content is extracted as difference data; if the data segment has not undergone semantic changes, it is not included in the difference data. After the comparison is completed, the difference data is repackaged into a differential packet. During the packaging process, version identifiers, verification information, and segment index information can be added to enable the host-side device to complete reception, verification, and restoration. For private protocol encoding / decoding script segments, semantic comparison can be performed according to script logical units during differential comparison, ensuring that the encoding / decoding capabilities of Bluetooth Low Energy, Wi-Fi / MQTT, or CAN bus protocols can be consistently migrated with rule updates. In practical applications, the encapsulation format of differential packets can also be configured with different metadata fields according to the parsing capabilities of the host side, and this application does not impose any restrictions on this.

[0170] This differential processing method ensures that the current edge linkage packet only carries the changed data content, and avoids the repeated transmission of unchanged data through semantic-level comparison, thereby reducing packet size and transmission overhead. It also enables different protocol scripts and rule content to be updated in a unified manner. Because the differential packet directly reflects the semantic changes between the old and new versions, the host side can recover an edge linkage packet consistent with the current linkage rules after applying the differential packet, thus achieving continuous updates to linkage rules and adaptation to heterogeneous protocols.

[0171] S204. Send differential packets to the host device.

[0172] In this application, after generating the differential packet, the cloud-side device can send the differential packet to the host-side device associated with the linkage rule.

[0173] The host-side device can be an in-vehicle smart cockpit host, a smart home gateway, an industrial edge gateway, or other terminals with edge linkage execution capabilities.

[0174] Before sending, the cloud-side device can read the online status of the host-side device, the currently installed edge linkage package version number, the host runtime version number, and the available transmission link information, and confirm that the base version identifier of the differential package is consistent with the old version edge linkage package currently saved on the host side.

[0175] If the versions are consistent, the cloud-side device will add the differential packet to the distribution queue and send it to the host-side device via a HyperText Transfer Protocol (HTTP) long connection, Message Queuing Telemetry Transport (MQTT) message channel, WebSocket link, or dedicated channel for host device management. If the versions are inconsistent, the cloud-side device can trigger a resynchronization of version information and reselect either the differential packet or the complete edge linkage packet based on the reconfirmed version relationship.

[0176] The data sent may include at least the rule identifier, base version number, target version number, differential record set, signature information, and integrity verification digest.

[0177] After receiving the data, the host device can first verify the signature, then perform patch synthesis on the local old version edge linkage package based on the differential record to generate the target new version edge linkage package, and switch to the new version rule execution unit after successful synthesis.

[0178] In practice, cloud-side devices can use a reliable delivery mechanism to manage the differential packet sending status.

[0179] For example, after sending the differential packet, the cloud-side device records the message identifier, sending time, and target host-side device identifier, and waits for the host-side device to return a receipt confirmation, signature verification result, and patch application result. If no confirmation is received within the set time limit, the cloud-side device performs a retransmission; if the host-side device returns a base version mismatch, the cloud-side device stops retransmitting the current differential packet and regenerates a differential packet adapted to the host-side version; if the host-side device returns a signature verification failure, the cloud-side device marks the update as abnormal and can switch to the complete edge-linked packet delivery process.

[0180] For host-side devices operating in weak network conditions or temporarily offline, cloud-side devices can store differential packets in a delivery queue and resume sending them when the host device comes back online. Since the differential packets contain base version and target version identifiers, the host-side device can use this information to confirm the continuity of the update chain, thus ensuring a clear version dependency in the rule packet update process.

[0181] Based on the above analysis, it can be seen that sending differential packets to the host device is not only a transmission action, but also includes adaptation verification of the host version status and closed-loop confirmation of the update result.

[0182] In one possible embodiment, the cloud-side device performs an integrity check on the differential packet again before sending it, and stores the differential packet digest and signature together so that they can be compared when the host side reports an anomaly.

[0183] In another possible embodiment, if the host-side devices are in a batch deployment scenario, the cloud-side devices can be grouped and distributed according to the host-side device model, host runtime version, and installed rule package version, so that host-side devices with the same basic version receive the same differential package.

[0184] It should be understood that the above examples are for illustrative purposes only and are not intended to be limiting.

[0185] This application provides a device linkage method. In response to a user's custom editing operation of linkage rules, a rule description file is determined. The rule description file is compiled into an edge linkage package, which includes bytecode, a capability whitelist, a private protocol encoding / decoding script, and a signature. Based on the old version of the edge linkage package corresponding to the linkage rule, semantic-level differential processing is performed on the edge linkage package to obtain a differential package of the linkage rule. The differential package is then sent to the host device. In this application, the user-edited linkage rules are first standardized into a rule description file on the cloud side, then compiled into an edge linkage package that can be executed independently on the host side. After performing semantic-level differential processing based on the old version of the edge linkage package, only the differential package is sent, ensuring that the updated rule content corresponds to the version status on the host side. After receiving the package, the host side can complete the package-level update and continuous execution locally. Therefore, the linkage logic no longer relies on the page runtime environment to be continuously online, nor does it require the redeployment of the host native program every time the rules are changed. Furthermore, for heterogeneous link devices such as Bluetooth, Wi-Fi, MQTT, and CAN, the private protocol encoding and decoding scripts have been solidified along with the edge linkage package, so that the linkage rules in edge scenarios can complete version iteration with a low update transmission volume and maintain continuous execution capability in scenarios with weak network, network outage, or when the host is moved to the background.

[0186] It should be understood that the above examples are for illustrative purposes only and are not intended to be limiting.

[0187] Below, in conjunction with Figure 3 The process of compiling the rule description file into an edge linkage package is explained.

[0188] Figure 3 A flowchart illustrating a device linkage method provided in this application Figure 2 Based on the above embodiments, see also Figure 3 The method includes:

[0189] S301. Perform field validation on the rule description file to obtain the validation results.

[0190] The verification result includes verification passed and verification failed.

[0191] During actual compilation, after receiving the rule description file edited by the user, the cloud-side device can parse and verify the rule identifier, object model reference, condition expression, action parameter, and signature field in the file, and mark the parsing result as either verification passed or verification failed.

[0192] S302. If the verification result is successful, the rule description file is subjected to de-visualization stripping and abstract syntax tree generation processes in sequence to obtain the rule abstract syntax tree.

[0193] For rule description files that pass validation, the compiler can perform a de-visualization process, separating the interface layout, form styles, visual control configurations, and other content from the file, retaining only the logical fragments related to the linkage execution, and then generating a tree-structured rule abstract syntax tree based on the retained logical fragments.

[0194] When generating a tree structure, the compiler can express the rules in layers according to condition nodes, logical connection nodes, and action nodes, so that they can be traversed in the order of tree nodes and converted into instruction sequences.

[0195] S303. Convert the rule abstract syntax tree into a sequence of semantic bytecode instructions for the object model to obtain the corresponding bytecode.

[0196] After obtaining the rule abstract syntax tree, the compiler can map the tree nodes one by one to the corresponding bytecode opcodes and operands according to the object model definition. Condition judgment nodes can be mapped to comparison instructions, event subscription nodes can be mapped to event receiving instructions, and service call nodes can be mapped to call instructions, thus forming a semantic bytecode instruction sequence of the object model.

[0197] Bytecode can be encapsulated together with the rule abstract syntax tree into an edge linkage package. The edge linkage package can also carry metadata describing the rule structure so that the host side can complete loading, verification, and interpretation execution after receiving it.

[0198] Through the above compilation method, the edge linkage package can simultaneously save the structural information and executable information of the rules, so that the host side can still interpret the linkage logic and execute the corresponding control actions based on the bytecode in the background running state, thereby realizing the edge deployment and stable execution of the rules.

[0199] S304. Perform capability field identification processing on the rule abstract syntax tree to obtain the capability whitelist.

[0200] Capability whitelists can be used to limit the range of resources that can be accessed by linkage rules.

[0201] After obtaining the rule abstract syntax tree and bytecode, the nodes in the rule abstract syntax tree can be traversed and parsed to extract the fields involving device access, capability invocation and permission constraints, and generate a capability whitelist that matches the host-side execution environment.

[0202] S305. Identify the private protocol device field in the rule abstract syntax tree, and compile the identified private protocol device field to obtain the private protocol encoding / decoding script.

[0203] Private protocol codec scripts can be used to supplement the communication capabilities of heterogeneous devices.

[0204] Private protocol encoding and decoding scripts can be carried in scripting languages ​​or intermediate representations so that they can complete message framing, field decomposition, or bitstream conversion when executed by the host device.

[0205] For fields in the rule abstract syntax tree that are identified as private protocol devices, corresponding private protocol encoding / decoding scripts can be generated according to preset protocol templates and compilation rules.

[0206] S306. Perform signature processing on multiple first data segments to obtain a signature.

[0207] Signatures are used to ensure the consistency of encapsulated content during transmission and storage.

[0208] Multiple first data segments include at least one of bytecode, capability whitelist, private protocol encoding / decoding script, preset bytecode instruction set, and preset mapping index table.

[0209] Bytecode, capability whitelist, private protocol encoding / decoding script, and at least one of the preset bytecode instruction set and preset mapping index table can be combined into multiple first data segments, and these segments can be signed. The signature can be generated using a hash digest combined with a key algorithm.

[0210] S307. Generate an edge linkage package based on multiple first data segments and signatures.

[0211] Edge linkage packages can serve as a unified carrier for executing linkage logic on the host side.

[0212] Below, with reference to Table 1, we will illustrate the structure of the edge linkage package with an example.

[0213] Table 1

[0214]

[0215] Custom instruction sets can be pre-configured.

[0216] Below, we will illustrate the custom instruction set with examples, referring to Table 2.

[0217] Table 2

[0218]

[0219] Multiple first data segments and signatures can be encapsulated to obtain a deployable edge linkage package.

[0220] The implementation details of each step in this application embodiment can be found in the description of the corresponding steps or operations in the above method embodiments; repeated content will not be repeated.

[0221] This embodiment provides a device linkage method that performs field validation on a rule description file to obtain validation results, including validation pass and validation fail. If the validation result is pass, the rule description file is sequentially stripped of its visual representation and generated as an abstract syntax tree (AST), resulting in a rule AST. The rule AST is then converted into a sequence of semantic bytecode instructions for an object model, yielding the corresponding bytecode. Capability field identification processing is performed on the rule AST to obtain a capability whitelist. Private protocol device fields in the rule AST are identified and compiled to obtain a private protocol encoding / decoding script. Multiple first data segments are signed to obtain a signature. Each first data segment includes at least one of the following: bytecode, capability whitelist, private protocol encoding / decoding script, preset bytecode instruction set, and preset mapping index table. An edge linkage package is generated based on the multiple first data segments and the signature. In this way, the linkage rules can complete permission constraints, protocol adaptation, and integrity verification during the encapsulation stage. Upon receiving the package at the edge, it can be directly loaded and executed, reducing reliance on online cloud parsing and improving the consistency and reliability of rule implementation and updates in multi-protocol device access scenarios.

[0222] Figure 4 A flowchart illustrating a device linkage method provided in this application Figure 3 .like Figure 4 As shown, this method can be executed by a host-side device, which can be an in-vehicle smart cockpit host, a home gateway, an industrial edge gateway, or other terminals with edge execution capabilities. The method includes:

[0223] S401: Receive differential packets sent by the cloud-side device and determine the edge linkage packet based on the differential packets.

[0224] The edge linkage package includes bytecode, capability whitelist, private protocol encoding / decoding scripts, and signature.

[0225] Differential packets can be used to carry change information about linkage rules relative to older versions.

[0226] The content of the differential packet can be instruction replacement fragments for bytecode, records of additions, deletions and modifications for capability whitelists, script block update content for private protocol encoding and decoding scripts, and signature information corresponding to the updated content.

[0227] Differential packets are not a repetition of complete linkage rules, but rather express rule changes in an incremental form, which the host device uses to recover and obtain new edge linkage packets.

[0228] Edge linkage packages can be linkage rule carriers that can be directly executed by host-side devices.

[0229] Among them, bytecode can carry the executable logic of linkage rules.

[0230] Capability whitelists can limit the device attributes, events, and services that rules can access.

[0231] Private protocol codec scripts can be used to convert data reported by heterogeneous protocol devices into uniform fields and perform reverse encoding during output control.

[0232] Signatures can be used to verify the integrity and origin of edge-linked packets.

[0233] After establishing a rule update channel between the host-side device and the cloud-side device, the host-side device can receive differential packets sent by the cloud-side device. The host-side device can receive differential packets via HTTP long connections, MQTT downlink topics, WebSocket connections, or vendor-defined message channels. Upon receiving the packets, the host-side device first extracts the rule identifier, version number, applicable host type, differential baseline version, and digest value from the differential packet header, and then searches locally for the old version edge linkage packet corresponding to the differential baseline version.

[0234] When the old version of the edge linkage package exists locally, the host device can perform recovery processing according to the semantic-level update instructions in the differential package. These semantic-level update instructions may include replacing the bytecode segment of a rule block, deleting a disabled capability item, adding access permissions for a certain object model, updating the private protocol encoding / decoding script corresponding to a certain device family, and refreshing the signature field. The host device generates the new version of the edge linkage package to be effective in memory, calculates a digest for the updated package body, compares it with the digest value attached to the differential package, and verifies the signature using a pre-set public key or certificate chain. In this application, the signature is used to verify the integrity and origin of the edge linkage package. Only when the digest matches and the signature verification passes will the host device write the edge linkage package to its local rule repository and replace the old version in a versioned manner.

[0235] In one possible embodiment, the differential packet corresponds to only a portion of the changes in the edge linkage packet, and the host-side device only performs updates on the changed portion.

[0236] For example, when the linkage conditions remain unchanged and only a new private device protocol mapping is added, only the corresponding private protocol encoding and decoding script is replaced while keeping the original bytecode and capability whitelist unchanged; when the access permission range is adjusted, only the capability whitelist entries are modified and the signature is re-verified.

[0237] After determining the edge linkage package, the host-side device can also load the bytecode in it into the waiting area of ​​the headless execution engine, load the capability whitelist into the permission verification table, load the private protocol encoding and decoding script into the script execution environment, and record the effective version, release time and rollback anchor point of the edge linkage package.

[0238] Based on the above analysis, this step restores and updates the edge linkage packet according to the differential packet on the host-side device, so that the linkage rules can be kept up-to-date in a form suitable for edge execution. Moreover, only the changed parts are processed during the update process, so that the rule distribution and execution in the weak network environment can maintain low transmission overhead and high content consistency.

[0239] It should be understood that the above examples are for illustrative purposes only and are not intended to be limiting.

[0240] S402. Receive device status events through the virtual device bus, and perform rule execution processing on the device status events according to the edge linkage packet to generate device control commands.

[0241] After the host device completes edge linkage packaging, it can establish a unified event input channel for multi-protocol devices, namely the virtual device bus.

[0242] The virtual device bus can be used to shield the differences between different physical links and protocol stacks such as Bluetooth, Wi-Fi, MQTT, CAN, and serial ports, and convert status reports from various terminals into a unified internal event format and distribute them to the rule execution module.

[0243] Device status events can be used to indicate changes in the current status of a device or to report information.

[0244] Device status events can include device identifier, product model identifier, event type, occurrence time, original payload, set of parsed fields, and link source identifier.

[0245] Rule execution can take place within the host device, where the execution engine judges and processes input events based on the bytecode in the edge linkage package, and generates device control instructions when the triggering conditions are met.

[0246] Device control commands can be control action data corresponding to the result of rule execution, which will be converted into control commands that can be transmitted through a specific link and sent to the target device.

[0247] Each protocol adapter in the host device can first receive the data frames reported by the terminal device.

[0248] For example, a Bluetooth adapter receives broadcast packets or Generic Attribute Profile (GATT) notifications, a Wi-Fi LAN adapter receives User Datagram Protocol (UDP) messages or HTTP callbacks, an MQTT adapter receives topic messages, and a CAN adapter receives bus messages.

[0249] When each protocol adapter writes raw data to the virtual device bus, it includes the link type, receive timestamp, and device addressing information. The virtual device bus normalizes and encapsulates these raw events, and after completing the adaptation process with the edge linkage packet, it delivers the device status events to the execution engine.

[0250] The execution engine can load the bytecode in the currently active edge linkage package and process the device status events based on the bytecode, including event type matching, field comparison, time window judgment, condition combination, action template selection, parameter filling and output assembly.

[0251] For example, in one possible embodiment, when the virtual device bus receives a device status event from the in-vehicle temperature sensor reporting that the temperature field exceeds a set threshold, the execution engine determines that the triggering conditions are met based on the bytecode, extracts the air conditioning on and set temperature parameters from the rule action segment, and generates the corresponding device control command.

[0252] Device control commands may include target device identifier, control service name, parameter set, expected effective time, retry policy flag, and link candidate information.

[0253] In this step, the signature can be used for legality verification when the linkage package is updated, but the host device can also confirm that the signature status of the currently loaded edge linkage package is valid before execution, and only allow the execution of the rule driven by the edge linkage package that has passed the signature verification.

[0254] Based on the above analysis, it can be seen that by uniformly accessing device status events through the virtual device bus and combining the edge linkage package to directly complete rule execution processing on the host device, the linkage logic can be decoupled from the page running environment and continuous online cloud dependence, and continue to output device control commands when the host device is in the background, in a weak network, or in an independent local area network state.

[0255] It should be understood that the above examples are for illustrative purposes only and are not intended to be limiting.

[0256] In one possible implementation, before performing rule execution processing on device status events, the method further includes: obtaining a directed acyclic graph, which is constructed with multiple object model attributes as nodes and read / write dependencies between attributes as edges; detecting write conflicts caused by multiple linkage rules in the host device targeting the same object model attribute based on the directed acyclic graph; and arbitrating linkage rules with write conflicts based on rule priority declarations and physical mutexes to determine the target linkage rule.

[0257] Among them, the object model attributes can be used to characterize the standardized fields corresponding to the equipment capabilities, state variables, or control variables.

[0258] A directed acyclic graph can be obtained from the rule compilation results when the linkage rules are loaded, or it can be regenerated based on the latest rule description after the rules are updated.

[0259] During construction, the attributes of the object models involved in the linkage can be used as graph nodes. Directed edges are established based on the relationship that the writing result of one object model attribute is referenced by the reading condition, calculation expression, or control action of another object model attribute. The direction of the directed edges is from the dependent object model attribute to the dependent object model attribute, so that there are no loops in the graph.

[0260] The host device can store the graph in the local rule runtime memory or persistent configuration area, and refresh it synchronously when the rule changes.

[0261] When detecting write conflicts, the host device matches the currently executed linkage rule with the object model attribute write relationship in the diagram to determine whether there are multiple linkage rules that generate write actions for the same object model attribute after the same device state event is triggered, and the target value, write timing or effective range of the write action are inconsistent with each other.

[0262] If multiple candidate write sources are detected for the same object model attribute, these linkage rules are marked as a conflict set, and the rule priority declaration is further read. The rule priority declaration can be issued by the cloud and saved in the edge linkage package along with the rule.

[0263] During the arbitration process, physical mutexes can be used to exclusively occupy physical write channels corresponding to the same object model attribute. When multiple linkage rules in the conflict set meet the execution conditions at the same time, the host device determines the preferred rule according to the rule priority declaration, and controls the writing order according to the acquisition status of the physical mutex when the rule priority declarations are the same, so that only one target linkage rule obtains actual writing permission at any given time.

[0264] The determined target linkage rules then participate in the subsequent execution and processing of equipment status event rules, and their control results are converted into corresponding equipment control commands and output.

[0265] Below, in conjunction with Figure 5 Examples are given to illustrate the conflict detection and arbitration process.

[0266] Figure 5 A schematic diagram of a conflict detection and arbitration process provided for this application. Please see below. Figure 5 The linkage rule R2 is configured to trigger the window closing operation on rainy days, with a priority of 10; the linkage rule R3 is configured to trigger the window opening operation on high temperatures, with a priority of 5.

[0267] Linkage rule R2 and linkage rule R3 both apply to the same object model attribute window state, resulting in a write conflict.

[0268] After the conflict directed acyclic graph arbitration unit detects a write conflict, it completes arbitration according to the rule priority, selects the higher priority linkage rule R2 as the target linkage rule, executes the write command, and sets the window state to closed; linkage rule R3 is suppressed and an audit log is generated.

[0269] The system performs a global loop detection when a linkage rule is initiated. If a loop is detected in the graph structure, the activation of that linkage rule group is refused. This ensures that write operations on the same object model attribute meet the requirements of eventual consistency and idempotency.

[0270] In this way, the host device can identify concurrent write relationships on the same object model attribute before the rule is executed, and complete arbitration by combining priority and physical mutex lock. The resulting target linkage rule is unique and executable, so that the rule execution result is consistent with the object model state, reducing state jitter and control ambiguity caused by conflicting writes.

[0271] S403. Perform link arbitration on the device control commands to obtain the target link.

[0272] After receiving the device control command generated by the rule execution, the host device does not send it directly along a fixed path. Instead, it performs link arbitration on the transmission path corresponding to the device control command based on the currently available communication resources.

[0273] Link arbitration can be used to select the most suitable link for the current control task from multiple candidate links.

[0274] The target link can be a communication link that, after link arbitration, is ultimately used to issue actual device control commands.

[0275] In practice, the host-side device can compare and select candidate links based on device control commands and the current link availability, and use the selected result as the target link.

[0276] In one possible embodiment, after the host-side device completes link arbitration, it can use other unselected candidate links as a reference for subsequent switching; when the current target link is unavailable, link arbitration can be performed again and the target link can be updated.

[0277] Optionally, the target link can be obtained by performing link arbitration on the device control command in the following manner: determining the score values ​​corresponding to multiple links according to the device control command, including cloud links, local area network links and near-field links; and determining the link with the highest score value among the multiple links as the target link.

[0278] In practice, after generating device control commands, the host device first calculates scores for cloud links, local area network links, and near-field links based on the transmission target, timeliness requirements, and current reachable link status of the device control commands.

[0279] Link status can be obtained from link probing results, which include connectivity, round-trip time, packet loss rate, and current link load. The score can be corrected by taking into account the freshness loss of device control commands.

[0280] For device control commands that require rapid response and can be executed locally, the score of a LAN link or near-field link can be higher due to lower latency; for device control commands that need to be sent across networks, a cloud link can get a higher score when the network quality meets the requirements.

[0281] The score calculation result can be output by the link arbitration module inside the host-side device and sent to the link selection logic.

[0282] When multiple links are available, the host device compares them according to their scores, determines the link with the highest score as the target link, and issues device control commands through the target link.

[0283] If multiple links have the same score, the target link can be determined by combining the preset link order.

[0284] This link arbitration method enables device control commands to adaptively select between cloud links, local area network links, and near-field links, and uses the link that best suits the current transmission conditions as the actual distribution channel.

[0285] The scoring values ​​for multiple links can be determined using the following formula. :

[0286]

[0287] in, 'k' can represent the link type; 'cloud' can represent a cloud link, 'lan' can represent a local area network link, and 'near' can represent a near-field link. , , , It can represent adjustable weight coefficients and supports online adaptive updates; It can represent the historical packet loss rate within the sliding window of the k-th channel; It can represent the round-trip time of the channel, and uses an exponentially weighted moving average for real-time statistics; It can represent the weight of the traffic overhead and the overall cost of equipment energy consumption corresponding to the channel; This can represent the loss of business freshness caused by data delivery delays.

[0288] In this way, device control commands can be scored and compared based on link status and device control command requirements, and then sent out by the link with the highest score, thus enabling control transmission under different network conditions to have consistent selection logic and strong adaptability.

[0289] Based on the above analysis, this step matches the rule execution results with the actual communication environment, enabling the device control commands to be sent along the most suitable execution path, thereby maintaining the continuity of linkage control in edge scenarios with weak networks, network outages, or multiple links coexisting.

[0290] It should be understood that the above examples are for illustrative purposes only and are not intended to be limiting.

[0291] S404: Send device control commands through the target link.

[0292] After obtaining the target link, the host device can encode and send the device control commands to the target device or its agent node according to the communication protocol and target device interface requirements corresponding to the target link, thereby realizing a closed-loop linkage control.

[0293] Before being issued, device control commands can contain control semantics in a uniform format, such as target service, parameter key-value pairs, command validity, idempotency identifiers, and acknowledgment requirements. However, before actual transmission, they need to be encapsulated in conjunction with the target link.

[0294] If the target device uses a standard object model interface, the host device can directly map the control commands into the corresponding service call messages; if the target device uses a vendor's proprietary protocol, the proprietary protocol encoding and decoding script in the edge linkage package is called to encode the control parameters and generate a binary frame, JavaScript Object Notation (JSON) payload, or bus message that the device can recognize.

[0295] In practice, when the target link is a local area network (LAN) link, the host device can send device control commands to the target device via Transmission Control Protocol (TCP) connection, HTTP request, Constrained Application Protocol (CoAP) message, LAN MQTT publication, or UDP command packets. When the target link is a near-field link, the host device can issue device control commands via Bluetooth GATT write feature value, Bluetooth Low Energy (BLE), Manufacturing Execution System (MES) message transmission, serial port pass-through, or CAN frame injection. When the target link is a cloud link, the host device uploads the device control commands to the corresponding control interface of the cloud device, and the cloud completes the subsequent forwarding.

[0296] Before actually sending the command, the host device can re-verify the validity of the edge linkage packet signature generated by the current driver and confirm that the device control command does not exceed the service range allowed by the capability whitelist before executing the sending operation. After sending, the host device waits for device acknowledgment, link layer confirmation, or timeout result, and writes the acknowledgment result to the execution log. If the target link does not return a successful response within the set timeout period, the host device can re-encapsulate and resend the device control command based on the backup link information; if the device control command carries an idempotent flag, the same idempotent flag will be used during resending so that the target device can identify duplicate commands.

[0297] In one possible embodiment, after the local area network link is distributed, the target device returns a success status code. The host device updates the device shadow status accordingly and can publish the result event via the virtual device bus for other linkage rules to continue consuming.

[0298] In another possible embodiment, after the cloud link sends the control task, it only receives the cloud acceptance receipt first. The host device then sets the control task to a pending confirmation state, and the state loop is completed after the subsequent device execution results are returned.

[0299] In this way, the transmission of device control commands includes not only a single message output, but also encoding, transmission, response reception, failure retry, and status write-back according to the link protocol.

[0300] Based on the above analysis, it can be seen that the host device actually issues device control commands through the target link obtained through arbitration, so that the aforementioned differential update, edge rule execution and link selection form a complete execution link, and the linkage rules can continuously act on heterogeneous devices in the edge scenario.

[0301] Optionally, the method further includes: maintaining a recent execution snapshot queue of N=32 for each linkage rule. The execution snapshot records information including the trigger time, hit branch, downlink transmission link, acknowledgment (ACK) result, and target device acknowledgment latency. When the network recovers from a disconnected state to a connected state, the execution snapshot is asynchronously pushed to the cloud ledger via MQTT for the system to perform eventual consistency reconciliation and support online learning and optimization of the link comprehensive score function.

[0302] It should be understood that the above examples are for illustrative purposes only and are not intended to be limiting.

[0303] The implementation details of each step in this application embodiment can be found in the description of the corresponding steps or operations in the above method embodiments; repeated content will not be repeated.

[0304] This embodiment provides a device linkage method that receives differential packets sent by a cloud-side device and determines an edge linkage packet based on the differential packets. The edge linkage packet includes bytecode, a capability whitelist, a private protocol encoding / decoding script, and a signature. Device status events are received via a virtual device bus, and rule execution processing is performed on the device status events based on the edge linkage packet to generate device control commands. Link arbitration is performed on the device control commands to obtain the target link. The device control commands are then issued through the target link. In this application, the cloud-side device outputs rule update content in differential form. The host-side device recovers and verifies the signature of the edge linkage packet based on the differential packets, then accesses multi-protocol device events via the virtual device bus, and completes rule execution locally in conjunction with the edge linkage packet. Subsequently, the target link is selected based on the current link status, and the control command is issued. Therefore, the linkage logic does not rely on continuous persistence on the foreground page, nor does it require online access to the cloud during rule execution. It also has unified access and control capabilities for heterogeneous protocol devices such as Bluetooth, Wi-Fi, MQTT, and CAN. Rule changes are completed through differential updates, keeping the processing and transmission burden on the host-side device within a controllable range.

[0305] It should be understood that the above examples are for illustrative purposes only and are not intended to be limiting.

[0306] Below, in conjunction with Figure 6 This section explains the process of executing rules on device status events based on edge linkage packages to generate device control commands.

[0307] Figure 6 A flowchart illustrating a device linkage method provided in this application Figure 4 Based on the above embodiments, see also Figure 6 The method includes:

[0308] S601. In response to receiving a device status event, dynamically load the private protocol encoding / decoding script.

[0309] The edge linkage package carries the script and its corresponding protocol adaptation information. After receiving the device status event, the host device can load the corresponding script according to the protocol type identified in the event.

[0310] In actual processing, the host device can store the script in the local cache corresponding to the edge linkage package and load it on demand after receiving the event trigger signal. Alternatively, it can preload the script into memory after the edge linkage package is updated to shorten the event response latency.

[0311] S602. Execute the private protocol encoding / decoding script to encode and decode the protocol data carried in the device status event to obtain the standard object model field.

[0312] The private protocol encoding and decoding script is executed. The script parses the protocol frame header, payload length, field encoding method and verification information, and then extracts the status value, enumeration value or timestamp information in the event payload and converts it into standard object model fields that can be recognized by the rule execution module.

[0313] S603. Based on the standard object model fields, perform rule execution processing on the equipment status events to generate equipment control instructions.

[0314] The script execution module and the rule execution module exchange data through the standard object model field interface. The rule execution module can compare, match or combine field values ​​according to preset conditions. When the linkage conditions are met, it outputs a device control command containing the target device identifier, control attributes and control values.

[0315] The instruction can then directly proceed to the link arbitration process and be sent to the corresponding terminal.

[0316] Optionally, before performing rule execution processing on device status events, the method further includes: submitting a tuple consisting of a resource reference identifier and an access type to the access control sandbox; and having the access control sandbox query the capability whitelist within the edge rule package list to determine whether to allow or deny the current instruction.

[0317] The third-party private protocol encoding / decoding assembly module runs in an independent linear memory space and can only call three types of restricted import interfaces exposed by the host: input buffer, output buffer, and Bluetooth Low Energy write interface. It is prohibited to access sensitive application interfaces such as the host file system, network interface, and address book.

[0318] Optionally, device status events can be processed by rule execution based on standard object model fields to generate device control commands in the following manner: determine whether the standard object model field exists in the capability whitelist; if so, process the device status events by rule execution based on the standard object model field to generate device control commands; if not, record the intercepted command information, call stack information, timestamp information and device information, generate audit logs, and upload the audit logs to the cloud.

[0319] In actual processing, after receiving a device status event, the host device first obtains the corresponding standard object model field based on the event parsing, and then performs a table lookup and matching of the standard object model field with the locally loaded capability whitelist.

[0320] If the matching result indicates that the standard object model field exists in the capability whitelist, then the standard object model field can be input into the rule execution module. The rule execution module will then generate device control instructions based on preset conditions, threshold relationships, or linkage mapping relationships. The device control instructions can be used to drive lighting, air conditioning, curtains, vehicle accessories, or other controlled terminals to perform linkage actions.

[0321] If the matching result indicates that the standard object model field is not in the capability whitelist, the rule execution chain will not be entered. Instead, interception instruction information will be written into the interception module. The interception instruction information is used to identify the blocked field name and its request source. At the same time, the current call stack information is collected to record the trigger path, and timestamp information is written to identify the time when the interception occurred. Combined with device information, a complete context is formed. Device information may include host-side device identifier, terminal identifier, protocol type, and operating environment identifier.

[0322] Subsequently, the host device encapsulates the above content into audit logs and uploads them to the cloud for storage via an available network link.

[0323] In this processing mechanism, the whitelist verification module and the rule execution module can be deployed within the same host process or called as independent services. They communicate via a memory queue or local interface, passing standard object model fields. When generating audit logs, the interception module can truncate the call stack to reduce log size and record timestamps using a unified millisecond-level time base, ensuring accurate comparison of intercepted events on the cloud side. In cases of temporary network unavailability, audit logs can be cached locally and uploaded to the cloud once the connection is restored.

[0324] By verifying the correspondence between standard object model fields and capability whitelists, only allowed standard object model fields can enter rule execution processing and generate device control commands, while unallowed standard object model fields are promptly intercepted and form traceable audit logs. This enables device linkage control to have clear field-level access control capabilities at the edge and provides a complete basis for cloud auditing and anomaly investigation.

[0325] The implementation details of each step in this application embodiment can be found in the description of the corresponding steps or operations in the above method embodiments; repeated content will not be repeated.

[0326] This embodiment provides a device linkage method that, in response to a received device status event, dynamically loads a private protocol encoding / decoding script; executes the private protocol encoding / decoding script to encode and decode the protocol data carried in the device status event, obtaining a standard object model field; and based on the standard object model field, performs rule execution processing on the device status event to generate device control commands. In this way, by dynamically encoding and decoding the protocol data in the device status event, heterogeneous protocol messages can be uniformly converted into standard object model fields, enabling rule execution processing to be completed at the same semantic layer, thereby forming device control commands that can be directly used for control issuance, thus improving protocol adaptability and linkage execution continuity in edge scenarios.

[0327] Below, in conjunction with Figure 7 The following example illustrates the equipment linkage method.

[0328] Figure 7 A flowchart illustrating a device linkage method provided in this application Figure 5 Based on the above embodiments, see also Figure 7 .

[0329] In the context of in-vehicle smart cockpit, the host-side device can be the vehicle system, which can connect to multiple brands and protocols of IoT devices such as Bluetooth BLE smart thermos cups, Wi-Fi / MQTT ambient lights, and CAN bus body control modules. When the vehicle enters a tunnel or underground parking garage, it may be in a weak network or no network environment, and the vehicle system still maintains the execution of linkage rules even when it is running in the background or in a screen-off state.

[0330] The cloud-side device responds to the user's custom editing operation of linkage rules on the low-code platform and determines the rule description file. For example, the user configures "when the temperature of the thermos cup is greater than 90 degrees Celsius and the condition is maintained for 3 seconds, call the ambient light flashing service, and the input parameters are configured as red color and flashing times of 2".

[0331] The cloud-side device first performs field validation on the rule description file, distinguishing between validation success and failure. If validation succeeds, it continues to perform de-viewing and abstract syntax tree generation processes in sequence, removing button styles, animation configurations, and other content from the H5 view-related attributes to obtain the rule abstract syntax tree, and then converting the rule abstract syntax tree into a sequence of semantic bytecode instructions for the object model to obtain the corresponding bytecode.

[0332] After generating bytecode, the cloud-side device performs capability field identification processing on the rule abstract syntax tree to obtain a capability whitelist, which may include the thermos cup "set_temperature" service, ambient light control field, and temperature sensor reporting field. At the same time, it identifies the private protocol device field in the rule abstract syntax tree and compiles the identified private protocol device field to obtain a private protocol encoding / decoding script, such as compiling the CAN bus frame format conversion logic into an assembly script.

[0333] The cloud-side device performs signature processing on multiple first data segments to obtain a signature. The multiple first data segments include at least one of bytecode, capability whitelist, private protocol encoding and decoding script, preset bytecode instruction set and preset mapping index table. Then, an edge linkage package is generated based on the multiple first data segments and the signature. The edge linkage package generated in the vehicle scenario can be 2KB to 20KB.

[0334] After the edge linkage package is generated, the cloud-side device, in conjunction with the old version of the edge linkage package corresponding to the linkage rules, determines multiple second data segments. Based on these second data segments, it performs semantic-level difference comparison processing on multiple first data segments in the edge linkage package to obtain difference data. This difference data is then encapsulated to generate a differential package for the linkage rules. The difference data can manifest as adding a condition node for "temperature greater than 90 degrees Celsius and this condition lasting for 3 seconds," updating the control action parameters corresponding to the thermos cup, or changing the object model reference index. The host-side device receives the differential package sent by the cloud-side device and determines the edge linkage package based on it, enabling the vehicle's infotainment system to receive only the rule-changed portion and complete hot updates even in weak network conditions.

[0335] Before rule execution, the host device acquires a directed acyclic graph (DAG). The DAG is constructed using multiple object model attributes as nodes and read / write dependencies between attributes as edges. For example, temperature sensor attributes and ambient light operating status attributes are used as nodes, and the dependencies of reading temperature and writing it to the thermos cup status and then to the ambient light are used as edges. Subsequently, the host device detects write conflicts arising from multiple linkage rules targeting the same object model attribute based on the DAG. Then, based on rule priority declarations and physical mutexes, it arbitrates the linkage rules with write conflicts to determine the target linkage rule.

[0336] After completing the loading of linkage rules and conflict arbitration, the host-side device receives device status events via the virtual device bus. The headless execution engine in the vehicle's infotainment system runs continuously as an independent thread or process, subscribing to the object model event stream. Upon receiving a device status event, it dynamically loads and executes a private protocol encoding / decoding script to encode and decode the protocol data carried in the device status event, obtaining the standard object model fields. For example, after the temperature sensor of a thermos cup reports raw protocol data via the CAN bus or BLE, the vehicle's infotainment system dynamically loads the corresponding script to convert it into a standard temperature field. When the temperature of the thermos cup is detected to be greater than 90 degrees Celsius and this condition is maintained for 3 seconds, the host-side device determines whether the standard object model field exists in the capability whitelist.

[0337] When a standard object model field exists in the capability whitelist, the host device processes device status events based on the standard object model field and target linkage rules, generating device control commands, such as commands to adjust ambient light color and flashing frequency. When a standard object model field does not exist in the capability whitelist, the system records intercepted command information, call stack information, timestamp information, and device information, generates audit logs, and uploads the audit logs to the cloud. For example, if a third-party script attempts to access a contact list field that is not in the capability whitelist, the vehicle system intercepts the corresponding call and records audit data.

[0338] After generating device control commands, the host device determines the score values ​​corresponding to multiple links based on the commands. These links include cloud links, local area network (LAN) links, and near-field links. The link with the highest score among these links is then designated as the target link. When the vehicle is in a normal network connection state, the LAN link can be used to synchronize the status to the cloud. When the vehicle enters a tunnel, the cloud link is disconnected, and there is no public network signal, the CAN bus corresponding to the near-field link receives the highest score. The host device then issues device control commands through the target link, sending air conditioning control commands to the body control module and window closing commands to the corresponding controlled devices.

[0339] Figure 8 This is a schematic diagram of a device linkage mechanism provided in an embodiment of this application. Please refer to [link / reference]. Figure 8 The equipment linkage device 800 includes a determination module 801, a compilation module 802, a processing module 803, and a sending module 804.

[0340] The determination module 801 is used to determine the rule description file in response to the user's custom editing operation on the linkage rules;

[0341] Compilation module 802 is used to compile the rule description file into an edge linkage package, which includes bytecode, capability whitelist, private protocol encoding and decoding script and signature;

[0342] The processing module 803 is used to perform semantic-level differential processing on the edge linkage package according to the old version edge linkage package corresponding to the linkage rule, so as to obtain the differential package of the linkage rule.

[0343] The sending module 804 is used to send differential packets to the host-side device.

[0344] In one possible implementation, compiler module 802 is specifically used for:

[0345] Perform field validation on the rule description file to obtain the validation results, which include validation passed and validation failed.

[0346] If the verification result is successful, the rule description file is sequentially subjected to de-visualization stripping and abstract syntax tree generation to obtain the rule abstract syntax tree.

[0347] The rule abstract syntax tree is converted into a sequence of semantic bytecode instructions for the object model to obtain the corresponding bytecode;

[0348] Based on the rules, abstract the syntax tree and bytecode to generate edge linkage packages.

[0349] In one possible implementation, compiler module 802 is specifically used for:

[0350] The rule abstract syntax tree is processed to identify capability fields, resulting in a capability whitelist.

[0351] The private protocol device field in the rule abstract syntax tree is identified, and the identified private protocol device field is compiled to obtain the private protocol encoding / decoding script;

[0352] Signature processing is performed on multiple first data segments to obtain a signature. The multiple first data segments include at least one of bytecode, capability whitelist, private protocol encoding / decoding script, preset bytecode instruction set and preset mapping index table.

[0353] Based on multiple first data segments and signatures, an edge linkage package is generated.

[0354] In one possible implementation, the sending module 804 is specifically used for:

[0355] Based on the old version edge linkage package corresponding to the linkage rules, determine multiple second data segments;

[0356] Based on multiple second data segments, semantic-level difference comparison processing is performed on multiple first data segments in the edge linkage package to obtain difference data;

[0357] The difference data is encapsulated to obtain a difference package.

[0358] Figure 9This is a schematic diagram of another device linkage device provided in an embodiment of this application. Please refer to... Figure 9 The message scheduling device 900 includes a determination module 901, a processing module 902, an arbitration module 903, and a sending module 904.

[0359] The determination module 901 is used to receive differential packets sent by cloud-side devices and determine edge linkage packets based on the differential packets. The edge linkage packets include bytecode, capability whitelist, private protocol encoding and decoding scripts, and signatures.

[0360] The processing module 902 is used to receive device status events through the virtual device bus, and perform rule execution processing on the device status events according to the edge linkage packet to generate device control instructions.

[0361] Arbitration module 903 is used to perform link arbitration on device control commands to obtain the target link;

[0362] The sending module 904 is used to send device control commands through the target link.

[0363] In one possible implementation, the processing module 902 is specifically used for:

[0364] In response to receiving a device status event, dynamically load the private protocol encoding / decoding script;

[0365] Execute the private protocol encoding / decoding script to encode and decode the protocol data carried in the device status event to obtain the standard object model field;

[0366] Based on standard object model fields, rule execution processing is performed on device status events to generate device control commands.

[0367] In one possible implementation, the processing module 902 is specifically used for:

[0368] Determine whether the standard product model field exists in the capability whitelist;

[0369] If so, based on the standard object model fields, perform rule execution processing on the device status events to generate device control commands;

[0370] If not, record the interception command information, call stack information, timestamp information, and device information, generate an audit log, and upload the audit log to the cloud.

[0371] In one possible implementation, the arbitration module 903 is specifically used for:

[0372] Based on the device control instructions, the score values ​​corresponding to multiple links are determined respectively. These multiple links include cloud links, local area network links, and near-field links.

[0373] The link with the highest score among multiple links is identified as the target link.

[0374] In one possible implementation, before performing rule enforcement processing on the device status events, the device further includes a detection module 905, which is used to:

[0375] Obtain a directed acyclic graph (DAG), which is constructed by using multiple object model attributes as nodes and the read / write dependencies between attributes as edges.

[0376] Based on the directed acyclic graph, detect write conflicts caused by multiple linkage rules in the host device targeting the same object model attribute;

[0377] Based on the rule priority declaration and physical mutex lock, arbitration is performed on linkage rules with write conflicts to determine the target linkage rule.

[0378] The apparatus provided in this embodiment can execute the methods in the above method embodiments, and its implementation principle and technical effect are similar, so it will not be described in detail here.

[0379] Figure 10 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Please refer to... Figure 10 The electronic device 1000 may include: a memory 1001, a processor 1002, and a transceiver 1003.

[0380] Memory 1001 is used to store program instructions;

[0381] The processor 1002 is used to execute the program instructions stored in the memory so that the electronic device 1000 performs the above-described method.

[0382] Transceiver 1003 may include a transmitter and / or a receiver. The transmitter may also be referred to as a transmitter, transmitter, transmitting port, or transmitting interface, and the receiver may also be referred to as a receiver, receiving port, or receiving interface, etc. Exemplarily, memory 1001, processor 1002, and transceiver 1003 are interconnected via bus 1004.

[0383] In the above embodiments, it should be understood that the processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in this invention can be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules within the processor.

[0384] The memory may include random access memory (RAM) and may also include non-volatile memory (NVM), such as at least one disk storage device.

[0385] The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, the buses shown in the accompanying drawings are not limited to a single bus or a single type of bus.

[0386] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the above-described method.

[0387] This application also provides a vehicle, including a vehicle body, an on-board air conditioner, and a controller, the controller being used to execute the methods described in the above method embodiments. The vehicle can be a gasoline-powered vehicle, a new energy vehicle, or a hybrid vehicle; the type of vehicle is not limited.

[0388] This application also provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, implement the above-described method.

[0389] The aforementioned readable storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The readable storage medium can be any available medium accessible to a general-purpose or special-purpose computer.

[0390] An exemplary readable storage medium is coupled to a processor, enabling the processor to read information from and write information to the readable storage medium. Of course, the readable storage medium can also be a component of the processor. The processor and the readable storage medium can reside in an Application Specific Integrated Circuit (ASIC). Alternatively, the processor and the readable storage medium can exist as discrete components in the device.

[0391] The division of units is merely a logical functional division; in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be indirect coupling or communication connection through some interfaces, devices, or units, and may be electrical, mechanical, or other forms.

[0392] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0393] In addition, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

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

[0395] Those skilled in the art will understand that all or part of the steps of the above-described method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When executed, the program performs the steps of the above-described method embodiments; and the aforementioned storage medium includes various media capable of storing program code, such as ROM, RAM, magnetic disks, or optical disks.

[0396] Finally, it should be noted that other embodiments of the invention will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This invention is intended to cover any variations, uses, or adaptations of the invention that follow the general principles of the invention and include common knowledge or customary techniques in the art not disclosed herein, and is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of the invention is limited only by the appended claims.

Claims

1. A method for linking equipment, characterized in that, Applied to cloud-side devices, the method includes: In response to the user's custom editing of the linkage rules, determine the rule description file; The rule description file is compiled into an edge linkage package, which includes bytecode, a capability whitelist, a private protocol encoding / decoding script, and a signature. Based on the old version edge linkage package corresponding to the linkage rule, semantic-level differential processing is performed on the edge linkage package to obtain the differential package of the linkage rule; The differential packet is sent to the host device.

2. The method according to claim 1, characterized in that, The rule description file is compiled into an edge linkage package, including: The rule description file is subjected to field validation processing to obtain validation results, which include validation passed and validation failed. If the verification result is that the verification passes, the rule description file is subjected to de-visualization stripping and abstract syntax tree generation processes in sequence to obtain the rule abstract syntax tree; The rule abstract syntax tree is converted into a sequence of semantic bytecode instructions for the object model to obtain the corresponding bytecode; Based on the abstract syntax tree of the rules and the bytecode, an edge linkage package is generated.

3. The method according to claim 2, characterized in that, Based on the abstract syntax tree of the rules and the bytecode, an edge linkage package is generated, including: The capability field identification process is performed on the rule abstract syntax tree to obtain the capability whitelist; The private protocol device field in the rule abstract syntax tree is identified, and the identified private protocol device field is compiled to obtain the private protocol encoding / decoding script; A signature is obtained by signing multiple first data segments, wherein the multiple first data segments include at least one of the bytecode, the capability whitelist, the private protocol encoding / decoding script, a preset bytecode instruction set, and a preset mapping index table; An edge linkage package is generated based on the plurality of first data segments and the signature.

4. The method according to any one of claims 1-3, characterized in that, Based on the old version edge linkage package corresponding to the linkage rule, semantic-level differential processing is performed on the edge linkage package to obtain a differential package, including: Based on the old version edge linkage package corresponding to the linkage rule, multiple second data segments are determined; Based on the plurality of second data segments, semantic-level difference comparison processing is performed on the plurality of first data segments in the edge linkage package to obtain difference data; The difference data is encapsulated to obtain a difference packet.

5. A method for linking equipment, characterized in that, Applied to a host-side device, the method includes: Receive differential packets sent by cloud-side devices, and determine edge linkage packets based on the differential packets. The edge linkage packets include bytecode, capability whitelist, private protocol encoding / decoding scripts, and signatures. Device status events are received via the virtual device bus, and the device status events are processed according to the edge linkage packet to generate device control commands. The device control commands are arbitrated to obtain the target link; The device control command is sent through the target link.

6. The method according to claim 5, characterized in that, Based on the edge linkage package, the device status events are processed according to rules to generate device control commands, including: In response to receiving the device status event, the private protocol codec script is dynamically loaded; The private protocol encoding / decoding script is executed to encode and decode the protocol data carried in the device status event to obtain the standard object model field; Based on the standard object model fields, the device status events are processed by rule execution to generate the device control instructions.

7. The method according to claim 6, characterized in that, Based on the standard object model fields, rule execution processing is performed on the device status events to generate the device control instructions, including: Determine whether the standard product model field exists in the capability whitelist; If so, based on the standard object model fields, the device status event is processed by rule execution to generate the device control command; If not, record the interception instruction information, call stack information, timestamp information, and device information, generate an audit log, and upload the audit log to the cloud.

8. The method according to any one of claims 5-7, characterized in that, Link arbitration is performed on the device control commands to obtain the target link, including: According to the device control instructions, the scoring values ​​corresponding to multiple links are determined respectively, and the multiple links include cloud links, local area network links and near-field links; The link with the highest score among the multiple links is identified as the target link.

9. The method according to any one of claims 5-7, characterized in that, Before performing rule enforcement processing on the device status events, the method further includes: Obtain a directed acyclic graph, wherein the directed acyclic graph is constructed with multiple object model attributes as nodes and read / write dependencies between attributes as edges; Based on the directed acyclic graph, write conflicts arising from multiple linkage rules in the host-side device targeting the same object model attribute are detected. Based on the rule priority declaration and physical mutex lock, arbitration is performed on linkage rules with write conflicts to determine the target linkage rule.

10. An electronic device, characterized in that, include: Memory, processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory, causing the processor to perform the method as described in any one of claims 1-4.

11. A vehicle, characterized in that, The vehicle includes a host-side device for performing the method according to any one of claims 5-9.

12. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the method as described in any one of claims 1-4 or the method as described in any one of claims 5-9.

13. A computer program product, characterized in that, Includes a computer program that, when executed by a processor, implements the method as described in any one of claims 1-4 or the method as described in any one of claims 5-9.

Images