Object model updating method, electronic device, and storage medium

Abstract

The embodiment of the application provides a kind of thing model updating method, electronic equipment and computer readable storage medium, it is related to the field of Internet of Things.The method comprises the following steps: in response to the access operation of Internet of Things equipment, the model of Internet of Things equipment is determined;If it is determined that the thing model of the model is not stored, the thing model acquisition request is sent to the cloud;Receive and store the first thing model of the model sent by the cloud, and communicate with the Internet of Things equipment according to the first thing model;Wherein, the first thing model is generated according to the second thing model of the model by the cloud;The first thing model is TLV encoding format;The second thing model is TSL description format.The embodiment of the application stores the thing model of TLV encoding format, and compared with the thing model of TSL description format, the function item of cloud special or irrelevant to gateway is omitted, can avoid invalid data transmission and gateway storage pollution.

Description

Technical Field

[0001] This application relates to the field of Internet of Things (IoT) technology, and more specifically, to a method, apparatus, electronic device, computer-readable storage medium, and computer program product for updating object models. Background Technology

[0002] In the Internet of Things (IoT) field, especially in smart home systems, gateways need to manage various models of smart sub-devices (such as switches, sensors, and lights) using different protocols. To achieve unified management, object models are typically used to digitally describe the functions of these devices. Common object model standards include the feature-rich Thing Specification Language (TSL) format and the Type-Length-Value (TLV) format, which is suitable for resource-constrained devices. Summary of the Invention

[0003] This application provides a method, apparatus, electronic device, computer-readable storage medium, and computer program product for updating a physical model, which can solve the above-mentioned problems of the prior art. The technical solution is as follows: According to one aspect of the embodiments of this application, a method for updating a physical model is provided, the method comprising: In response to an access operation by an IoT device, the model of the IoT device is determined; If it is determined that the object model of the specified model is not stored, a request to retrieve the object model is sent to the cloud. Receive and store the first physical model of the specified model sent by the cloud, and communicate with the Internet of Things device based on the first physical model; The first object model is generated by the cloud based on the second object model of the specified model. The first object model is in TLV encoding format, including information of each first functional item, which is used for the gateway to communicate with IoT devices; The second object model adopts the TSL description format, including information on each of the first and second functional items. The second functional item is used for communication between the cloud and IoT devices.

[0004] According to another aspect of the embodiments of this application, a property model updating apparatus is provided, the apparatus comprising: The model determination module is used to determine the model of the IoT device in response to the access operation of the IoT device; The request sending module is used to send a request to the cloud to obtain the object model if it is determined that the object model of the specified model is not stored. The communication module is used to receive and store the first physical model of the specified model sent by the cloud, and to communicate with the Internet of Things device based on the first physical model; The first object model is generated by the cloud based on the second object model of the specified model. The first object model is in TLV encoding format, including information of each first functional item, which is used for the gateway to communicate with IoT devices; The second object model adopts the TSL description format, including information on each of the first and second functional items. The second functional item is used for communication between the cloud and IoT devices.

[0005] According to another aspect of the embodiments of this application, an electronic device is provided, the electronic device including a memory, a processor and a computer program stored in the memory, the processor executing the computer program to implement the above-described object model update method.

[0006] According to another aspect of the embodiments of this application, a computer-readable storage medium is provided, on which a computer program is stored, which, when executed by a processor, implements the above-described object model update method.

[0007] According to one aspect of the embodiments of this application, a computer program product is provided, including a computer program that, when executed by a processor, implements the above-described object model update method.

[0008] The beneficial effects of the technical solution provided in this application are as follows: The gateway responds to the access operation of an IoT device, determines the model of the IoT device, and does not need to load all potentially supported object models at startup. Object model queries are only triggered when the IoT device is actually connected, significantly shortening the gateway's startup time and initialization memory usage. Furthermore, the gateway does not need to upgrade firmware or update the model library to support new devices. As long as object models are stored in the cloud, the gateway can dynamically support them, greatly enhancing the system's backward compatibility and scalability. The gateway in this application only needs to store object models in TLV encoding format, and compared to object models in TSL description format, this object model omits cloud-specific or gateway-irrelevant functional items, avoiding invalid data transmission and gateway storage pollution. Attached Figure Description

[0009] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments of this application will be briefly introduced below.

