Object model dynamic configuration method and device of Internet of Things equipment, and electronic equipment

Abstract

The invention relates to a physical model dynamic configuration method and device of Internet of Things equipment and electronic equipment. The method comprises the following steps: constructing a metadata table of a physical model, and reserving a low-code script field in the metadata table; selecting a target model structure from preset model structures according to business requirements of the Internet of Things equipment, the model structures including a hierarchical unified structure, a type inheritance structure and a specific type independent structure; generating low-code logic according to business requirements, and writing the low-code logic into a corresponding low-code script field in the metadata table according to an attribute of the target model structure, a service or an event organization mode; and in the running process of the Internet of Things equipment, determining attributes, services or events to be called according to the object model, loading corresponding low-code scripts, and executing corresponding script logic in the sandbox environment to complete reading, writing or linkage operation. According to the method, the technical problems of static stiffness and lack of logic and version management of the physical model are solved.

Description

Technical Field

[0001] This application relates to the field of Internet of Things (IoT) technology, and in particular to a method, apparatus, storage medium, and electronic device for dynamic configuration of object models of IoT devices. Background Technology

[0002] As the scale of IoT devices continues to expand, the industry commonly adopts Thing Models to describe device attributes, services, and events, thereby achieving a standardized expression of device capabilities. Currently, most mainstream IoT platforms define device models in JSON or XML format, which are static descriptive structures. However, existing static Thing Models have revealed several technical bottlenecks in practical applications.

[0003] First, the existing object model is highly coupled with the platform code. When adding new device types, extending attributes, or adjusting business logic, developers must modify and release the code. Business personnel cannot independently complete device adaptation, resulting in high configuration costs and insufficient flexibility. Second, the traditional object model only serves as a "data structure definition" function and lacks runtime logic capabilities. It cannot execute custom logic during attribute reading and writing, service calls, or event triggering, such as protocol parsing, data verification, exception handling, or cross-device linkage control, thus failing to meet the increasingly diverse business needs of devices.

[0004] Furthermore, IoT device models evolve frequently, but existing platforms lack a robust model version management mechanism, making it difficult to simultaneously support older devices continuing to run old logic and new devices using new models, leading to version confusion risks. Finally, different business scenarios often require different modeling paradigms (such as single logical models, inherited models, and independent models), but existing platforms lack unified abstraction and automated configuration capabilities, resulting in complex system architectures and high maintenance costs. Summary of the Invention

[0005] This application provides a method, apparatus, and electronic device for dynamic configuration of object models for Internet of Things (IoT) devices, in order to solve the technical problems of static and rigid object models, lack of logic and version management.

[0006] Firstly, this application provides a method for dynamically configuring the object model of an IoT device, comprising: constructing a metadata table for the object model and reserving low-code script fields in the metadata table, wherein the metadata table includes a master table, an attribute table, a service table, and an event table; selecting a target model structure from a preset model structure according to the business requirements of the IoT device, wherein the model structure includes a hierarchical unified structure, a type inheritance structure, and a specific type independent structure; generating low-code logic according to the business requirements and writing the low-code logic into the corresponding low-code script fields in the metadata table according to the organization method of the attributes, services, or events of the target model structure; during the operation of the IoT device, determining the attributes, services, or events to be invoked according to the object model, loading the corresponding low-code scripts, and executing the corresponding script logic in a sandbox environment to complete read, write, or linkage operations.

[0007] Secondly, this application provides a device for dynamically configuring an object model of an IoT device, comprising: a construction module for constructing a metadata table of the object model and reserving low-code script fields in the metadata table, wherein the metadata table includes a master table, an attribute table, a service table, and an event table; a selection module for selecting a target model structure from a preset model structure according to the business requirements of the IoT device, wherein the model structure includes a hierarchical unified structure, a type inheritance structure, and a specific type independent structure; a writing module for generating low-code logic according to the business requirements and writing the low-code logic into the corresponding low-code script fields in the metadata table according to the organization of attributes, services, or events of the target model structure; and an execution module for determining the attributes, services, or events to be invoked according to the object model during the operation of the IoT device, loading the corresponding low-code scripts, and executing the corresponding script logic in a sandbox environment to complete read, write, or linkage operations.

[0008] As an optional example, when the target model structure is a hierarchical unified structure, the writing module includes: a first processing unit, used to treat the implementation of the hierarchical unified structure in the metadata table as a single logical model, and to define the attributes, services and events of all IoT device types in the single logical model; a determination unit, used to determine the low-code logic corresponding to each attribute, service or event according to the business requirements; and a first writing unit, used to write the low-code logic into the reserved script fields of each attribute, service or event.

