Access method, device and equipment of Internet of Things equipment model, and storage medium

Abstract

The invention discloses an access method, device and equipment of an internet of things equipment object model, and a storage medium, and the method comprises the steps: analyzing an object model file, generating an intermediate representation of the internet of things equipment, generating an execution context of each command according to the intermediate representation, generating a command processing handle according to a preset general execution function and the execution context, and storing the command processing handle in the storage medium; the command processing handle is registered to the protocol adapter, so that the command processing handle of the to-be-accessed Internet of Things equipment is dynamically generated by adopting one general execution function and execution contexts of different commands, and registration and access of the to-be-accessed Internet of Things equipment are completed; according to the method, the command execution function of each command which needs to be compiled by a developer in the prior art is replaced, the developer does not need to compile the command execution function for each piece of Internet of Things equipment, the development period is shortened, the maintenance cost is reduced, the reliability is high, and the Internet of Things equipment is simple and convenient to access.

Description

Technical Field

[0001] This invention relates to the field of Internet of Things (IoT) technology, and in particular to an access method, apparatus, device, and storage medium for IoT device object models. Background Technology

[0002] With the development of IoT technology, more and more hardware devices are being connected to IoT platforms via wide area networks or local area networks, making it easier for users to interact with IoT devices.

[0003] When an IoT device is first connected to an IoT platform, developers need to manually write data parsing logic and command execution functions in the backend code of the IoT platform based on the IoT device's object model file. Every time a new type of IoT device is connected or a new function command is added to a device, developers need to modify the code, recompile, and re-deploy the system, resulting in a long development cycle, high maintenance costs, and a high risk of errors. Summary of the Invention

[0004] This invention provides a method, apparatus, device, and storage medium for accessing IoT device object models. When an IoT device is first accessed, there is no need to manually write execution functions for various commands of the IoT device, which shortens the development cycle, reduces maintenance costs, and has high reliability. The access of IoT devices is simple and convenient.

[0005] In a first aspect, the present invention provides an access method for an Internet of Things (IoT) device object model, comprising:

[0006] When an IoT device to be connected is detected, the object model file of the IoT device is obtained;

[0007] The object model file is parsed to generate an intermediate representation of the IoT device;

[0008] The execution context of each command of the IoT device is generated based on the intermediate representation;

[0009] A command processing handle for the command is generated based on a pre-configured generic execution function and the execution context;

[0010] Register the command processing handle to the protocol adapter.

[0011] Secondly, the present invention provides an access device for an Internet of Things (IoT) device model, comprising:

[0012] The object model file acquisition module is used to acquire the object model file of the IoT device when an IoT device to be connected is detected.

[0013] An intermediate representation generation module is used to parse the object model file and generate an intermediate representation of the Internet of Things device.

[0014] An execution context generation module is used to generate the execution context of each command of the IoT device based on the intermediate representation;

[0015] A command processing handle generation module is used to generate a command processing handle for the command based on a pre-configured general execution function and the execution context.

[0016] The handle registration module is used to register the command processing handle to the protocol adapter.

[0017] Thirdly, the present invention provides an electronic device, the electronic device comprising:

[0018] At least one processor; and

[0019] A memory communicatively connected to the at least one processor; wherein,

[0020] The memory stores a computer program that can be executed by the at least one processor, the computer program being executed by the at least one processor to enable the at least one processor to perform the access method for the Internet of Things device model according to the first aspect of the present invention.

[0021] Fourthly, the present invention provides a computer-readable storage medium storing computer instructions, which are used to cause a processor to execute and implement the Internet of Things device object model access method described in the first aspect of the present invention.

[0022] This invention, after obtaining the object model file of the IoT device to be connected, parses the object model file and generates an intermediate representation of the IoT device. Based on the intermediate representation, it generates the execution context of each command of the IoT device. Based on a pre-configured general execution function and the execution context, it generates command processing handles for the commands and registers the command processing handles to the protocol adapter. This realizes the assembly of command processing handles for different commands based on a general execution function and the execution contexts of different commands. In other words, it uses a general execution function and the execution contexts of different commands to dynamically generate command processing handles for each command of the IoT device to be connected, thereby completing the registration and access of the IoT device. This replaces the traditional technology where developers need to write command execution functions for each command of the IoT device to be connected. Developers do not need to write command execution functions for each IoT device, shortening the development cycle, reducing maintenance costs, and ensuring high reliability. This allows IoT devices to connect to the IoT simplely, conveniently, and quickly.

