A secondary development system and method based on industrial Internet of Things gateway

Abstract

The present invention relates to the field of industrial Internet of Things technology, and in particular to a secondary development system and method based on an industrial Internet of Things gateway. It comprises a client and an industrial Internet of Things gateway; the client sends device information and variable information of the configured script device to the industrial Internet of Things gateway; the industrial Internet of Things gateway comprises: a secondary development module; an initialization module; a thing model module; a variable module; and a Python SDK module. The present invention implements system modular decoupling through a publish-subscribe mechanism of a built-in MQTT server, supports dynamic expansion of multi-industrial protocol conversion and edge computing capabilities, and provides a low-code Python SDK development environment. Compared with existing technologies, this solution greatly shortens the edge secondary development cycle and improves development efficiency, effectively solving the core pain points in the industrial Internet of Things field, such as poor protocol scalability, limited openness, high difficulty in secondary development, and heavy workload.

Description

Technical Field

[0001] The present invention relates to the technical field of industrial Internet of Things, and in particular to a secondary development system and method based on an industrial Internet of Things gateway. Background Art

[0002] The Chinese utility model patent application number CN202322767382, titled "An Industrial Gateway Supporting Secondary Development and Remote Debugging," provides an environment for secondary development and debugging, but practical implementation still requires significant development work. Mainstream vendors have shifted from single-protocol support to multi-protocol compatibility, but dynamic scalability is generally insufficient. Low-code development is gaining momentum, but Python SDK support remains limited, and edge computing capabilities are weak.

[0003] The Chinese patent invention application with application number 202310023365 and titled "A dynamic component extension implementation method based on API gateway" provides API expansion capabilities, but does not disclose the implementation process of the components corresponding to each API, and does not have protocol capabilities. It is difficult to get started, and specific functions need to be developed and implemented by technical personnel themselves.

[0004] The existing technology has the following disadvantages:

[0005] 1. Inflexible protocol extension:

[0006] The protocol expansion cycle is long, most solutions require firmware upgrades or application recompilation, and the plug-in development threshold is high.

[0007] 2. Weak edge computing capabilities:

[0008] Existing solutions are mostly limited to simple data processing. When they lack a complete Python runtime environment, they cannot execute complex logic, cannot dynamically add Python dependency libraries, and rely on the cloud for data calculation.

[0009] The secondary development capabilities are limited, relying on self-written plug-ins, with poor code debugging support and difficulty in locating problems.

[0010] 3. Lack of convenience:

[0011] All data acquisition needs to be queried in the Industrial Internet of Things. Summary of the Invention

[0012] The purpose of the present invention is to provide a secondary development system and method based on industrial Internet of Things gateway.

[0013] In order to achieve the above objectives, the technical solutions adopted by the present invention are as follows:

[0014] A secondary development system based on an industrial Internet of Things gateway includes a client and an industrial Internet of Things gateway; the client sends device information and variable information of a configured script device or a universal protocol device to the industrial Internet of Things gateway;

[0015] The industrial Internet of Things gateway includes:

[0016] Initialization module, receives the device information and variable information of the configured script device or general protocol device and parses them;

[0017] The physical model module receives the parsing results of the initialization module and generates a physical model, and sends the physical model to the variable module;

[0018] The secondary development module is started after the object model is initialized;

[0019] The variable module publishes the object model to the MQTT server through the secondary development module; parses the real-time data message sent by the script device received by the industrial Internet of Things gateway and binds it with the object model;

[0020] The MQTT server is started by the secondary development module and connected to the secondary development module and the Python SDK module respectively;

[0021] Python SDK module, connects to the MQTT server, and obtains the object model.

[0022] After the variable module is bound, data is reported through the northbound interface module of the industrial Internet of Things gateway.

[0023] The physical model generated by the physical model module is the physical model after adding the static information of the device and the static information of the variables. The parsing result of the initialization module is the static information of the device and the static information of the variables. Physical model initialization means: the physical model module generates the physical model after adding the static information of the device and the static information of the variables for the first time.

[0024] The variable module publishes the object model to the MQTT server through the secondary development module. Specifically, the object model after the device static information and variable static information are added to the variable module is sent to the secondary development module. The secondary development module establishes the mapping relationship between all variables in the object model and services based on the variable type in the object model and the correspondence between the variable type and the service, and obtains the object model with the mapping relationship between variables and services. The object model with the mapping relationship between variables and services is then published to the MQTT server.

