Automated Modeling Method for OPC UA Server of Mining Station-Level Equipment

Abstract

This application relates to an automated OPC UA server modeling method for mining station-level equipment in the field of OPC UA server automated modeling technology. The method includes: environment preparation and platform startup; creating and running OPC UA server nodes; creating and running link protocol nodes; creating groups; creating tags; address space mapping between nodes and groups; address space mapping of tags; plug-and-play device identification and automatic tag creation; automatic mapping of plug-and-play tags; and address space synchronization during dynamic changes. This invention enables automatic synchronization of the OPC UA server address space with device changes, thereby reducing human intervention, improving modeling efficiency and accuracy, ensuring that the address space model truly reflects the on-site equipment organization, and achieving unified modeling and semantic interoperability of heterogeneous equipment.

Description

Technical Field

[0001] This invention relates to the field of automated modeling technology for OPC UA servers, specifically to an automated modeling method for mining station-level equipment that is applied to mining edge computing equipment stations and automatically maps the southbound node label level to the OPC UA server address space. Background Technology

[0002] OPC UA uses its information modeling mechanism to unify the modeling of device data and semantic descriptions, enabling data interconnection and interoperability.

[0003] In the field of smart mine construction, underground equipment is diverse, with varying communication protocols, resulting in a widespread "information silo" problem. Currently, when mine-level equipment operates as an OPC UA server, it often relies on manual modeling: technicians must write code or manually configure address space nodes for each device and sensor node. In this model, a mine may involve hundreds or even thousands of measuring points, leading to a massive modeling workload and a high risk of missing nodes and incorrect hierarchical relationships. When equipment is added, removed, or changed, the existing model is difficult to update dynamically, resulting in high maintenance costs.

[0004] Existing methods for automatically building OPC UA models based on structured data tables involve generating nodes via Excel or databases. However, these methods have limited adaptability to mining edge computing scenarios: mining embedded devices have limited resources, making it difficult to deploy complex modeling tools; and existing methods are typically geared towards offline design scenarios, unable to respond in real time to dynamic changes in device status on the fieldbus. Furthermore, existing solutions are insufficient in preserving the original device hierarchy (such as the hierarchical relationships between nodes, groups, and tags).

[0005] Therefore, how to achieve automated and hierarchical mapping of southbound field device information to the OPC UA server address space, taking into account the resource constraints of embedded devices in mining edge computing stations, is a technical problem to be solved in this field. Summary of the Invention

[0006] The purpose of this invention is to overcome the shortcomings of the prior art and solve the following technical problems: (1) Manual modeling is inefficient and prone to errors: Manual modeling relies on writing code one by one or manually configuring nodes, which leads to long modeling cycles, large workload, and problems such as missing nodes and incorrect hierarchical relationships.

[0007] (2) The model cannot be updated in real time when the equipment changes dynamically: The equipment in the mine will dynamically add or remove sensors as needed for production operations. However, the traditional static modeling method cannot respond to the changes in the status of the fieldbus equipment in real time, resulting in the inconsistency between the model and the actual physical topology.

[0008] (3) Poor adaptability of modeling schemes in edge computing resource-constrained environments: As an embedded device, the mining edge computing station has limited computing power and storage resources, making it difficult to deploy complex modeling tools or run heavy code generation software.

[0009] (4) The model hierarchy is disconnected from the field equipment organization: Existing automated modeling methods are unable to retain the original hierarchical relationship of field equipment “node-group-tag”, which leads to the inability of upper-level applications (monitoring software, etc.) to restore the physical and logical topology of the equipment.

[0010] (5) Inconsistent information models when accessing devices with multiple protocols and brands: In mining scenarios, devices from different manufacturers and with different buses (such as Modbus, CAN, etc.) have different data formats. When accessing the OPC UA server, there is a lack of unified modeling specifications, which leads to problems such as inconsistent data semantics and poor interoperability.

[0011] This invention first utilizes an edge computing software platform to dynamically perceive and automatically map southbound node information, enabling the OPC UA server address space to automatically synchronize with device changes, thereby reducing human intervention and improving modeling efficiency and accuracy. Secondly, during the mapping process, the original hierarchical relationship of "node-group-tag" is explicitly preserved and reconstructed to ensure that the address space model accurately reflects the on-site equipment organization. Simultaneously, through the normalized abstraction of southbound node tags (measurement points) and their mapping with the standard OPC UA information model, unified modeling and semantic interoperability of heterogeneous devices are achieved.