[0023] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of the present invention, nor is it intended to limit the scope of the invention. Other features of the invention will become readily apparent from the following description. Attached Figure Description

[0024] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0025] Figure 1 This is a flowchart of an IoT device object model access method provided in Embodiment 1 of the present invention;

[0026] Figure 2 This is a flowchart of an IoT device object model access method provided in Embodiment 2 of the present invention;

[0027] Figure 3 This is a system framework diagram of the IoT platform according to an embodiment of the present invention;

[0028] Figure 4 This is a flowchart of generating a command processing handle in an embodiment of the present invention;

[0029] Figure 5 This is a flowchart illustrating an example of command execution in an embodiment of the present invention;

[0030] Figure 6 This is a schematic diagram of the structure of an access device for an IoT device object model provided in Embodiment 3 of the present invention;

[0031] Figure 7 This is a schematic diagram of the structure of the electronic device provided in Embodiment 4 of the present invention. Detailed Implementation

[0032] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.

[0033] Example 1

[0034] Figure 1This is a flowchart of a method for accessing an IoT device object model according to Embodiment 1 of the present invention. This embodiment is applicable to the situation of accessing IoT device object models in the Internet of Things (IoT). This method can be executed by an IoT device object model access device, which can be implemented in hardware and / or software and can be configured in an electronic device. Figure 1 As shown, the access method for this IoT device model includes:

[0035] S101. When an IoT device to be connected is detected, obtain the object model file of the IoT device.

[0036] In this embodiment, the IoT device can be various sensors (such as ambient light sensors, temperature sensors, etc.), smart home appliances (such as smart lights, televisions, refrigerators, etc.), etc. In one embodiment, when the IoT device connects for the first time, the IoT device can actively initiate a registration request to the IoT platform. When the IoT platform receives the registration request, it determines that it has detected the IoT device to be connected and determines the device identifier of the IoT device. The device identifier can be information representing the identity of the IoT device, such as the device identifier can be the SN number, MAC address, IMEI code, etc. In another embodiment, the IoT platform can also actively scan the network or interface according to a preset period. When the scan finds an unidentified IoT device, it can determine that it has detected the IoT device to be connected. The IoT platform can send a probe message to the IoT device to be connected. After the IoT device responds to the probe message, it can obtain the device identifier from the response data.

[0037] The object model file can be a standardized configuration file that describes the functions and interaction rules of IoT devices. The object model file records the attributes, commands, events and protocol adaptation information of IoT devices in structured data. The object model file can be in the format of JSON, YAML, TOML, XML, etc. The object model file describes the key contents such as what the device can do (commands), what information it can provide (attributes), what status it can report (events), and how to communicate with the device (protocol association information).

[0038] In this embodiment, after detecting the IoT device to be connected and determining the device identifier, the device model file can be read from the local device model library, the cloud device model library, or the IoT device itself based on the device identifier. Specifically, the device identifier can be used to first check whether the local cache library contains the IoT device's device model file. If the local cache library does not contain the file, the device model file can be downloaded from the preset cloud device model library based on the device identifier. In addition, for devices with self-describing capabilities (such as devices connected via USB, HDMI, EDID, etc.), the device model file can be read directly from the IoT device itself, realizing multi-channel and intelligent acquisition of device model files and improving the reliability of acquiring device model files in various network environments.

[0039] S102. Parse the object model file and generate an intermediate representation of the IoT device.

[0040] In this embodiment, the intermediate representation (IR) of an IoT device is a standardized description file for the IoT device. Through the intermediate representation, various formats of object model files can be abstracted into a unified format description file, providing a unified data foundation for IoT device access and registration. The intermediate representation describes the attributes, commands, events, protocol conversion rules, data verification rules, and other information of the IoT device in a unified format.

[0041] Specifically, in this embodiment, for object model files of different formats, the object model file can be parsed using the corresponding parsing method to obtain parsed data, and at least one preset field content information can be extracted from the parsed data. The preset field and field content information are used to generate a standardized intermediate representation of the Internet of Things device. The field content information includes at least one of the following: device basic information, attribute definition set information, command definition set information, protocol information, event definition set information, and general configuration information.