[0025] After receiving the device information and variable information of the configured script device or universal protocol device, the initialization module identifies the script flag in the device information, determines whether the device ID is associated with the script flag, stores a list of device IDs associated with the script flag, and sends the list to the secondary development module;

[0026] When the IIoT gateway receives real-time data from a device, the secondary development module determines whether the device ID is in the device ID list associated with the script flag. If it is in the list, it is determined to be real-time data from a script device and the variable module is called for parsing. If it is not in the list, it is determined to be real-time data from a general protocol device and the protocol module is called for parsing.

[0027] The real-time data of the script device parsed by the variable module and the real-time data of the general protocol device parsed by the protocol module are bound to the object model after the device static information and variable static information are added to the variable module.

[0028] The general protocol equipment mentioned are PLC, DCS, sensors, etc.

[0029] Another object of the present invention is to disclose a secondary development method based on an industrial Internet of Things gateway, using a secondary development system based on an industrial Internet of Things gateway, the secondary development method comprising the following steps:

[0030] Step 1: Configure script devices and general protocol devices;

[0031] Step 2: Analyze device static information and variable static information and generate physical models;

[0032] Step 3: Start the secondary development module and MQTT server;

[0033] Step 4: Publish the object model.

[0034] Step 5: Real-time data analysis and release;

[0035] Step 6: Report data.

[0036] Step 1 is as follows: add a script device or a universal protocol device on a local client or a remote client, and add required variables under the script device or the universal protocol device.

[0037] Step 2 is as follows: the initialization module receives the device information and variable information sent by the client and parses them to obtain device static information and variable static information; the device static information and variable static information are placed in the object model module, and then the object model module abstracts the device static information and variable static information in the object model module to obtain a object model with the device static information and variable static information added, and the object model module sends the object model to the variable module;

[0038] The initialization module further identifies the script flag in the device information, determines whether the device ID is associated with the script flag, stores a list of device IDs associated with the script flag, and sends the list to the secondary development module after the secondary development module is started;

[0039] Step 3 is as follows: the secondary development module is started after the object model is initialized, and then the MQTT server is started.

[0040] In step 4, the publishing process of the object model is as follows: the secondary development module calls the object model with the device static information and variable static information added to it from the variable module. The secondary development module establishes mapping relationships between all variables in the object model and services based on the variable types in the object model and the correspondence between variable types and services, thereby obtaining a object model with mapping relationships between variables and services established. The correspondence between variable types and services is preset in the secondary development module. The object model with mapping relationships between variables and services established is published to the MQTT server.

[0041] The Python SDK module in the IIoT gateway connects to the MQTT server and, through topic subscription, obtains the object model published by the IIoT gateway that establishes the mapping relationship between variables and services.

[0042] The Open API module supports the MQTT protocol, enabling the MQTT server to support subscription / publishing with respect to both the Python SDK module and the secondary development module.

[0043] In step 5, after the real-time data of all variables of the device are obtained by the industrial Internet of Things gateway, the secondary development module identifies the device ID and determines whether the device ID is in the device ID list associated with the script flag. If it is in the list, it is determined to be the real-time data of the script device and the variable module is called for parsing. If it is not in the list, it is determined to be the real-time data of the general protocol device and the protocol module is called for parsing.

[0044] The variable module parses the real-time data of the script device and binds the parsed real-time data to the physical model in the variable module. At the same time, the protocol module parses the real-time data of the general protocol device and sends the parsed real-time data to the variable module and binds it to the physical model in the variable module.

[0045] After binding is completed, the variable module can call the method in the calculation module to calculate or analyze the relevant results, and publish the relevant result data to the MQTT server through the secondary development module and Open API interface, or report it to a third-party system through the northbound interface module.

[0046] This paper proposes a secondary development system and method based on an Industrial Internet of Things (IIoT) gateway. This system achieves modular decoupling through a built-in MQTT Broker publish-subscribe mechanism, supports dynamic expansion of multi-industrial protocol conversion and edge computing capabilities, and provides a low-code Python SDK development environment. Compared to existing technologies, this solution significantly shortens the edge secondary development cycle and improves development efficiency, effectively addressing the core pain points of the IIoT sector, such as poor protocol scalability, limited openness, and the difficulty and workload of secondary development. BRIEF DESCRIPTION OF THE DRAWINGS

[0047] Figure 1 This is a flow chart of the secondary development method based on the Industrial Internet of Things gateway;

[0048] Figure 2 This is a schematic diagram of the secondary development system based on the Industrial Internet of Things gateway. DETAILED DESCRIPTION

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

