An industrial thing model design method and system based on an industrial internet of things platform

Abstract

The application discloses an industrial thing model design method and system based on an industrial Internet of Things platform, constructs a three-level thing model architecture of product, equipment and variable, defines the public attributes of the product thing model through the product layer, including communication protocols and message formats, adds the individualized attributes of the equipment instance through the equipment layer, including equipment coding, network modes and installation positions, realizes the fine configuration of the product thing model variable level through the variable layer, including storage strategies, calculation rules and simulation configuration, and the three-level thing model architecture supports the cross-equipment reuse of the product thing model, and all variable definitions under the product thing model are automatically inherited when the equipment instance is created. The application realizes the unified digital modeling, efficient access and intelligent management of heterogeneous industrial equipment through the construction of the three-level thing model architecture, the fine storage strategy of the variable, the built-in simulation engine, the cross-variable correlation calculation driven by the expression and the real-time alarm linkage mechanism driven by the event.

Description

Technical Field

[0001] This invention relates to an industrial object model design method and system based on an industrial Internet of Things (IIoT) platform. It can be used for digital modeling of equipment, unified access of heterogeneous equipment, data governance, and industrial equipment management in an IIoT platform, and belongs to the field of industrial Internet of Things technology. Background Technology

[0002] In the field of Industrial Internet of Things (IIoT), the diverse types of devices, varying communication protocols, and inconsistent data formats have long been core pain points. A typical industrial scenario may simultaneously contain dozens of different types of devices, such as PLCs (Programmable Logic Controllers), sensors, CNC machine tools, robots, and smart meters. These devices use different communication protocols, such as Modbus, OPC-UA, MQTT, HTTP, CoAP, and SIP, and report data in vastly different formats.

[0003] Currently, mainstream industrial IoT platforms (such as AWS IoT Core, Alibaba Cloud IoT, and Huawei Cloud IoT) generally adopt the concept of a "Thing Model" to digitally abstract physical devices. A Thing Model typically abstracts device capabilities into three categories: Properties, Services, and Events. Properties describe the device's operational status data (such as temperature, humidity, and rotational speed), services describe the device's invoked capabilities (such as switch control and parameter settings), and events describe alarms or notifications proactively reported by the device (such as fault alarms and status changes). However, existing Thing Model design methods have the following shortcomings:

[0004] 1. Strong coupling between object model definition and device: Traditional object model design methods require developers to define a complete object model for each type of device. As the number of device types increases, the management and maintenance costs of the object model increase linearly. For example, in the Alibaba Cloud IoT platform, each product requires the definition of a TSL (Thing Specification Language) model for each device. When there are hundreds of device types, the reusability of the object model is extremely low.

[0005] 2. Separation of data storage and computing capabilities: Existing platforms typically store device attribute data in relational databases or general time-series databases. The calculation rules in the object model (such as derivation calculations and aggregation calculations between variables) need to be implemented separately at the application layer, which cannot be deeply coupled with the data storage engine, resulting in high real-time computing latency and complex system architecture.

[0006] 3. Lack of a multi-level, inheritable object model system: In industrial scenarios, there are natural hierarchical and inheritance relationships between devices (e.g., "general sensor" → "temperature sensor" → "a certain type of industrial temperature sensor"), but existing object model solutions do not support hierarchical inheritance and combination reuse, resulting in a large number of duplicate definitions.

[0007] 4. Disconnect between alarm rules and object model data: In existing solutions, alarm rule engines are usually independent of the object model system. They obtain data by polling the database or message queue and then make conditional judgments. This results in millisecond or even second-level delays, which cannot meet the alarm scenarios in industrial settings with extremely high real-time requirements.

[0008] The existing technology has the following drawbacks:

[0009] 1. Low efficiency of heterogeneous device access: When facing industrial equipment with different communication protocols and data formats, existing solutions require writing independent parsing scripts or adapters for each protocol. The lack of a unified access abstraction layer and hot-loading mechanism for protocol parsing scripts results in long access cycles and high development costs for new devices.

[0010] 2. Lack of variable-level fine-grained storage strategy for object models: In industrial scenarios, the data acquisition frequency, storage period, and aggregation method of different variables vary greatly (for example, high-frequency vibration data needs to be sampled at the millisecond level but is only retained for 7 days, while temperature data may be sampled every minute but needs to be retained for several years). Existing solutions usually adopt a "one-size-fits-all" storage strategy, which cannot achieve variable-level fine-grained storage configuration, resulting in waste of storage resources or loss of critical data.

[0011] 3. Lack of simulation capabilities: During the development and debugging phase of an industrial IoT platform, real physical devices are often unavailable or have high access costs. Existing solutions lack built-in device simulation capabilities and cannot simulate device data reporting through configuration, resulting in low development and testing efficiency.

[0012] 4. Weak ability to perform cross-device variable association calculations: There are many scenarios in industrial settings where cross-device variable association calculations are required (e.g., calculating "total power = power of device A + power of device B + power of device C"). Existing solutions usually require writing code at the application layer and cannot be completed at the object model level by configuring expressions. Summary of the Invention