[0042] The basic information settings can include the device ID, communication address, etc.; the attribute definition set information can include the attribute ID, attribute name, data type, update frequency, etc.; the command definition set information can include the command ID, command name, parameter list, parameter validation rules, etc.; the protocol information can include the protocol type, such as MQTT / CoAP / HTTP / custom protocol, etc.; the event definition set information can include the event ID, event name (such as low battery event), trigger condition (such as battery level less than 10%), reported data list, priority, etc.; and the general configuration information can include the object model version, protocol adaptation type, etc.

[0043] S103. Generate the execution context of each command of the IoT device based on the intermediate representation.

[0044] The execution context can include information such as parameter verification rules, protocol conversion rules, and target address of IoT devices required when executing commands. The intermediate representation includes a set of command definitions. For each command in the command definition set, the parameter verification rules, protocol conversion rules, and target address of IoT devices can be read from the intermediate representation as the execution context, and the execution context is stored in memory.

[0045] S104. Generate a command processing handle for the command based on the pre-configured generic execution function and execution context.

[0046] In this embodiment, the CommandHandle is the core bridge connecting the intermediate representation and the device control logic. It is a lightweight, directly callable structured object. In this embodiment, a general execution function can be pre-configured. This general execution function accepts the command name and control parameters as input. It is the execution entry point for all commands and the unified execution template for all commands. This general execution function can be pre-compiled in the firmware.

[0047] A command handling handle is a standardized structure that includes a function pointer and a context pointer. The function pointer points to a unified, generic execution function, while the context pointer executes the execution context of that command. Through this command handling handle, the generic execution function can be bound to the execution context required to execute the command. This allows replacing the N command-specific execution functions in existing technologies with a single generic execution function combined with N command-specific execution contexts. On the one hand, developers do not need to write execution functions for each command, shortening the development cycle and avoiding the error-prone problems of manually writing execution functions, thus improving reliability. On the other hand, the command handling handle uses less temporary storage space than the execution function, saving resources, making it easier to maintain, reducing maintenance costs, and making IoT device access simpler and more convenient.

[0048] S105. Register the command processing handle to the protocol adapter.

[0049] Each command's execution context includes protocol conversion rules, which determine the target protocol adapter for those rules. The command processing handle is then registered with the target protocol adapter. Once all commands from the IoT device to be connected have generated command processing handles and been registered, the IoT device completes its connection. When the IoT platform receives a control command for the IoT device, it locates the corresponding command processing handle, uses the function pointer and context in the handle to call a general execution function, and passes the control parameters and execution context to this function. The general execution function validates the control parameters based on the parameter validation rules in the execution context. If the validation passes, it sends the control parameters, command name, and target address to the corresponding protocol adapter. The protocol adapter performs protocol conversion, generates a control message, and sends it to the IoT device at the target address to control the IoT device.

[0050] In this embodiment, the protocol adapter performs format conversion and message transmission and reception without needing to pay attention to the device and commands, thus decoupling the protocol adaptation layer from the device control logic, that is, achieving separation of the control plane and the transmission plane.

[0051] This invention, after obtaining the object model file of the IoT device to be connected, parses the object model file and generates an intermediate representation of the IoT device. Based on the intermediate representation, it generates the execution context of each command of the IoT device. Based on a pre-configured general execution function and the execution context, it generates command processing handles for the commands and registers the command processing handles to the protocol adapter. This realizes the assembly of command processing handles for different commands based on a general execution function and the execution contexts of different commands. In other words, it uses a general execution function and the execution contexts of different commands to dynamically generate command processing handles for each command of the IoT device to be connected, thereby completing the registration and access of the IoT device. This replaces the traditional technology where developers need to write command execution functions for each command of the IoT device to be connected. Developers do not need to write command execution functions for each IoT device, shortening the development cycle, reducing maintenance costs, and ensuring high reliability. This allows IoT devices to connect to the IoT simplely, conveniently, and quickly.

[0052] Example 2

[0053] Figure 2 This is a flowchart of an IoT device object model access method provided in Embodiment 2 of the present invention. This embodiment of the present invention is an optimization based on Embodiment 1 described above, such as... Figure 2 As shown, the access method for this IoT device model includes:

[0054] S201. When an IoT device to be connected is detected, obtain the object model file of the IoT device.

[0055] When an IoT device is used for the first time, it needs to connect to the IoT platform. The IoT device can actively initiate a registration request to the IoT platform. When the IoT platform receives the registration request, it determines that it has detected the IoT device to be connected. In another embodiment, the IoT platform can also actively scan the network or interface at a preset period to discover the IoT device to be connected. The IoT platform can obtain the device identifier of the IoT device and use the device identifier to read the IoT device's object model file from the local object model library or the cloud object model library, or from the IoT device itself.

[0056] S202. Parse the object model file and generate an intermediate representation of the IoT device.

[0057] like Figure 3 The diagram shows a system block diagram of an IoT platform. The IoT platform may include an access layer, a runtime layer, and a protocol adaptation layer. The access layer may include a device model parsing engine, an intermediate representation generator, and a handle generator. The device model parsing engine can parse device model files in file formats such as JSON, YAML, TOML, XML, and HDMI, and perform syntax and semantic verification to obtain parsed data. The parsed data is input into the intermediate representation generator, which generates an intermediate representation of IoT devices in a unified format. This intermediate representation includes at least one of the following: device basic information, attribute definition set information, command definition set information, protocol information, event definition set information, and general configuration information.

[0058] S203. For each command in the intermediate representation, obtain the command's basic information, parameter verification rules, protocol conversion rules, and the address information of the IoT device.

[0059] The intermediate representation of the IoT device is input into the handle generator. For each command in the intermediate representation, the handle generator obtains the command basic information, parameter verification rules, protocol conversion rules, and IoT device address information from the intermediate representation.

[0060] S204. Fill the command basic information, parameter verification rules, protocol conversion rules, and address information into the corresponding field positions in the pre-configured execution context template to obtain the command execution context.

[0061] In this embodiment, an execution context template can be pre-configured. The execution context template can be a lightweight structure. The execution context obtained after the structure is filled includes all the information required to execute a command. For each command, the basic information of the command, parameter verification rules, protocol conversion rules, and address information can be filled into the corresponding field positions in the pre-configured execution context template to obtain the execution context of the command. Memory is allocated for the execution context of each command, and a context pointer is set to point to the memory address.

[0062] S205. Obtain the function pointer of the general execution function and the context pointer of the command execution context.

[0063] In this embodiment, a general command execution function can be pre-configured. This general execution function accepts the command name and control parameters as input. It is the execution entry point for all commands and a unified execution template for all commands. This general execution function can be pre-compiled in the firmware and a function pointer pointing to the general execution function can be set.

[0064] When generating a command processing handle for each command, the handle generator can obtain a function pointer to a generic execution function and a context pointer to the execution context of the command.

[0065] S206. The command processing handle for generating commands, which includes function pointers and context pointers.

[0066] Specifically, command processing handles can be generated using function pointers and context pointers, making the command processing handle include function pointers and context pointers. This binds the general execution function to the execution context of the command, making the command processing handle a directly callable unit. When the command processing handle is called, it is equivalent to executing the command and the logic of the IoT device through the general execution function. This avoids the performance and complexity issues caused by interpreting or compiling native code at runtime, achieving execution efficiency close to that of native code. At the same time, command processing handles for each command can be dynamically generated.

[0067] like Figure 3 As shown, after generating the command processing handle for the IoT device, the device agent module dynamically instantiates an agent for each IoT device and manages the association between the IoT device and the dynamically generated command processing handle through the attribute management module.

[0068] S207. Determine the target protocol adapter for the command based on the intermediate representation, and register the command processing handle to the target protocol adapter.

[0069] The intermediate representation includes the protocol type of the command. The handle registration module of the runtime layer can determine the target protocol adapter from the protocol adaptation layer based on the protocol type and register the command processing handle to the target protocol adapter.