[0050] like Figure 1 and Figure 2 As shown, a secondary development system based on an industrial Internet of Things gateway includes a client and an industrial Internet of Things gateway; the client sends device information and variable information of a configured script device or a general protocol device to the industrial Internet of Things gateway;

[0051] The industrial Internet of Things gateway includes:

[0052] Initialization module, receives the device information and variable information of the configured script device or general protocol device and parses them;

[0053] The physical model module receives the parsing results of the initialization module and generates a physical model, and sends the physical model to the variable module;

[0054] The secondary development module is started after the object model is initialized;

[0055] The variable module publishes the object model to the MQTT server through the secondary development module; parses the real-time data message sent by the script device received by the industrial Internet of Things gateway and binds it with the object model;

[0056] The MQTT server is started by the secondary development module and connected to the secondary development module and the Python SDK module respectively;

[0057] Python SDK module, connects to the MQTT server, and obtains the object model.

[0058] After the variable module is bound, data is reported through the northbound interface module of the industrial Internet of Things gateway.

[0059] The physical model generated by the physical model module is the physical model after adding the static information of the device and the static information of the variables. The parsing result of the initialization module is the static information of the device and the static information of the variables. Physical model initialization means: the physical model module generates the physical model after adding the static information of the device and the static information of the variables for the first time.

[0060] The variable module publishes the object model to the MQTT server through the secondary development module. Specifically, the object model after the device static information and variable static information are added to the variable module is sent to the secondary development module. The secondary development module establishes the mapping relationship between all variables in the object model and services based on the variable type in the object model and the correspondence between the variable type and the service, and obtains the object model with the mapping relationship between variables and services. The object model with the mapping relationship between variables and services is then published to the MQTT server.

[0061] After receiving the device information and variable information of the configured script device or universal protocol device, the initialization module identifies the script flag in the device information, determines whether the device ID is associated with the script flag, stores a list of device IDs associated with the script flag, and sends the list to the secondary development module;

[0062] When the IIoT gateway receives real-time data from a device, the secondary development module determines whether the device ID is in the device ID list associated with the script flag. If it is in the list, it is determined to be real-time data from a script device and the variable module is called for parsing. If it is not in the list, it is determined to be real-time data from a general protocol device and the protocol module is called for parsing.

[0063] The real-time data of the script device (dynamic information (variable value, time, status information), variable ID, device ID, variable address, etc.) parsed by the variable module, and the real-time data of the general protocol device (dynamic information (variable value, time, status information), variable ID, device ID, variable address, etc.) parsed by the protocol module are bound to the object model with the device static information and variable static information added to the variable module.

[0064] The general protocol equipment mentioned are PLC, DCS, sensors, etc.

[0065] The present invention provides a secondary development method based on an industrial Internet of Things gateway, comprising the following specific steps:

[0066] Step 1: Configure script devices and general protocol devices

[0067] Add a script device on the local client or remote client and add the required variables under the script device.

[0068] Adding a script device on a local or remote client involves determining the device's network or serial port connection and the IIoT gateway network or serial port number to which the device should connect, based on the device's proprietary protocol documentation and the device's proprietary protocol definition rules. Script device information includes the device ID, network or serial port ID (i.e., network or serial port number), and script flag. The script flag is used to identify a device as a script device and is associated with the device ID of the script device. For example, if the script flag is "*" and the device ID of a script device is "3244," "*3244" indicates that the device with ID 3244 is a script device. Configured general protocol device information does not include a script flag; that is, the corresponding device ID is not associated with a script flag.

[0069] A proprietary protocol is a customized protocol that doesn't use a standard protocol. For example, it can be a closed-source protocol. Devices that use proprietary protocols are called script devices (custom script devices). Script devices have corresponding proprietary protocol documents that specify the rules for defining the device's proprietary protocol. These rules specify whether the device should be connected via an Ethernet or serial port, along with supported variables and variable-related information (variable name, unit, data type (string, floating-point, etc.), address, byte order, and range).

[0070] Adding required variables to a script device involves determining the variables to be added based on the device's proprietary protocol documentation and the protocol's definition rules. This includes the variable name, variable type, variable unit, data type (string, floating point, etc.), variable address, byte order, and range (some are required, others are optional). Each variable has a unique variable ID.

[0071] The data format for script device information and added variable information is JSON. In JSON format, the device ID, network or serial port ID, variable ID, variable name, variable type, data type, variable address, byte order, etc. are each identified (represented by a key) to facilitate subsequent parsing of the script device information and added variable information.