[0012] To address the aforementioned technical problems, this invention provides an automated modeling method for OPC UA servers in mining station-level equipment, comprising the following steps: S1 Environment Preparation and Platform Startup: Start and run the mining edge computing embedded software platform, load the platform configuration file, and initialize the core; S2 Create and run an OPC UA server node: Create an OPC UA server node instance in the edge computing platform, configure various information, start the OPC UA server to put it into normal operation, and append the device's custom URI to the value list of the NamespaceArray node; S3 creates and runs the link protocol node: Based on the device configuration information, it creates a link protocol node instance, initializes the link communication parameters, and starts the link node to put it into normal operation. S4 Create Group: Based on the already created link protocol nodes, create one or more groups according to any of the following methods: Automatically created based on pre-configured group configuration files; Dynamically created based on group creation requests initiated by external systems; Automatically created based on the default grouping rules of the link protocol nodes; Groups are used to logically group tags that have the same data collection cycle, the same processing logic, or the same physical location. S5 Tag Creation: Based on a single group under a link protocol node, create one or more tags according to any of the following methods: Automatically created based on pre-configured tag configuration files; Creates tags dynamically based on tag creation requests initiated by external systems; Automatically created via a plug-and-play mechanism; S6 Node and Group Address Space Mapping: Based on configuration information or external trigger requests, the OPC UA server node subscribes to groups under a specified link protocol node. Leveraging the API features of the embedded lightweight OPC UA server, and according to mapping rules, the following operations are performed for each link protocol node and each group: Map link protocol nodes to object nodes in the OPC UA address space to contain group nodes; Map the group to an object node in the OPC UA address space to contain the tag node; The object nodes generated by the mapping are added to the OPC UA address space via hierarchical references; Address space mapping for tag S7: Iterate through each tag in the group from step S6, and perform the following operations for each tag according to the mapping rules: Map the label to a variable node in the OPC UA address space; Add the variable node to the corresponding group node; Configure the various properties of this variable node; S8 Plug and Play Device Identification and Automatic Tag Creation: If the link protocol supports plug and play functionality, the following operations are automatically triggered when a link protocol node detects a new device access: Parse the data reported by plug-and-play devices; Based on the device information and measurement point information obtained from the protocol parsing, tags are automatically created under the corresponding group, and the tag attributes are automatically filled in according to the measurement point information; If no matching group exists, a new group will be created automatically according to the preset strategy. S9 Plug and Play Automatic Tag Mapping: For tags automatically created in S8, the OPC UA server node automatically triggers the modeling mapping process. Generate variable nodes in the OPC UA address space corresponding to the tags according to the mapping rules; Add the variable node to the corresponding group node; Configure the various properties of this variable node; The address space is dynamically updated without manual intervention or server restart. S10 Address Space Synchronization During Dynamic Changes: Based on external requests or state changes reported by link protocol nodes, when the group or label under the link protocol node undergoes the following changes, the OPC UA address space is automatically synchronized and updated, ensuring the atomicity of address space changes and preventing intermediate states from being exposed to the client: Create a new group, create an object node according to the mapping rules, and add it to the OPC UA address space object node corresponding to the link node; Add a new tag, create a variable node according to the mapping rules, and add it to the OPC UA address space object node corresponding to the tag's group; Delete group, which deletes the OPC UA nodes corresponding to the group and all tags under it; Delete the tag and the corresponding OPC UA variable node; Modify the tag attributes and update the attribute values ​​of the corresponding OPC UA node.

[0013] In order to enable the model to be updated in real time when the device changes dynamically, in step S1, the core is initialized, including the manager, database, log, dynamic loader, adapter, message router, etc.

[0014] To aggregate the OPC UA nodes generated by the mapping of each measurement point and ensure node integrity, in step S2, an object node named after the current OPC UA server node is created under the / Root / Objects node in the address space. This object node is used to aggregate the OPC UA nodes generated by the mapping of each measurement point under the southbound link protocol node subscribed to by the server node. A custom URI is appended, and all custom nodes created in the address space that are related to the device function use the namespace corresponding to this custom URI. The namespace index of all custom nodes created in the address space points to the index value corresponding to the device's custom URI.

