Industrial internet of things data collection system

Abstract

The application belongs to the technical field of industrial internet of things, and provides an industrial internet of things data acquisition system, which comprises an application server and a state processing module; a gateway server comprises a northward communication module, a message queue, a southward acquisition module and a database; a string expression after legality verification is generated based on user execution of an online dragging operation, a graphical device state formula is obtained by executing analysis on the string expression by a state rule analysis component, a state data judgment component receives original point data called from the message queue by a state data receiving component, and device state data corresponding to the original point data is determined in combination with the graphical device state formula and reported to the application server. The application can simplify and improve the creation and modification efficiency of the device state formula, solve the problem of using hard coding to determine the device state formula, and realize accurate acquisition of the device state data.

Description

Technical Field

[0001] This invention relates to the field of industrial Internet of Things (IoT) technology, and in particular to an industrial IoT data acquisition system. Background Technology

[0002] Industrial Internet of Things (IIoT) and IIoT data acquisition systems are typically implemented based on an IoT architecture, including a device layer, gateway servers, and application servers. The device layer includes sensors for measuring actual data, actuators for performing corresponding functions, and transceivers for transmitting sensor data and receiving actuator commands. The application server is used for monitoring and managing the entire IoT system; it connects to multiple gateway servers and analyzes the collected and stored data. The gateway server is responsible for communication between the device layer and the application server, as well as data forwarding.

[0003] Industrial Internet of Things (IIoT) data acquisition systems need to collect data on numerous devices at the equipment layer, based on their processes, uses, and types, and the corresponding tags for each state, to form point data. Point data aims to reflect the actual operating status of the equipment in its current state (e.g., running, powered off, standby, faulty), facilitating remote monitoring of multiple devices and centralized monitoring of equipment status on the application server. Directly acquired point data is often relatively simple and raw, and some point data may contain noise, spike signals (e.g., momentary spike signals caused by dust adhering to the surface of photoelectric sensors), and anomalies. Therefore, it is impossible to directly determine the accuracy and reliability of the actual state of the equipment based on point data. Thus, it is necessary to define equipment state formulas. Equipment state formulas, based on mathematical and / or logical rules, translate point data into equipment state data. For example, if a device outputs temperature data, the temperature data can be converted into equipment state data using a device state formula, allowing users to remotely determine whether the equipment is in a normal, abnormal, faulty, or standby state. The aforementioned normal, abnormal, faulty, or standby states constitute the state data. Industrial IoT data acquisition systems need to incorporate device status formulas. These formulas are used to compile location data such as temperature, generating device status data to determine whether the device is functioning correctly. Currently, device status formulas are typically designed using hard-coding.

[0004] Point data includes various types of data such as switch signals, motor operation status, and counting pulse signals. Equipment status data, however, requires users to design a massive number of equipment status formulas based on factors such as the differences in point data, the process flow at the equipment installation site, the differences in controllers used in the same equipment (e.g., whether the motor controller is a Mitsubishi or Panasonic inverter), and even the age of similar equipment. This makes defining equipment status formulas extremely inconvenient. Existing technologies require developing, testing, and deploying each equipment status according to a specific formula. After deployment, comparisons are made, and if the pre-designed equipment status formula is inconsistent with the actual equipment, the code needs to be modified, tested, and deployed again. Therefore, the delivery cycle of hard-coded industrial IoT data acquisition systems is very long, heavily reliant on the programmer's experience, and cannot adapt to the generation and modification of equipment status formulas in extremely complex application scenarios. Furthermore, the state logic, rule deployment, modification, and rule / logic changes included in hard-coded equipment status formulas are hard-coded into the code and the point table (tag list). If any point in the model, manufacturer, or process of a field device changes, resulting in changes to naming conventions, address formats, data types, and units, the only solution is for programmers to recompile, redeploy, and modify the state logic and corresponding code. Furthermore, hard-coded device state formulas require rewriting code during modification and redeployment, which users cannot do themselves. This approach is highly dependent on programmers' experience and coding habits, and suffers from poor flexibility and project reusability. Especially in large industrial or power grid systems, the number of data points can reach tens of billions, making existing hard-coded device state formulas clearly inadequate. The applicant found that Chinese invention patent publication CN117499513A discloses a method for deriving IoT device attributes and a derived calculation formula. The applicant points out that while the aforementioned prior art can be used to calculate device states to some extent, it requires developers with specialized knowledge to manually write formulas. For formulas with complex logical relationships, it is inconvenient and impossible to create, edit, or modify formulas based on experience or memory.

[0005] In view of this, it is necessary to improve the relevant technical solutions of existing industrial Internet of Things (IoT) data acquisition systems to solve the above problems. It should be noted that the above background description is only for the purpose of clearly and completely explaining the technical solutions of this application and facilitating understanding by those skilled in the art. It should not be assumed that these technical solutions are known to those skilled in the art simply because they have been described in the background section of this application. Summary of the Invention

[0006] The purpose of this invention is to disclose an industrial Internet of Things (IoT) data acquisition system to solve some or all of the technical problems mentioned in the background art, and in particular to realize the visual and online configuration of equipment status formulas, avoiding the aforementioned technical problems of equipment status formulas determined by hard coding in the prior art, simplifying the deployment difficulty, and improving the convenience and security of deployment, upgrade and maintenance of industrial IoT data acquisition systems.

[0007] To achieve the above objectives, the present invention provides an industrial Internet of Things (IoT) data acquisition system, comprising: The application server includes at least a locally deployed gateway server and a status processing module; the gateway server includes a northbound communication module, a message queue, a southbound acquisition module, and a database. The state processing module includes: a user configuration client, a state rule parsing component, a state data reporting component, a state data judgment component, and a state data receiving component. The user configuration client is embedded to form a visual operation interface for users to perform visual operations, generating a valid string expression based on the user's online drag-and-drop operation. The state rule parsing component parses the string expression to obtain a graphical device state formula. The state data judgment component receives the original location data retrieved from the message queue by the state data receiving component and determines the device state data corresponding to the original location data by combining it with the graphical device state formula. The state data reporting component then reports the device state data to the application server.

[0008] As a further improvement of the present invention, the state processing module is deployed on the gateway server, or the state processing module is logically deployed independently of the gateway server; The status data judgment component determines the device status data corresponding to the original point data by combining all the states formed by the device with the graphical device status formula.

[0009] As a further improvement of the present invention, the database performs persistent processing on the original point data; The southbound acquisition module consists of several independent data acquisition modules. Each data acquisition module independently acquires the raw location data of the devices in the device layer and reports the raw location data to the message queue based on the southbound communication protocol to form a southbound data stream. The northbound communication module communicates with the application server using the northbound communication protocol to form a northbound data stream; The message queue provides logical isolation between the southbound data stream and the northbound data stream.