[0072] Users can add several custom script devices on a local or remote client. These devices cannot be directly connected to the Industrial IoT gateway and require a secondary development system to complete device docking. The required variables, such as current, voltage, temperature, and humidity, are then added to the device. Add as many variables as required device data. Finally, the configured script device information and required variable information are sent to the Industrial IoT gateway via MQTT (Message Queuing Protocol) / HTTP (Hypertext Transfer Protocol).

[0073] If the device uses a universal, standardized protocol, the user, on a local or remote client, determines the device's Ethernet or serial port connection based on the universal protocol documentation and its definition rules. The user then determines the IIoT gateway's Ethernet or serial port number to which the device should connect. The user then adds the required variables to the device. The configuration process is the same as for the script device above. The data format for the universal protocol device information and added variables is also JSON. The configured universal protocol device and variable information is also sent to the IIoT gateway via MQTT (Message Queuing Protocol) or HTTP (Hypertext Transfer Protocol).

[0074] Specifically, before the secondary development system based on the industrial Internet of Things gateway of the present invention is activated, the device information and variable information of all configured script devices and general protocol devices are simultaneously sent to the industrial Internet of Things gateway.

[0075] Step 2: Analyze device static information and variable static information, and generate object models

[0076] The device is connected to a network port or a serial port of the industrial Internet of Things gateway.

[0077] The initialization module parses the device information and variable information of the configured script device and / or universal protocol device sent by the client. Specifically, it parses the device and variable information; more specifically, it parses to obtain device static information (device ID, network port or serial port ID, script flag, etc.) and variable static information (variable ID, variable name, variable type, data type, variable address, byte order, etc.). This information is collectively referred to as device static information and variable static information. The parsing results (i.e., device static information and variable static information) are placed in the object model module; the object model module itself includes the devices, variables, and services that constitute the object model. The devices, variables, and services are at the same level, and the services are built into the object model module. The devices and variables specify the device and variable related information required by the object model (for example, the object model requires device ID, network port or serial port ID, etc. as device attributes, and the object model requires variable ID, variable name, variable type, data type, range, etc. as variable attributes). Then the object model module abstracts the device static information and variable static information in the object model module (abstraction refers to using device static information and variable static information as the specific content of the device and variable of the object model, that is, the device level includes device 1, device 2, device 3, etc., and each device contains specific device ID, network port or serial port ID and other information as attributes. The variable level contains variable 1, variable 2, variable 3, etc.). Each variable has specific attributes such as variable ID, variable name, variable type, data type, and range. Each variable corresponds to a specific device, and the number of devices and the number of variables under the same device are counted. A physical model is generated by adding device static information and variable static information. The generated physical model is sent to the variable module by the physical model module.

[0078] The device static information and variable static information correspond to the attributes of the object model, such as variable ID, variable name, data type, and range.

[0079] Among them, after the initialization module receives the device information and variable information of the configured script device or universal protocol device, it also identifies the script flag in the device information, determines whether the device ID is associated with the script flag, stores the device ID list associated with the script flag, and sends the list to the secondary development module after the secondary development module is started (actually the initialization module is called by the secondary development module to send the list to the secondary development module).

[0080] In device static information and variable static information, variable types can include acquisition variables, calculation variables, attribute variables, and script variables (i.e., variables configured by script devices). Services include device or variable status notifications, event notifications, support for historical data storage, and support for Python SDK calculations or analysis. These services are pre-defined in the object model module. The object model module abstracts all devices and variables placed in the object model module and generates an object model that incorporates device static information and variable static information. The initial generation of the object model with device static information and variable static information is called the object model initialization process (also known as initializing the object model). In the initialized object model, all device static information and variable static information are retained.

[0081] After the client configures device and variable information for the first time, the initialization module parses the configuration information, initializes the object model, and then publishes the object model for the first time. After the client configures device and variable information again, the initialization module parses the configuration information again, updates the object model, and then publishes the object model again. The updated object model also retains the updated static device and variable information. The method for parsing configuration information, generating the object model, and publishing the object model remains consistent each time.

[0082] When a user adds, removes, or modifies a configured device and / or variable on a local or remote client, the local or remote client sends all the device-related information and variable information currently configured on the client after the addition, removal, or modification to the IIoT gateway. The initialization module reparses all the device-related information and variable information currently configured on the client, and the results of the reparse (updated device static information and variable static information) completely replace the original device static information and variable static information in the initialized object model, which is then re-abstracted to obtain the updated object model. Furthermore, when a user adds, removes, or modifies a configured device and / or variable on a local or remote client, the local or remote client can also send only the configuration information related to the added, removed, or modified configured device and / or variable to the IIoT gateway. The initialization module then parses only the configuration information related to the added, removed, or modified configured device and / or variable, and then re-abstracts the device static information and variable static information of the added, removed, or modified configured device and / or variable in the initialized object model.