[0015] Preferably, in step S3, the fieldbus protocol includes Modbus, CAN, and proprietary protocols.

[0016] In order to address the different data formats of devices from different manufacturers and using different buses (such as Modbus, CAN, etc.) in mining scenarios, in step S3, the link protocol node supports data communication with one or more physical devices that are consistent with the link protocol type. Multiple link node instances of different or the same protocol type can be created at the same time to support the mixed access of heterogeneous bus devices.

[0017] To standardize the modeling process, in step S5, each tag corresponds to a specific measurement point of a physical device. The tag definition includes: tag name, tag address, data type, data precision, read / write attributes, and description information.

[0018] To ensure that the "node-group-label" combination identifier corresponding to any label is unique globally, the edge computing platform adopts a three-level uniqueness definition rule for naming nodes, groups, and labels: Node names are globally unique across the platform; Group names are unique within the same node, but can be repeated between different nodes; Tag names must be unique within the same group, but can be repeated between different groups.

[0019] To ensure the accurate consistency between the OPC UA address space model and the actual physical device topology and data correspondence, and to eliminate human error, the mapping rules between southbound node labels and the OPC UA server address space node model are as follows: NodeId consists of three parts: NamespaceIndex, IdentifierType, and Identifier. The value of Identifier is related to the hierarchical structure of the tag. BrowseName is a combination of the tag name and the tag address; DisplayName can be the label name directly. Description: Directly use the descriptive information from the tag; AccessLevel is formed by mapping the read and write attributes of the tag; DataType is formed by mapping the data type of the tag.

[0020] The present invention has the following beneficial effects: (1) This invention enables the rapid construction of information models for mine station-level equipment, improves modeling efficiency, reduces the input of technical personnel, and lowers the cost of project implementation and maintenance.

[0021] (2) The present invention adopts a programmatically driven mapping mechanism to ensure that the OPC UA address space model is accurate and consistent with the topology and data correspondence of the actual physical device, thus eliminating human error.

[0022] (3) Based on the edge computing platform, the present invention has the ability to perceive southbound node information in real time. When the fieldbus equipment is added, removed, replaced or the measurement point is changed, the OPC UA address space can be automatically updated synchronously without manual intervention or server restart, thereby enhancing the system's adaptability to the dynamic production environment in the mine.

[0023] (4) The present invention explicitly preserves the hierarchical relationship of “node-group-tag”, so that the information model in the OPC UA address space can reflect the topology of the field device.

[0024] (5) This invention normalizes and abstracts the measurement points of equipment from different protocols and manufacturers, and maps them uniformly to a standard OPC UA information model, shielding the differences of underlying equipment and providing a consistent data access interface and semantic description for upper-layer applications, thereby realizing the interconnection and interoperability of heterogeneous mining equipment.

[0025] (6) The present invention adopts a lightweight plug-in mechanism, which can run stably on mining embedded edge computing stations with limited computing power and storage resources, and has good engineering practicality and deployment flexibility. Attached Figure Description

[0026] Figure 1 This is a flowchart of the OPC UA server automated modeling method for mining station-level equipment of the present invention; Figure 2 This is a system block diagram of the automated modeling method for OPC UA server of mining station-level equipment of the present invention; Figure 3 This is a flowchart illustrating the automated modeling method for OPC UA server of mining station-level equipment according to the present invention. Figure 4 This is a schematic diagram illustrating the mapping rules between the southbound node labels and the OPC UA server address space node model of the present invention; Figure 5 This is a schematic diagram illustrating the mapping relationship between the edge computing software platform and the OPC UA address space organization in a specific embodiment of the present invention; Figure 6 This is a diagram of the address space organization structure of the mining edge computing station OPC UA in a specific embodiment of the present invention. Detailed Implementation

[0027] The preferred embodiments of the present invention will now be described in detail with reference to the accompanying drawings, so that the advantages and features of the present invention can be more easily understood by those skilled in the art, thereby providing a clearer and more explicit definition of the scope of protection of the present invention.