[0010] Figure 1 This is a schematic diagram of the system architecture for updating the implementation model provided in the embodiments of this application; Figure 2A flowchart illustrating a method for updating an object model provided in an embodiment of this application; Figure 3 An interactive flowchart illustrating an object model update method provided in an embodiment of this application; Figure 4 A schematic diagram of a process for generating a first object model provided in an embodiment of this application; Figure 5 This is a schematic diagram of the structure of a physical model updating device provided in an embodiment of this application; Figure 6 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0011] The embodiments of this application are described below with reference to the accompanying drawings. It should be understood that the embodiments described below with reference to the accompanying drawings are exemplary descriptions for explaining the technical solutions of the embodiments of this application, and do not constitute a limitation on the technical solutions of the embodiments of this application.

[0012] Those skilled in the art will understand that, unless otherwise stated, the singular forms “a,” “an,” and “the” used herein may also include the plural forms. It should be further understood that the terms “comprising” and “including” as used in embodiments of this application mean that the corresponding feature can be implemented as the presented feature, information, data, step, operation, element, and / or component, but do not exclude implementation as other features, information, data, step, operation, element, component, and / or combinations thereof supported by the art. It should be understood that when we say that an element is “connected” or “coupled” to another element, the one element can be directly connected or coupled to the other element, or it can mean that the one element and the other element establish a connection relationship through an intermediate element. Furthermore, “connected” or “coupled” as used herein can include wireless connection or wireless coupling. The term “and / or” as used herein indicates at least one of the items defined by the term; for example, “A and / or B” can be implemented as “A,” or as “B,” or as “A and B.”

[0013] To make the objectives, technical solutions, and advantages of this application clearer, the embodiments of this application will be described in further detail below with reference to the accompanying drawings.

[0014] In the Internet of Things (IoT) field, especially in smart home systems, gateways need to manage various models and protocols of smart sub-devices (such as switches, sensors, and lights). To achieve unified management, object models are typically used to digitally describe the functions of these devices. Common object model standards include the feature-rich TSL description format and the simplified TLV encoding format suitable for resource-constrained devices.

[0015] In existing technologies, the device's TSL model file (used for communication between the cloud and the device application layer for display and interaction with the cloud) and TLV model file (used for low-power communication between the gateway and sub-devices within the local area network) typically need to be manually written and maintained by developers. Gateways often need to pre-configure or pull all potentially supported sub-device model files at the factory or during initialization for use when binding new devices.

[0016] The shortcomings and deficiencies of existing technologies and the technical problems that this invention aims to solve. Low development efficiency: TSL and TLV files need to be written and maintained manually. When the device function changes, both files need to be modified simultaneously, which is prone to errors and consumes a lot of development time.

[0017] Gateway resource waste: Gateways need to store complete model files of all potential devices, which consumes a lot of unnecessary storage space and memory resources, and is cost-sensitive for embedded devices.

[0018] Inconvenient model updates: When device firmware is upgraded or functions are added, the object model may change. Existing solutions struggle to achieve dynamic and seamless updates of the gateway-side object model, potentially leading to new functions being unusable or control malfunctions.

[0019] The object model updating method, apparatus, electronic device, computer-readable storage medium, and computer program product provided in this application are intended to solve the above-mentioned technical problems of the prior art, so as to improve development efficiency, save gateway resources, and support flexible updates.

[0020] The technical solutions of this application and their effects are described below through several exemplary embodiments. It should be noted that the following embodiments can be referenced, borrowed from, or combined with each other. Identical terms, similar features, and similar implementation steps in different embodiments will not be repeated.

[0021] Figure 1 This is a schematic diagram of the system architecture for updating the implementation model provided in an embodiment of this application, which includes a cloud 101, a gateway 102, and at least one Internet of Things (IoT) device 103. The cloud platform 101 is used to receive second object models of various IoT devices published by developers. The second object model adopts the TSL description format and includes information of each first function item and second function item. The first function item is used for communication between the gateway and the IoT device, and the second function item is used for communication between the cloud platform and the IoT device. The cloud platform 101 generates the corresponding first object model through the object model update method provided in the embodiment of this application. The first object model is in TLV encoding format, which is different from the second object model. The first object model includes information of each first function item but does not include information of each second function item.