[0009] As an optional example, when the target model structure is a type inheritance structure, the writing module includes: a second processing unit, used to define object models for the parent device model and the child device model respectively, wherein the child device model references the attributes, services and events of the parent device model through inheritance; and a second writing unit, used to generate low-code logic according to the business requirements and write the differentiated logic into the low-code script field of the child device model.

[0010] As an optional example, when the target model structure is a specific type-independent structure, the writing module includes: a third processing unit, used to establish an independent object model and corresponding metadata table for each specific device type, wherein each object model contains base class attributes and attributes, services and events specific to that device type; and a third writing unit, used to generate low-code logic according to business requirements and write it into the low-code script fields of the attributes, services or events of the corresponding device type object model.

[0011] As an optional example, the execution module includes: a query unit, used to query the device instance table based on the identifier of the device instance carried in the device operation request when a device operation request is received, so as to determine the model identifier corresponding to the device instance; an acquisition unit, used to acquire the corresponding object model and its associated attributes, services or events based on the model identifier; an inspection unit, used to inspect the metadata fields of the attributes, services or events; and an execution unit, used to inject context information into the sandbox environment when a non-empty low-code script is detected, call the low-code engine to execute the low-code script to complete the corresponding read, write or linkage operation, and return the execution result or exception information.

[0012] As an optional example, the above apparatus further includes: a generation module, used to generate a new version identifier for the object model and record it in the metadata table when the attributes, services, events or their corresponding low-code scripts of the object model are modified; a first processing module, used to continue to call the low-code scripts of the corresponding version of the attributes, services or events for online device instances according to the model identifier and version information they are bound to; and a second processing module, used to automatically associate the new version of the object model with newly added device instances when binding the device instance.

[0013] As an optional example, the above apparatus further includes: a saving module, used to save the metadata and low-code script of the new version of the object model to a snapshot record when a new version of the object model is generated; a comparison module, used to compare the differences between the attributes, services, events and their low-code scripts of different versions of the object model when a version management operation request is received; and a rollback module, used to roll back the attributes, services, events and their low-code scripts of the object model to the corresponding version according to the above snapshot record if it is determined that an old version of the object model needs to be restored.

[0014] Thirdly, this application provides a storage medium storing a computer program, wherein the computer program is executed by a processor to perform the above-described method for dynamic configuration of the object model of an Internet of Things device.

[0015] Fourthly, this application also provides an electronic device, including a memory and a processor, wherein the memory stores a computer program, and the processor is configured to execute the above-described method for dynamic configuration of the object model of an Internet of Things device through the computer program.

[0016] The technical solutions provided in this application have the following advantages compared with the prior art: This application employs a metadata table for a construct model, and reserves low-code script fields in the aforementioned metadata table. The metadata table includes a main table, an attribute table, a service table, and an event table. Based on the business requirements of the IoT device, a target model structure is selected from preset model structures. These model structures include a hierarchical unified structure, a type inheritance structure, and a specific type independent structure. Low-code logic is generated according to the aforementioned business requirements, and written into the corresponding low-code script fields in the aforementioned metadata table according to the organization of attributes, services, or events of the target model structure. During the operation of the IoT device, based on the aforementioned construct model... The method identifies the attributes, services, or events to be invoked, loads the corresponding low-code scripts, and executes the script logic in a sandbox environment to complete read, write, or linkage operations. This method involves constructing a metadata table containing a main table, attribute table, service table, and event table, reserving low-code script fields within it. Combined with a model selection mechanism that uses a unified hierarchical structure, type inheritance structure, or specific type independent structure, the low-code logic generated according to business requirements is written into the corresponding fields. During device operation, the platform loads and executes the low-code scripts in the sandbox environment based on the device's object model, enabling attribute reading, writing, and service or event linkage operations. This transforms the object model from a static description into a dynamically programmable entity, supporting the coexistence of different device versions, rapid adjustment of business logic, and unified management of multiple device types. This improves the platform's adaptability, maintainability, and operational efficiency, thereby solving the technical problems of static and rigid object models lacking logic and version management. Attached Figure Description

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

[0018] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0019] One or more embodiments are illustrated by way of example with reference numerals in the accompanying drawings. These illustrations do not constitute a limitation on the embodiments. Elements with the same reference numerals in the drawings are denoted as similar elements. Unless otherwise stated, the figures in the drawings are not to be limited by scale.