[0028] like Figure 1 , Figure 2 The OPC UA server automated modeling method for mining station-level equipment, as shown, includes the following steps: S1 Environment Preparation and Platform Startup; S2 creates and runs an OPC UA server node; S3 creates and runs the link protocol node; S4 creates a group; Create tags with S5; Address space mapping between S6 nodes and groups; Address space mapping of S7 tags; S8 Plug and Play Device Identification and Automatic Tag Creation; S9 plug-and-play automatic tag mapping; Address space synchronization during S10 dynamic changes.

[0029] The following is combined Figure 3 The above-mentioned automated modeling method will be explained in detail.

[0030] S1: Environment Preparation and Platform Startup Start and run the mining edge computing embedded software platform, load the platform configuration file, and initialize the core, including the manager, database, log, dynamic loader, adapter, message router, etc.

[0031] S2: Create and run the OPC UA server node Create an OPC UA server node (northbound node) instance in the edge computing platform, configure the server port, security policy, certificate and other information, start the OPC UA server to enable it to enter normal operation, and append the device's custom URI to the value list of the NamespaceArray node.

[0032] Under the / Root / Objects node in the address space, create an object node named after the current OPC UA server node. This object node is used to aggregate the OPCUA nodes generated by the mapping of various test points under the southbound link protocol nodes subscribed to by the server node. Append a custom URI. All custom nodes created in the address space that are related to device functions use the namespace corresponding to this custom URI. The namespace index of all custom nodes created in the address space points to the index value corresponding to the device's custom URI.

[0033] S3: Create and run the link protocol node The link protocol is consistent with the link protocol of the sensor devices to be connected (temperature sensors, humidity sensors, methane sensors, etc.), and there is no limit to the number of link node instances. Based on the device configuration information or external trigger request (specifying the fieldbus protocol used by the connectable sensors, including but not limited to Modbus, CAN, and proprietary protocols), a corresponding link protocol node instance is created, link communication parameters (such as baud rate, data bits, station address, etc.) are initialized, and the link node is started. Each link protocol node supports data communication with one or more sensors, alarms, or other devices that match the specified link protocol type. There is no limit to the number of link nodes; multiple link node instances of different or the same protocol types can be created simultaneously to support the mixed access of heterogeneous bus devices.

[0034] S4: Create Group Based on the existing link protocol nodes, create one or more groups using any of the following methods: Automatically created based on pre-configured group configuration files (such as XML, JSON format, or database); Dynamically create groups based on group creation requests initiated by external systems, and save them to the group configuration file after successful creation; Automatically create groups based on the default grouping rules of the link protocol nodes (such as by device type or by functional module), and save them to the group configuration file after successful creation.

[0035] Groups are used to logically aggregate tags that have the same data collection cycle, the same processing logic, or the same physical location.

[0036] S5: Create Tags Create one or more tags based on a single group under a link protocol node, using any of the following methods: Automatically created based on pre-configured tag configuration files; The tag is dynamically created based on a tag creation request initiated by an external system. Once created successfully, it is saved to the tag configuration file. Automatically created via a plug-and-play mechanism (see S8-S9), and saved to the tag configuration file upon successful creation.

[0037] Each tag corresponds to a specific measurement point of a physical sensor (such as temperature value, pressure value, or switch status). The tag definition includes: tag name, tag address (addressing information within the protocol), data type, data precision, read / write attributes, and description information.

[0038] S6: Address space mapping between nodes and groups Based on configuration information or external trigger requests, the OPC UA server node subscribes to groups under a specified link protocol node. Leveraging the API features of the embedded lightweight OPC UA server, and according to mapping rules, the following operations are performed for each link protocol node and each group: The link protocol node is mapped to an object node in the OPC UA address space. This object node is used to contain group nodes and records basic information about the nodes (such as plugin name, version, type, and description) through custom attributes.

[0039] The group is mapped to an object node in the OPC UA address space, which is used to contain and aggregate tag nodes.

[0040] The object nodes generated by the mapping are added to the OPC UA address space through hierarchical references, that is, under the OPC UA server node created in step S2, explicitly retaining the three-level hierarchical structure of "protocol node - group - tag".