[0010] As a further improvement of the present invention, the user configuration client includes: a text editing unit, a graphics editing unit, a legality verification unit, a graphics rendering engine, and a formula processing unit; The text editing unit receives a string expression manually entered by the user; The graphic editing unit is embedded to form a logical editing area for constructing device status formulas by dragging and dropping. After the device status formula is constructed, it requests the legality verification unit to perform legality verification on the device status formula. The legality verification unit is pre-configured with verification logic to perform legality verification of the operation logic based on the verification logic, so as to generate a legality verification result for the graphics rendering engine. The graphics rendering engine executes the logic for generating the graphical expression, processes the validation result output by the validity check, performs graphical rendering on the device state formula, and outputs a graphical expression to respond to the user and / or the graphics editing unit, and the graphics editing unit forwards the graphical expression to the formula processing unit. The formula processing unit converts the graphical expression into a device status formula and returns the device status formula to the graphical editing unit.

[0011] As a further improvement of the present invention, the text editing unit is configured with a device status rule definition interface to add device attributes through the device status rule definition interface. The device attributes include device name, string expression, priority, and glitch threshold. The string expression is defined by variables, constants, and operators.

[0012] As a further improvement of the present invention, the state rule parsing component receives the string expression forwarded by the text editing unit and converts it into data that the graphics editing unit can recognize and render. The state rule parsing component parses the string expression and returns the graphical data to the graphics editing unit. The graphics editing unit forwards the graphical data to the graphics rendering engine to request the graphics rendering engine to render the graphical nodes and the connection relationships between the nodes.

[0013] As a further improvement of the present invention, the state rule parsing component includes: a lexical analysis unit, a lexical construction unit, and a graph data construction unit; The lexical analysis unit is pre-configured with a lexical type configuration table. After the string expression is input into the lexical analysis unit, it outputs a lexical unit array based on the lexical analysis process deployed by the lexical analysis unit and sends it to the lexical construction unit. The lexical construction unit deploys a lexical construction process, which runs a syntax constructor. The syntax constructor takes the lexical unit array as input to generate a lexical binary tree. The graphical data construction unit deploys a graphical data construction process that outputs graphical data. The lexical unit array is defined by both the lexical type and the lexical value.

[0014] As a further improvement of the present invention, the lexical analysis process pre-configures a lexical type configuration table, and the lexical construction process pre-configures lexical priorities; The lexical analysis process splits the lexical types contained in the input string expression according to the lexical type configuration table, and outputs the output lexical unit array. The lexical construction process includes: initializing the operator stack and the syntax tree stack; Based on the lexical priority, determine whether the lexical types contained in the lexical unit array belong to the target lexical type. If so, push them onto the syntax tree stack, and then pop the corresponding number of operands from the syntax tree stack in sequence to construct syntax tree nodes and push them onto the syntax tree stack. The target lexical types include: string type, status type, boolean type, numeric type, or message variable; The lexical precedence rules are as follows: parentheses have higher precedence than functions, functions have higher precedence than unary operators, unary operators have higher precedence than multiplication or division, multiplication or division has higher precedence than addition or subtraction, addition or subtraction has higher precedence than comparison operators, comparison operators have higher precedence than logical operators, and logical operators have higher precedence than assignment operators.

[0015] As a further improvement of the present invention, the graphical data construction process takes the lexical binary tree as input and merges consecutive operators to regenerate the syntax tree. Traverse each node in the syntax tree and assign a unique identifier to each node; Extract the state node and expression node, and use the state node as the root node and the expression node as the child node of the root node; Initialize the graph expression object and append all nodes to the node array to construct the graphical data to be rendered.

[0016] As a further improvement of the present invention, the graphics editing unit uses the graphical data returned by the state rule parsing component as input parameters to perform supplementary node attribute operations by traversing the nodes of the node array. The graphics rendering engine obtains all edge data from the graphics editing unit and adds edge attributes to the edge objects corresponding to the edge data to form edge data; The graphics rendering engine obtains the node array from the graphics editing unit, and sets the rendering content, node style and node connection stubs for all data nodes contained in the node array to form node data; The layouter included in the graphics rendering engine is initialized, the edge data and node data are called, the two-dimensional coordinates of each node are calculated based on the Dagre layering algorithm, and a model object for rendering is output. The model object for rendering is deserialized, and the model object for rendering is rendered to the logical editing area formed by the graphics editing unit, so as to return the graphical expression to the graphics editing unit.

[0017] As a further improvement of the present invention The edge attributes include: the start point of the line, the end point of the line, and line attributes, including the line style, line width, line color, line height, and line offset. The node attributes include: unique identifier, node name, and node type; The node style includes: the node's X coordinate position, the node's Y coordinate position, a unique identifier, the data object associated with the node, the node's shape, the node's height, the node's connection port configuration, the node's HTML content, the width of the border forming the node, the color of the border forming the node, the transparency of the border forming the node, and the rounded corners of the border forming the node. The layoutr included in the initialization of the graphics rendering engine includes: Set the layout type of the layout manager to Dagre, set the layout direction to left to right, set the alignment to top right, set the spacing between hierarchical nodes, and set the spacing between sibling nodes.

[0018] Compared with the prior art, the beneficial effects of the embodiments of the present invention include some or all of the following: First, once the industrial IoT data acquisition system is deployed, no further development or testing is required. Users can generate string expressions through a visual interface provided by the user configuration client, using drag-and-drop operations and multiple validity checks. These expressions are then rendered to generate graphical device status formulas. Therefore, in this invention, users do not need to understand the logical meaning of the string expressions during the generation of device status formulas. This simplifies and improves the ease of visual and online configuration of device status formulas, as well as the understandability of the code logic. It avoids intrusion into the code of the already deployed industrial IoT data acquisition system and prevents unreasonable or erroneous modifications. This improves the flexibility and accuracy of editing and modifying device status formulas, providing users with a user-friendly and easy-to-understand graphical operation method. Secondly, since it is not necessary to hardcode the status logic, rule deployment, modification, and change rules and logic contained in the equipment status formula into the code and point table, when the equipment at any point in the field changes, there is no need to modify the underlying code, modify the non-graphical string expression, and redeploy. Instead, users only need to modify the original equipment status formula in the graphical operation interface for visual operation, and after legality verification, create or modify the graphical equipment status formula. This allows for accurate collection of the actual equipment status data when the equipment at the point changes, thus significantly improving the convenience of deployment, upgrade, and maintenance of the industrial IoT data acquisition system. Attached Figure Description

[0019] Figure 1 This is an overall topology diagram of the industrial Internet of Things (IoT) data acquisition system provided in an embodiment of the present invention; Figure 2 Configure the client's topology for the user; Figure 3 A sequence diagram showing the session between the sub-modules included in the user configuration client provided in this embodiment of the invention and the state rule parsing component; Figure 4 for Figure 3 The sequence diagram is initialized and displayed graphically using existing string expressions; Figure 5 This is a diagram illustrating how the state rule parsing component converts string expressions into graphical editing units for graphical rendering. Figure 6 A schematic diagram of a graphical editing unit for users to create a text editing interface for state rules; Figure 7 A schematic diagram of the visual interface that users can create for the graphical editing unit; Figure 8This is a schematic diagram of the original syntax tree; Figure 9 To Figure 8 A schematic diagram of the syntax tree after performing a second traversal on the original syntax tree. Detailed Implementation