[0020] Figure 1 This is a flowchart of an optional method for dynamically configuring the object model of an Internet of Things (IoT) device according to an embodiment of this application; Figure 2 This is a flowchart illustrating the operation of an optional method for dynamically configuring the object model of an IoT device according to an embodiment of this application. Figure 3 This is a schematic diagram of the structure of an optional object model dynamic configuration device for an Internet of Things device according to an embodiment of this application; Figure 4 This is a schematic diagram of an optional electronic device according to an embodiment of this application. Detailed Implementation

[0021] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0022] The following disclosure provides numerous different embodiments or examples for implementing various structures of this application. To simplify the disclosure, specific examples of components and arrangements are described below. These are merely examples and are not intended to limit the scope of this application. Furthermore, reference numerals and / or letters may be repeated in different examples. Such repetition is for simplification and clarity and does not in itself indicate a relationship between the various embodiments and / or arrangements discussed.

[0023] According to a first aspect of the embodiments of this application, a method for dynamically configuring object models of Internet of Things (IoT) devices is provided, optionally, as follows: Figure 1 As shown, the above method includes: S102, the metadata table of the building model, and the low-code script field is reserved in the metadata table. The metadata table includes the main table, attribute table, service table and event table. S104. Based on the business requirements of IoT devices, select the target model structure from the preset model structures. The model structures include hierarchical unified structure, type inheritance structure, and specific type independent structure. S106. Generate low-code logic based on business requirements, and write the low-code logic into the corresponding low-code script field in the metadata table according to the organization of attributes, services or events of the target model structure. S108 determines the attributes, services, or events to be invoked based on the object model during the operation of the IoT device, loads the corresponding low-code script, and executes the corresponding script logic in the sandbox environment to complete the read, write, or linkage operation.

[0024] Optionally, this embodiment provides a method for dynamically configuring the object model of an IoT device. This method first constructs a metadata table for the object model and reserves a low-code script field in the metadata table to store executable logic related to device attributes, services, or events. The metadata table includes a master table, an attribute table, a service table, and an event table, enabling unified management of various device capability information and their corresponding low-code logic, achieving structured storage and flexible expansion.

[0025] Subsequently, based on the business needs of IoT devices, a target model structure is selected from a variety of preset model structures. These structures include hierarchical unified structures, type inheritance structures, and specific type independent structures to meet the management needs of different device types and business scenarios. By selecting different model structures, the platform can flexibly adapt to situations such as differences in device attributes, device iteration upgrades, and the coexistence of multiple versions.

[0026] Next, low-code logic is generated based on business requirements, and written into the corresponding low-code script field in the metadata table according to the organization of attributes, services, or events of the selected target model structure. In this way, the object model is no longer just a static description, but a dynamically programmable entity, supporting customized processing of device behavior at runtime, including logical operations such as attribute reading, attribute writing, service calls, or event triggering.

[0027] During the operation of IoT devices, the platform determines the attributes, services, or events to be invoked based on the object model to which the device instance belongs, and loads the corresponding low-code script. When executing this script logic in the sandbox environment, context information such as device identifier, current value, and user input parameters can be injected, and the platform's pre-built interfaces can be called to complete the business logic processing. Finally, the execution result or exception information is returned, realizing dynamic interaction of devices and execution of business rules.

[0028] This embodiment enables dynamic configuration of the object model and deep integration of low-code logic, significantly improving the adaptability and maintainability of the IoT platform for devices. Its benefits include: business personnel can quickly define and adjust device behavior without modifying the underlying code; old device logic remains unchanged during device version iterations, while new devices automatically adapt to new logic; it also supports multiple model structures and uniformly manages device attributes, services, and events, improving system flexibility, scalability, and overall operational efficiency.

[0029] As an optional example, when the target model structure is a hierarchical unified structure, low-code logic is generated according to business requirements, and written into the corresponding low-code script fields in the metadata table according to the organization of attributes, services, or events in the target model structure. These fields include: The hierarchical unified structure is implemented in the metadata table as a single logical model, and the attributes, services and events of all IoT device types are defined in the single logical model. Determine the low-code logic corresponding to each attribute, service, or event based on business requirements; Write low-code logic into reserved script fields for each property, service, or event.

[0030] Optionally, in this embodiment, when the target model structure is a hierarchical unified structure, this embodiment achieves the hierarchical unified structure by constructing a single logical model in the metadata table. In this single logical model, attributes, services, and events for all IoT device types are defined, enabling centralized management of capability information for different types of devices within a unified model. Subsequently, the low-code logic required for each attribute, service, or event is determined according to specific business needs, and the generated low-code logic is written into the reserved script fields of each attribute, service, or event in the metadata table. By loading these low-code scripts at runtime, the platform can execute the corresponding logic in a sandbox environment, realizing dynamic processing of device attribute reading, attribute writing, and service calls or event triggering.