[0013] Purpose of the invention: In order to overcome the shortcomings of the existing technology, the present invention provides an industrial object model design method and system based on an industrial Internet of Things platform. By constructing a three-level object model architecture of product-equipment-variable, a configurable variable fine storage strategy, a built-in simulation engine, expression-driven cross-variable correlation calculation, and an event-driven real-time alarm linkage mechanism, the invention achieves unified digital modeling, efficient access, and intelligent management of heterogeneous industrial equipment.

[0014] Technical solution: To achieve the above objectives, the technical solution adopted by this invention is as follows:

[0015] An industrial object model design method based on an Industrial Internet of Things (IIoT) platform constructs a three-tier object model architecture: product → device → variable. The product layer defines common attributes of the product object model, including communication protocols and message formats. The device layer inherits the variable definitions from the product layer and adds personalized attributes for device instances, including device code, network mode, and installation location. The variable layer enables fine-grained configuration of product object model variables, including data types, storage strategies, calculation rules, and simulation configurations. This three-tier object model architecture supports cross-device reuse of product object models; device instances automatically inherit all variable definitions from the product object model upon creation, significantly reducing redundant configuration.

[0016] In traditional object modeling schemes, the definition of the object model is tightly coupled with the device instance, lacking hierarchical inheritance and reuse mechanisms, which leads to a large amount of redundant definition and maintenance costs. This invention, through a three-level object model architecture, can support cross-device reuse of product object models. Through the hierarchical inheritance mechanism, when a new device of the same type is added, the device instance can automatically inherit all variable definitions under the product object model when it is created, improving creation efficiency by more than 90%. When the device variables of the product object model change, all device instances that inherit the product object model are automatically updated synchronously, realizing consistent management of the product object model.

[0017] Specifically, storage strategies are defined at the variable layer, including storage types and storage rules. The storage types support four modes: time-series storage, relational storage, cache storage, and no storage. The storage rules define the storage period, data retention duration, aggregation downsampling strategy, and hot / cold data separation strategy in JSON format. The data storage routing module automatically routes data to the corresponding storage engine based on the storage strategy of each device variable.

[0018] Traditional object modeling solutions employ a one-size-fits-all storage strategy, which fails to meet the differentiated storage needs of various equipment variables in industrial scenarios, leading to wasted storage resources or loss of critical data. The storage strategy designed in this invention enables refined management of storage resources. For equipment variables that are collected frequently but retained for short periods (such as vibration data) and those that are collected frequently but retained for long periods (such as cumulative runtime), a differentiated storage strategy is adopted, which can reduce storage costs by 40%-60% while ensuring data availability.

[0019] Specifically, in the variable layer, calculation rules are introduced to define the associated calculation logic between device variables in JSON format. It supports referencing the values ​​of other device variables within the same device or across devices and automatically parses them through variable encoding. Real-time calculation between device variables is performed through Aviator expressions. The dependency graph between device variables is automatically constructed through the variable management module, and the calculation order is determined based on topological sorting. When the source variable value changes, the cascading recalculation of dependent variables is automatically triggered through EventBus event-driven mechanisms.

[0020] In industrial scenarios, cross-device variable correlation calculations are common, but traditional object modeling solutions cannot accomplish this through configuration at the object model level. This invention moves cross-variable correlation calculations down from the application layer to the object model layer. Users only need to configure expressions to complete complex correlation calculation logic without writing code, improving configuration efficiency by over 80%. An event-driven cascading calculation mechanism ensures real-time calculation results with latency controlled within milliseconds.

[0021] Specifically, simulation configuration is introduced at the variable layer, including simulation type and simulation rules; device instances switch between real mode and simulation mode through simulation identifiers; the simulation engine supports multiple waveform types, and simulation data is automatically generated according to the numerical range constraints and data types of device variables, and published to the industrial IoT platform through EventBus. Simulation data and real data follow the same processing flow, which can ensure the consistency between the test environment and the production environment.

[0022] In traditional physical modeling solutions, during the development and debugging phases of an industrial IoT platform, real physical devices are often unavailable or have high access costs, lacking built-in simulation capabilities. This invention, through simulation configuration, eliminates the need for real physical devices during the development and testing phases. End-to-end functional verification can be completed through configuration alone, improving development efficiency by over 50%. Simulated data and real data share the same processing flow.

[0023] Specifically, the alarm linkage module subscribes to variable value change events through EventBus to achieve real-time push of device variable values ​​instead of polling; alarm conditions are defined through Aviator expressions, directly referencing the variable codes of the product object model without the need for additional data mapping configuration; when device variable values ​​are updated, real-time evaluation of relevant alarm conditions is automatically triggered; alarm conditions support multiple condition combinations, multiple alarm levels, and silent period configuration.