[0083] Step 3: Start the secondary development module and MQTT server

[0084] After the object model is initialized, the secondary development module is started, and then the MQTT server is started.

[0085] Specifically, the secondary development module starts an MQTT server, also known as the MQTT Broker. A timer is included in the module to monitor and manage the MQTT server. If the timer detects an MQTT server anomaly, it restarts the server (i.e., the secondary development module restarts the MQTT server), ensuring the normal operation of the MQTT server and the Python SDK module.

[0086] Step 4: Publish the object model

[0087] After the physical model is initialized, the secondary development module starts and calls the physical model module, so that the physical model module sends the physical model generated for the first time with the device static information and variable static information added to the variable module (the physical model updated thereafter is also sent to the variable module).

[0088] The secondary development module acts as a bridge:

[0089] The publishing process for the object model in the variable module is as follows: the secondary development module retrieves the object model from the variable module, after adding static device and variable information. Based on the variable types in the object model and the correspondence between variable types and services, the secondary development module establishes mapping relationships between all variables in the object model and services, resulting in an object model with established mapping relationships between variables and services. The correspondence between variable types and services is preset in the secondary development module. When this object model with established mapping relationships between variables and services is published to the MQTT server, the object model obtained by the PythonSDK module from the MQTT server more intuitively clarifies the correspondence between devices, variables, and services. This significantly reduces the development difficulty when developing Python SDK functions, such as expanding calculation or analysis functions in the Python SDK.

[0090] The variable module always retains the object model sent from the object model module (if the object model has been updated, the most recently updated object model is retained). This is used to subsequently bind dynamic information parsed from real-time data to the static information about devices and variables in the object model. After binding, the object model in the variable module not only contains static information about devices and variables, services, etc., but also dynamic information as attributes of the variables in the object model in the variable module. This allows the object model in the variable module to contain both static and dynamic information. The object model in the variable module is regularly published to the MQTT server through the secondary development module.

[0091] Before publishing, the secondary development module also assembles the object model or other data into JSON format, for example, assembles the object model data to be published into JSON format for publishing.

[0092] The secondary development module also integrates and calls all modules of the Industrial Internet of Things Gateway ( Figure 2 ), including notification module, variable module, object model module, storage module, etc.

[0093] When the secondary development module integrates and calls all modules of the Industrial Internet of Things gateway, it calls different modules through the type identifier of the Open API interface module. The type identifier is used to indicate the role of different modules (notification module, variable module, storage module, system module, calculation module, protocol module, object model module, and initialization module).

[0094] Calculation module: built-in calculation function or analysis function. The real-time data of general protocol devices parsed from the protocol module or the real-time data of script devices parsed from the variable module can be used as input parameters of the calculation module. When the user subscribes to the calculated device data from MQTTBroker, the secondary development module can call the calculation module to perform relevant calculations, and the corresponding results obtained by the calculation are then published to the MQTT Broker through the secondary development module.

[0095] Storage module: Used to store device information and variable information sent by the client, data parsed from general protocol devices, or data parsed from script devices (usually storing historical data). When a user subscribes to data in a storage module from the MQTT Broker, the secondary development module calls the corresponding storage module.

[0096] Notification Module: Built-in device offline notifications, such as those in the event of a device failure, notify the user platform or third-party management system of on-site device anomalies; variable offline notifications; alarm notifications; device latitude and longitude location notifications, etc. For example, the notification module traverses the variables in the variable module that represent the device's offline or online status, determines whether the device is offline based on its dynamic information (status). The notification module then stores the device offline determination result, device ID, variable ID, and static and dynamic information about the variables representing the device's offline or online status in the notification module, and simultaneously sends it to the third-party management system or user platform via the northbound interface module. Users can also subscribe to data in the notification module through the MQTT broker, in which case the secondary development module needs to call the notification module.

[0097] System module: includes system resources (IO input and output control, etc.) and system management (restoring factory settings, restarting, clock synchronization, etc.). The interaction between the system module and the secondary development module is the same as the other modules above.