[0031] Through the method of this embodiment, the single logical model under the hierarchical unified structure not only realizes the unified management and centralized configuration of multiple types of devices, but also transforms the object model from a static description into a dynamic programmable entity, thereby supporting business personnel to quickly define or adjust device logic, improving the system's flexibility, maintainability and operation and maintenance efficiency, while reducing the dependence on developer intervention.

[0032] As an optional example, when the target model structure is a type inheritance structure, low-code logic is generated according to business requirements, and written into the corresponding low-code script fields in the metadata table according to the organization of attributes, services, or events of the target model structure. Define object models for the parent device model and the child device model respectively. The child device model references the attributes, services and events of the parent device model through inheritance. Generate low-code logic based on business requirements and write the differentiated logic into the low-code script field of the subclass device model.

[0033] Optionally, in this embodiment, when the target model structure is a type inheritance structure, this embodiment first defines object models for the parent device model and the child device model respectively, and records their attributes, services, and events in the metadata table. The child device model references the attributes, services, and events of the parent device model through inheritance, achieving reuse and unified management of common capabilities. Subsequently, low-code logic is generated according to specific business requirements. For differentiated behaviors of the child device model, the corresponding low-code logic is written into the low-code script field of the child model, so that at runtime, only the logic unique to the child class is processed custom-definedly, while the attributes, services, and events inherited from the parent class maintain unified logic.

[0034] Through the method of this embodiment, the object model under the type inheritance structure can effectively support device iteration upgrades and functional expansion. Subclass devices can inherit the common logic of the parent class, and can also independently define differentiated behaviors, realizing the combination of logic reuse and differentiated management, thereby improving the maintainability, scalability and business configuration flexibility of the IoT platform, while reducing the repetitive workload of developers.

[0035] As an optional example, when the target model structure is a type-independent structure, low-code logic is generated according to business requirements, and written into the corresponding low-code script fields in the metadata table according to the organization of attributes, services, or events of the target model structure. Establish an independent object model and corresponding metadata table for each specific device type. Each object model contains base class attributes as well as attributes, services and events specific to that device type. Generate low-code logic based on business requirements and write it into the low-code script fields of the corresponding device type object model's attributes, services, or events.

[0036] Optionally, in this embodiment, when the target model structure is a type-independent structure, an independent object model and its corresponding metadata table are established for each specific device type. Each object model includes base class attributes, as well as attributes, services, and events specific to that device type, enabling independent capability definition and management for each device type. Subsequently, low-code logic is generated according to specific business requirements, and this generated low-code logic is written into the low-code script fields of each attribute, service, or event in the corresponding device type object model, so that custom operations can be performed for that device type at runtime. By loading and executing these low-code scripts in a sandbox environment, the platform can achieve dynamic processing of device attribute reading, attribute writing, service invocation, or event triggering.

[0037] Through the method of this embodiment, the object model under the specific type independent structure realizes logical isolation and independent management between device types. Each device type can independently evolve and extend low-code logic, while supporting high-concurrency operation and dynamic configuration, improving the maintainability, scalability and business flexibility of the IoT platform, and reducing development and operation and maintenance costs.

[0038] As an optional example, during the operation of an IoT device, the attribute, service, or event to be invoked is determined based on the object model, and the corresponding low-code script is loaded. The corresponding script logic is then executed in a sandbox environment to complete read, write, or linkage operations, including: Upon receiving a device operation request, the device instance table is queried based on the device instance identifier carried in the device operation request to determine the model identifier corresponding to the device instance; Retrieve the corresponding object model and its associated attributes, services, or events based on the model identifier; Inspect metadata fields for attributes, services, or events; When a non-empty low-code script is detected, context information is injected into the sandbox environment, the low-code engine is invoked to execute the low-code script to complete the corresponding read, write or linkage operation, and the execution result or exception information is returned.

[0039] Optionally, in this embodiment, as Figure 2The flowchart shown illustrates that during the operation of an IoT device, this embodiment determines the attribute, service, or event to be invoked based on the device's object model and loads the corresponding low-code script. The script logic is then executed in the sandbox environment to complete the read, write, or linkage operation. When the platform receives a device operation request, it first queries the device instance table based on the device instance identifier carried in the request to determine the model identifier corresponding to that device instance. Then, it obtains the corresponding object model and its associated attribute, service, or event definitions based on the determined model identifier. Next, it checks the metadata fields of the attribute, service, or event. If no non-empty low-code script is detected, default logic is executed. If a non-empty low-code script is detected, context information such as the device identifier, current value, and user input is injected into the sandbox environment, and the low-code engine is invoked to execute the corresponding script to complete the read, write, or linkage operation. Finally, the execution result or exception information is returned.