[0024] In traditional object model solutions, the alarm rule engine is independent of the object model system and obtains data through polling, which results in latency and increases system load. In this invention, the alarm evaluation latency can be reduced from the second level in traditional solutions to the millisecond level, which can meet the alarm requirements with extremely high real-time requirements in industrial scenarios. The event-driven push mechanism adopted in this invention avoids the system overhead caused by polling and reduces CPU utilization by more than 30% in high-concurrency scenarios.

[0025] Specifically, the method includes the following steps:

[0026] S10. Create product object models and define communication protocols and data access specifications: Create a product object model for each type of device in the industrial IoT platform, and define the common attributes of the device, including product name, product code, device type, communication protocol, message format and parsing script;

[0027] S20. Create equipment instances based on the product model and establish a mapping relationship between equipment and equipment variables in the product model: Equipment instances automatically inherit all variable definitions under the product model. The core attributes of equipment instances include equipment name, equipment code, parent device identifier, equipment status, network mode, simulation identifier, and hierarchical relationship.

[0028] S30. Constructing fine-grained configurations at the variable level: Create device variables under device instances to form a three-level object model architecture of product → variable → device; The core attributes of each device variable include variable name, variable code, variable type, data type, access mode, numerical range constraints, unit of measurement, default value, storage strategy, calculation rules and simulation configuration;

[0029] S40. Device data is reported and, after being processed by the protocol parsing script, is persisted according to the storage policy.

[0030] S50. Based on the equipment variable values ​​of the product model, the relevant alarm conditions are evaluated in real time through Aviator expressions;

[0031] S60. Generating simulated data through the simulation engine: When the device is in simulation mode, the simulation engine generates simulated data for the device. The simulated data follows the same processing flow as the real data.

[0032] Specifically, in step S40, after the device reports device data via the communication protocol, the industrial IoT platform processes the data through the following process:

[0033] S41. The MQTT client subscribes to the corresponding MQTT topic according to the device code and receives the original messages reported by the device; the MQTT topic adopts a hierarchical naming rule and supports wildcard subscription to realize batch device access;

[0034] S42. Based on the communication protocol of the product model to which the equipment belongs, the protocol is parsed using a script. The parsing script uses a Python script engine hot-loading mechanism, which supports dynamic loading and updating, and can adapt to new communication protocols without restarting the industrial IoT platform. The original message is taken as input, and the script is parsed to output a standardized list of variable data key-value pairs.

[0035] S43. Persist device variable values ​​according to storage type and storage rules; for device variables with time-series storage type, device variable values ​​are written to the TDengine time-series database. The TDengine time-series database adopts the storage rule of super table + sub-table. Each data type corresponds to a super table, and each device variable corresponds to a sub-table. The sub-table is associated with tenant ID and variable ID through TAGS to achieve efficient multi-tenant data isolation and query.

[0036] Specifically, in step S50, the alarm linkage module is deeply integrated with the data storage routing module through an event-driven architecture, including the following steps:

[0037] S51. When the device variable value is updated, the variable value change event is published through EventBus. The alarm linkage module subscribes to the variable value change event through EventBus to realize the real-time push of the device variable value instead of polling.

[0038] S52, Aviator expressions define alarm conditions;

[0039] S53. When the real-time evaluation result of the Aviator expression is true, an alarm action is triggered.

[0040] Specifically, in step S60, when the device is in simulation mode, the simulation engine generates simulation data including the following steps:

[0041] S61. Determine the simulation type and simulation rules for the equipment variables. The simulation types include random values, sine values, square waves, triangle waves, increasing / decreasing values, and constants.

[0042] S62. Using a defined simulation type and simulation rules, automatically generate simulation data according to the numerical range constraints and data types of equipment variables;

[0043] S63. Simulated data is published to the industrial IoT platform via EventBus. The simulated data follows the same processing flow as the real data, enabling full-chain functional verification to be completed without relying on real physical devices during the development and testing phase.

[0044] An industrial object model design system based on an industrial Internet of Things (IIoT) platform includes a product management module, an equipment management module, a variable management module, a protocol parsing module, a data storage and routing module, an alarm linkage module, and a simulation module.

[0045] The product management module is used to create and manage product object model templates, and define common attributes including communication protocols, message formats and script associations; the product management module maintains the parent-child hierarchy relationship between product object models and device variables, and supports version management and change tracking of product object models;

[0046] The equipment management module is used to create equipment instances based on the product model, manage the equipment lifecycle, and support the management of equipment parent-child hierarchical relationships, real-time monitoring of equipment status, and switching of equipment simulation modes.

[0047] The variable management module is used to define and manage device variables under a device instance, including the data type, access mode, storage strategy, calculation rules and simulation configuration of the device variables;

[0048] The protocol parsing module includes a Python script engine and a Python script execution environment. The Python script engine supports a hot-loading mechanism, version management, and execution strategy configuration for the parsing script. The parsing script interacts with the industrial IoT platform through standardized input / output interfaces. The input is the raw message, and the output is a standardized list of variable data key-value pairs.

[0049] The data storage routing module routes data to the corresponding storage engine based on the storage type and storage rules of the device variables.