[0070] Figure 4 The diagram shown is a flowchart for dynamically generating handles, as follows: Figure 4As shown, the object model parsing engine parses the object model's JSON, extracts command metadata, parameter constraints, and protocol configuration, and sends a creation command request to the handle factory. The handle factory requests the memory manager to allocate context memory and receives the context pointer returned by the memory manager. Based on the command metadata, parameter constraints, and protocol configuration, it populates the context template, sets the protocol type, configures the target address, defines verification rules, sends a handle memory request to the memory manager, and receives the handle pointer returned by the memory manager. The handle generator initializes the handle, sets the function in the handle to the generic execution function pointed to by the function pointer, and the context to the context pointed to by the context pointer. It obtains the command processing handle, registers the command processing handle to the registry, and returns the registration result to the handle factory. The handle factory returns the handle processing command to the object model parsing engine.

[0071] S208. Upon receiving a control command, determine the target command processing handle based on the command name of the control command.

[0072] In one embodiment, a user can send a structured control command, including a command name and control parameters, to an IoT platform via a mobile app, webpage, or API. After receiving the control command, the IoT platform uses the command name to find the target command processing handle in the command registry through the mapping between the command name and the handle.

[0073] S209. Call the function pointer and context pointer in the target command processing handle to call the general execution function and obtain the target context, and pass the control parameters in the control command and the obtained target context to the general execution function.

[0074] The target command handling handle includes a function pointer and a context pointer. The function pointer can call a generic execution function, and the context pointer can read the execution context from memory, passing the control parameters in the control command and the read execution context into the generic execution function.

[0075] S210. The control parameters are validated based on the parameter validation rules in the target context through a general execution function, and the target protocol conversion rules and target address are read from the target context.

[0076] The general execution function determines the parameter verification rules, target protocol conversion rules, and target address from the target context. It then verifies the control parameters using the parameter verification rules to determine whether the control parameters are correct.

[0077] S211. After successful verification, the command name, control parameters, and target address are sent to the protocol adapter corresponding to the target protocol conversion rule, so that the command name and control parameters are converted into control messages and sent to the IoT device corresponding to the target address through the target protocol adapter.

[0078] After the general execution function passes the control parameter verification, it can send the command name, control parameters, and target address to the protocol adapter corresponding to the target protocol conversion rule. The target protocol adapter converts the command name and control parameters into control messages and sends them to the IoT device corresponding to the target address. After receiving the control messages, the IoT device performs relevant control operations.

[0079] Taking the user issuing a control command for the smart light light_A (such as {"command":"setBrightness","params":{"level":80}}) as an example, the specific process is as follows:

[0080] Command name matching search: The IoT platform searches the registry for the handle_bright corresponding to the smart light light_A by using the command name setBrightness.

[0081] Call the function pointer of the handle: The handle_bright contains two pointers: executor_func (pointing to the universal execution function universal_command_executor) and bound_context (pointing to the execution context ctx_bright of the brightness adjustment command). Call the universal execution function through bound_context and pass the user parameter level:80 and the execution context ctx_bright to the universal execution function.

[0082] Parameter validation: The general execution function reads the parameter validation rules (level is an integer from 0 to 100) from the execution context ctx_bright and validates whether the parameter 80 passed by the user meets the requirements.

[0083] Protocol Conversion: After successful verification, the general execution function sends the command name, control parameters, and the target address of the smart light light_A in the execution context to the registered protocol adapter;

[0084] The protocol adapter sends a control message to the smart light light_A: Based on the protocol conversion rules in the execution context ctx_bright, the protocol adapter converts the general format parameter ({"level":80}) into a protocol message format that the smart light light_A can recognize. For example, if the specified protocol is MQTT and the encoding format is JSON, the converted MQTT message content is {"command":"setBrightness","level":80}. The protocol adapter sends the converted message content to the target address ( / device / light_A / control), which is a dedicated MQTT topic message that the smart light light_A continuously subscribes to. Upon receiving the message, it parses it and executes the operation to set the brightness to 80.

[0085] Figure 5 The diagram shown is a flowchart of an example command execution, such as... Figure 5 As shown, the user sends a request to set brightness A. The command finder returns a handle to the user through the brightness setting command lookup. The user calls this handle, and the command processing handle calls a general execution function through a function pointer. The execution context is read through the context execution, and the context and control parameter A are sent to the executor. The executor verifies parameter A. If the verification is successful, the corresponding protocol adapter is called based on the protocol type in the context. The protocol adapter performs protocol conversion on the command and parameter A to obtain a message, which is then sent to the target device corresponding to the target address. After receiving the message, the target device adjusts the brightness to A and returns an acknowledgment message.