[0020] The present invention will now be described in detail with reference to the embodiments shown in the accompanying drawings. However, it should be noted that these embodiments are not intended to limit the present invention. Equivalent changes or substitutions in function, method, or structure made by those skilled in the art based on these embodiments are all within the scope of protection of the present invention.

[0021] This application discloses specific implementations of an industrial Internet of Things (IoT) data acquisition system (hereinafter referred to as the "data acquisition system" or "system"). The data acquisition system provides users with a visual and convenient way to quickly construct and modify equipment status formulas. It enables users without coding skills to better understand the expressions contained in the equipment status formulas, quickly identify and verify the correctness of syntax rules, reduce system debugging costs and deployment cycles, and perform real-time collection, reporting, summarization, and status analysis of massive amounts of data points generated by equipment at the user's site. This satisfies the need to monitor and summarize the status of equipment (normal, abnormal, shutdown, fault, standby, process normality, sensor normality, etc.) in complex environments.

[0022] In the embodiments of this application, the term "user" is understood to refer to an ordinary user without code editing capabilities, and is distinct from developers with professional knowledge, such as those developing code for data acquisition systems. However, developers can also use the data acquisition system. Meanwhile, due to interference from dust, debris, and other factors in the environment where the equipment is located, the point data generated by the photoelectric sensor (a sub-concept of a type of equipment) may produce momentary spike signals. This can cause the mechanical equipment with the photoelectric sensor installed (e.g., a CNC machining center, also a sub-concept of equipment) to frequently and erroneously switch between "production" and "standby" states, leading the application server 10 to display that the CNC machining center is in an abnormal working state. Therefore, another function of the industrial IoT data acquisition system disclosed in this application is to avoid misjudgments of equipment status by sensors such as photoelectric sensors, ensuring that the current state of the equipment in the equipment layer 30 (e.g., the aforementioned CNC machining center) is not misjudged, thereby achieving more accurate and effective monitoring of the equipment in the equipment layer 30.

[0023] The data acquisition system and point data in each embodiment of this application are all stored on a local server located on the local area network of user 1, eliminating the risk of network attacks and ensuring reliable security. The one or more data acquisition modules a~i included in the southbound acquisition module 250 can be flexibly configured with point configuration information according to different equipment manufacturers (e.g., Panasonic servo drives or Omron servo drives) or different equipment models from the same manufacturer in different usage scenarios, thereby improving the flexibility and adaptability of the data acquisition system in actual use. Furthermore, by deploying the data acquisition system on a local server located on the user's local machine, network data transmission volume and latency are reduced. It also allows for customized compilation for each locally deployed device, enabling the import of custom functions to meet personalized needs for collecting device status data from points formed by locally deployed devices. This avoids the reliance on experience to design device status formulas in existing technologies, thus drastically simplifying the development, testing, deployment, and online deployment process of the industrial IoT data acquisition system for collecting device point data. It completely solves the numerous technical problems inherent in existing technologies where the state logic and rules of device status formulas are hard-coded, and operations such as deployment, modification, and rule / logic changes are fixed in the code and tag list. The logical location of the aforementioned local server is distinct from the logical location of device layer 30 and are logically independent. The aforementioned device refers to the specific object whose specific point data is being collected, including but not limited to a machine in a factory, sensors, drivers, motor counters, and switch quantity detection devices within the machine. Equipment status data includes, but is not limited to, the status data that needs to be monitored and collected during the operation of the equipment, including normal, abnormal, shutdown, fault, and standby states. This data can provide real-time online reminders to users to promptly resolve and eliminate faults.

[0024] As a typical implementation method, combined with Figure 1 and Figure 2As shown, the industrial IoT data acquisition system referred to in this application includes: an application server 10, a gateway server 20 deployed at least locally, and a status processing module 220 deployed on the local server. The gateway server 20 includes: a northbound communication module 210, a message queue 230, a southbound acquisition module 250, and a database 240. The database 240 performs persistent processing on the raw point data. The southbound acquisition module 250 consists of several independent data acquisition modules a~i. Data acquisition modules a~i independently acquire raw point data from devices a~i in the device layer 30 based on southbound communication protocols such as Modbus, S7, and OPCUA, and report the raw point data to the message queue 230 based on the southbound communication protocol to form a southbound data stream. The northbound communication module 210 communicates with the application server 10 using a northbound communication protocol (e.g., MQTT protocol) to form a northbound data stream. The message queue 230 logically isolates the southbound and northbound data streams. The northbound communication module 210 forwards equipment-layer process parameters to the reference server 10 and periodically retrieves raw data from the database 240, organizes data packets, publishes status-related point data to the message queue 230 deployed on the gateway server 20, and directly sends other equipment-layer process parameters such as process parameters and output to the application server 10 via MQTT. Simultaneously, the northbound communication module 210 also supports simple data processing before sending to the message queue 230, specifically including number system conversion, arithmetic operations, basic mathematical operations, and conditional filtering. The status processing module 220 can be deployed on the gateway server 20, or logically independently of the gateway server 20. In the embodiments included in this application, the deployment of the status processing module 220 on the gateway server 20 is used as a typical embodiment for detailed description.

[0025] Application server 10 can be viewed as a terminal device with a user interface 101 (UI), through which user 1 (or administrator) can remotely configure message queue 230. Simultaneously, application server 10 can also be viewed as a logically independent peer device separate from state processing module 220, and in actual deployment scenarios, it can be considered a cloud server or a physical server. State processing module 220 is configured to interact with user 1 and provide access via an API (Application Programming Interface), while gateway server 20 is configured to interact with user 1 and provide access via another API (Application Programming Interface). Furthermore, user 1 can also access application server 10.

[0026] Data acquisition modules a~i load and / or modify the driver and location configuration information of devices a~i in device layer 30. Message queue 230 is logically deployed and runs on a message queue server (not shown), which can be logically independent of database 240. Database 240 is preferably a key-value in-memory database. Alternatively, message queue 230 can also be considered as a component of database 240. Using a key-value in-memory database can fully leverage the advantages of data residing in memory, extremely fast read and write speeds, support for high QPS (Queries Per Second), and distributed scaling, adapting to the actual needs of high-concurrency operations on massive amounts of data in industrial IoT scenarios. Status processing module 220 performs status judgment on the raw location data collected by southbound data acquisition module 250 to forward device status data to application server 10, or processes the output data of northbound communication module 210 to forward the process parameters of device layer 30 to application server 10.