[0041] S7: Address space mapping of tags Iterate through each label in the group in step S6, and perform the following operations on each label according to the mapping rules: Map the label to a variable node in the OPC UA address space; Add the variable node to the corresponding group node using the HasComponent reference type; Configure the various properties of this variable node (Value, DataType, AccessLevel, Description, etc.).

[0042] S8: Plug and Play Device Identification and Automatic Tag Creation If the link protocol supports plug-and-play functionality, the following operations will be automatically triggered when a link protocol node detects a new device accessing the network: Parse the data reported by plug-and-play devices; Based on the device information and measurement point information obtained from the protocol parsing, tags are automatically created under the corresponding group, and the tag attributes are automatically filled in according to the measurement point information; If no matching group exists, a new group will be created automatically according to a preset strategy (such as by plugin or link port name).

[0043] S9: Plug and play automatic tag mapping For tags automatically created in S8, the OPC UA server node automatically triggers the modeling mapping process: Generate variable nodes in the OPC UA address space corresponding to the tags according to the mapping rules; Add the variable node to the corresponding group node; Configure the various properties of this variable node (Value, DataType, AccessLevel, Description, etc.). The address space is dynamically updated without manual intervention or server restart.

[0044] S10: Address space synchronization during dynamic changes Based on external requests or state changes reported by link protocol nodes, when the group or label under the link protocol node undergoes the following changes, the OPC UA address space is automatically updated synchronously, ensuring the atomicity of address space changes and preventing intermediate states from being exposed to the client: Create a new group, create an object node according to the mapping rules, and add it to the OPC UA address space object node corresponding to the link node; Add a new tag, create a variable node according to the mapping rules, and add it to the OPC UA address space object node corresponding to the tag's group; Delete group, which deletes the OPC UA nodes corresponding to the group and all tags under it; Delete the tag and the corresponding OPC UA variable node; Modify the tag attributes and update the attribute values ​​of the corresponding OPC UA node.

[0045] In the aforementioned automated modeling method, the naming of nodes, groups, and tags in the edge computing platform of mining station-level equipment adopts a three-level uniqueness definition rule: Node names are globally unique across the platform; Group names are unique within the same node, but can be repeated between different nodes; Tag names must be unique within the same group, but can be repeated between different groups.

[0046] This uniqueness definition rule directly determines that the "node-group-label" combination identifier corresponding to any label must be unique globally.

[0047] In the above automated modeling method, the mapping rules between southbound node labels and OPC UA server address space node models are as follows: Figure 4 As shown: (1) NodeId consists of three parts: NamespaceIndex, IdentifierType, and Identifier.

[0048] The value of NamespaceIndex is the sequence number of the custom URI in the OPC UA server node; IdentifierType is a numeric type; the value of Identifier is a 32-bit unsigned integer obtained by hashing the string "node name / group name / tag name".

[0049] (2) BrowseName is formed by combining the label name and the label address.

[0050] (3) DisplayName, use the label name directly.

[0051] (4) Description: Directly use the description information of the tag.

[0052] (5) AccessLevel is formed by mapping the read and write attributes (readable, writable, subscribed) of the tag.

[0053] (6) DataType, which is formed by mapping the data type (type) of the tag.

[0054] The present invention will now be described in detail with reference to the embodiments.

[0055] Taking the scenario of underground environmental monitoring in coal mines as an example. Combined with... Figure 5 , Figure 6 As shown, a mining edge computing station-level device and several environmental monitoring sensors are deployed on-site, including a methane sensor (CH4), a carbon monoxide sensor (CO), and a temperature sensor. The edge computing station has four RS485 bus interfaces: RS485_1, RS485_2, RS485_3, and RS485_4, all of which can be used to connect the sensor devices.

[0056] After the edge computing station is powered on, one OPC UA server node (station) and one private protocol node (rtu1) are created according to the pre-configuration. The station node has a custom URI of "urn:www.cari.com.cn" and an index value of 2 in the NamespaceArray node. The rtu1 node occupies the RS485_1 bus interface, and the protocol itself creates group G1 by default. The rtu1 node creates three tags according to the pre-configuration, with tag names CH4, CO, and Temp; tag addresses 6, 5, and 3; data types UINT16, UINT16, and UINT16; data precisions of 100, 1, and 10; read / write attributes of readable / writable; and description information of "methane concentration", "carbon monoxide concentration", and "temperation" respectively.