[0086] The IoT device object model access method of this invention has the following beneficial effects:

[0087] (1) By parsing the object model file, the execution context of each command of the IoT device is obtained. By dynamically generating the command processing handle of each command, the general execution function and the execution context are bound together. This replaces the traditional method of manually writing the function code of each IoT device command. On the one hand, developers do not need to write command execution functions for each IoT device, which shortens the development cycle, reduces maintenance costs, and has high reliability. IoT devices are easy and convenient to access. On the other hand, it can maintain the execution efficiency of the native code level of the general execution function and can dynamically extend the device commands at runtime, which fundamentally solves the performance, memory and security problems of dynamic technology in the embedded environment.

[0088] (2) The protocol adapter performs format conversion and message sending and receiving without having to pay attention to device type and command. This decouples the protocol adaptation layer from the device control logic, that is, it separates the control plane from the transmission plane. New types of devices can be plugged in and used without modifying or recompiling the core platform code. The control logic can be automatically generated and the system integration can be completed through the object model file of the IoT device, which greatly improves the flexibility and scalability of the system.

[0089] (3) When acquiring the object model file, the local cache library is queried first. If the local cache library is not found, the object model file is downloaded from the cloud object model library according to the device identifier. For IoT devices with self-describing capabilities, the object model file is read directly from the IoT device's own interface. This ensures that the acquisition and adaptive access of the object model file can be reliably completed in various complex network environments, including online, offline, and for different IoT devices, thereby enhancing the robustness and application scope of the platform.

[0090] (4) After parsing, object model files of different source formats generate intermediate representations of a unified format, which abstracts the differences in underlying description formats. This provides a unified and structured input for the dynamic code generation of subsequent command processing handles, and also achieves compatibility with object model files of multiple formats. It isolates the complexity of front-end parsing from the stability of back-end code generation, thereby improving the platform's versatility and maintainability.

[0091] Example 3

[0092] Figure 6 This is a schematic diagram of the structure of an access device for an IoT device object model provided in Embodiment 3 of the present invention. Figure 6 As shown, the access device for this IoT device model includes:

[0093] The object model file acquisition module 601 is used to acquire the object model file of the IoT device when an IoT device to be connected is detected;

[0094] The intermediate representation generation module 602 is used to parse the object model file and generate an intermediate representation of the Internet of Things device.

[0095] The execution context generation module 603 is used to generate the execution context of each command of the Internet of Things device based on the intermediate representation;

[0096] The command processing handle generation module 604 is used to generate a command processing handle for the command based on a pre-configured general execution function and the execution context.

[0097] The handle registration module 605 is used to register the command processing handle to the protocol adapter.

[0098] Optionally, the object model file acquisition module 601 includes:

[0099] The device identifier determination unit is used to determine the device identifier of the IoT device when an IoT device to be connected is detected;

[0100] The object model file reading unit is used to read the object model file of the Internet of Things (IoT) device from a local object model library or a cloud object model library, or from the IoT device, based on the device identifier.

[0101] Optionally, the intermediate representation generation module 602 includes:

[0102] The object model file parsing unit is used to parse the object model file to obtain parsed data, and extract the field content information of at least one preset field from the parsed data;

[0103] An intermediate representation generation unit is used to generate a standardized intermediate representation of the Internet of Things device using the preset fields and the field content information;

[0104] The field content information includes at least one of the following: device basic information, attribute definition set information, command definition set information, protocol information, event definition set information, and general configuration information.

[0105] Optionally, the execution context generation module 603 includes:

[0106] The information extraction unit is used to obtain, for each command in the intermediate representation, the command basic information, parameter verification rules, protocol conversion rules, and address information of the IoT device.

[0107] The template filling unit is used to fill the command basic information, parameter verification rules, protocol conversion rules and address information into the corresponding field positions in the pre-configured execution context template to obtain the execution context of the command.

[0108] Optionally, the command processing handle generation module 604 includes:

[0109] The pointer acquisition unit is used to acquire the function pointer of the general execution function and the context pointer of the execution context of the command;

[0110] A handle generation unit is used to generate a command processing handle for the command, wherein the command processing handle includes the function pointer and the context pointer.