[0050] The alarm linkage module subscribes to variable value change events through EventBus and performs real-time evaluation of alarm conditions based on Aviator expressions.

[0051] The simulation module has a built-in simulation engine in the industrial IoT platform, which supports the generation of simulation data according to the simulation type. The simulation types include random values, sine values, square waves, triangular waves, increasing / decreasing values, and constants. The simulation data follows the same processing flow as the real data and supports the injection of simulation data into the MQTT access layer, protocol parsing layer, or variable update layer.

[0052] Beneficial effects: The industrial object model design method and system based on the Industrial Internet of Things platform provided by this invention have the following advantages compared with the prior art:

[0053] 1. Unified access capability for heterogeneous devices: Through the three-level object model architecture of "product-device-variable" and the hot loading mechanism of protocol parsing script, unified digital modeling and access management of heterogeneous industrial devices using different communication protocols (MQTT, Modbus, OPC-UA, HTTP, CoAP, SIP, etc.) and data formats (JSON, binary, hexadecimal, etc.) are realized, and the access cycle of new devices is shortened from several weeks in the traditional solution to several hours.

[0054] 2. Refined Management of Storage Resources: Through variable-level refined storage strategies, the optimal storage solution is automatically selected based on the data characteristics of variables (collection frequency, retention period, query requirements), reducing storage costs by 40%-60% while ensuring data availability;

[0055] 3. Low-code association calculation configuration: Through expression-driven cross-variable association calculation, complex association calculation logic is pushed down from the application layer to the object model configuration layer. Users can complete the calculation logic configuration without writing code, improving configuration efficiency by more than 80%.

[0056] 4. Significantly improved development and testing efficiency: With the built-in simulation engine, the development and testing phases do not require real physical devices, and it supports the generation of simulated data of various waveform types, improving development efficiency by more than 50%.

[0057] 5. Millisecond-level real-time alarm response: Through an event-driven alarm-object model linkage mechanism, the alarm evaluation latency is reduced from the second level to the millisecond level, meeting the alarm scenarios with extremely high real-time requirements in industrial settings;

[0058] 6. High-throughput data access capability: Through a three-layer data pipeline architecture of MQTT+Kafka+TDengine, it supports data access and persistence capabilities of more than 100,000 points per second, meeting the performance requirements of large-scale industrial IoT scenarios. Attached Figure Description

[0059] Figure 1 This is a schematic diagram illustrating the implementation process of the method of the present invention.

[0060] Figure 2 This is a schematic diagram of the structural framework of the system of the present invention. Detailed Implementation

[0061] The present invention will now be described in detail with reference to the accompanying drawings and specific embodiments.

[0062] like Figure 1 The diagram shows the overall flowchart of the industrial object model design method based on the industrial Internet of Things platform provided by the present invention. The steps are explained in detail below.

[0063] S10. Create a product model and define the communication protocol and data access specifications.

[0064] In the Industrial Internet of Things (IIoT) platform, create a product model for each type of device, defining the common attributes of that type of device, including but not limited to:

[0065] Product name and product code: uniquely identify a specific type of equipment;

[0066] Device Type: Identifies the industrial category to which the device belongs, such as "temperature sensor", "frequency converter", "PLC controller", etc.

[0067] Telecom Protocol: The communication protocol used by the device, including but not limited to MQTT, Modbus, OPC-UA, HTTP, CoAP, SIP, etc.

[0068] PacketFormat: The format in which the device reports data, such as JSON, binary, hexadecimal, etc.

[0069] Script parser (scriptId): A unique identifier for the associated protocol parser script, used to parse the device's raw messages into the platform-standardized object model data format.

[0070] S20. Based on the product model of the missionary equipment example, establish the mapping relationship between the equipment and the equipment variables.

[0071] After completing the product object model definition, users can create specific device instances (IotDevice) based on the product object model. Device instances inherit all variable definitions defined under the product object model, forming a three-level object model architecture of "product-device-variable". Device instances contain the following core attributes:

[0072] Device name (name) and device code (deviceCode): These uniquely identify the device instance. The device code is used for MQTT topic subscription, data routing, and access control.

[0073] Parent device identifier (parentId): Supports hierarchical relationships between devices and is used to build device topology in industrial scenarios (such as gateway-child device relationships).

[0074] Device status (state): Indicates the current operating status of the device, including online, offline, fault, inactive, etc.;

[0075] Network mode (netMode): The mode in which the device accesses the network, such as WiFi, 4G / 5G, Ethernet, LoRa, etc.;

[0076] Device Type: Stores multi-dimensional type tags for devices in JSON format, supporting flexible device classification and retrieval;

[0077] SimulateFlag: Indicates whether the device is in simulation mode. When true, the device data is generated by the platform's built-in simulation engine, rather than from a real physical device.

[0078] Project Id and Tenant Id: Supports device isolation management in multi-tenant, multi-project industrial IoT scenarios.

[0079] S30. Create device variables under the device instance to build fine-grained configuration at the variable level.

[0080] Under the device instance created in step S20, device variables are further defined to form a fine-grained configuration at the variable level; each device variable contains the following core attributes:

[0081] Variable name (name) and variable code (variableCode): Uniquely identify device variables; variable code is used for MQTT topic subscription and data routing.

[0082] Variable Type: Defines the capability type of device variables, including three types: Property, Service, and Event.

[0083] Data type (dataType): The data type of the device variable value, including integer (int), floating-point (float), string (string), boolean (boolean), enumeration (enum), array (array), etc.; for complex data types, custom data structures are stored in JSON format through the dataTypeJson field, and nested structure definitions are supported;

[0084] Access Mode: Defines the read and write permissions for device variables, including three modes: Read-only, Write-only, and ReadWrite.

[0085] Numerical range constraints: minimum (min) and maximum (max), used for data validation and anomaly detection;

[0086] Unit of measurement: The physical unit of measurement for equipment variables, such as "℃", "MPa", "rpm", etc.

[0087] Default value (defaultVal): The default value of a device variable when no data is received;

[0088] Storage type (storeType): Defines the persistent storage strategy for device variables, including time-series storage (TS), relational storage (RDB), cache storage (Cache), and none.

[0089] Storage rules (storeRule): Defines fine-grained storage strategies for device variables in JSON format, including: storage period (in milliseconds), data retention duration (in days), aggregation downsampling strategies (such as average, maximum, minimum, first value, last value), hot and cold data separation strategies, etc.

[0090] Calculation rule (calcRule): Defines the associated calculation expression of device variables in JSON format, supports referencing other variable values ​​of the same device or across devices, and performs real-time calculation through the Aviator expression engine; for example, the calculation rule for the variable "total power" can be defined as `deviceA.power+deviceB.power+deviceC.power`.

[0091] S40. Device data is reported and, after being processed by the protocol parsing script, is persisted according to the storage policy.

[0092] After the device reports its data via the communication protocol, the industrial IoT platform processes the data through the following process:

[0093] S41. The MQTT client (MqttClient) subscribes to the corresponding MQTT topic according to the device code and receives the original messages reported by the device. The MQTT topic adopts a hierarchical naming rule, such as ` / iot / {productCode} / {deviceCode} / property / post`, and supports wildcard subscription to achieve batch device access.

[0094] S42. Based on the communication protocol of the product model to which the equipment belongs, the protocol is parsed using a script. The parsing script uses a Python script engine hot-loading mechanism, which supports dynamic loading and updating, and can adapt to new communication protocols without restarting the industrial IoT platform. The original message is taken as input, and the script is parsed to output a standardized list of variable data key-value pairs.

[0095] S43. Persist device variable values ​​according to storage type and storage rules. For device variables with time-series storage, the device variable values ​​are written to the TDengine time-series database. The TDengine time-series database uses a super table + sub table storage rule. Each data type corresponds to a super table (e.g., `stable_int`, `stable_float`, `stable_string`), and each device variable corresponds to a sub table (e.g., `int_{variableId}`). The sub tables are associated with tenant IDs and variable IDs through tags, achieving efficient multi-tenant data isolation and querying. For high-frequency write scenarios, it supports using Kafka message queues as a buffer layer for batch writing to TDengine, increasing system throughput to hundreds of thousands of points per second or more.

[0096] S50, based on the product object model, the equipment variable values ​​are evaluated in real time using Aviator expressions.

[0097] The alarm linkage module is deeply integrated with the data storage and routing module through an event-driven architecture, including the following steps:

[0098] S51. When the device variable value is updated, the variable value change event is published through EventBus (Guava event bus). The alarm linkage module subscribes to the variable value change event through EventBus to realize the real-time push of the device variable value instead of polling.

[0099] S52. Aviator expressions define alarm conditions, such as `temperature>80&&humidity<20`. The Aviator expression engine supports direct references to object model variables, automatically resolving the current value of variables through variable encoding, without requiring additional configuration of data mapping relationships;

[0100] S53. When the real-time evaluation result of the Aviator expression is true, an alarm action is triggered. Alarm action types include: SMS notification, WeChat push, email alarm, MQTT command issuance (reverse control of the device), HTTP callback, etc. Alarms support silent period configuration to avoid duplicate alarms.

[0101] S60 generates simulated data through a simulation engine.

[0102] When the device is in simulation mode, the simulation engine generates simulation data for the device, including the following steps:

[0103] S61. Determine the simulation type and simulation rules for the equipment variables. The simulation types include random values, sine values, square waves, triangle waves, increasing / decreasing values, and constant values.

[0104] S62. Using a defined simulation type and simulation rules, automatically generate simulation data according to the numerical range constraints and data types of equipment variables to ensure the rationality of the simulation data;

[0105] S63. Simulated data is published to the industrial IoT platform via EventBus. The simulated data follows the same processing flow (storage, alarm evaluation, etc.) as real data, so that the full-link functional verification can be completed without relying on real physical devices during the development and testing phase.