[0022] Gateway 102 is used to respond to the access operation of any IoT device 103, determine the model of the IoT device, and if it is determined that the model is not stored, send a model acquisition request to the cloud, receive and store the first model of the model sent by the cloud, and communicate with the IoT device according to the first model.

[0023] This application provides a method for updating an object model, such as... Figure 2 As shown, the method includes: S101. In response to the access operation of the IoT device, determine the model of the IoT device.

[0024] When a user connects an IoT device to the gateway, the gateway discovers the IoT device and obtains the Product ID, thereby accurately identifying the required object model type for that IoT device model. This avoids the one-size-fits-all pre-set model strategy in traditional solutions and is a prerequisite for subsequent differentiated processing.

[0025] S102. If it is determined that the object model of the specified model is not stored, a request to obtain the object model is sent to the cloud.

[0026] Traditional gateways require pre-storing a large number of object models in JSON format, consuming Flash storage and RAM. This application's embodiment determines the object model by checking the local cache status; only when the object model of that model is not stored locally will a request be sent to the cloud to retrieve it. Verification has shown that this can effectively reduce the gateway's model storage space usage by 50%-90%.

[0027] S103. Receive and store the first physical model of the model sent by the cloud, and communicate with the Internet of Things device based on the first physical model.

[0028] The gateway in this application stores a trimmed TLV-encoded object model (hereinafter referred to as TLV model). Compared with the complete TSL description format object model (hereinafter referred to as TSL model), the TLV model removes a large number of secondary functional items used for cloud display and management, such as desc, from, complex constraints, etc., and only retains the information of the primary functional items necessary for the gateway to communicate with IoT devices. This further reduces the gateway's requirement for Flash storage capacity and lowers the cost threshold of embedded hardware.

[0029] Furthermore, developers only need to maintain one feature-rich TSL model in the cloud (for App display, cloud logic, and rule engine). The cloud automatically converts it into a TLV model suitable for the gateway, avoiding the need to manually write and maintain two sets of files for the TSL model and TLV model separately, reducing the maintenance time of the object model by more than 70%, and reducing the rate of human error.

[0030] It is important to note that in this embodiment, the cloud is responsible for defining the functionality (TSL, for the Internet), while the gateway is responsible for executing communication (TLV, for the local area network). This layered design allows the cloud to iterate the model more freely without worrying about disrupting the underlying parsing logic of the gateway.

[0031] The gateway in this application responds to the access operation of an IoT device by determining the model of the IoT device. It does not need to load all potentially supported object models at startup; object model queries are only triggered when the IoT device is actually connected. This significantly shortens the gateway's startup time and initial memory usage. Furthermore, the gateway does not require firmware upgrades or model library updates to support new devices. As long as object models are stored in the cloud, the gateway can dynamically support them, greatly enhancing the system's backward compatibility and scalability. The gateway in this application only needs to store object models in TLV encoding format. Compared to object models in TSL description format, this object model omits cloud-specific or gateway-irrelevant functional items, avoiding invalid data transmission and gateway storage pollution.

[0032] Based on the above embodiments, as an optional embodiment, the method further includes: receiving an update notification of the first physical model of the model sent by the cloud; Update the local first object model according to the update notification.

[0033] After storing a first IoT model of a certain model, the gateway in this embodiment of the application can send a storage completion notification to the cloud. The gateway identifier and the IoT device model identifier included in the storage completion notification are stored in a first data table maintained locally. Thus, when the cloud obtains a second IoT model of a new version of that model and automatically generates a new version of the first IoT model, it can determine the gateway that stored the first IoT model of that model by searching the first data table, and then send an update notification to the gateway that stored the first IoT model of that model.

[0034] In some embodiments, the update notification may include a download address for the latest version of the first object model of the corresponding model, so that the gateway downloads the latest version of the first object model of the model according to the download address.

[0035] For example, if a manufacturer adds a "battery statistics" attribute to the firmware of a certain model of IoT device already connected to a gateway, and updates the corresponding TSL model in the cloud, the cloud can automatically generate a new version of the TLV model. The cloud then pushes an update notification to all online gateways that have bound to that model of IoT device. After receiving the update notification, the gateway downloads the new version of the TLV model and updates its local cache. Afterward, the gateway can read and report the battery information of the IoT device using the new TLV model.