[0027] Specifically, the state processing module 220 includes: a user configuration client 221, a state rule parsing component 222, a state data reporting component 223, a state data judgment component 224, and a state data receiving component 225; the user configuration client 221 is embedded to form a visual operation interface 200 for user 1 to perform visual operations (see...). Figure 7the visual operation interface 200 formed by the graphics editing unit 2212 in , so as to generate a legally verified string expression based on the user 1's online drag-and-drop operation; the state rule parsing component 222 parses the string expression to obtain a graphical device state formula; the state data judgment component 224 receives the original point data called by the state data receiving component 225 from the message queue 230, and determines the device state data of the device corresponding to the original point data in combination with the graphical device state formula, so that the state data reporting component 223 reports the device state data to the application server 10. The aforementioned device state data is the real and correct device state data determined by the graphical device state formula of the device at the current moment, and how to determine the device state data of the device corresponding to the original point data based on the device state formula belongs to the prior art, which will not be repeated in the specification of the present application. The state data judgment component 224 determines the device state data of the device corresponding to the original point data by combining the graphical device state formula for all states formed by the device. It should be noted that one device can have multiple device states, and correspondingly generate multiple device state data. Therefore, different device state formulas need to be designed for each device state data. The data acquisition system in this embodiment can visually create, manage, modify and deploy different device state formulas of different devices and the same device through the state processing module 220, without intruding into the underlying code.

[0028] Refer to Figure 2 as shown, the user configuration client 221 in this embodiment includes: a text editing unit 2211, a graphics editing unit 2212, a legality verification unit 2213, a graphics rendering engine 2214 and a formula processing unit 2215. The text editing unit 2211 is triggered based on the click event of the user 1, and serves as an entry for defining device state rules, which can support adding and managing attributes such as the device state name, string expression, priority, and burr threshold of the device, so as to jump the string expression that a specific device state of a specific device depends on to the logic editing area 203 (i.e., visual editing page) provided by the graphics editing unit 2212, perform operations such as creation, modification, and saving of device state formulas in a visual manner such as drag-and-drop, and perform visual online display to the user 1. The graphics editing unit 2212 interacts with other units / engines / users contained in the user configuration client 221. User 1 clicks on the text editing unit 2211 to jump to Figure 6 the illustrated text editing unit provides a state rule text editing interface for the user, and user 1 clicks on Figure 6 graphical buttons such as "Details", "Edit", "Copy" and "Delete" in the operation bar to execute the logical expression corresponding to the corresponding state name (i.e., corresponding to the underlying string expression), Figure 6 corresponding to the front-end page. Figure 6 The current logical expression can be displayed in the logical expression field, and each line of logical expression corresponds to a different status name in the "Status Name" field. When user 1 clicks the "Edit" button, the system jumps to Figure 7 to enter the online visual drag-and-drop operation page. Figure 6 The logical expressions corresponding to each status name in are not shown.

[0029] as shown in Figure 7 , the graphic editing unit 2212 forms a visual operation interface 200 for user 1 to perform visual operations such as drag-and-drop. Specifically, Figure 7 it comprises an operator logic selection area 201 vertically embedded on the left, an object selection area 202 embedded on the upper side, a logic editing area 203 embedded in the middle, a logic expression display area 204 embedded on the lowermost side, and "Cancel", "Clear", "Restore" and "Save" buttons embedded in the lower right corner. The term "button" in the present application is not a physical button, but an interactive control in software engineering, and clicking the button triggers a corresponding operation event or a certain program; for example, clicking the "Save" button triggers a save event for saving a string expression.

[0030] The operator logic selection area 201 comprises logical operators, such as AND, OR, NOT and other logical operators; comparison operators, such as equal to, not equal to, greater than or equal to, less than or equal to and other comparison operators; arithmetic operators, such as addition, subtraction, multiplication, division, modulo; function operators, such as base conversion, four arithmetic operations and the like. The aforementioned logical operators serve as operators for constructing string expressions.

[0031] The object selection area 202 comprises statuses, points and constants, wherein the points are pre-configured point identifiers, for example, Sta_On_Line_1, Sta_On_Line_2, Sta_Standby, Sta_E_stop and the like. The following Table 1 is an example of device points and point identifiers of an acid adding machine (device identifier: 102000004977) in the device layer 30. The acid adding machine is a specific concept of one type of device in the device layer 30.

[0032]

[0033] Table 1 Select one or more operators from the operator logic selection area 201, and select one or more operands from the object selection area 202. Each operand is treated as an operation object and understood as a node. Nodes are connected. For example, drag an operator (e.g., "+" represents addition), and drag two objects (e.g., A and B) from the object selection area 202. Connect the end node of A to the start node of "+", and the end node of "+" to the end node of B. This visually creates the logical expression A+B. The aforementioned A and B are symbolic abbreviations and are considered arbitrary point identifiers, as detailed in Table 1.

[0034] Meanwhile, the text editing unit 2211 serves as the entry point for defining device status rules, supporting the addition and management of multiple device status names, logical expressions, priorities, glitch thresholds, and other attributes. This embodiment further illustrates the device status rules shown in Table 2 below, using the aforementioned acid-adding machine as an example.

[0035]