[0111] Optionally, the handle registration module 605 includes:

[0112] A target protocol adapter determination unit is configured to determine the target protocol adapter for the command based on the intermediate representation.

[0113] A handle registration unit is used to register the command processing handle to the target protocol adapter.

[0114] Optionally, it also includes:

[0115] The target handle determination module is used to determine the target command processing handle based on the command name of the control command when a control command is received.

[0116] The pointer invocation module is used to invoke the function pointer and context pointer in the target command processing handle to invoke the general execution function and obtain the target context, and pass the control parameters in the control command and the obtained target context to the general execution function;

[0117] The parameter verification module is used to verify the control parameters based on the parameter verification rules in the target context through the general execution function, and to read the target protocol conversion rules and target address from the target context;

[0118] The message conversion and sending module is used to send the command name, control parameters and target address to the protocol adapter corresponding to the target protocol conversion rule after the verification is passed, so that the target protocol adapter can convert the command name and control parameters into a command message and send it to the IoT device corresponding to the target address.

[0119] The IoT device object model access device provided in the embodiments of the present invention can execute the IoT device object model access method provided in any embodiment of the present invention, and has the corresponding functional modules and beneficial effects of the execution method.

[0120] Example 4

[0121] Figure 7 A schematic diagram of an electronic device 40 that can be used to implement embodiments of the present invention is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices (e.g., helmets, glasses, watches, etc.), and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the invention described and / or claimed herein.

[0122] like Figure 7As shown, the electronic device 40 includes at least one processor 41 and a memory, such as a read-only memory (ROM) 42 or a random access memory (RAM) 43, communicatively connected to the at least one processor 41. The memory stores computer programs executable by the at least one processor. The processor 41 can perform various appropriate actions and processes based on the computer program stored in the ROM 42 or loaded from storage unit 48 into the RAM 43. The RAM 43 may also store various programs and data required for the operation of the electronic device 40. The processor 41, ROM 42, and RAM 43 are interconnected via a bus 44. An input / output (I / O) interface 45 is also connected to the bus 44.

[0123] Multiple components in electronic device 40 are connected to I / O interface 45, including: input unit 46, such as keyboard, mouse, etc.; output unit 47, such as various types of monitors, speakers, etc.; storage unit 48, such as disk, optical disk, etc.; and communication unit 49, such as network card, modem, wireless transceiver, etc. Communication unit 49 allows electronic device 40 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0124] Processor 41 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of processor 41 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various processors running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. Processor 41 performs the various methods and processes described above, such as access methods for IoT device object models.

[0125] In some embodiments, the access method for an IoT device model can be implemented as a computer program tangibly contained in a computer-readable storage medium, such as storage unit 48. In some embodiments, part or all of the computer program can be loaded and / or installed on electronic device 40 via ROM 42 and / or communication unit 49. When the computer program is loaded into RAM 43 and executed by processor 41, one or more steps of the access method for an IoT device model described above can be performed. Alternatively, in other embodiments, processor 41 can be configured to perform the access method for an IoT device model by any other suitable means (e.g., by means of firmware).

[0126] Various implementations of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), complex programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various implementations may include: implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0127] Computer programs used to implement the methods of the present invention may be written in any combination of one or more programming languages. These computer programs may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device, such that when executed by the processor, the computer programs cause the functions / operations specified in the flowcharts and / or block diagrams to be performed. The computer programs may be executed entirely on a machine, partially on a machine, or as a standalone software package, partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0128] In the context of this invention, a computer-readable storage medium can be a tangible medium that may contain or store a computer program for use by or in conjunction with an instruction execution system, apparatus, or device. A computer-readable storage medium may include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination thereof. Alternatively, a computer-readable storage medium may be a machine-readable signal medium. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0129] To provide interaction with a user, the systems and techniques described herein can be implemented on an electronic device having: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user; and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the electronic device. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0130] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as data servers), or middleware components (e.g., application servers), or frontend components (e.g., user computers with graphical user interfaces or web browsers through which users can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., communication networks). Examples of communication networks include local area networks (LANs), wide area networks (WANs), blockchain networks, and the Internet.