[0036] In some embodiments, the cloud can also compare the updated (different) first functional items between the latest version and the previous version of the first object model, package the updated first functional items into a difference package, and include the difference package in the update notification. Thus, the gateway can update the local first object model according to the difference package, further saving update traffic and time.

[0037] It should be understood that each functional item in this application embodiment is assigned a functional item identifier. Therefore, the gateway can determine which first functional items in the local first object model need to be updated based on the functional item identifier in the difference packet.

[0038] Based on the above embodiments, as an optional embodiment, the update notification includes the model identifier of the model and the version number of the updated first physical model; The step of updating the local first object model according to the update notification includes: The version number in the update notification is compared with the version number of the first object model stored locally; If the version numbers are inconsistent, the updated first object model or first function item will be downloaded from the cloud.

[0039] The update notification in this application embodiment includes a model identifier and the version number of the updated first object model. The gateway can quickly determine whether the local model is the latest version. If the versions are consistent, there is no need to perform subsequent download operations, reducing unnecessary network requests and gateway computing overhead.

[0040] In some embodiments, after determining that the version numbers are inconsistent, the gateway can send an update item retrieval request to the cloud. This request requests the latest version of the first object model to obtain features that are updated relative to the local version. The gateway can determine whether to download the complete first object model or only the updated first feature based on the proportion of the required updated feature to the total number of features stored locally. For example, if the proportion exceeds a threshold (e.g., 50%), the complete latest version of the first object model is downloaded; otherwise, only the updated first feature is downloaded.

[0041] Please see Figure 3 The figure illustrates an interactive flowchart of the object model update method according to an embodiment of this application, as shown in the figure, which includes: S201. The IoT device sends an access request to the gateway. The access request includes the model of the IoT device. S202. The gateway checks locally whether the object model of the model is stored. If the object model of the model is not stored, it sends an object model retrieval request to the cloud. S203, The cloud sends the first physical model of this type to the gateway; S204. The gateway communicates with the IoT device based on the first object model; S205. The cloud receives the updated second object model of this model and generates the latest version of the first object model based on the updated second object model; S206. The cloud sends an update notification to the gateway. The update notification includes the model identifier of the model and the version number of the updated first object model. S207. The gateway compares the version number in the update notification with the version number of the first object model stored locally. S208. If the version numbers are inconsistent, the gateway downloads the updated first object model or first function item from the cloud to update the local first object model. S209. The gateway communicates with IoT devices based on the locally updated first object model.

[0042] Based on the above embodiments, as an optional embodiment, the first object model is generated by the cloud in the following way: Determine at least one first functional item from the functional items of the second object model; A conversion operation is performed on each first function item, the conversion operation including: If the first function item is determined to be a structure or an array of structures, then each field in the first function item is treated as a new first function item. If it is determined that the first functional item is not a structure or a structure array, a functional item identifier (TID) for the corresponding first functional item in the first object model is generated, and the information of the first functional item in the second object model is converted into the information in the first object model according to the preset conversion rules. The information includes type and name.

[0043] The second functional item in the embodiments of this application often carries the desc:"noWithTlv" flag, indicating that it does not need to be sent to the gateway. Therefore, by traversing each functional item in the second object model to see if it carries the above flag, each functional item can be distinguished into the first functional item and the second functional item.

[0044] It should be understood that TSL models often support complex nested JSON structures (such as localTimer containing multiple subfields), while the TLV protocol between the gateway and the sub-device usually only supports simple tag-value pairs. Therefore, when performing the conversion operation, this application first determines whether a first functional item is a complex structure—a structure or an array of structures. If it is a complex structure, the cloud will recursively traverse its specs, expand each nested subfield into an independent functional item, and generate a unique functional item identifier to flatten the complex data model and adapt it to the simple key-value pair format of TLV.

[0045] If a first functional item is not a structure or an array of structures, a functional item identifier (TID) for the corresponding first functional item in the first object model is generated, and the information of the first functional item in the second object model is converted into the information in the first object model according to a preset conversion rule. The information includes type and name.

[0046] Please refer to Table 1, which exemplarily illustrates the conversion rule table of this application embodiment. The first rule can use the least significant bit of 1 byte to represent the switch state, which saves space and facilitates bit operations. The second rule avoids transmitting lengthy strings between the gateway and the device, greatly improving communication efficiency. The third rule ensures that data does not overflow and avoids the storage waste caused by using large byte types in a "one-size-fits-all" manner. The fourth rule takes into account both accuracy and hardware processing capabilities.