[0040] Through the method of this embodiment, IoT devices can dynamically execute low-code logic during operation, realize custom processing of attribute operations, service calls and event triggering, thereby enhancing the dynamic programmability of the object model, supporting flexible adjustment of business logic, improving the platform's adaptability, maintainability and operation and maintenance efficiency, and reducing dependence on developers.

[0041] As an optional example, the above method also includes: When the properties, services, events, or their corresponding low-code scripts of the object model are modified, a new version identifier is generated for the object model and recorded in the metadata table; For device instances that are already online, continue to call the low-code scripts of the corresponding version of attributes, services or events based on their bound model identifier and version information; For newly added device instances, the new version of the object model will be automatically associated when binding the device instance.

[0042] Optionally, in this embodiment, when the attributes, services, events, or their corresponding low-code scripts of a thing model are modified, a new version identifier is generated for the thing model, and this version information is recorded in the metadata table to form a complete version record. Based on this, for already online device instances, the platform continues to call the low-code scripts of the corresponding versions of attributes, services, or events according to the model identifier and version information bound to the device instance, thereby ensuring that the logic of already running devices is not affected by the new version changes. Simultaneously, for newly added device instances, the latest version of the thing model is automatically associated when binding the device instance, enabling new devices to directly use the updated logic and functions.

[0043] Through the method of this embodiment, the version management mechanism of the object model can realize the secure iteration and version isolation of device logic, support the continuous and stable operation of old devices, enable new devices to automatically use the latest functions, and provide a complete version record and management method, thereby improving the maintainability, flexibility and business continuity of the IoT platform, while reducing operation and maintenance and development costs.

[0044] As an optional example, the above method also includes: When a new version of the object model is generated, the metadata of the new version of the object model and its low-code script are saved to the snapshot record; Upon receiving a version management operation request, the differences in attributes, services, events, and their low-code scripts between different versions of the object model are compared. If it is determined that an older version of the object model needs to be restored, the object model's properties, services, events, and low-code scripts are rolled back to the corresponding version based on the snapshot records.

[0045] Optionally, in this embodiment, when a new version of the object model is generated, the metadata of the new version of the object model and its low-code script are saved as a snapshot record to form a recoverable version archive. Upon receiving a version management operation request, the platform can compare the differences in attributes, services, events, and their low-code scripts between different versions of the object model to identify the changes between versions. When it is determined that an old version of the object model needs to be restored, the platform rolls back the object model's attributes, services, events, and their low-code scripts to the corresponding version based on the snapshot record, thereby restoring the previous operating logic and business behavior.

[0046] Through the method in this embodiment, the snapshot, difference comparison and rollback mechanism of the object model can realize the traceability and reversibility of the object model version, ensuring that the old version of the device can still run stably during the iteration or modification of the device logic, and the new version can be used safely. At the same time, it provides flexible version management methods, improving the maintenance efficiency, business continuity and system reliability of the IoT platform.

[0047] Optionally, this application predefines low-code script fields (including lowcode_get and lowcode_set for attributes and lowcode_handler and lowcode_trigger for services or events) in the object model metadata. During the object model instance loading phase, the platform parses and registers the corresponding scripts, thereby triggering the corresponding scripts and executing the corresponding logic during device operation, thus realizing the dynamic programmability of the object model. Specifically, when creating or loading an object model, the platform determines the target model strategy from MPH (Model per Hierarchy), MPT (Model per Type), or MPC (Model per Concrete Type) based on the `thing_model.type` field in the object model's metadata (the object model's model strategy type field, used to identify the metadata organization and instantiation strategy adopted by the object model, such as MPH, MPT, or MPC. This field determines the underlying metadata storage structure, inheritance relationship, and instance loading method; it belongs to the object model's structural metadata, not executable logic). Based on this, the platform selects the corresponding metadata storage structure, attribute inheritance rules, and instantiation method. Simultaneously, the low-code script bound to the object model version is loaded into the low-code engine, which then accesses and controls the device or external system through a pre-integrated IoT protocol interface. Through this process, automatic adaptation of different model strategies and dynamic execution of runtime logic are achieved under a unified metadata abstraction framework, ensuring the consistency and scalability of object model behavior, and enabling flexible configuration and rapid iteration of device capabilities without modifying the underlying code.