[0057] After the station node is running normally, it subscribes to group G1 under the rtu1 node according to the pre-configured subscription. According to the automated modeling rules, the station object node is automatically created under / Root / Objects first, then the rtu1 object node is automatically created under the station object node, the G1 object node is created under this node, and then three variable nodes CH4:6, CO:5 and Temp.:3 are created. Among them, the NodeId of the CH4:6 variable node is “ns=2;i=2576150915”, BrowseName is “CH4:6”, DisplayName is “CH4”, Description is “methane concentration”, AccessLevel is 3, and DataType is “ns=0;i=10”; the NodeId of the CO:5 variable node is “ns=2;i=3510973243”, BrowseName is “CO:5”, DisplayName is “CO”, Description is “carbon monoxide concentration”, AccessLevel is 3, and DataType is “ns=0;i=5”; the NodeId of the Temp.:3 variable node is “ns=2;i=1087006542”, BrowseName is “Temp.:3”, DisplayName is “Temp.”, Description is “temperation”, AccessLevel is 3, and DataType is “ns=0;i=10”.

[0058] During operation, a new temperature sensor with address 4 was connected to the RS485_1 bus interface of the edge computing station. This proprietary protocol supports plug-and-play. When the rtu1 node recognizes the newly connected temperature sensor device (number 4), according to the rule of unique tag names within the same group in the edge computing embedded software platform, since a tag named "Temp." already exists under group G1, the system automatically generates a new tag name "Temp.#4" with the address number as the suffix. After receiving the new tag message, the station node automatically creates the corresponding variable node Temp.:4 under station / rtu1 / G1 in the address space. The NodeId of the Temp.:4 variable node is "ns=2;i=1072010396", BrowseName is "Temp.:4", DisplayName is "Temp.", Description is "temperation", AccessLevel is 3, and DataType is "ns=0;i=10".

[0059] During operation, the edge computing station receives configuration instructions and dynamically creates rtu2 and rtu3 nodes, which occupy the RS485_2 and RS485_3 bus interfaces respectively, running a private protocol. After rtu2 and rtu3 nodes are running normally, they automatically create group G1 by default. At this time, the station node receives a subscription instruction and subscribes to group G1 under rtu2 and rtu3 nodes. After successful subscription, according to the automated modeling rules, object nodes rtu2 and rtu3 are automatically created under the station object node in the address space, and object nodes G1 are created under rtu2 and rtu3 nodes respectively.

[0060] The above are all preferred embodiments of this application, and are not intended to limit the scope of protection of this application. Therefore, all equivalent changes made in accordance with the structure, shape, principle and application direction of this application should be covered within the scope of protection of this application.

Claims