[0036] Table 2 The text editing unit 2211 receives a string expression manually input by user 1. The graphics editing unit 2212 embeds a logical editing area 203 for constructing device status formulas via drag-and-drop, and after the device status formula is constructed, requests the validity verification unit 2213 to perform a validity verification on the device status formula. The validity verification unit 2213 pre-configures verification logic to perform operational logic validity verification based on the verification logic, and generates a validity verification result in response to the graphics rendering engine 2214, combined with... Figure 3 As shown, the validity verification unit 2213 performs two validity verifications (i.e., Figure 3 Steps 506 and 517) return the verification results, which are then sent to the graphics rendering engine 2214. The state rule parsing component 222 performs a validity check (i.e., Figure 3In step 523), the graphics rendering engine 2214 executes the logic for generating the graphical expression, processes the validation result output by the validity validation unit 2213, and performs graphical rendering on the device state formula, outputting the graphical expression to respond to user 1 and / or the graphics editing unit 2212. The graphics editing unit 2212 then forwards the graphical expression to the formula processing unit 2215. The formula processing unit 2215 converts the graphical expression into a device state formula and returns the device state formula to the graphics editing unit 2212. The formula processing unit 2215 generates the device state formula, receiving the graphical device state formula determined by the rendered graphical nodes and the connection relationships between nodes forwarded by the graphics rendering engine 2214 via the graphics editing unit 2212. The formula processing unit 2215 also performs graphical data integrity checks, initializes the device state formula, performs topological sorting on the symbols of the device state formula, and finally outputs the graphical device state formula. Finally, the device status formula displayed in the canvas area 2031 of the logic editing area 203 is formed by dragging operators selected from the operator logic selection area 201 and operands selected from the object selection area 202 (both operators and operands are considered operation objects) into the logic editing area 203. This graphically displays a specific logical expression, which has the same meaning and logic as the logical expression displayed in the logical expression display area 204 (i.e., the textual string expression). User 1 completes a graphical editing operation of a logical expression (i.e., in... Figure 7 After completing the construction of the logical expression in the logic editing area 203, click... Figure 7 The "Cancel", "Clear", "Restore" and "Save" buttons are used to create a graphical representation of the device status formula for the logical expression.

[0037] Text editing unit 2211 configures the device status rule definition interface to add device attributes through the device status rule definition interface. Device attributes include device name, string expression, priority, and glitch threshold. Table 3 below shows the device attributes included in different device states, and defines the device attributes.

[0038]

[0039] Table 3 A string expression is defined by variables (e.g., Sta_debug), constants (e.g., 1), and operators (e.g., >). Table 4 below illustrates the definitions of string expressions.

[0040]

[0041] Table 4 Based on Table 4 above, a typical string expression is shown, for example: 1==Sta_debug)&&((Sta_ On_Line_1==1)||(1==Sta_On_Line_2)||(Sta_On_Line_3==1)||(Sta_On_Line_4==1)|| (Sta_On_Line_5==1))&&(0==Sta_E_stop The aforementioned string expression embodies the code logic for device status data, and is implemented through... Figure 5 The state rule parsing component 222 converts the string expression into an instance of graphical rendering executed by the graphical editing unit 2212 to output a graphical device state formula. This eliminates the need to consider or modify the underlying logic of the code contained in the string expression when creating, editing, or modifying the device state formula. Through joint verification by the legality verification unit 2213 and the state data judgment component 224, the device state data ultimately obtained and reported to the application server 10 is accurate and truly reflects the device's actual state at the current point in time. This improves the ability to promptly detect, alert, and resolve anomalies in a device within the device layer 30. It should be noted that the string expression can be considered a logical expression in the front-end page; specific details can be found in the relevant parameters. Figure 6 As shown.

[0042] The validation logic is an operation validity check, which includes user operation validity check, drag-and-drop operation validity check, and connection operation validity check (i.e., Figure 3 Step 506) is the first validity check performed. The specific steps of the check are as follows: Figure 3 As shown.

[0043] The state rule parsing component 222 receives the string expression forwarded by the text editing unit 2211 and converts it into data that the graphics editing unit 2212 can recognize and render. The state rule parsing component 222 parses the string expression and returns the graphical data to the graphics editing unit 2212. The graphics editing unit 2212 forwards the graphical data to the graphics rendering engine 2214 to request the graphics rendering engine 2214 to render the graphical nodes and the connection relationships between the nodes.

[0044] The state rule parsing component 222 includes a lexical analysis unit 11, a lexical construction unit 13, and a graph data construction unit 15. The lexical analysis unit 11 pre-configures a lexical type configuration table 111. After a string expression is input to the lexical analysis unit 11, the lexical analysis process 110 deployed by the lexical analysis unit 11 outputs a lexical unit array 12, which is then sent to the lexical construction unit 13. The lexical construction unit 13 deploys a lexical construction process 130, which runs a syntax constructor. The syntax constructor takes the lexical unit array 12 as input to generate a lexical binary tree 14. The graph data construction unit 15 deploys a graph data construction process 150 that outputs graph data. The lexical unit array 12 is defined by both the lexical type and the lexical value.

[0045] Lexical unit array 12 contains one or more lexical units (Tokens), which serve as the smallest unit for processing or operation in this application's syntax constructor. A typical example of a lexical unit is shown below, using the operator "+" as an example; the lexical unit parameters are shown in the code below.

[0046] LexicalItem { Type: 5 Value: "+" } Lexical analysis process 110 ultimately returns an array of lexical units.

[0047] When the lexical analysis process 110 encounters an error, such as when it encounters an unrecognized character, the lexical analysis process 110 calls the Create Lexical Analysis Error function to generate detailed error information containing the error location, the current character, the content of the previous lexical unit, and the reason for the error, and finally returns the error information and the list of generated lexical units.

[0048] Lexical analysis process 110 pre-configures a lexical type configuration table, and lexical construction process 130 pre-configures lexical priorities. Lexical analysis process 110 splits the lexical types contained in the input string expression according to the lexical type configuration table to output the output lexical unit array 12. For example, the input string expression is: <standby> state = (Sta_Standby == 1) || (1 == Sta_E_stop). The process iterates through the input expression string and, according to internally defined judgment logic, splits the aforementioned string expression into several lexical units, as shown in Table 5.

[0049]

[0050] Table 5 The string expression in the example shown in Table 5 above can be broken down into 13 lexical units, which together form a lexical array. The following code is the final output after lexical analysis.

[0051] LexicalItem[] array { Type: State 3 / / Lexical type Value: Conforms to the <standby> state / / Lexical value }, { Type: Assigned value 7 / / Lexical type Value := / / Lexical value }, { Type: (Parentheses 2) / / Lexical type Value : ( / / Lexical value) }, { Type: Message variable 11 / / Lexical type Value: Sta_Standby / / Lexical value }, { Type: Logical 8 / / Lexical type Value : == / / Lexical value }, { Type: Value 12 / / Lexical type Value: 1 / / Lexical value }, { Type: (Parentheses 2) / / Lexical type Value :) / / Lexical value }, { Type: Logical 8 / / Lexical type Value : || / / Lexical value }, { Type: (Parentheses 2) / / Lexical type Value : ( / / Lexical value) }, { Type: Value 12 / / Lexical type Value: 1 / / Lexical value }, { Type: Logical 8 / / Lexical type Value : == / / Lexical value }, { Type: Message variable 11 / / Lexical type Value: Sta_E_stop / / Lexical value }, { Type: (Parentheses 2) / / Lexical type Value :) / / Lexical value } The lexical construction process 130 includes: initializing the operator stack and the syntax tree stack. Based on lexical precedence, it determines whether the lexical types contained in the lexical unit array 12 belong to the target lexical type. If so, they are pushed onto the syntax tree stack. Then, a corresponding number of operands are popped from the syntax tree stack sequentially to construct syntax tree nodes and push them onto the syntax tree stack. The aforementioned target lexical types include: string, status, boolean, numeric, or message variables. The aforementioned lexical precedence is as follows: parentheses have higher precedence than functions; functions have higher precedence than unary operators; unary operators have higher precedence than multiplication or division; multiplication or division has higher precedence than addition or subtraction; addition or subtraction has higher precedence than comparison operators; comparison operators have higher precedence than logical operators; and logical operators have higher precedence than assignment operators.

[0052] The graphical data construction process 150 takes the lexical binary tree 14 as input and merges consecutive operators to regenerate the syntax tree. The syntax tree takes lexical units as input.

[0053] { Type: State 3 / / Lexical type Value: Conforms to the <standby> state / / Lexical value }, { Type: Assigned value 7 / / Lexical type Value := / / Lexical value }, { Type: (Parentheses 2) / / Lexical type Value : ( / / Lexical value) }, { Type: Message variable 11 / / Lexical type Value: Sta_Standby / / Lexical value }, { Type: Logical 8 / / Lexical type Value : == / / Lexical value }, { Type: Value 12 / / Lexical type Value: 1 / / Lexical value }, { Type: (Parentheses 2) / / Lexical type Value :) / / Lexical value }, { Type: Logical 8 / / Lexical type Value : || / / Lexical value }, { Type: (Parentheses 2) / / Lexical type Value : ( / / Lexical value) }, { Type: Value 12 / / Lexical type Value: 1 / / Lexical value }, { Type: Logical 8 / / Lexical type Value : == / / Lexical value }, { Type: Message variable 11 / / Lexical type Value: Sta_E_stop / / Lexical value }, { Type: (Parentheses 2) / / Lexical type Value :) / / Lexical value } The final output is as follows Figure 8 The original syntax tree is shown. Figure 8 In this context, the traversal order of the original syntax tree is as follows: Later, again Figure 8The original syntax tree shown is traversed twice to complete the construction of the graphical data, constructing the graphical data to be rendered. Figure 8 The syntax tree in the code undergoes a second traversal to remove the "=" nodes, where the "=" nodes correspond to traversal order number ②. The resulting syntax tree after the second traversal has the following traversal order: The aforementioned process is described in detail below.