[0048] This application supports business personnel in configuring device behavior independently, allowing them to define device attribute read / write, service calls, and linkage logic without developer intervention. Combined with a management mechanism that strongly binds the object model version and the low-code version, it ensures consistency in device instance behavior and system stability during operation. Furthermore, the low-code engine has pre-integrated interfaces with the IoT protocol stack (MQTT, HTTP, SSH, databases, etc.), enabling the low-code engine to directly operate physical devices and external systems. This significantly reduces platform development and maintenance costs, and enhances platform scalability, agility, and business adaptability.

[0049] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions and modules involved are not necessarily essential to this application.

[0050] According to another aspect of the embodiments of this application, a device for dynamic configuration of object models for Internet of Things (IoT) devices is also provided, such as... Figure 3 As shown, it includes: Module 302 is used to construct the metadata table of the object model and reserves low-code script fields in the metadata table. The metadata table includes a master table, an attribute table, a service table, and an event table. The selection module 304 is used to select a target model structure from the preset model structures based on the business requirements of the IoT device. The model structures include a hierarchical unified structure, a type inheritance structure, and a specific type independent structure. The writing module 306 is used to generate low-code logic according to business requirements and write the low-code logic into the corresponding low-code script field in the metadata table according to the organization of attributes, services or events of the target model structure. The execution module 308 is used to determine the attribute, service or event to be invoked based on the object model during the operation of the IoT device, load the corresponding low-code script, and execute the corresponding script logic in the sandbox environment to complete the read, write or linkage operation.

[0051] It should be noted that the construction module 302 in this embodiment can be used to execute step S102 in this application embodiment, the selection module 304 in this embodiment can be used to execute step S104 in this application embodiment, the writing module 306 in this embodiment can be used to execute step S106 in this application embodiment, and the execution module 308 in this embodiment can be used to execute step S108 in this application embodiment.

[0052] As an optional example, when the target model structure is a hierarchical unified structure, the writing module includes: The first processing unit is used to implement the hierarchical unified structure in the metadata table as a single logical model, and to define the attributes, services and events of all IoT device types in the single logical model. The determination unit is used to determine the low-code logic corresponding to each attribute, service, or event based on business requirements. The first write unit is used to write low-code logic into the reserved script fields of various properties, services, or events.

[0053] As an optional example, when the target model structure is a type inheritance structure, the writing module includes: The second processing unit is used to define object models for the parent device model and the child device model respectively, wherein the child device model references the attributes, services and events of the parent device model through inheritance. The second writing unit is used to generate low-code logic according to business requirements and write the differentiated logic into the low-code script field of the subclass device model.

[0054] As an optional example, when the target model structure is a type-independent structure, the writing module includes: The third processing unit is used to establish an independent object model and corresponding metadata table for each specific device type. Each object model contains base class attributes and attributes, services and events specific to that device type. The third writing unit is used to generate low-code logic according to business requirements and write it into the low-code script fields of the corresponding device type object model's attributes, services, or events.

[0055] As an optional example, the execution module includes: The query unit is used to query the device instance table based on the identifier of the device instance carried in the device operation request when a device operation request is received, so as to determine the model identifier corresponding to the device instance. The acquisition unit is used to obtain the corresponding object model and its associated attributes, services, or events based on the model identifier; The inspection unit is used to inspect metadata fields of attributes, services, or events; The execution unit is used to inject context information into the sandbox environment when a non-empty low-code script is detected, call the low-code engine to execute the low-code script, complete the corresponding read, write or linkage operation, and return the execution result or exception information.

[0056] As an optional example, the above-described apparatus further includes: The generation module is used to generate a new version identifier for the object model and record it in the metadata table when the object model's attributes, services, events, or their corresponding low-code scripts are modified. The first processing module is used to continue calling the low-code scripts of the corresponding version of attributes, services or events for online device instances based on their bound model identifiers and version information. The second processing module is used to automatically associate the new version of the object model when binding a newly added device instance.

[0057] As an optional example, the above-described apparatus further includes: The save module is used to save the metadata and low-code script of the new version of the object model to the snapshot record when a new version of the object model is generated; The comparison module is used to compare the differences in attributes, services, events and their low-code scripts between different versions of the object model when a version management operation request is received. The rollback module is used to roll back the properties, services, events, and low-code scripts of an object model to the corresponding version based on snapshot records when it is determined that an old version of the object model needs to be restored.

[0058] For other examples of this embodiment, please refer to the examples above, which will not be repeated here.