[0131] A computing system can include clients and servers. Clients and servers are generally located far apart and typically interact through communication networks. The client-server relationship is created by computer programs running on the respective computers and having a client-server relationship with each other. The server can be a cloud server, also known as a cloud computing server or cloud host, which is a hosting product within the cloud computing service system to address the shortcomings of traditional physical hosts and VPS services, such as high management difficulty and weak business scalability.

[0132] It should be understood that the various forms of processes shown above can be used, with steps reordered, added, or deleted. For example, the steps described in this invention can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution of this invention can be achieved, and this is not limited herein.

[0133] The specific embodiments described above do not constitute a limitation on the scope of protection of this invention. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this invention should be included within the scope of protection of this invention.

Claims

1. A method for accessing an IoT device object model, characterized in that, include: When an IoT device to be connected is detected, the object model file of the IoT device is obtained; The object model file is parsed to generate an intermediate representation of the IoT device; The execution context of each command of the IoT device is generated based on the intermediate representation; A command processing handle for the command is generated based on a pre-configured generic execution function and the execution context; Register the command processing handle to the protocol adapter.

2. The method according to claim 1, characterized in that, When an IoT device to be connected is detected, the object model file of the IoT device is obtained, including: When an IoT device to be connected is detected, the device identifier of the IoT device is determined; Based on the device identifier, the object model file of the IoT device is read from a local object model library or a cloud object model library, or from the IoT device itself.

3. The method according to claim 1, characterized in that, Parsing the object model file and generating an intermediate representation of the IoT device includes: The object model file is parsed to obtain parsed data, and the field content information of at least one preset field is extracted from the parsed data; A standardized intermediate representation of the IoT device is generated using the preset fields and the field content information; The field content information includes at least one of the following: device basic information, attribute definition set information, command definition set information, protocol information, event definition set information, and general configuration information.

4. The method according to claim 3, characterized in that, The execution context for each command of the IoT device is generated based on the intermediate representation, including: For each command in the intermediate representation, obtain the command basic information, parameter verification rules, protocol conversion rules, and address information of the IoT device; The command's basic information, parameter validation rules, protocol conversion rules, and address information are filled into the corresponding field positions in the pre-configured execution context template to obtain the execution context of the command.

5. The method according to claim 1, characterized in that, A command processing handle for the command is generated based on a pre-configured generic execution function and the execution context, including: Obtain the function pointer of the general execution function and the context pointer of the execution context of the command; A command processing handle for the command is generated, the command processing handle including the function pointer and the context pointer.

6. The method according to claim 1, characterized in that, Registering the command processing handle to the protocol adapter includes: The target protocol adapter for the command is determined based on the intermediate representation; Register the command processing handle to the target protocol adapter.

7. The method according to any one of claims 1-6, characterized in that, After registering the command processing handle to the protocol adapter, the process also includes: Upon receiving a control command, the target command processing handle is determined based on the command name of the control command; The function pointer and context pointer in the target command processing handle are invoked to call the general execution function and obtain the target context, and the control parameters in the control command and the obtained target context are passed to the general execution function; The control parameters are validated based on the parameter validation rules in the target context using the general execution function, and the target protocol conversion rules and target address are read from the target context. After successful verification, the command name, control parameters, and target address are sent to the protocol adapter corresponding to the target protocol conversion rule, so that the target protocol adapter can convert the command name and control parameters into a command message and send it to the IoT device corresponding to the target address.

8. An access device for an Internet of Things (IoT) device model, characterized in that, include: The object model file acquisition module is used to acquire the object model file of the IoT device when an IoT device to be connected is detected. An intermediate representation generation module is used to parse the object model file and generate an intermediate representation of the Internet of Things device. An execution context generation module is used to generate the execution context of each command of the IoT device based on the intermediate representation; A command processing handle generation module is used to generate a command processing handle for the command based on a pre-configured general execution function and the execution context. The handle registration module is used to register the command processing handle to the protocol adapter.

9. An electronic device, characterized in that, The electronic device includes: At least one processor; and A memory communicatively connected to the at least one processor; wherein, The memory stores a computer program that can be executed by the at least one processor, the computer program being executed by the at least one processor to enable the at least one processor to perform the access method of the Internet of Things device model according to any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions that, when executed by a processor, implement the access method for the IoT device object model as described in any one of claims 1-7.

Images