[0054] Traversal Figure 8 Each node in the syntax tree is uniquely identified. State nodes and expression nodes are extracted, with the state node as the root node and the expression node as a child node of the root node. A graph expression object is initialized, containing an array of nodes and an array of edges. All nodes are appended to the node array (i.e., the `[]Node` array), and the edge data representing the relationships between nodes is appended to the edge array (i.e., the `[]Edge` array) to construct the graphical data to be rendered. The syntax tree corresponding to the graphical data to be rendered... Figure 9 As shown. The aforementioned graph expression object has the same technical meaning as the graphical data returned by the state rule parsing component 222 described below.

[0055] The graphics editing unit 2212 uses the graphical data returned by the state rule parsing component 222 as input parameters to perform supplementary node attribute operations on the node array through node traversal. The graphics rendering engine 2214 obtains all edge data (i.e., the []Edge array) from the graphics editing unit 2212 and adds edge attributes to the edge objects corresponding to the edge data to form edge data. The graphics rendering engine 2214 obtains the node array from the graphics editing unit 2212, sets the rendering content, node style, and node connection stubs for all node data contained in the node array to form the final node data. The layouter contained in the graphics rendering engine 2214 is initialized, and all edge data in the edge array and all node data in the node array are called. The two-dimensional coordinates (X coordinate and Y coordinate) of each node are calculated based on the Dagre layering algorithm to output the model object for rendering. The model object for rendering is deserialized and rendered to the logical editing area 203 formed by the embedding of the graphics editing unit 2212 to return a graphical expression to the graphics editing unit 2212.

[0056] The node attribute structure after the graphics editing unit 2212 performs the supplementary node attribute operation on the node array is as follows: type Graph struct { AllNodes []Node struct { ID string / / Node ID Name Interface{} / / Node name Type string / / Node type SelfID string / / Node's own ID OriginalType string / / Original type of the node Placeholder string / / Input constant node placeholder text Icon string / / Symbol node icon Symbol string / / Symbol node identifier } } Edge attributes include: the line's start point (source), the line's end point (target), and line attributes (attrs). Line attributes include the line's style, width, color, height, and offset. The definitions of edge and line attributes are shown in Table 6 below.

[0057]

[0058] Table Six Node attributes include: unique identifier (id), node name (name), and node type (type). The definitions of node attributes are shown in Table 7 below.

[0059]

[0060] Table 7 Node styles include: the node's X-coordinate position, Y-coordinate position, unique identifier, associated data object, shape, height, connection port configuration, HTML content, width of the node's border, color of the node's border, transparency of the node's border, and rounded corners of the node's border. After setting the node styles as described above, the complete node style attribute structure is as follows: type Graph struct { AllNodes []Node struct { X float64 / / The x-coordinate of the node Y float64 / / The y-coordinate of the node ID string / / Unique identifier for the node Data interface{} / / Data object associated with the node Shape string / / The shape of the node, rendered using HTML. Width int / / Width of the node Height int / / Height of the node Ports interface{} / / Node connection port configuration HTML string / / The HTML content of the node Attrs struct { Body struct { RX float64 / / Corner radius Stroke string / / Border color setting StrokeWidth int / / Set border width } } } } The initialization of the graphics rendering engine 2214 includes the following layout initializer: determining the layout type as Dagre, setting the layout direction to left-to-right, setting the alignment to top-right, setting the spacing between hierarchical nodes (ranksep), and setting the spacing between sibling nodes (nodesep). The code and comments for initializing the layout initializer are shown below: const dagreLayout=new layout.DagreLayout({ type:'dagre', / / Specifies the layout type as dagre rankdir: 'LR', / / Sets the layout direction to left to right. align:'UR', / / Sets the alignment to upper right. ranksep:80, / / Sets the spacing between ranks to 80 pixels nodesep:10 / / Sets the spacing between sibling nodes to 10 pixels }) The returned model object: { nodes:[{...all nodes...}], edges:[{....all edges...}] } Dagre is an open-source JavaScript directed graph layout library. Its core function is to automatically calculate the node coordinates and edge paths of a directed acyclic graph (DAG).

[0061] All computational processes and function logic contained in the aforementioned lexical analysis process 110 to graphical data construction process 150 are executed independently by the state rule parsing component 222, and interact with the user configuration client 221 and the state data judgment component 224 for conversation and data transfer.

[0062] When the industrial IoT data acquisition system collects the location data of devices in device layer 30, the location identifier in the logical expression (i.e., the string expression) is replaced with the corresponding location value in the device status data reported to the application server 10 in message form. Combining the device status rules in Table 2 above with the logical expression determined by the online drag-and-drop method, after replacing the corresponding location value in the device status data with the location identifier in the logical expression, see Table 8 below.

[0063]

[0064] Table 8 As shown in Table 8, after the logical expression for each device state is evaluated, only the logical expression for the running state is evaluated as true. Therefore, the final state result of the reported message (i.e., device state data) is running.

[0065] Applicant combined Figure 3 and Figure 4 The detailed process of the conversation between the sub-modules included in the user configuration client 221 in the industrial Internet of Things data acquisition system and the state rule parsing component 222 is further explained. Figure 3 and Figure 4 Includes steps 501) to 526 below.

[0066] Step 501): User 1 clicks the graphical button to open the graphical editing unit 2212.

[0067] Step 502): Jump to the graphic editing unit 2212 page and pass the string expression in the input box of the text editing unit 2211 to the graphic editing unit 2212.

[0068] Step 503): The graphical editing unit 2212 initializes and displays the existing string expression graphically. The specific process of this step is as follows: Figure 4The entire session procedure from sub-steps 5031) to 5033) is as follows. Sub-step 5031) converts the string expression into data recognizable and renderable by the graphics editing unit 2212, and then forwards it to the state rule parsing component 222. The state rule parsing component 222 then executes sub-step 5032) to parse the string expression and return graphical data (i.e., the graphical device state formula) to the graphics editing unit 2212. Finally, sub-step 5033) is executed, where the graphics editing unit 2212 forwards the aforementioned graphical data to the graphics rendering engine 2214 for front-end rendering to render graphical nodes and the connections between nodes. (See details...) Figure 7 The logical editing area 203 is shown.