[0098] The MQTT server also serves as a bridge for users to implement secondary development using the IIoT gateway. The variable module publishes the object model via MQTT topics, effectively publishing user-configured device and variable information to the MQTT Broker. The Python SDK module in the IIoT gateway also connects to this MQTT Broker and, through topic subscriptions, retrieves the object model published by the IIoT gateway. This provides a clear overview of devices, variables, and services, facilitating the development of customized calculation or analysis functions. Similarly, users who are not using Python can connect to the MQTT Broker via an MQTT client and access object model data by calling the Open API.

[0099] The Python SDK module and the MQTT server implement publish / subscribe functions through the Open API interface. Other modules implement publish / subscribe functions through secondary development modules and the Open API interface and the MQTT server.

[0100] The Python SDK module has built-in variable calculation or analysis functions, and you can also develop and set new calculation or analysis functions in the Python SDK module. Calculation functions include addition and subtraction of some variables and calculation of averages, while analysis functions include multivariate correlation analysis.

[0101] Step 5: Real-time data analysis and release

[0102] The variable module can bind the real-time data of the device analyzed by the variable module or protocol module to the physical model in the variable module, that is, which value corresponds to temperature, and which data corresponds to pressure. The real-time data of the device comes from: According to the serial port or network port corresponding to the device configured in step 1, by calling the serial port or network port, the real-time data message of the device is obtained, which contains the real-time data of all variables of the device.

[0103] After the real-time data of all variables of the device are obtained by the industrial Internet of Things gateway, the secondary development module identifies the device ID and determines whether the device ID is in the device ID list associated with the script flag. If it is in the list, it is determined to be the real-time data of the script device and the variable module is called for parsing; if it is not in the list, it is determined to be the real-time data of the general protocol device and the protocol module is called for parsing.

[0104] The variable module parses the real-time data of the script device and binds the parsed real-time data to the physical model in the variable module. Meanwhile, the protocol module parses the real-time data of the general protocol device and sends the parsed real-time data to the variable module and binds it to the physical model in the variable module.