[0047]

[0048] Table 1 Conversion Rules Table Based on the above embodiments, as an optional embodiment, a conversion operation is performed on each first functional item, including: Based on the functional elements of each first functional item, each first functional item is classified to obtain a set of functional items corresponding to each functional element. For each set of functional items, a common functional item is determined from the set of functional items; According to the preset processing order of each function item set, the first function item in each function item set is converted sequentially. For each function item set, the common function item in the function item set is converted first.

[0049] In this embodiment, each functional item is categorized according to its functional elements, including attributes, events, and actions. Each first functional item is classified according to the three functional elements of attributes, events, and actions to form an independent set of functional items. The mixed TSL functional items are classified according to their properties, so that the generated TLV file structure is well-ordered.

[0050] It should be noted that the embodiments of this application can follow different conversion rules for different functional elements—for example, attributes are mostly state values, and actions are function calls. After classification, the cloud can apply specific verification or mapping logic to each set, which reduces the coupling of the code and improves the maintainability of the system.

[0051] In some embodiments, the functional itemsets can be processed sequentially according to the order of attributes, events, and actions. That is, the functional itemsets that are all attributes are transformed first, then the functional itemsets that are all events are transformed, and preferably the functional itemsets that are all actions are transformed last. In this way, no matter how the JSON order of the input TSL file changes, the arrangement order of each functional item and the TID allocation in the output TLV structure are stable, thereby ensuring the determinism of the model transformation process. Developers can confidently edit TSL files without worrying about gateway-side parsing errors caused by field order adjustments, thus improving development efficiency.

[0052] Furthermore, this application identifies and prioritizes common functional items within each functional item set, such as the common attribute macAddr, firmwareVersion, common event errorEvent, and common action resetAction. By prioritizing common functional items, the system ensures that they are assigned to fixed TID ranges across all device models; for example, the functional item identifier macAddr has TID=3. Gateway-side code can write general processing logic for these fixed TIDs without relying on dynamic configuration tables. Regardless of the number of new IoT device models connected, the parsing method for their basic information (such as MAC address and fault reporting) remains consistent, greatly enhancing the system's backward compatibility and stability.

[0053] Based on the above embodiments, as an optional embodiment, at least one first functional item is determined from the functional items of the second object model, further comprising: Verify the validity of the Product Id model number in the second physical model; Extract the configuration information from the second object model, and generate the group identifier Gid Type of the model in the gateway based on the configuration information; Assign a globally unique model identifier (Model Id) to the second object model; Before parsing the TSL model, this embodiment first checks whether the character length and format of the Product ID in its profile conform to the specifications. This ensures that all subsequent operations are based on a valid device model. If the Product ID is invalid (e.g., empty or incorrectly formatted), the system can terminate the process early to avoid wasting computational resources on incorrect models.

[0054] In some embodiments, the cloud extracts the manufacturer ID and model code from the TSL model, and obtains the Gid Type using the formula: Gid Type = ((Manufacturer ID << 9) | Model Code) & 0xFFFFF, which is then converted to 5 hexadecimal digits. Through bitwise operations, this theoretically supports access to the same gateway for devices from a large number of manufacturers and models, resolving the ID conflict issue when the number of devices expands.

[0055] It's important to note that the Gid Type is a crucial index for devices to perform logical grouping and fast lookup within the gateway. Compared to the string-based Product ID, a 5-digit hexadecimal number is more suitable for use in the gateway's underlying communication protocols (such as TP-Mesh), improving the efficiency of device discovery and addressing.

[0056] This application also attempts to read an existing model ID from the TSL model. If it does not exist, it queries the maintained SQLite database to see if a record of the same file already exists, or automatically generates a new globally incrementing Model ID. The Model ID serves as a unique identifier for the model itself. When IoT devices with the same Product ID undergo firmware upgrades or functional changes, the new Model ID can be used to distinguish different versions of the model, ensuring that the gateway can accurately load the corresponding version of the TLV.