[0069] Step 504): User 1 performs drag-and-drop, editing, deletion, and connection operations in the logical editing area 203 of the graphics editing unit 2212 to form... Figure 7 The device status formula displayed in canvas area 2031.

[0070] Step 505): The legality verification unit 2213 monitors operations such as dragging, editing, deleting, and connecting, and the graphic editing unit 2212 requests the legality verification unit 2213 to verify the legality of the aforementioned operations.

[0071] Step 506): The legality verification unit 2213 verifies the legality of operations such as dragging, editing, deleting, and connecting. If yes, proceed to step 507): The legality verification unit 2213 determines the operation is legal and returns Y (i.e., the operation is legal) to the graphics editing unit 2212. If no, the legality verification unit 2213 determines the operation is illegal, returns N (i.e., the operation is illegal), and proceeds to step 510): The operation is deemed incorrect (i.e., illegal), and the error reason is returned and the user 1 is prompted. After the first legality verification is deemed incorrect, proceed to step 510') to respond to the user 1. At this time, when the error is deemed, the graphics editing unit 2212 provides two user options: for the first scenario, step 530) jumps to notify the user 1 so that the user 1 can re-execute step 504); for the second scenario, the graphics editing unit 2212 responds to the text editing unit 2211 to re-execute step 502), so that the string expression manually entered by the user 1 or in Figure 7The visualized operation interface 200 allows users to modify or create new string expressions that conform to the validity verification logic in step 506 via online drag-and-drop. This facilitates the final generation and reporting of device status data that has actual and real meaning to the original point data. Therefore, the industrial IoT data acquisition system disclosed in this embodiment, through this validity verification and the subsequent two validity verifications, ensures that users without professional programming skills can easily test and deploy the system in scenarios such as changes to a device in device layer 30 (e.g., replacing a Mitsubishi PLC with an Omron PLC, or changing the model of a photoelectric sensor from the same manufacturer). This shortens the deployment cycle of the industrial IoT data acquisition system and reduces the difficulty of later maintenance operations.

[0072] Step 508): After the legality verification unit 2213 determines that the operation is legal, the graphics editing unit 2212 requests the graphics rendering engine 2214 to execute the graphical expression rendering, specifically rendering the string expression on the front-end page. The front-end page is embedded in the state processing module 20.

[0073] Step 509): After rendering is complete, the graphics rendering engine 2214 will visualize the obtained graphical expression to user 1.

[0074] Step 511): The graphical editing unit 2212 requests the formula processing unit 2215 to perform graphical processing on the string expression that has passed the first validity check (i.e., meets the validity check logic corresponding to step 506). The graphical processing procedure is as follows: Figure 5 Combined with the above Figure 5 As stated in the instruction manual, it will not be repeated here.

[0075] Step 512): The graphical editing unit 2212 generates a graphical expression based on the graphical expression generation logic, and returns the graphical expression to the graphical editing unit 2212 after execution (step 513). After returning, user 1 can see the graphical expression in the visual operation interface 200 formed by the graphical editing unit 2212. Step 514) is executed so that user 1 can confirm the graphical expression displayed by the graphical editing unit 2212, and user 1 triggers the execution of step 515).

[0076] Step 515): Request verification of all connections and graphical expressions within the current image editing unit 2212, using the verification logic of step 516). In step 516), the validity verification unit 2213 verifies and judges the validity of connections and numerical constant inputs contained in the generated graphical expressions according to validity verification rules, in order to execute the validity verification of step 517). Steps 516) and 517) together constitute the second validity verification, and in a variant example, the aforementioned steps 516) and 517) can be logically merged into a single judgment logic. The validity verification of step 517) is considered the second validity verification. During the execution of step 517), if yes, execute step 518); if no, it proves that the graphical expression verification has failed, and thus jumps to execute step 519) to return N, and notifies the graphics editing unit 2212.

[0077] Step 518): After the second validity check passes (i.e., returns Y), the validity check unit 2213 returns the validity result to the text editing unit 2211 and fills the graphical expression into the text input box (not shown). Since HTML text input boxes are mature existing technology, they will not be described in detail here. After filling, proceed to step 520).

[0078] Step 520): The text editing unit 2211 displays the result of filling the text input box with the graphical expression to user 1, providing user 1 with browsing / modification operations. At this time, as an optional approach, this embodiment provides a third scenario for users with code development experience. User 1 executes step 550) to manually input or modify the string expression corresponding to the graphical expression directly in the text input box embedded in the text editing unit 2211 after needing to modify the aforementioned fill result, thereby re-executing step 502) and subsequent steps in sequence.

[0079] Step 521): After the user confirms that everything is correct, click "Save" and proceed to the next step, 522).

[0080] Step 522): The status rule parsing component 222 configures the verification logic, the text editing unit 2211 requests the status rule parsing component 222 to verify the string expression, and enters the third legality verification referred to in step 523). The verification object requested by the status rule parsing component 222 is the graphical expression corresponding to the second legality verification or the string expression manually entered (including modified) by user 1 online.

[0081] Step 523): The state rule parsing component 222 performs the third validity check. If yes, proceed to step 525; if no, proceed to step 524, return N, prompt an error, and return the error message to the text editing unit 2211.

[0082] Step 525): Persist the string expression to database 240. After persistence is complete, proceed to step 526.

[0083] Step 526): Database 240 displays a visual representation to user 1 through status processing module 220, prompting the user that the string expression has been successfully saved, and then ends.

[0084] In the industrial IoT data acquisition system, the user configuration client 221 and the status processing module 220 convert plain text string expressions into device status formulas and graphically represent them. In one embodiment, the expression string, for example: (1==Sta_debug)&&((Sta_On_Line_1==1)||(1==Sta_On_Line_2)||(Sta_On_Line_3==1)||(Sta_On_Line_4==1)||(Sta_On_Line_5==1))&&(0==Sta_E_stop)"] outputs its corresponding graphical device status formula that conforms to the design logic. Finally, through the graphical device status formula, the device status data of a certain device in the device layer 30 is reported to the application server 10 via the status data receiving component 225, the status data judging component 224, and the status data reporting component 223 to display the current status of the device.

[0085] In summary, the industrial IoT data acquisition system disclosed in the embodiments simplifies deployment difficulty and improves the convenience and security of deployment, upgrade and maintenance of industrial IoT data acquisition systems. It solves many technical problems existing in the prior art that use hard coding. In particular, through the online visualization configuration of graphical device status formulas, it greatly adapts to the modification and editing of device status formulas in usage scenarios where devices in device layer 30 change. In particular, it solves many technical problems existing in the prior art where the state logic, rule deployment, modification, and change rules and logic contained in device status formulas are hard-coded into code and tag lists.

[0086] The detailed descriptions listed above are merely specific descriptions of feasible embodiments of the present invention, and are not intended to limit the scope of protection of the present invention. All equivalent embodiments or modifications made without departing from the spirit of the present invention should be included within the scope of protection of the present invention.