[0059] Figure 4 This is a schematic diagram of an optional electronic device according to an embodiment of this application, such as... Figure 4 As shown, it includes a processor 402, a communication interface 404, a memory 406, and a communication bus 408. The processor 402, communication interface 404, and memory 406 communicate with each other via the communication bus 408. Memory 406 is used to store computer programs; When processor 402 executes a computer program stored in memory 406, it performs the following steps: The metadata table of the construct model is constructed, and a low-code script field is reserved in the metadata table. The metadata table includes a master table, an attribute table, a service table, and an event table. Based on the business requirements of IoT devices, a target model structure is selected from the preset model structures. The model structures include a hierarchical unified structure, a type inheritance structure, and a specific type independent structure. Generate low-code logic based on business requirements, and write the low-code logic into the corresponding low-code script field in the metadata table according to the organization of attributes, services or events of the target model structure. During the operation of IoT devices, the attributes, services or events to be invoked are determined based on the object model, and the corresponding low-code scripts are loaded. The corresponding script logic is then executed in the sandbox environment to complete the read, write or linkage operations.

[0060] Optionally, in this embodiment, the communication bus can be a PCI (Peripheral Component Interconnect) bus or an EISA (Extended Industry Standard Architecture) bus, etc. This communication bus can be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Figure 4 The symbol is represented by a single thick line, but this does not indicate that there is only one bus or one type of bus. The communication interface is used for communication between the aforementioned electronic devices and other devices.

[0061] The memory may include RAM, or non-volatile memory, such as at least one disk storage device. Optionally, the memory may also be at least one storage device located remotely from the aforementioned processor.

[0062] As an example, the memory 406 described above may include, but is not limited to, the construction module 302, selection module 304, writing module 306, and execution module 308 of the object model dynamic configuration device of the aforementioned IoT device. Furthermore, it may include, but is not limited to, other module units in the object model dynamic configuration device of the aforementioned IoT device, which will not be elaborated upon in this example.

[0063] The processor mentioned above can be a general-purpose processor, including but not limited to: CPU (Central Processing Unit), NP (Network Processor), etc.; it can also be DSP (Digital Signal Processor), ASIC (Application Specific Integrated Circuit), FPGA (Field-Programmable Gate Array) or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components.

[0064] Optionally, specific examples in this embodiment can refer to the examples described in the above embodiments, and will not be repeated here.

[0065] Those skilled in the art will understand that Figure 4 The structure shown is for illustrative purposes only. The device implementing the above-described method for dynamic configuration of the object model of IoT devices can be a terminal device, such as a smartphone (e.g., an Android phone, an iOS phone), a tablet computer, a PDA, a mobile Internet device (MID), a PAD, or other terminal devices. Figure 4 This does not limit the structure of the aforementioned electronic devices. For example, the electronic device may also include components that are more... Figure 4 The more or fewer components shown (such as network interfaces, display devices, etc.), or having the same Figure 4 The different configurations shown.

[0066] Those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be implemented by a program instructing the hardware related to the terminal device. The program can be stored in a computer-readable storage medium, which may include: flash drive, ROM, RAM, disk or optical disk, etc.

[0067] According to another aspect of the embodiments of this application, a computer-readable storage medium is also provided, wherein a computer program is stored in the computer program, which, when executed by a processor, performs the steps in the above-described method for dynamic configuration of the object model of an Internet of Things device.

[0068] Optionally, in this embodiment, those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be implemented by a program instructing the hardware related to the terminal device. The program can be stored in a computer-readable storage medium, which may include: flash drive, read-only memory (ROM), random access memory (RAM), disk or optical disk, etc.

[0069] The sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0070] If the integrated units in the above embodiments are implemented as software functional units and sold or used as independent products, they can be stored in the aforementioned computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause one or more computer devices (which may be personal computers, servers, or network devices, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application.

[0071] In the above embodiments of this application, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0072] In the several embodiments provided in this application, it should be understood that the disclosed client can be implemented in other ways. The device embodiments described above are merely illustrative; for example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces, indirect coupling or communication connection between units or modules, and may be electrical or other forms.

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

[0074] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0075] The above description is only a preferred embodiment of this application. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. A method for dynamically configuring object models of Internet of Things (IoT) devices, characterized in that, include: The metadata table of the construct model is constructed, and a low-code script field is reserved in the metadata table. The metadata table includes a master table, an attribute table, a service table, and an event table. Based on the business requirements of IoT devices, a target model structure is selected from the preset model structures, wherein the model structure includes a hierarchical unified structure, a type inheritance structure, and a specific type independent structure; Based on the business requirements, generate low-code logic, and write the low-code logic into the corresponding low-code script field in the metadata table according to the attributes, service or event organization method of the target model structure; During the operation of the IoT device, the attributes, services or events to be invoked are determined according to the object model, and the corresponding low-code scripts are loaded. The corresponding script logic is executed in the sandbox environment to complete the read, write or linkage operation.