[0106] like Figure 2 The diagram shows the structural block diagram of an industrial object model design system based on an industrial Internet of Things (IIoT) platform, which includes a product management module, an equipment management module, a variable management module, a protocol parsing module, a data storage and routing module, an alarm linkage module, and a simulation module.

[0107] The product management module is used to create and manage product object model templates, and define common attributes including communication protocols, message formats, and script associations. The product management module maintains the parent-child hierarchy between product object models and device variables, and supports version management and change tracking of product object models.

[0108] The device management module is used to create device instances based on the product model, manage the device lifecycle, and supports: ① device parent-child hierarchical relationship management and construction of device topology tree; ② real-time monitoring of device status and detection of device online status through MQTT heartbeat mechanism; ③ device simulation mode switching, supporting dynamic switching of devices between real mode and simulation mode.

[0109] The variable management module is used to define and manage device variables under a device instance. Core attributes include the data type, access mode, storage strategy, calculation rules, and simulation configuration of the device variables. The variable management module supports: ① Batch import / export of device variables, enabling rapid definition of device variables via Excel templates; ② Automatic construction of dependency graphs between device variables, automatically establishing a directed dependency graph when a variable references other variables (via referVariableId) for topological sorting of calculation order; ③ Cascading updates after variable changes, automatically notifying all computational variables that depend on the source variable to recalculate when the source variable changes.

[0110] The protocol parsing module includes a Python script engine and a Python script execution environment. The Python script engine supports hot-loading of the parsing script, version management, and execution strategy configuration. The parsing script interacts with the industrial IoT platform through standardized input / output interfaces. The input is the raw message (byte[]), and the output is a standardized list of variable data key-value pairs (Map).<String,Object> The protocol parsing module supports configuring multi-level parsing script chains for the same product to achieve layered parsing (such as unpacking the binary frame header first, and then parsing the JSON payload).

[0111] The data storage routing module routes data to the corresponding storage engine based on the storage type and storage rules of the device variables, including: ① Time-series storage engine (TDengine): suitable for high-frequency collected time-series data, supporting super table / sub-table mode, automatic downsampling, data retention strategies, etc.; ② Relational storage engine (MySQL): suitable for configuration data with low-frequency changes; ③ Caching storage engine (Redis): suitable for real-time data that needs to be read quickly, supporting data expiration strategies and publish / subscribe modes.

[0112] The alarm linkage module subscribes to variable value change events through EventBus and performs real-time evaluation of alarm conditions based on Aviator expressions. The alarm linkage module supports: ① multi-condition combined alarms, supporting AND / OR / NOT logical operators; ② alarm level management, supporting multi-level alarms (urgent, severe, general, alert); ③ alarm notification channel management, supporting multiple notification methods such as SMS, WeChat, email, and MQTT command issuance; ④ alarm processing flow tracking, recording the entire lifecycle log of alarm triggering, notification, confirmation, processing, and closure.

[0113] The simulation module has a built-in simulation engine in the industrial IoT platform, which supports the generation of simulation data according to the simulation type. The simulation types include random values, sine values, square waves, triangular waves, increasing / decreasing values, and constants. The simulation data follows the same processing flow as the real data and supports the injection of simulation data into the MQTT access layer, protocol parsing layer, or variable update layer.

[0114] like Figure 1 , Figure 2 As shown, this case as a whole includes a core architecture layer, a fine-grained management and control layer, a protocol parsing and data routing layer, a real-time response layer, and a development and testing layer.

[0115] I. Core Architecture Layer: Templated and Inherited, corresponding to steps S10 and S20.

[0116] Because there are many types of equipment in industrial scenarios, traditional solutions require redefining the model for each new device. This solution first uses a "product model" to define the common attributes (protocol, message format, variable set) of a "type of equipment", and then allows "device instances" to inherit from this "product model".

[0117] Compared to existing technologies, the design in this case achieves the following: ① Batch reuse and significant burden reduction: For example, similar devices only need to define a product template once; when adding a new device, the device instance automatically inherits all variable definitions, improving creation efficiency; ② Consistency management: When the product model variables change (such as adding a temperature monitoring variable), all devices inheriting that product are automatically updated synchronously, avoiding omissions and configuration errors caused by modifying each device individually in traditional solutions.

[0118] II. Refined Management Layer: Variable-level fine-grained configuration, corresponding to step S30.

[0119] Because industrial equipment data varies greatly (vibration data is stored for short periods due to high frequency, while temperature data is stored for long periods due to low frequency), the traditional "one-size-fits-all" storage strategy will result in wasted resources or data loss.

[0120] Compared to existing technologies, the design in this case achieves the following: ① A sharp reduction in storage costs: By using variable-level storage strategies (storage period, retention time, aggregation downsampling), differentiated storage schemes are adopted for different variables, resulting in an overall reduction in storage costs of 40% to 60%; ② Real-time data computation is decentralized: Through calculation rules (calcRule) and Aviator expressions, cross-device, multi-variable correlation calculations (such as total power = A + B + C) are decentralized from "writing code at the application layer" to the "object model configuration layer," improving configuration efficiency by more than 80%, and the results are calculated immediately as soon as the data is updated.