[0087] Furthermore, it should be understood that although this specification describes embodiments, not every embodiment contains only one independent technical solution. This narrative style is merely for clarity. Those skilled in the art should consider the specification as a whole, and the technical solutions in each embodiment can also be appropriately combined to form other embodiments that can be understood by those skilled in the art.

Claims

1. An industrial Internet of Things (IoT) data acquisition system, characterized in that, include: Application server, at least a local gateway server, and state processing module; The gateway server includes: a northbound communication module, a message queue, a southbound acquisition module, and a database; The state processing module includes: a user configuration client, a state rule parsing component, a state data reporting component, a state data judgment component, and a state data receiving component. The user configuration client is embedded to form a visual operation interface for users to perform visual operations, generating a valid string expression based on the user's online drag-and-drop operation. The state rule parsing component parses the string expression to obtain a graphical device state formula. The state data judgment component receives raw location data retrieved from the message queue by the state data receiving component and, in conjunction with the graphical device state formula, determines the device state data corresponding to the raw location data. The state data reporting component then reports the device state data to the application server. The database performs persistent processing on the raw location data. The southbound acquisition module consists of several independent data acquisition modules. Each data acquisition module independently acquires the raw location data of the devices in the device layer and reports the raw location data to the message queue based on the southbound communication protocol to form a southbound data stream. The northbound communication module communicates with the application server using the northbound communication protocol to form a northbound data stream; The message queue provides logical isolation between the southbound data stream and the northbound data stream.

2. The industrial IoT data acquisition system according to claim 1, characterized in that, The status processing module is deployed on the gateway server, or... The state processing module is logically deployed independently of the gateway server; The status data judgment component determines the device status data corresponding to the original point data by combining all the states formed by the device with the graphical device status formula.

3. The industrial IoT data acquisition system according to claim 1 or 2, characterized in that, The user configuration client includes: a text editing unit, a graphics editing unit, a validity verification unit, a graphics rendering engine, and a formula processing unit; The text editing unit receives a string expression manually entered by the user; The graphic editing unit is embedded to form a logical editing area for constructing device status formulas by dragging and dropping. After the device status formula is constructed, it requests the legality verification unit to perform legality verification on the device status formula. The legality verification unit is pre-configured with verification logic to perform legality verification of the operation logic based on the verification logic, so as to generate a legality verification result for the graphics rendering engine. The graphics rendering engine executes the logic for generating the graphical expression, processes the validation result output by the validity check, performs graphical rendering on the device state formula, and outputs a graphical expression to respond to the user and / or the graphics editing unit, and the graphics editing unit forwards the graphical expression to the formula processing unit. The formula processing unit converts the graphical expression into a device status formula and returns the device status formula to the graphical editing unit.

4. The industrial IoT data acquisition system according to claim 3, characterized in that, The text editing unit is configured with a device status rule definition interface to add device attributes through the device status rule definition interface. The device attributes include device name, string expression, priority, and glitch threshold. The string expression is defined by variables, constants, and operators.

5. The industrial IoT data acquisition system according to claim 3, characterized in that, The state rule parsing component receives the string expression forwarded by the text editing unit, converts it into data that the graphics editing unit can recognize and render, parses the string expression, and returns graphical data to the graphics editing unit. The graphics editing unit then forwards the graphical data to the graphics rendering engine to request the graphics rendering engine to render graphical nodes and the connection relationships between nodes.

6. The industrial IoT data acquisition system according to claim 5, characterized in that, The state rule parsing component includes: a lexical analysis unit, a lexical construction unit, and a graph data construction unit; The lexical analysis unit is pre-configured with a lexical type configuration table. After the string expression is input into the lexical analysis unit, it outputs a lexical unit array based on the lexical analysis process deployed by the lexical analysis unit and sends it to the lexical construction unit. The lexical construction unit deploys a lexical construction process, which runs a syntax constructor. The syntax constructor takes the lexical unit array as input to generate a lexical binary tree. The graphical data construction unit deploys a graphical data construction process that outputs graphical data. The lexical unit array is defined by both the lexical type and the lexical value.

7. The industrial IoT data acquisition system according to claim 6, characterized in that, The lexical analysis process pre-configures a lexical type configuration table, and the lexical construction process pre-configures lexical priorities; The lexical analysis process splits the lexical types contained in the input string expression according to the lexical type configuration table, and outputs the output lexical unit array. The lexical construction process includes: initializing the operator stack and the syntax tree stack; Based on the lexical priority, determine whether the lexical types contained in the lexical unit array belong to the target lexical type. If so, push them onto the syntax tree stack, and then pop the corresponding number of operands from the syntax tree stack in sequence to construct syntax tree nodes and push them onto the syntax tree stack. The target lexical types include: string type, status type, boolean type, numeric type, or message variable; The lexical precedence rules are as follows: parentheses have higher precedence than functions, functions have higher precedence than unary operators, unary operators have higher precedence than multiplication or division, multiplication or division has higher precedence than addition or subtraction, addition or subtraction has higher precedence than comparison operators, comparison operators have higher precedence than logical operators, and logical operators have higher precedence than assignment operators.

8. The industrial IoT data acquisition system according to claim 6, characterized in that, The graphical data construction process takes the lexical binary tree as input and merges consecutive operators to regenerate the syntax tree; Traverse each node in the syntax tree and assign a unique identifier to each node; Extract the state node and expression node, and use the state node as the root node and the expression node as the child node of the root node; Initialize the graph expression object and append all nodes to the node array to construct the graphical data to be rendered.

9. The industrial IoT data acquisition system according to claim 8, characterized in that, The graphical editing unit uses the graphical data returned by the state rule parsing component as input parameters to perform supplementary node attribute operations by traversing the nodes of the node array. The graphics rendering engine obtains all edge data from the graphics editing unit and adds edge attributes to the edge objects corresponding to the edge data to form edge data; The graphics rendering engine obtains the node array from the graphics editing unit, and sets the rendering content, node style and node connection stubs for all the node data contained in the node array to form node data; The layouter included in the graphics rendering engine is initialized, the edge data and node data are called, the two-dimensional coordinates of each node are calculated based on the Dagre layering algorithm, and a model object for rendering is output. The model object for rendering is deserialized, and the model object for rendering is rendered to the logical editing area formed by the graphics editing unit, so as to return the graphical expression to the graphics editing unit.

10. The industrial Internet of Things data acquisition system according to claim 9, characterized in that, The edge attributes include: the start point of the line, the end point of the line, and line attributes, including the line style, line width, line color, line height, and line offset. The node attributes include: unique identifier, node name, and node type; The node style includes: the node's X coordinate position, the node's Y coordinate position, a unique identifier, the data object associated with the node, the node's shape, the node's height, the node's connection port configuration, the node's HTML content, the width of the border forming the node, the color of the border forming the node, the transparency of the border forming the node, and the rounded corners of the border forming the node. The layoutr included in the initialization of the graphics rendering engine includes: Set the layout type of the layout manager to Dagre, set the layout direction to left to right, set the alignment to top right, set the spacing between hierarchical nodes, and set the spacing between sibling nodes.

Images