1. An automated modeling method for OPC UA server of mining station-level equipment, characterized in that, Includes the following steps: S1 Environment Preparation and Platform Startup: Start and run the mining edge computing embedded software platform, load the platform configuration file, and initialize the core; S2 Create and run an OPC UA server node: Create an OPC UA server node instance in the edge computing platform, configure various information, start the OPC UA server to put it into normal operation, and append the device's custom URI to the value list of the NamespaceArray node; S3 creates and runs the link protocol node: Based on the device configuration information, it creates a link protocol node instance, initializes the link communication parameters, and starts the link node to put it into normal operation. S4 Create Group: Based on the already created link protocol nodes, create one or more groups according to any of the following methods: Automatically created based on pre-configured group configuration files; Dynamically created based on group creation requests initiated by external systems; Automatically created based on the default grouping rules of the link protocol nodes; Groups are used to logically group tags that have the same data collection cycle, the same processing logic, or the same physical location. S5 Tag Creation: Based on a single group under a link protocol node, create one or more tags according to any of the following methods: Automatically created based on pre-configured tag configuration files; Creates tags dynamically based on tag creation requests initiated by external systems; Automatically created via a plug-and-play mechanism; S6 Node and Group Address Space Mapping: Based on configuration information or external trigger requests, the OPC UA server node subscribes to groups under a specified link protocol node. Leveraging the API features of the embedded lightweight OPC UA server, and according to mapping rules, the following operations are performed for each link protocol node and each group: Map link protocol nodes to object nodes in the OPC UA address space to contain group nodes; Map the group to an object node in the OPC UA address space to contain the tag node; The object nodes generated by the mapping are added to the OPC UA address space via hierarchical references; Address space mapping for tag S7: Iterate through each tag in the group from step S6, and perform the following operations for each tag according to the mapping rules: Map the label to a variable node in the OPC UA address space; Add the variable node to the corresponding group node; Configure the various properties of this variable node; S8 Plug and Play Device Identification and Automatic Tag Creation: If the link protocol supports plug and play functionality, the following operations are automatically triggered when a link protocol node detects a new device access: Parse the data reported by plug-and-play devices; Based on the device information and measurement point information obtained from the protocol parsing, tags are automatically created under the corresponding group, and the tag attributes are automatically filled in according to the measurement point information; If no matching group exists, a new group will be created automatically according to the preset strategy. S9 Plug and Play Tag Auto-Mapping: For tags automatically created in S8, the OPC UA server node automatically triggers the modeling mapping process. Generate variable nodes in the OPC UA address space corresponding to the tags according to the mapping rules; Add the variable node to the corresponding group node; Configure the various properties of this variable node; The address space is dynamically updated without manual intervention or server restart. S10 Address Space Synchronization During Dynamic Changes: Based on external requests or state changes reported by link protocol nodes, when the group or label under the link protocol node undergoes the following changes, the OPC UA address space is automatically synchronized and updated, ensuring the atomicity of address space changes and preventing intermediate states from being exposed to the client: Create a new group, create an object node according to the mapping rules, and add it to the OPC UA address space object node corresponding to the link node; Add a new tag, create a variable node according to the mapping rules, and add it to the OPC UA address space object node corresponding to the tag's group; Delete group, which deletes the OPC UA nodes corresponding to the group and all tags under it; Delete the tag and the corresponding OPC UA variable node; Modify the tag attributes and update the attribute values ​​of the corresponding OPC UA node.

2. The OPC UA server automated modeling method for mining station-level equipment according to claim 1, characterized in that, In step S1, the core initialization includes the manager, database, log, dynamic loader, adapter, and message router.

3. The OPC UA server automated modeling method for mining station-level equipment according to claim 2, characterized in that, In step S2, under the / Root / Objects node in the address space, an object node named after the current OPC UA server node is created to aggregate the OPCUA nodes generated by the mapping of each measurement point under the southbound link protocol node subscribed by the server node; a custom URI is appended, and all custom nodes created in the address space that are related to the device function use the namespace corresponding to the custom URI; the namespace index of all custom nodes created in the address space points to the index value corresponding to the device custom URI.

4. The OPC UA server automated modeling method for mining station-level equipment according to claim 3, characterized in that, In step S3, the fieldbus protocols include Modbus, CAN, and proprietary protocols.

5. The OPC UA server automated modeling method for mining station-level equipment according to claim 4, characterized in that, In step S3, the link protocol node supports data communication with one or more physical devices that are consistent with the link protocol type. Multiple link node instances of different or the same protocol type can be created at the same time to support the mixed access of heterogeneous bus devices.

6. The OPC UA server automated modeling method for mining station-level equipment according to claim 5, characterized in that, In step S5, each tag corresponds to a specific measurement point of a physical device. The tag definition includes: tag name, tag address, data type, data precision, read / write attributes, and description information.

7. The OPC UA server automated modeling method for mining station-level equipment according to any one of claims 1-6, characterized in that, In edge computing platforms, the naming of nodes, groups, and tags adopts a three-level uniqueness definition rule: Node names are globally unique across the platform; Group names are unique within the same node, but can be repeated between different nodes; Tag names must be unique within the same group, but can be repeated between different groups.

8. The OPC UA server automated modeling method for mining station-level equipment according to claim 7, characterized in that, The mapping rules between southbound node labels and OPC UA server address space node models are as follows: NodeId consists of three parts: NamespaceIndex, IdentifierType, and Identifier. The value of Identifier is related to the hierarchical structure of the tag. BrowseName is a combination of the tag name and the tag address; DisplayName can be the label name directly. Description: Directly use the descriptive information from the tag; AccessLevel is formed by mapping the read and write attributes of the tag; DataType is formed by mapping the data type of the tag.

Images