[0105] Specifically, the data parsed from real-time data packets sent by script devices or general protocol devices contains dynamic information such as value, time, and status. Static information such as variable name, unit, and range is user-configured. Binding the parsed dynamic information with the static information in the object model creates the complete variable information (i.e., the variable's static information + dynamic information + the corresponding device ID constitutes the complete variable information). Binding is performed based on the variable ID. The data parsed from the device's real-time data packets also contains variable ID information, and the static information also contains variable ID information, so the two can correspond. Variable IDs are unique and do not repeat for different devices.

[0106] The protocol module parses the real-time data messages sent by the general protocol devices.

[0107] After binding is complete, the variable module can call methods in the Python SDK module (i.e., the calculation or analysis functions in step 4, where the Python SDK module predefines which variables serve as input parameters for which functions) to calculate or analyze the relevant results (in calculations, the input parameters are dynamic information about the variables, such as numerical values). The resulting data (such as the device ID, complete variable information, and calculation or analysis results) can be published to the MQTT broker via the secondary development module or the Open API, or reported to a third-party system via the northbound interface module. The variable module can also call methods in the calculation module to calculate or analyze the relevant results, publish them to the MQTT server via the secondary development module or the Open API, or report them to a third-party system via the northbound interface module. Alternatively, the complete information about the bound variables can be published to the MQTT broker via the secondary development module or the Open API, or reported to a third-party system via the northbound interface module, without calling Python SDK methods or the calculation module. If using other languages, data can be published directly to the MQTT broker via the Open API. The Industrial IoT Gateway subscribes to published data. The variable module parses the real-time data of all variables in script devices, while the protocol module parses the real-time data of all variables in general protocol devices. This information is then converted into dynamic information (value, time, status information), variable ID, device ID, variable address, and so on. Within the complete variable information, dynamic information is updated in real time, while other static information does not need to be updated unless the client configuration has changed. Status information refers to information indicating the operating status of a device or variable, such as device offline, device online, device warning, variable online, and variable offline.

[0108] For the real-time data message of the acquired device, let's take an example: if there is a string of data, the private protocol or the universal protocol specifies the start and end of the string of data; the first two bits are specified as the device address, and the data area is parsed to determine how many data variables there are, the value, data type, byte order of each data, etc., and finally the check code is used to determine whether the string of data is complete. During parsing, you only need to get a complete string of data, and check which device the string of data belongs to based on the device address, what type of data it contains, and then take out the value from the data field, as well as dynamic information such as time and status, and then bind the dynamic information with the static information in the object model.

[0109] The Python SDK module of the present invention relies on the Open API interface module, such as Figure 2 As shown, the OpenAPI interface module and secondary development module of the present invention support the MQTT protocol, so that the MQTT server supports subscription / publishing relative to the Python SDK module and the secondary development module. Users can also directly use the Open API interface module to develop their own SDK without using the Python SDK module.

[0110] Step 6: Data reporting

[0111] The complete information of the bound variables or the results of further calculations or analysis must be reported to the user platform or third-party management system or subscribed to by the user platform or third-party management system. This function is completed by the northbound interface module in the Industrial Internet of Things gateway. The northbound interface organizes the synchronized data into a structure according to the protocol requirements and provides a variety of application layer protocols for the user platform or third-party management system to choose from (MQTT, HTTP, HJ212-2017, MODBUS, OPC UA, IEC104, IEC61850).

[0112] The present invention realizes the decoupling of system architecture. Each functional module interacts through MQTT topics, and physical deployment is separated from logical calls. All data exchanges adopt a unified MQTT message format, eliminating the interface protocol differences between modules. New modules only need to subscribe to related topics without modifying the existing system architecture.

[0113] This invention is highly open. In addition to opening up the various sensors, PLCs (programmable logic controllers), and DCS (distributed control system) protocols built into the IIoT gateway, it also opens up the IIoT gateway's hardware interfaces (RS485, RS232, Ethernet), as well as system resources (database, IO input and output control, file operations), system management (factory reset, restart, clock synchronization), and the IIoT gateway's northbound interfaces (MQTT, HTTP, HJ212-2017, MODBUS, OPC UA, IEC104, IEC61850).

[0114] The present invention has high reliability and built-in device offline notification. For example, if a fault occurs during device operation, a dedicated notification module notifies the user of the on-site device abnormality (for example, notification can be completed through the northbound interface module), variable offline notification, alarm notification, latitude and longitude location notification, and the northbound interface module's QOS (message quality of service) supports customization 0, 1, and 2 (Qos 0: message is delivered at most once; Qos 1: message is delivered at least once; Qos 2: message is delivered exactly once); breakpoint resume (in case of network anomalies, data push fails and will be cached locally. The previous data will be resent after recovery).

[0115] This system enables low-code secondary development, with built-in protocol conversion and adaptation. Special device protocols (such as custom and proprietary protocols) can be extended, requiring only protocol integration, seamlessly achieved using the northbound interface of the Industrial IoT gateway. A built-in Python SDK module and Open API interface cater to various user scenarios. Customizable publish and subscribe topics allow for the subscription, processing, and publishing of various messages.

[0116] The present invention has data encryption and security. In multi-protocol data docking, ensuring data security is crucial. The MQTT interface of the Industrial Internet of Things gateway (referring to the northbound interface module) supports the use of SSL / TLS encryption technology to protect data in transmission. Encryption, one-way authentication, and two-way authentication can be selected to confirm that the other party of communication is indeed the expected server, rather than a middleman in disguise.

[0117] The above embodiments are only used to illustrate the technical solutions of the present invention. Those skilled in the art should understand that the above embodiments do not limit the present invention in any form, and any technical solutions obtained by equivalent replacement or equivalent transformation fall within the scope of protection of the present invention.

Claims

1. A secondary development system based on industrial Internet of Things gateway, characterized by: Including clients and industrial IoT gateways; The client sends the device information and variable information of the configured script devices and general protocol devices to the industrial Internet of Things gateway; The industrial Internet of Things gateway includes: An initialization module receives and parses the device information and variable information of the configured script device and universal protocol device; the script device is a device using a private protocol; The physical model module receives the parsing results of the initialization module and generates a physical model, and sends the physical model to the variable module; The secondary development module is started after the object model is initialized; The variable module publishes the object model to the MQTT server through the secondary development module. Specifically, the object model in the variable module, after adding the device static information and variable static information, is sent to the secondary development module. The secondary development module establishes the mapping relationship between all variables in the object model and the service based on the variable type in the object model and the correspondence between the variable type and the service, and obtains the object model with the mapping relationship between variables and services. The object model with the mapping relationship between variables and services is then published to the MQTT server. The real-time data packets sent by the script device received by the industrial Internet of Things gateway are parsed. The real-time data of the script device parsed by the variable module and the real-time data of the general protocol device parsed by the protocol module are bound to the object model in the variable module after adding the device static information and variable static information. The MQTT server is started by the secondary development module and connected to the secondary development module and the Python SDK module respectively; Python SDK module, connects to the MQTT server, and obtains the object model.

2. The secondary development system based on the industrial Internet of Things gateway according to claim 1 is characterized in that: After the variable module is bound, data is reported through the northbound interface module of the industrial Internet of Things gateway.

3. The secondary development system based on the industrial Internet of Things gateway according to claim 1 is characterized in that: The physical model generated by the physical model module is the physical model after adding the static information of the device and the static information of the variable; the parsing result of the initialization module is the static information of the device and the static information of the variable; Physical model initialization refers to the first generation of a physical model by the physical model module after adding device static information and variable static information.

4. The secondary development system based on the industrial Internet of Things gateway according to claim 1 is characterized in that: After receiving the device information and variable information of the configured script device and general protocol device, the initialization module identifies the script flag in the device information, determines whether the device ID is associated with the script flag, stores a list of device IDs associated with the script flag, and sends the list to the secondary development module; When the industrial Internet of Things gateway receives real-time data from a device, the secondary development module determines whether the device ID is in the device ID list associated with the script flag. If it is in the list, it is determined to be real-time data of the script device and the variable module is called for parsing. If it is not in the list, it is determined to be real-time data of a general protocol device and the protocol module is called for parsing.

5. The secondary development system based on the industrial Internet of Things gateway according to claim 1 is characterized in that: The general protocol devices are PLC, DCS and sensors.

6. A secondary development method based on industrial Internet of Things gateway, characterized in that: The secondary development system based on the industrial Internet of Things gateway according to any one of claims 1 to 5 is adopted, and the secondary development method comprises the following steps: Step 1: Configure script devices and general protocol devices; Step 2: Analyze device static information and variable static information and generate physical models; Step 3: Start the secondary development module and MQTT server; Step 4: Publish the object model. Step 5: Real-time data analysis and release; Step 6: Report data.

7. The secondary development method based on the industrial Internet of Things gateway according to claim 6 is characterized in that: Step 1 is as follows: add a script device or a universal protocol device on a local client or a remote client, and add required variables under the script device or the universal protocol device.

8. The secondary development method based on the industrial Internet of Things gateway according to claim 6 is characterized in that: Step 2 is as follows: the initialization module receives the device information and variable information sent by the client and parses them to obtain device static information and variable static information; the device static information and variable static information are placed in the object model module, and then the object model module abstracts the device static information and variable static information in the object model module to obtain a object model with the device static information and variable static information added, and the object model module sends the object model to the variable module; The initialization module further identifies the script flag in the device information, determines whether the device ID is associated with the script flag, stores a list of device IDs associated with the script flag, and sends the list to the secondary development module after the secondary development module is started; Step 3 is as follows: the secondary development module is started after the object model is initialized, and then the MQTT server is started.

9. The secondary development method based on the industrial Internet of Things gateway according to claim 6 is characterized in that: In step 4, the publishing process of the object model is as follows: the secondary development module calls the object model with the device static information and variable static information added to it from the variable module. The secondary development module establishes mapping relationships between all variables in the object model and services based on the variable types in the object model and the correspondence between variable types and services, thereby obtaining a object model with mapping relationships between variables and services established. The correspondence between variable types and services is preset in the secondary development module. The object model with mapping relationships between variables and services established is published to the MQTT server. The Python SDK module in the IIoT gateway connects to the MQTT server and, through topic subscription, obtains the object model published by the IIoT gateway that establishes the mapping relationship between variables and services. The Open API module supports the MQTT protocol, enabling the MQTT server to support subscription / publishing with respect to both the Python SDK module and the secondary development module.

10. The secondary development method based on the industrial Internet of Things gateway according to claim 6 is characterized in that: In step 5, after the real-time data of all variables of the device are obtained by the industrial Internet of Things gateway, the secondary development module identifies the device ID and determines whether the device ID is in the device ID list associated with the script flag. If it is in the list, it is determined to be the real-time data of the script device and the variable module is called for parsing. If it is not in the list, it is determined to be the real-time data of the general protocol device and the protocol module is called for parsing. The variable module parses the real-time data of the script device and binds the parsed real-time data to the physical model in the variable module. At the same time, the protocol module parses the real-time data of the general protocol device and sends the parsed real-time data to the variable module and binds it to the physical model in the variable module. After binding is completed, the variable module calls the method in the calculation module to calculate or analyze the relevant results, and publishes the relevant result data to the MQTT server through the secondary development module and Open API interface, or reports it to a third-party system through the northbound interface module.

Images