[0121] III. Protocol parsing and data routing layer: hot loading and hybrid storage, corresponding to step S40.

[0122] Because industrial protocols are diverse (Modbus, OPC-UA, etc.), and message formats vary, traditional methods require system shutdown and restart to adapt to new protocols, and database queries often encounter bottlenecks.

[0123] Compared to existing technologies, the design in this case achieves: ① "Zero downtime" for connecting new devices: By adopting a hot-loading mechanism of Python script engine, new protocol parsing scripts can be dynamically loaded without restarting the platform, shortening the new device access cycle from several weeks to several hours; ② High concurrency throughput: The underlying layer adopts a three-layer pipeline architecture of MQTT+Kafka+TDengine, with each data type corresponding to a "super table" and each variable corresponding to a "sub-table", supporting more than 100,000 data writes and persistence per second, meeting the needs of large-scale industrial scenarios.

[0124] IV. Real-time Response Layer: Event-driven alarm linkage, corresponding to step S50.

[0125] Traditional alarm engines retrieve data by polling the database, which results in a delay of up to a second and makes it impossible to perform complex cross-variable condition judgments.

[0126] Compared to existing technologies, this design achieves the following: ① Millisecond-level alarm response: Data is pushed using the EventBus event bus. Alarm evaluation is triggered immediately upon variable change, reducing alarm latency from seconds to milliseconds, meeting the extremely high real-time requirements of industrial environments for vibration, temperature exceedances, etc.; ② Low load and low code: The design changes from "polling" to "push," reducing CPU utilization by more than 30% under high concurrency. Furthermore, alarm conditions directly reference variable codes, eliminating the need for additional maintenance of complex mapping relationships.

[0127] V. Development and Testing Layer: Built-in simulation engine, corresponding to step S60.

[0128] The biggest pain point in IoT development is often that "the code has been written before the device arrives, and there is no way to test it"; this solution does not rely on physical devices and has built-in simulation capabilities.

[0129] Compared to existing technologies, the design in this case achieves the following: ① Physical device independence: It supports the simulation of various waveforms such as sine waves, triangle waves, and random values, and the entire chain function can be verified without waiting for real hardware during the development and testing phase; ② Environmental consistency guarantee: After the simulated data is injected through EventBus, it goes through the same processing flow (storage, alarm, calculation) as the real data, ensuring that the simulation environment and the production environment are 100% consistent, and improving the efficiency of development, implementation and verification.

[0130] The foregoing has shown and described the basic principles, main features, and advantages of the present invention. Those skilled in the art should understand that the above embodiments do not limit the present invention in any way, and all technical solutions obtained by equivalent substitution or equivalent transformation fall within the protection scope of the present invention.

Claims

1. A method for designing industrial object models based on an industrial Internet of Things (IIoT) platform, characterized in that: A three-tiered object model architecture is constructed, consisting of product, device, and variable layers. The product layer defines common attributes of the product object model, including communication protocols and message formats. The device layer adds personalized attributes to device instances, including device code, network mode, and installation location. The variable layer enables fine-grained configuration of product object model variables, including data types, storage strategies, calculation rules, and simulation configurations. This three-tiered object model architecture supports cross-device reuse of product object models, with device instances automatically inheriting all variable definitions from the product object model upon creation.

2. The industrial object model design method based on an industrial Internet of Things platform according to claim 1, characterized in that: A storage strategy is defined at the variable layer, including storage type and storage rules; the storage type supports four modes: time-series storage, relational storage, cache storage, and no storage; the storage rules define the storage period, data retention duration, aggregation downsampling strategy, and hot and cold data separation strategy in JSON format. Based on the storage strategy of each device variable, data is automatically routed to the corresponding storage engine.

3. The industrial object model design method based on an industrial Internet of Things platform according to claim 1, characterized in that: In the variable layer, the association calculation logic between device variables is defined in JSON format. It supports referencing the values ​​of other device variables within the same device or across devices. Real-time calculation between device variables is performed through Aviator expressions. The dependency graph between device variables is automatically constructed through the variable management module. The calculation order is determined based on topological sorting. When the source variable value changes, the cascading recalculation of dependent variables is automatically triggered through EventBus event-driven mechanisms.

4. The industrial object model design method based on an industrial Internet of Things platform according to claim 1, characterized in that: Simulation configuration is introduced at the variable layer, including simulation type and simulation rules; device instances switch between real mode and simulation mode through simulation identifiers; the simulation engine supports multiple waveform types, and simulation data is automatically generated according to the numerical range constraints and data types of device variables, and published to the industrial IoT platform through EventBus. Simulation data and real data follow the same processing flow.

5. The industrial object model design method based on an industrial Internet of Things platform according to claim 1, characterized in that: The alarm linkage module subscribes to variable value change events through EventBus to achieve real-time push of device variable values ​​instead of polling; alarm conditions are defined through Aviator expressions, directly referencing the variable codes of the product object model; when device variable values ​​are updated, real-time evaluation of relevant alarm conditions is automatically triggered; alarm conditions support multiple condition combinations, multi-level alarm levels, and silent period configuration.