2. The method for dynamic configuration of object models for IoT devices according to claim 1, characterized in that, When the target model structure is a hierarchical unified structure, the step of generating low-code logic according to the business requirements and writing the low-code logic into the corresponding low-code script field in the metadata table according to the organization of attributes, services, or events of the target model structure includes: The implementation of the hierarchical unified structure in the metadata table is used as a single logical model, in which the attributes, services and events of all IoT device types are defined; Determine the low-code logic corresponding to each attribute, service, or event based on the aforementioned business requirements; Write the low-code logic into the reserved script fields of each attribute, service, or event.

3. The method for dynamic configuration of object models for IoT devices according to claim 1, characterized in that, When the target model structure is a type inheritance structure, the step of generating low-code logic according to the business requirements and writing the low-code logic into the corresponding low-code script field in the metadata table according to the organization method of the attributes, services, or events of the target model structure includes: Define object models for the parent device model and the child device model respectively, wherein the child device model references the attributes, services and events of the parent device model through inheritance; Low-code logic is generated based on the business requirements, and the differentiated logic is written into the low-code script field of the subclass device model.

4. The method for dynamic configuration of object models for IoT devices according to claim 1, characterized in that, When the target model structure is a type-independent structure, the step of generating low-code logic based on the business requirements and writing the low-code logic into the corresponding low-code script field in the metadata table according to the organization of attributes, services, or events of the target model structure includes: Establish an independent object model and corresponding metadata table for each specific device type. Each object model contains base class attributes as well as attributes, services and events specific to that device type. Generate low-code logic based on business requirements and write it into the low-code script fields of the corresponding device type object model's attributes, services, or events.

5. The method for dynamic configuration of object models for IoT devices according to claim 1, characterized in that, The process of determining the attribute, service, or event to be invoked based on the object model during the operation of the IoT device, loading the corresponding low-code script, and executing the corresponding script logic in the sandbox environment to complete the read, write, or linkage operation includes: Upon receiving a device operation request, the device instance table is queried based on the device instance identifier carried in the device operation request to determine the model identifier corresponding to the device instance; Based on the model identifier, obtain the corresponding object model and its associated attributes, services, or events; Inspect the metadata fields of the attribute, service, or event; When a non-empty low-code script is detected, context information is injected into the sandbox environment, the low-code engine is invoked to execute the low-code script to complete the corresponding read, write or linkage operation, and the execution result or exception information is returned.

6. The method for dynamic configuration of object models for IoT devices according to claim 1, characterized in that, The method further includes: When the attributes, services, events, or their corresponding low-code scripts of the object model are modified, a new version identifier is generated for the object model and recorded in the metadata table; For device instances that are already online, continue to call the low-code scripts of the corresponding version of attributes, services or events based on their bound model identifier and version information; For newly added device instances, the new version of the object model will be automatically associated when binding the device instance.

7. The method for dynamic configuration of object models for IoT devices according to claim 1, characterized in that, The method further includes: When a new version of the object model is generated, the metadata of the new version of the object model and its low-code script are saved to the snapshot record; Upon receiving a version management operation request, the differences in attributes, services, events, and their low-code scripts between different versions of the object model are compared. If it is determined that an older version of the object model needs to be restored, the object model's attributes, services, events, and low-code scripts are rolled back to the corresponding version based on the snapshot records.

8. A device for dynamic configuration of object models for Internet of Things (IoT) devices, characterized in that, include: A construction module is used to construct the metadata table of the object model, and a low-code script field is reserved in the metadata table. The metadata table includes a master table, an attribute table, a service table, and an event table. The selection module is used to select a target model structure from preset model structures based on the business needs of IoT devices. The model structures include a hierarchical unified structure, a type inheritance structure, and a specific type independent structure. The writing module is used to generate low-code logic according to the business requirements, and write the low-code logic into the corresponding low-code script field in the metadata table according to the organization method of the attributes, services or events of the target model structure. The execution module is used to determine the attribute, service or event to be invoked according to the object model during the operation of the IoT device, load the corresponding low-code script, and execute the corresponding script logic in the sandbox environment to complete the read, write or linkage operation.

9. A computer-readable storage medium storing a computer program, characterized in that, The computer program is executed by the processor to perform the method described in any one of claims 1 to 7.

10. An electronic device comprising a memory and a processor, characterized in that, The memory stores a computer program, and the processor is configured to execute the method described in any one of claims 1 to 7 through the computer program.

Images