[0057] Finally, by combining the Model Id, Product Id, Gid Type, and information from each first functional item within the first object model, a first object model in JSON storage format is generated. The JSON format facilitates both cloud storage and API distribution, as well as gateway parsing. This file contains all the metadata required for gateway-device communication (not only the function list but also the device's basic identity information), achieving a seamless transition from "cloud definition" to "edge execution."

[0058] Please see Figure 4 The figure illustrates an exemplary flowchart of the process for generating a first object model according to an embodiment of this application, as shown in the figure, including: S301. Verify the validity of the Product Id model number in the second physical model; S302. Extract the configuration information from the second physical model, and generate the group identifier Gid Type of the model in the gateway based on the configuration information; S303. Assign a globally unique model identifier, Model Id, to the second object model; S304. Based on the functional elements of each first functional item, classify each first functional item to obtain a set of functional items corresponding to each functional element. S305. Determine if there is an unprocessed set of functional items. If yes, execute S306; otherwise, execute S314. S306. Determine the current function set to be processed according to the preset processing order of each function set; S307. Determine whether all common function items in the function item set have been converted. If not, execute S308; if yes, execute S309. S308. Determine a function item that has not undergone conversion from all common function items as the target function item, and execute S311. S309. Determine whether all function items in the function set have been converted. If yes, determine that the current function item set has been processed and return to step S305. If no, execute S310. S310. Determine a function item that has not undergone conversion from among the various non-common function items, and use it as the target function item. Execute S311. S311. Determine whether the target function item is a structure or an array of structures. If yes, execute S312; otherwise, execute S313. S312. Treat each field in the target function item as a new first function item; S313. Generate the corresponding first function item's function item identifier TID in the first object model, and convert the information of the first function item in the second object model into the information in the first object model according to the preset conversion rules. The information includes type and name. Return to step S307. S314. Generate a first object model in JSON storage format based on the Model Id, Product Id, Grouping Id, and information of each first functional item in the first object model.

[0059] This application also provides a TLV generation interface for viewing and filtering the TID-function item mapping tables of all converted models. It supports exporting the mapping relationship of a specified model to an Excel file ({ProductId}.xls), with the first line of the file being the ModelId, which facilitates verification during the development and debugging phases. It also supports the management of the model database, such as deleting old model records.

[0060] Based on the above embodiments, as an optional embodiment, receiving and storing the first object model of the model in TLV format sent from the cloud includes: Receive a first file sent by the cloud, wherein the first file is a first object model processed by the cloud in binary encoding format or compression algorithm; The first file is reverse-processed according to the decoding format corresponding to the binary encoding format or the decompression algorithm corresponding to the compression algorithm to obtain the first object model.

[0061] It should be noted that the original JSON storage format's first object model contains a large number of curly braces, quotation marks, and redundant characters, and its size is still relatively large. After processing through binary encoding (such as Protobuf, CBOR) or compression algorithms (such as gzip, zlib), the data size can be significantly reduced. In smart homes or industrial IoT, the network conditions between the gateway and the cloud may be unstable or have limited bandwidth. Smaller data packets mean faster transmission speeds and lower transmission failure rates.

[0062] Based on the above embodiments, as an optional embodiment, receiving and storing the first object model of the model in TLV format sent from the cloud includes: Receive the first object model, which includes a checksum and signature to be verified; The checksum and signature are verified. If the verification passes, the first object model is stored.

[0063] It should be noted that in a wireless network environment, data packets may experience bit flipping or loss due to interference. Checksum mechanisms (such as CRC) can quickly detect whether the model file has been damaged during transmission. If verification fails (checksum mismatch), the gateway will refuse to store or load the model. This effectively prevents serious failures such as gateway control logic collapse and device communication paralysis caused by loading incomplete or erroneous TLV files.

[0064] Verify the digital signature of the first object model to ensure that the received object model does indeed come from a legitimate cloud server, rather than a malicious node disguised as a third-party attacker, and to ensure that every model executed by the gateway is authenticated by the cloud private key signature.

[0065] This application provides a device for updating a physical model, such as... Figure 5 As shown, the object model update device may include: a model determination module 201, a request sending module 202, and a communication module 203, wherein, Model determination module 201 is used to determine the model of the Internet of Things (IoT) device in response to the access operation of the IoT device; The request sending module 202 is used to send a request to the cloud to obtain the object model if it is determined that the object model of the specified model is not stored. Communication module 203 is used to receive and store the first physical model of the model sent by the cloud, and to communicate with the Internet of Things device based on the first physical model; The first object model is generated by the cloud based on the second object model of the specified model. The first object model is in TLV encoding format, including information of each first functional item, which is used for the gateway to communicate with IoT devices; The second object model adopts the TSL description format, including information on each of the first and second functional items. The second functional item is used for communication between the cloud and IoT devices.

[0066] The apparatus in this application embodiment can execute the method provided in this application embodiment, and the implementation principle is similar. The actions performed by each module in the apparatus of each embodiment of this application correspond to the steps in the method of each embodiment of this application. For detailed functional descriptions of each module of the apparatus, please refer to the descriptions in the corresponding methods shown above, which will not be repeated here.

[0067] This application provides an electronic device including a memory, a processor, and a computer program stored in the memory. The processor executes the computer program to implement the steps of the object model update method. Compared with related technologies, this method achieves the following: The gateway responds to the access operation of an IoT device, determines the model of the IoT device, and does not need to load all potentially supported object models at startup. Object model queries are only triggered when the IoT device is actually connected, significantly shortening the gateway's startup time and initial memory usage. Furthermore, the gateway does not need to perform firmware upgrades or model library updates to support new devices. As long as object models are stored in the cloud, the gateway can dynamically support them, greatly enhancing the system's backward compatibility and scalability. The gateway in this application only needs to store object models in TLV encoding format. Compared to object models in TSL description format, this object model omits cloud-specific or gateway-irrelevant functional items, avoiding invalid data transmission and gateway storage pollution.

[0068] In one alternative embodiment, an electronic device is provided, such as Figure 6 As shown, Figure 6 The illustrated electronic device 4000 includes a processor 4001 and a memory 4003. The processor 4001 and the memory 4003 are connected, for example, via a bus 4002. Optionally, the electronic device 4000 may further include a transceiver 4004, which can be used for data interaction between the electronic device and other electronic devices, such as sending and / or receiving data. It should be noted that in practical applications, the transceiver 4004 is not limited to one type, and the structure of the electronic device 4000 does not constitute a limitation on the embodiments of this application.

[0069] Processor 4001 may be a CPU (Central Processing Unit), a general-purpose processor, a DSP (Digital Signal Processor), an ASIC (Application Specific Integrated Circuit), an FPGA (Field Programmable Gate Array), or other programmable logic devices, transistor logic devices, hardware components, or any combination thereof. It may implement or execute the various exemplary logic blocks, modules, and circuits described in conjunction with the disclosure of this application. Processor 4001 may also be a combination that implements computational functions, such as including one or more microprocessor combinations, a combination of a DSP and a microprocessor, etc.

[0070] Bus 4002 may include a pathway for transmitting information between the aforementioned components. Bus 4002 may be a PCI (Peripheral Component Interconnect) bus or an EISA (Extended Industry Standard Architecture) bus, etc. Bus 4002 can be divided into address bus, data bus, control bus, etc. For ease of representation, bus 4002 is represented by only one thick line in the figure, but this does not indicate that there is only one bus or one type of bus.

[0071] The memory 4003 may be ROM (Read Only Memory) or other types of static storage devices capable of storing static information and instructions, RAM (Random Access Memory) or other types of dynamic storage devices capable of storing information and instructions, or EEPROM (Electrically Erasable Programmable Read Only Memory), CD-ROM (Compact Disc Read Only Memory) or other optical disc storage, optical disc storage (including compressed optical discs, laser discs, optical discs, digital universal optical discs, Blu-ray discs, etc.), magnetic disk storage media, other magnetic storage devices, or any other medium capable of carrying or storing computer programs and capable of being read by a computer, without limitation herein.

[0072] The memory 4003 stores computer programs that execute embodiments of this application, and its execution is controlled by the processor 4001. The processor 4001 executes the computer programs stored in the memory 4003 to implement the steps shown in the foregoing method embodiments.

[0073] This application provides a computer-readable storage medium storing a computer program. When the computer program is executed by a processor, it can implement the steps and corresponding content of the aforementioned method embodiments.

[0074] This application also provides a computer program product, including a computer program that, when executed by a processor, can implement the steps and corresponding content of the aforementioned method embodiments.

[0075] The terms "first," "second," "third," "fourth," "1," "2," etc. (if present) in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in a sequence other than that shown in the illustrations or text descriptions.

[0076] It should be understood that although arrows indicate various operation steps in the flowcharts of this application's embodiments, the order in which these steps are implemented is not limited to the order indicated by the arrows. Unless explicitly stated herein, in some implementation scenarios of this application's embodiments, the implementation steps in each flowchart can be executed in other orders as required. Furthermore, some or all steps in each flowchart, based on the actual implementation scenario, may include multiple sub-steps or multiple stages. Some or all of these sub-steps or stages can be executed at the same time, and each sub-step or stage can also be executed at different times. In scenarios where execution times differ, the execution order of these sub-steps or stages can be flexibly configured according to requirements, and this application's embodiments do not limit this.

[0077] The above description is only an optional implementation method for some implementation scenarios of this application. It should be noted that for those skilled in the art, other similar implementation methods based on the technical concept of this application without departing from the technical concept of this application also fall within the protection scope of the embodiments of this application.

Claims

1. A method for updating an object model, characterized in that, Applied to a gateway, the method includes: In response to an access operation by an IoT device, the model of the IoT device is determined; If it is determined that the object model of the specified model is not stored, a request to retrieve the object model is sent to the cloud. Receive and store the first physical model of the specified model sent by the cloud, and communicate with the Internet of Things device based on the first physical model; The first object model is generated by the cloud based on the second object model of the specified model. The first object model is in Type Length Value (TLV) encoding format, which includes information about each first functional item. The first functional item is used for communication between the gateway and the Internet of Things (IoT) device. The second object model adopts the Device Specification Language (TSL) description format, which includes information on each of the first and second functional items. The second functional item is used for communication between the cloud and IoT devices.

2. The method according to claim 1, characterized in that, Also includes: Receive the update notification of the first physical model of the specified model sent from the cloud; Update the local first object model according to the update notification.

3. The method according to claim 2, characterized in that, The update notification includes the model identifier of the model and the version number of the updated first object model; The step of updating the local first object model according to the update notification includes: The version number in the update notification is compared with the version number of the first object model stored locally; If the version numbers are inconsistent, the updated first object model or first function item will be downloaded from the cloud.

4. The method according to claim 1, characterized in that, The first object model is generated by the cloud in the following way: Determine at least one first functional item from the functional items of the second object model; A conversion operation is performed on each first function item, the conversion operation including: If the first function item is determined to be a structure or an array of structures, then each field in the first function item is treated as a new first function item. If it is determined that the first functional item is not a structure or a structure array, a functional item identifier (TID) for the corresponding first functional item in the first object model is generated, and the information of the first functional item in the second object model is converted into the information in the first object model according to the preset conversion rules. The information includes type and name.

5. The method according to claim 4, characterized in that, The conversion operation for each first function item includes: Based on the functional elements of each first functional item, each first functional item is classified to obtain a set of functional items corresponding to each functional element. The types of functional elements include attributes, events, and actions. For each set of functional items, determine common functional items from the set of functional items; According to the preset processing order of each function item set, the first function item in each function item set is converted sequentially. For each function item set, the common function item in the function item set is converted first.

6. The method according to claim 4, characterized in that, The step of determining at least one first functional item from the functional items of the second object model further includes: Verify the validity of the Product Id model number in the second physical model; Extract the configuration information from the second object model, and generate the group identifier Gid Type of the model in the gateway based on the configuration information; Assign a globally unique model identifier (Model Id) to the second object model; The step of converting the information of the first functional item in the second object model into information in the first object model further includes: Based on the Model Id, Product Id, Grouping Id, and information of each first functional item in the first object model, a first object model in JSON storage format is generated.

7. The method according to claim 1, characterized in that, The first object model that receives and stores the class length value in TLV format of the model sent from the cloud includes: Receive a first file sent by the cloud, wherein the first file is a first object model processed by the cloud in binary encoding format or compression algorithm; The first file is reverse-processed according to the decoding format corresponding to the binary encoding format or the decompression algorithm corresponding to the compression algorithm to obtain the first object model.

8. The method according to claim 1, characterized in that, The first object model that receives and stores the class length value in TLV format of the model sent from the cloud includes: Receive the first object model, which includes a checksum and signature to be verified; The checksum and signature are verified. If the verification passes, the first object model is stored.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory, characterized in that, The processor executes the computer program to implement the object model update method according to any one of claims 1-8.

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

Images