6. The industrial object model design method based on an industrial Internet of Things platform according to claim 1, characterized in that: The method includes the following steps: S10. Create product object models and define communication protocols and data access specifications: Create a product object model for each type of device in the industrial IoT platform, and define the common attributes of the device, including product name, product code, device type, communication protocol, message format and parsing script; S20. Create equipment instances based on the product model and establish a mapping relationship between equipment and equipment variables in the product model: Equipment instances automatically inherit all variable definitions under the product model. The core attributes of equipment instances include equipment name, equipment code, parent device identifier, equipment status, network mode, simulation identifier, and hierarchical relationship. S30. Constructing fine-grained configurations at the variable level: Create device variables under device instances to form a three-level object model architecture of product → device → variable; The core attributes of each device variable include variable name, variable code, variable type, data type, access mode, numerical range constraints, unit of measurement, default value, storage strategy, calculation rules and simulation configuration; S40. Device data is reported and, after being processed by the protocol parsing script, is persisted according to the storage policy. S50. Based on the equipment variable values ​​of the product model, the relevant alarm conditions are evaluated in real time through Aviator expressions; S60. Generating simulated data through the simulation engine: When the device is in simulation mode, the simulation engine generates simulated data for the device. The simulated data follows the same processing flow as the real data.

7. The industrial object model design method based on an industrial Internet of Things platform according to claim 6, characterized in that: In step S40, after the device reports device data via the communication protocol, the industrial IoT platform processes the data through the following process: S41. The MQTT client subscribes to the corresponding MQTT topic according to the device code and receives the original messages reported by the device; the MQTT topic adopts a hierarchical naming rule and supports wildcard subscription to realize batch device access; S42. Based on the communication protocol of the product model to which the equipment belongs, the protocol parsing script is used; the parsing script adopts the hot loading mechanism of the Python script engine, which supports dynamic loading and updating; The original message is taken as input, and the script is parsed to output a standardized list of variable data key-value pairs. S43. Persist the device variable values ​​according to the storage type and storage rules; for device variables with time-series storage type, write the device variable values ​​to the TDengine time-series database, which uses the storage rule of super table + sub-table.

8. The industrial object model design method based on an industrial Internet of Things platform according to claim 6, characterized in that: In step S50, the alarm linkage module is deeply integrated with the data storage routing module through an event-driven architecture, including the following steps: S51. When the device variable value is updated, the variable value change event is published through EventBus. The alarm linkage module subscribes to the variable value change event through EventBus to realize the real-time push of the device variable value instead of polling. S52, Aviator expressions define alarm conditions; S53. When the real-time evaluation result of the Aviator expression is true, an alarm action is triggered.

9. The industrial object model design method based on an industrial Internet of Things platform according to claim 6, characterized in that: In step S60, when the device is in simulation mode, the simulation engine generates simulation data including the following steps: S61. Determine the simulation type and simulation rules for the equipment variables. The simulation types include random values, sine values, square waves, triangle waves, increasing / decreasing values, and constants. S62. Using a defined simulation type and simulation rules, automatically generate simulation data according to the numerical range constraints and data types of equipment variables; S63. Simulated data is published to the Industrial Internet of Things platform via EventBus, and the simulated data follows the same processing flow as real data.

10. An industrial object model design system based on an industrial Internet of Things (IIoT) platform, characterized in that: It includes a product management module, an equipment management module, a variable management module, a protocol parsing module, a data storage and routing module, an alarm linkage module, and a simulation module; The product management module is used to create and manage product object model templates and define common attributes including communication protocols, message formats and script associations. The product management module maintains the parent-child hierarchy between product models and equipment variables, and supports version management and change tracking of product models. The equipment management module is used to create equipment instances based on the product model, manage the equipment lifecycle, and support the management of equipment parent-child hierarchical relationships, real-time monitoring of equipment status, and switching of equipment simulation modes. The variable management module is used to define and manage device variables under a device instance, including the data type, access mode, storage strategy, calculation rules and simulation configuration of the device variables; The protocol parsing module includes a Python script engine and a Python script execution environment. The Python script engine supports a hot-loading mechanism, version management, and execution strategy configuration for the parsing script. The parsing script interacts with the industrial IoT platform through standardized input / output interfaces. The input is the raw message, and the output is a standardized list of variable data key-value pairs. The data storage routing module routes data to the corresponding storage engine based on the storage type and storage rules of the device variables. The alarm linkage module subscribes to variable value change events through EventBus and performs real-time evaluation of alarm conditions based on Aviator expressions. The simulation module has a built-in simulation engine in the industrial IoT platform, which supports the generation of simulation data according to the simulation type. The simulation types include random values, sine values, square waves, triangular waves, increasing / decreasing values, and constants. The simulation data follows the same processing flow as the real data and supports the injection of simulation data into the MQTT access layer, protocol parsing layer, or variable update layer.

Images