A Method and System for Constructing OPC UA Models Based on Subgraph Matching and Constraint Projection

Abstract

This invention discloses an OPC UA model construction method and system based on subgraph matching and constraint projection. First, the acquired protocol parsing data frame is processed by extracting field attributes and standardizing field names to obtain the field nodes to be matched. Then, an official template graph database is loaded, and multi-dimensional semantic alignment is performed with the field nodes to be matched to complete the candidate field mapping. Next, illegal nodes in the candidate mapping are filtered out according to OPC UA attribute constraints, and a query graph is constructed. Then, attribute constraint subgraph matching is performed in the official template graph database to determine the target template subgraph corresponding to the acquired protocol parsing data frame. Next, projection completion is performed according to the rules in the target template subgraph to generate an intermediate representation. Finally, an OPC UA model and a runtime interface binding table for real-time updating of field equipment data are generated based on the intermediate representation.

Description

Technical Field

[0001] This invention relates to the fields of industrial automation, industrial internet and industrial equipment information modeling technology, and in particular to an OPC UA model construction method and system based on subgraph matching and constraint projection. Background Technology

[0002] With the development of the Industrial Internet and intelligent manufacturing, industrial equipment needs to access upper-level monitoring systems, edge platforms, and data applications through a unified information model. OPC UA, as a commonly used information modeling and interoperability standard in industrial automation, can describe equipment capabilities and operational data through mechanisms such as objects, variables, reference relationships, data types, and access permissions. However, in actual industrial settings, equipment typically accesses via Modbus, Profinet, EtherNet / IP, MQTT, or vendor-specific protocols. Protocol parsing results are often expressed as field key-value pairs, register addresses, interface addresses, or message topics, lacking object structures, variable nodes, and reference relationships that conform to the OPC UA address space specification, making it difficult to directly form a standardized information model.

[0003] Current methods for constructing OPC UA information models largely rely on manual modeling or rule template filling. Manual modeling requires engineers to manually create UAObject, UAVariable, NodeId, DataType, AccessLevel, and reference relationships such as HasComponent and HasProperty based on equipment manuals and protocol point tables. This is labor-intensive and prone to problems such as missing Mandatory nodes, inconsistent data types, and incorrect reference relationships. Automatic mapping methods based solely on field names or semantic similarity struggle to handle field abbreviations, inconsistent naming, missing metadata, and cross-device template differences, and also lack constraints from official NodeSet modeling rules. Therefore, there is an urgent need for an automated OPC UA information model construction method that combines official NodeSet templates, attribute constraint subgraph matching, and Mandatory rule projection completion. Summary of the Invention

[0004] To address the aforementioned technical problems in existing technologies, this invention proposes an OPC UA model construction method and system based on subgraph matching and constraint projection. This method is designed for protocol parsing data frames output by industrial gateways, protocol parsers, or edge acquisition programs, and utilizes official... Template graph database, multidimensional semantic alignment, attribute constraint subgraph matching and Constraint projection completion enables the automatic generation of the OPC UA information model and runtime interface binding table. The specific technical solution is as follows:

[0005] A method for constructing an OPC UA model based on subgraph matching and constraint projection, comprising:

[0006] Step 1: Obtain the protocol parsing data frames output by the industrial gateway, protocol parser, or edge acquisition program;

[0007] Step 2: Extract field attributes and normalize field names from the protocol parsing data frame to obtain a set of field nodes to be matched;

[0008] Step 3: Load by official File pre-parsing construction Template diagram database, serving as a searchable template diagram database;

[0009] Step 4: [Regarding...] The candidate variable nodes in the template graph database are semantically aligned with the field nodes to be matched in multiple dimensions. The comprehensive matching score between the field nodes and the candidate variable nodes is calculated, and a candidate field mapping set is generated.

[0010] Step 5: Based on the OPC UA attribute compatibility constraints, filter out illegal candidate variable nodes in the candidate field mapping set, and construct a query graph based on the filtered candidate field mapping set;

[0011] Step 6: Utilize the query graph in Attribute constraint subgraph matching is performed in the template graph database to determine the target template subgraph corresponding to the protocol parsing data frame;

[0012] Step 7: Based on the target template sub-graph Forced modeling rules to perform projection completion, generating The middle represents;

[0013] Step 8: According to The intermediate representation generates the OPC UA XML information model;

[0014] Step 9: According to The intermediate representation, along with the original field names and source interface address information extracted through field attributes, generates a runtime interface binding table; this runtime interface binding table binds the source interface address to the corresponding generated node. By binding the table through the running interface, the data of the field device can be updated in real time on the server by writing mapping code and setting polling in the OPCUA server code.

[0015] Step 10: During device operation, load the runtime interface binding table and convert subsequent arriving protocol parsing data frames into... The updated table for field values ​​serves as the data update input for the OPC UA XML Information Model runtime service or edge runtime service.

[0016] Furthermore, step 2 specifically includes:

[0017] Step 2.1: Read the protocol parsing data frame The field retrieves key-value pairs containing the original field name and field value.

[0018] Step 2.2: Read the data corresponding to the original field name The field retrieves one or more field metadata, including the field data type, read / write permissions, and project unit, and reads the data corresponding to the original field name. The field allows you to obtain one or more source interface address information from the field register address, interface address, I / O address, or message topic;

[0019] Step 2.3: Perform case normalization, camelCase splitting, underscore normalization, hyphen normalization, number and letter separation, and special character removal on the original field name to obtain the initial normalized field name;

[0020] Step 2.4: Perform abbreviation expansion on the initial normalized field name to obtain the normalized field name;

[0021] Step 2.5: Convert the normalized field names into a set of field terms;

[0022] Step 2.6: Infer or confirm the field data type based on the field value and field metadata; when When the data type is already specified, use that data type; when... When the data type is not specified, the data type can be inferred from the Boolean, integer, floating-point, or string characteristics of the field value.

[0023] Step 2.7: Confirm the read / write permissions and engineering units of the field based on the field metadata; when the read / write permissions or engineering units are not given in the field metadata, set the corresponding attribute to an empty value or a default attribute, and retain the field for subsequent attribute constraint filtering;

[0024] Step 2.8: Extract the first data frame from the protocol parsing data frame. Each original field is encapsulated into a field node to be matched. ; Indicates the first One field node to be matched Indicates the first The original field name of each field. This represents the field name obtained after normalizing the original field name. Indicates the first The set of field terms corresponding to each field Indicates the first The field values ​​corresponding to each field Indicates the first The data type of each field. Indicates the first Read and write permissions for each field, Indicates the first The project unit for each field, Indicates the first The source interface address corresponding to each field;

[0025] Step 2.9: Traverse all the original fields in the protocol parsing data frame, repeat steps 2.1 to 2.8, and generate a set of field nodes to be matched.

[0026] Furthermore, step 4 specifically includes:

[0027] Step 4.1: Construct candidate descriptive text for candidate variable nodes;

[0028] Step 4.2: After name normalization, calculate the edit distance similarity between the field node to be matched and the candidate variable node;

[0029] Step 4.3: Calculate the tokens between the field node to be matched and the candidate variable node. Similarity;

[0030] Step 4.4: Calculate the edit distance similarity. and word elements Similarity The result is a word-based similarity score, calculated using the following formula:

[0031]

[0032] in, Weighting is based on word similarity. Indicates the first One field node to be matched Indicates the first One candidate variable node;

[0033] Step 4.5: Use a semantic encoding model to perform vector encoding on the text describing the field to be matched and the text describing the candidate variables, and calculate the cosine semantic similarity between the two.

[0034] Step 4.6: Calculate the data type constraint function based on data type compatibility. The specific formula is as follows:

[0035]

[0036] in, Indicates the data type of the field node. Indicates the data type of the candidate variable node. This represents the OPC UA numeric data type set. A value of 1 indicates compatibility, and a value of 0 indicates incompatibility;

[0037] Step 4.7: Calculate the attribute constraint items based on engineering unit compatibility, read / write permission compatibility, and data type compatibility. , and And set an attribute conflict penalty item, the specific formula is as follows:

[0038]

[0039] in, , and These represent data type compatibility, read / write permission compatibility, and project unit compatibility, respectively. , , For the corresponding penalty weight;

[0040] Step 4.8: Calculate the overall matching score between the field node to be matched and the candidate variable nodes. The specific formula is as follows:

[0041]

[0042] in, to These are the weighting coefficients for each similarity or compatibility feature. This is a penalty item for attribute conflicts. This is the attribute conflict penalty coefficient;

[0043] Step 4.9: When data types, node types, or reference relationship types are incompatible, set the attribute conflict penalty to a rejection penalty, causing the corresponding candidate variable node to be removed from the candidate field mapping set;

[0044] Step 4.10: Sort the candidate variable nodes according to the comprehensive matching score, and retain the Top-K candidate variable nodes for each field node to be matched, to obtain the candidate field mapping set.

[0045] Furthermore, step 5 specifically includes:

[0046] Step 5.1: Construct an initial query graph based on the candidate field mapping set and field context. Then, based on the data type of the field node to be matched, process the candidate variable nodes. Compatibility filtering;

[0047] Step 5.2: Based on the node category of the field to be matched in the query graph, sort the candidate variable nodes. Compatibility filtering ensures that field variable nodes only map to those in the template diagram. Type node;

[0048] Step 5.3: Based on the relationship type between the field node to be matched and its parent node, perform matching on the candidate variable nodes. or Relationship Compatibility filtering;

[0049] Step 5.4: Perform read / write permissions on candidate variable nodes. and Compatibility filtering;

[0050] Step 5.5: Filter candidate variable nodes based on unit compatibility according to engineering units. When the unit of the field conflicts with the unit of the candidate variable and there is no preset unit conversion relationship, remove the candidate variable node.

[0051] Step 5.6: Filter by the attribute constraints, and apply a rejection penalty or remove candidate variable nodes that only meet the textual or semantic similarity but do not meet the OPC UA modeling attribute constraints;

[0052] Step 5.7: Construct a query graph based on the candidate field mapping set.

[0053] Furthermore, step 6 specifically includes:

[0054] Step 6.1: From The template graph database is loaded with candidate target template graphs, and pre-filtered based on the candidate field mapping scores.

[0055] Step 6.2: Initialize the candidate target node set of the node to be matched in the query graph, so that the node categories and data types are compatible and the matching score is not lower than the candidate score threshold;

[0056] Step 6.3: Perform candidate domain propagation filtering based on the reference relationships between the query graph and the template graph;

[0057] Step 6.4: Select the query graph node with the smallest candidate domain as the current expansion node, and select the target template node according to the candidate mapping matching score from high to low;

[0058] Step 6.5: Construct an injective mapping function from query graph nodes to target template graph nodes, so that different query nodes cannot be mapped to the same target template node;

[0059] Step 6.6: Determine whether the injective mapping function satisfies the structural constraints, such that the edges in the query graph are mapped to edges of the same reference type in the target template graph;

[0060] Step 6.7: If the current mapping does not satisfy the structural constraints, perform backtracking and pruning; if the current mapping satisfies the structural constraints, expand the matching state.

[0061] Step 6.8: When all query graph nodes have been mapped, calculate the template matching score between the query graph and the target template graph under the mapping.

[0062] Step 6.9: Select the template graph with the highest matching score and that satisfies the OPC UA attribute constraints as the target template subgraph, and output the mapping relationship from the original fields to the target variable nodes.

[0063] Furthermore, step 7 specifically includes:

[0064] Step 7.1: Input the target template subgraph and the matched field nodes, and obtain the nodes marked as... The set of nodes;

[0065] Step 7.2: Judge one by one Does the node already exist in the query graph or field mapping results?

[0066] like If a node already exists in the query graph or field mapping results, the existing node mapping will be retained.

[0067] like If the node does not exist in the query graph or field mapping results, then only that node will be included. Nodes are deterministically projected from the target template subgraph to The middle represents;

[0068] Step 7.3: Mark the source of nodes in the IR intermediate representation: Mark the nodes retained by the query graph or field mapping results as... The This indicates that the node was generated from the observation fields in the protocol-parsed data frame; it will be present in the query graph or field mapping results. Node marked as The This indicates that the node is... Constrained projection completion generation;

[0069] Step 7.4: [The text appears to be incomplete and contains several grammatical errors. A more accurate translation would require The node corresponding or Reference relationships are synchronously projected to The intermediate representation forms a satisfying condition. Rules picture.

[0070] Furthermore, step 8 specifically includes:

[0071] Step 8.1: Based on Intermediate representation generation Device instance nodes, and mount the device instance nodes to the OPC UA address space. ;

[0072] Step 8.2: Based on Intermediate representation generation Module nodes, and through Reference relationships will module The node is attached to the device instance node;

[0073] Step 8.3: Based on Intermediate representation generation Variable nodes, and according to The reference type recorded in the middle is through Alternatively, the HasProperty reference relationship can be mounted to the device instance node or module node;

[0074] Step 8.4: For Variable node settings , , , , , , and Quotation;

[0075] Step 8.5: Generate access levels based on variable read / write permissions. When read / write permissions are read-only, and Set to 1; when read / write permissions are set to read / write, and Set to 3;

[0076] Step 8.6: Do not write static variables into the variable nodes when generating the OPC UA XML information model. This ensures that the model file only describes the stable address space structure, and the real-time values ​​of variables are updated during runtime by the runtime interface binding table.

[0077] Step 8.7: Assigning to the generated nodes The It must satisfy the following form: ,in, Represents a node OPC UA node identifier; Indicates to be generated Nodes; Indicates a namespace index; Represents a node A unique integer number in the generative model.

[0078] Furthermore, in step 9, from Extracting node source markers from intermediate representations The variable node is used to obtain its original field name, source interface address, data type, read / write permissions, and project unit. ;from Extracting node source markers from intermediate representations From the variable nodes, obtain their data type, reference relationship, and... And set its source field name and source interface address to empty;

[0079] Each binding record in the runtime interface binding table contains: , indicating the first The OPC UA node identifier corresponding to each binding record; , indicating the first The browsing name of the OPC UA corresponding to each bound record; , indicating the first The standard field identifier corresponding to each bound record; , indicating the first The original field names in the protocol parsing data frame corresponding to each bound record; , indicating the first The source interface address corresponding to each binding record; , indicating the first The data type of the variable node corresponding to each bound record; , indicating the first Read and write permissions for the variable nodes corresponding to each bound record; , indicating the first The node source corresponding to the bound record variable node; the node source includes and , Indicates the first The binding role of the binding record includes the device instance. Module Examples Variable nodes that are bound to runtime data ;

[0080] When the source of the variable node is If the original field name or source interface address exists, set its bound role to... ;

[0081] When the source of the variable node is Furthermore, if the source interface address does not exist, its structural node information is retained, but it is not directly written as a source field binding node as a real-time value.

[0082] Furthermore, during the device operation phase, the runtime interface binding table is loaded, and the bound roles are filtered as follows: And there are variable nodes with original field names or source interface addresses; construct the source field name to OPC UA The hash mapping, and the source interface address to The hash mapping; when subsequent protocol parsing data frames arrive, the corresponding OPC UA is looked up based on the original field name or source interface address. Perform type conversion on field values ​​according to the data type in the runtime interface binding table, including... Integer, floating-point and Type conversion; generation The table updates the field values, where each update record contains... The table contains the type-converted field values ​​and conversion status, and is used as the data update input for the OPC UA runtime service or edge runtime service.

[0083] Beneficial effects: This invention systematically solves the problem of the difficulty in automatically converting industrial protocol parsing data frames into standard OPC UA information models, significantly improving the automation level and standard consistency of industrial equipment information modeling; the designed method is based on official... The template graph database serves as the standard constraint source. Multi-dimensional semantic alignment enables comprehensive matching of field names, semantics, and attribute features. Attribute constraint subgraph matching ensures that the field mapping results satisfy... s、 , OPC UA modeling constraints; secondly, based on The modeling rules perform deterministic constraint projection to complete missing mandatory nodes, avoiding manual omissions and unfounded completions. Finally, by generating an OPC UAXML information model and a runtime interface binding table, the modeling phase and runtime phase are decoupled, improving the efficiency of model generation and on-site data mapping. Attached Figure Description

[0084] Figure 1 This is a flowchart illustrating the overall process of constructing an OPC UA model based on subgraph matching and constraint projection in an embodiment of the present invention.

[0085] Figure 2 This is a block diagram of the overall structure of an OPC UA model construction system based on subgraph matching and constraint projection in an embodiment of the present invention.

[0086] Figure 3 This is the official embodiment of the present invention. Template diagram database construction flowchart;

[0087] Figure 4 This is a flowchart of multidimensional semantic alignment and candidate selection in an embodiment of the present invention;

[0088] Figure 5 This is a flowchart of attribute constraint subgraph matching in an embodiment of the present invention;

[0089] Figure 6 This is an embodiment of the present invention. Flowchart of constrained projection completion;

[0090] Figure 7 This is a flowchart illustrating the process of model generation and runtime binding in an embodiment of the present invention. Detailed Implementation

[0091] To make the objectives, technical solutions, and technical effects of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments.

[0092] like Figure 1 As shown, the present invention provides a method for constructing an OPC UA model based on subgraph matching and constraint projection, comprising the following steps:

[0093] Step 1: Obtain the protocol parsing data frame output by the industrial gateway, protocol parser, or edge acquisition program. The protocol parsing data frame includes at least the device identifier, protocol type, timestamp, field key-value pairs, field metadata, and source interface address information. The specific process is as follows:

[0094] Step 1.1: Receive the output of the industrial gateway, protocol parser, or edge acquisition program. The protocol parses the data frame and represents it as:

[0095] .

[0096] in, Indicates the first The protocol parses the data frame. Indicates the sequence number of the data frame parsed by the protocol. Indicates the first The protocol parses the key-value set of field names and field values ​​in the data frame. Indicates the first The protocol parses a set of field metadata in a data frame. This field metadata includes one or more of the following: field data type, read / write permissions, and engineering units. Indicates the first The protocol parses the device identifier corresponding to the data frame. Indicates the first The protocol type is used to parse the data frame. Indicates the first The protocol parses the data frame's acquisition timestamp. Indicates the first The protocol parses the source interface address information in the data frame;

[0097] Step 1.2: From the above Extract the field names and field values ​​from the... Extract one or more of the following from the field data type, read / write permissions, and project unit: Extract one or more of the following: the field register address, interface address, I / O address, or message topic.

[0098] Step 2: Extract field attributes and normalize field names from the protocol parsing data frame to obtain a set of field nodes to be matched. The specific process is as follows:

[0099] Step 2.1: Read the protocol parsing data frame The field retrieves key-value pairs containing the original field name and field value.

[0100] Step 2.2: Read the data corresponding to the original field name The field retrieves one or more field metadata, including the field data type, read / write permissions, and project unit, and reads the data corresponding to the original field name. The field allows you to obtain one or more source interface address information from the field register address, interface address, I / O address, or message topic;

[0101] Step 2.3: Perform case normalization, camelCase splitting, underscore normalization, hyphen normalization, number and letter separation, and special character removal on the original field name to obtain the initial normalized field name;

[0102] Step 2.4: Perform abbreviation expansion on the initial normalized field name, mapping common industrial abbreviations to standard semantic words. For example, expand tmp or temp to temperature, expand spd to speed, expand prs or press to pressure, and expand pos to position to obtain normalized field names.

[0103] Step 2.5: Convert the normalized field names into a set of field terms, the expression of which is:

[0104]

[0105] in, Indicates the first The set of field terms corresponding to each field This indicates the sequence number of the field in the protocol-parsed data frame. Indicates the first The original field name of each field. This represents the field name normalization function. This indicates a field splitting function. This indicates the function for expanding abbreviations;

[0106] Step 2.6: Infer or confirm the field data type based on the field value and field metadata; when When the data type is already specified, use that data type; when... When the data type is not specified, the data type can be inferred from the Boolean, integer, floating-point, or string characteristics of the field value.

[0107] Step 2.7: Confirm the read / write permissions and engineering units of the field based on the field metadata; when the read / write permissions or engineering units are not given in the field metadata, set the corresponding attribute to an empty value or a default attribute, and retain the field for subsequent attribute constraint filtering;

[0108] Step 2.8: For the first data frame in the protocol parsing data frame... The original field is encapsulated into a field node to be matched. . Indicates the first One field node to be matched Indicates the first The original field name of each field. This represents the field name obtained after normalizing the original field name. Indicates the first The set of field terms corresponding to each field Indicates the first The field values ​​corresponding to each field Indicates the first The data type of each field. Indicates the first Read and write permissions for each field, Indicates the first The project unit for each field, Indicates the first The source interface address corresponding to each field;

[0109] Step 2.9: Traverse all the original fields in the protocol parsing data frame, repeat steps 2.1 to 2.8, and generate a set of field nodes to be matched.

[0110] Step 3: As Figure 3 As shown, loading the official... Template diagram database, the official Template diagram database is composed of official The file is pre-parsed and constructed, including at least object type nodes, object nodes, variable nodes, reference relationships, variable aliases, data types, read / write permissions, and project units. The modeling rules and specific process are as follows:

[0111] Step 3.1: Obtain official The document, the official The file includes one or more standard node sets from DI, Machinery, PADIM, CNC, MachineTool, Robotics, PLCopen, AutoID, Pumps, and MachineVision;

[0112] Step 3.2: Analysis In the document , and Nodes, Extract , , , , , , and One or more node attributes;

[0113] Step 3.3: Resolve the reference relationships between nodes, wherein the reference relationships include at least... , , and One or more reference relationships in the text;

[0114] Step 3.4: Set HasModellingRule to point The variable nodes of the rule are identified as mandatory nodes, and the target template is constructed accordingly. The set of nodes, specifically the formula is as follows:

[0115]

[0116] in, Indicates the first In each OPC UA template Node set, This indicates the sequence number of the OPC UA template in the template graph database. Indicates the first Nodes in a template diagram Indicates the first A set of nodes in a template graph. This indicates the reference relationships in the template diagram. Indicates the first A set of reference relationships in a template graph. This indicates the OPC UA modeling rule reference type. This indicates a mandatory modeling rule;

[0117] Step 3.5: Using object type nodes, object nodes, and variable nodes as graph nodes, ... , , and Using one or more reference relationships as graph edges, construct the first... The directed property graph corresponding to each OPC UA template: . Indicates the first A directed property graph corresponding to each OPC UA template. Indicates the first A set of nodes in a template graph, the set of nodes including object type nodes, object nodes, and variable nodes. express , , , A set of one or more reference relationships in the middle. Indicates the first A set of node attributes in a template graph. Indicates the first A set of edge attributes in a template graph;

[0118] Step 3.6: Configure the directed attribute graph, node attributes, edge attributes, variable aliases, data types, read / write permissions, and engineering units. The tags are written to the offline template database, forming a searchable template index, enabling the device modeling stage to read official templates. The template database completes the loading of candidate templates without requiring repeated scanning of the official template database. document.

[0119] Step 4: As Figure 4 As shown, multi-dimensional semantic alignment is performed between the set of field nodes to be matched and the candidate variable nodes in the template graph database. The comprehensive matching score between the field nodes and the candidate variable nodes is calculated, and a candidate field mapping set is generated. The specific process is as follows:

[0120] Step 4.1: Construct candidate description text for candidate variable nodes in the template graph database. The candidate description text includes device type, object type, module name, variable name, variable alias, variable description, data type, and engineering unit.

[0121] Step 4.2: Calculate the edit distance similarity between the field node to be matched and the candidate variable node. The specific formula is as follows:

[0122]

[0123] in, Indicates edit distance, Indicates the normalized name of the field. The normalized label representing the candidate variable node;

[0124] Step 4.3: Calculate the tokens between the field node to be matched and the candidate variable node. Similarity, the specific formula is as follows:

[0125]

[0126] in, Represents the set of field terms. The set of terms representing candidate variable nodes;

[0127] Step 4.4: Combine edit distance similarity and lexical Jaccard similarity into word-based similarity, using the following formula:

[0128]

[0129] in, Weighting is based on word similarity.

[0130] Step 4.5: Use a semantic encoding model to perform vector encoding on the text describing the field to be matched and the text describing the candidate variables, and calculate the semantic similarity. The specific formula is as follows:

[0131]

[0132] in, This represents a semantic vector representing the text describing the field to be matched. This represents a semantic vector describing the text from which candidate variables are represented. This represents the cosine semantic similarity between the two.

[0133] Step 4.6: Calculate the data type constraint function based on data type compatibility. The specific formula is as follows:

[0134]

[0135] in, Indicates the first One field node to be matched Indicates the first Candidate variable nodes, Indicates the data type of the field node. Indicates the data type of the candidate variable node. This represents the OPC UA numeric data type set. A value of 1 indicates compatibility, and a value of 0 indicates incompatibility;

[0136] Step 4.7: Calculate the attribute constraint items based on engineering unit compatibility, read / write permission compatibility, and data type compatibility. , and And set an attribute conflict penalty item, the specific formula is as follows:

[0137]

[0138] in, , and These represent data type compatibility, read / write permission compatibility, and project unit compatibility, respectively. , , For the corresponding penalty weight;

[0139] Step 4.8: Calculate the overall matching score between the field node to be matched and the candidate variable nodes. The specific formula is as follows:

[0140]

[0141] in, to These are the weighting coefficients for each similarity or compatibility feature. This is a penalty item for attribute conflicts. This is the attribute conflict penalty coefficient; It is the field node to be matched;

[0142] Step 4.9: When data types, node types, or reference relationship types are incompatible, set the attribute conflict penalty to a rejection penalty, causing the corresponding candidate variable node to be removed from the candidate field mapping set;

[0143] Step 4.10: Sort the candidate variable nodes according to the comprehensive matching score, and retain the Top-K candidate variable nodes for each field node to be matched, to obtain the candidate field mapping set. The specific formula is as follows:

[0144]

[0145] in, Represents field nodes The set of Top-K candidate variable nodes, This indicates that the top performers are selected based on their overall matching scores, from highest to lowest. Candidate nodes, This represents the set of candidate variable nodes in the template graph database.

[0146] Step 5: As Figure 4 and Figure 5 As shown, the candidate field mapping set is filtered according to the OPC UA attribute constraints, and fields that do not meet the constraints are removed. , , , Or, for illegal candidate variable nodes with engineering unit compatibility constraints, a query graph is constructed based on the filtered candidate field mapping set. The specific process is as follows:

[0147] Step 5.1: Construct an initial query graph based on the candidate field mapping set, and perform matching on the candidate variable nodes according to the data type of the field nodes to be matched. Compatibility filtering;

[0148] Step 5.2: Based on the node category of the field to be matched in the query graph, sort the candidate variable nodes. Compatibility filtering ensures that field variable nodes only map to those in the template diagram. Type node;

[0149] Step 5.3: Based on the relationship type between the field node to be matched and its parent node, perform matching on the candidate variable nodes. or Relationship Compatibility filtering;

[0150] Step 5.4: Perform read / write permissions on candidate variable nodes. and Compatibility filtering;

[0151] Step 5.5: Filter candidate variable nodes based on unit compatibility according to engineering units. When the unit of the field conflicts with the unit of the candidate variable and there is no preset unit conversion relationship, remove the candidate variable node.

[0152] Step 5.6: Filter by the attribute constraints, and apply a rejection penalty or remove candidate variable nodes that only meet the textual or semantic similarity but do not meet the OPC UA modeling attribute constraints from the candidate field mapping set;

[0153] Step 5.7: Construct a query graph based on the candidate field mapping set: ,in , This indicates a query for a set of graph nodes. This indicates a query for the graph edge set. This represents the set of node attributes and edge attributes in the query graph.

[0154] Step 6: On the official website The template graph database performs attribute constraint subgraph matching to determine the target template subgraph corresponding to the protocol parsing data frame and the mapping relationship between fields and target variable nodes. The specific process is as follows:

[0155] Step 6.1: From the official website The template graph database is loaded with candidate target template graphs, and the candidate target template graphs are pre-filtered based on the candidate field mapping scores.

[0156] Step 6.2: According to , , Initialize the candidate domains of query graph nodes by mapping candidate field scores:

[0157]

[0158] in, Indicates the query node The set of candidate target nodes This indicates the node to be matched in the query graph. This represents a candidate node in the target template graph. and These represent the node categories, This indicates that the two data types are the same or compatible. Indicates the candidate score threshold;

[0159] Step 6.3: Perform candidate domain propagation filtering based on the reference relationship between the query graph and the template graph. The specific formula is as follows:

[0160]

[0161] in, Indicates the first Candidate domain after round propagation Indicates the round of candidate domain propagation. Represents and queries nodes Adjacent query nodes that have a referencing relationship Indicates the relationship with candidate nodes There are candidate target nodes with corresponding reference relationships. This indicates the type of reference relationship in the query graph. This indicates a query for the graph edge set. Represents the set of edges in the template graph;

[0162] Step 6.4: Select the query graph node with the smallest candidate domain as the current expansion node, and select the target template node according to the candidate mapping score from high to low;

[0163] Step 6.5: Construct an injective mapping function from the query graph node to the target template graph node. The specific formula is as follows:

[0164]

[0165] in, This represents an injective mapping function from the query graph node set to the target template graph node set. This indicates a query for a set of graph nodes. Represents the set of nodes in the target template graph. and This indicates a query for any two distinct nodes in the graph. and This represents the corresponding target template graph node, indicating that different query nodes cannot be mapped to the same target template node.

[0166] Step 6.6: Determine whether the injective mapping function satisfies... , and Structural constraints, the specific formulas are as follows:

[0167]

[0168] in, This represents an edge with a reference type in the query graph. This represents the edge in the target template graph after mapping. This indicates the reference type in the query graph. This indicates the reference type in the template graph. The formula means that the edges in the query graph must be mapped to the edges of the same reference type in the target template graph.

[0169] Step 6.7: If the current mapping does not satisfy... , , , or If there are structural constraints, backtracking and pruning are performed; if the current mapping satisfies the structural constraints, the matching state is expanded.

[0170] Step 6.8: When all query graph nodes have been mapped, calculate the template matching score. The specific expression is as follows:

[0171]

[0172] in, This indicates the mapping between the query graph and the target template graph. Template matching score below This represents a query graph. Represents the target template diagram. Indicates the query node The candidate matching score between it and its mapped node. For structural matching weights, This is an indicator function that takes the value 1 when the condition inside the parentheses is true, and 0 otherwise.

[0173] Step 6.9: Select The highest-ranking template graph that satisfies the OPC UA attribute constraints is used as the target template subgraph, and the mapping relationship between the original fields and the target variable nodes is output.

[0174] Step 7: As Figure 6 As shown, according to the target template sub-graph Modeling rules, judging the target template subgraph Check if the node already exists in the query graph or field mapping results; if it already exists, retain the existing node mapping and mark the node source as observation-generated; if it does not exist, only add the node mapping. Deterministic projection of nodes and their corresponding references onto The intermediate representation, and the node source marked as projection completion, generates a result that satisfies... Rules The specific process is as follows:

[0175] Step 7.1: Input the target template subgraph and the matched field nodes, and obtain the nodes marked as... The set of nodes;

[0176] Step 7.2: Judge one by one Does the node already exist in the query graph or field mapping results?

[0177] like If a node already exists in the query graph or field mapping results, the existing node mapping will be retained.

[0178] like If the node does not exist in the query graph or field mapping results, then only that node will be included. Nodes are deterministically projected from the target template subgraph to The middle represents;

[0179] Step 7.3: Mark the source of nodes in the IR intermediate representation, marking nodes retained by the query graph or field mapping results as... The This indicates that the node was generated from the observation fields in the protocol-parsed data frame, and will not exist in the query graph or field mapping results. Node marked as The This indicates that the node is... Constrained projection completion generation;

[0180] Step 7.4: [The text appears to be incomplete and contains several grammatical errors. A more accurate translation would require The node corresponding or Reference relationships are synchronously projected to The intermediate representation forms a satisfying condition. Rules picture.

[0181] Among them, those that need projection completion The set of nodes can be represented as:

[0182]

[0183] in, This indicates that projection completion is required. Node set, For the target template subgraph Node set, This refers to the set of nodes that have already been mapped from the query graph to the target template graph. This represents the set difference operation, i.e., from Remove already mapped nodes;

[0184] Generate based on observed field nodes and constraint projection nodes A set of nodes, expressed as follows:

[0185]

[0186] express The set of nodes in the intermediate representation This represents the set of nodes observed from the data frames parsed by the protocol. Indicates by The set of nodes obtained by constrained projection completion;

[0187] According to the target template subgraph Relationship generation with HasProperty edge set, such that The intermediate representation forms a satisfying condition. Rules picture.

[0188] Step 8: As Figure 7 As shown, according to the The intermediate representation generates an OPC UA XML information model, which includes... Device instance nodes, Module nodes, The process for defining variable nodes and the reference relationships between nodes is as follows:

[0189] Step 8.1: Based on Intermediate representation generation Create a device instance node and mount the device instance node to the ObjectsFolder in the OPC UA address space;

[0190] Step 8.2: Based on Intermediate representation generation Module nodes, and through Reference relationships will module The node is attached to the device instance node;

[0191] Step 8.3: Based on Intermediate representation generation Variable nodes, and according to The reference type recorded in the middle is through Alternatively, the HasProperty reference relationship can be mounted to the device instance node or module node;

[0192] Step 8.4: For Variable node settings , , , , , , and Quotation;

[0193] Step 8.5: Generate access levels based on variable read / write permissions. When read / write permissions are read-only, and Set to 1; when read / write permissions are set to read / write, and Set to 3;

[0194] Step 8.6: Do not write variable nodes when generating the OPC UA XML information model. This ensures that the model file only describes the stable address space structure, and the real-time values ​​of variables are updated during runtime by the runtime interface binding table.

[0195] Step 8.7: Assigning to the generated nodes The It must satisfy the following form: ,in, Represents a node OPC UA node identifier; Indicates to be generated Nodes; Indicates a namespace index; Represents a node A unique integer number in the generative model.

[0196] Step 9: As Figure 7 As shown, according to Intermediate representation, original field name, and source interface address information generate a runtime interface binding table. This runtime interface binding table records the source field name or source interface address and its relation to the OPC UA. The correspondence between them, and the specific process is as follows:

[0197] Step 9.1: From Extracting node source markers from intermediate representations The variable node is used to obtain its original field name, source interface address, data type, read / write permissions, and project unit. ;

[0198] Step 9.2: From Extracting node source markers from intermediate representations From the variable nodes, obtain their data type, reference relationship, and... And set its source field name and source interface address to empty;

[0199] Step 9.3: Generate a runtime interface binding table. Each binding record in the runtime interface binding table is represented as follows:

[0200]

[0201] in, Indicates the first Runtime interface binding record, This indicates the sequence number of the binding record in the runtime interface binding table. Indicates the first The OPC UA node identifier corresponding to each binding record. Indicates the first The OPC UA browsing name corresponding to each binding record. Indicates the first The standard field identifier corresponding to each bound record Indicates the first The original field names in the protocol parsing data frame corresponding to each bound record. Indicates the first The source interface address corresponding to each binding record. Indicates the first The data type of the variable node corresponding to each bound record. Indicates the first The read and write permissions of the variable node corresponding to each bound record. Indicates the first The node source corresponding to the bound record variable node, wherein the node source includes and , Indicates the first The binding roles of the binding record include , and ;

[0202] Step 9.4: When the source of the variable node is If the original field name or source interface address exists, set its bound role to... ;

[0203] Step 9.5: When the source of the variable node is Furthermore, if the source interface address does not exist, its structural node information is retained, but it is not directly written as a source field binding node as a real-time value.

[0204] Step 10: As Figure 7 As shown, during the device operation phase, the runtime interface binding table is loaded, and subsequently arriving protocol parsing data frames are converted into... The updated table for field values ​​serves as the data update input for the OPC UA runtime service or edge runtime service; however, during device operation, multidimensional semantic alignment, template graph matching, and... are not repeatedly performed. The specific process for constraint projection completion is as follows:

[0205] Step 10.1: Load the runtime interface binding table during the device operation phase;

[0206] Step 10.2: Filter and bind characters as And there are variable nodes with original field names or source interface addresses;

[0207] Step 10.3: Construct source field names to OPC UA The hash mapping is defined by the following formula:

[0208]

[0209] in, Indicates the source field name to hash mapping, Indicates the first The original field name in the bound record, Indicates the first The OPC UA node identifier corresponding to each binding record;

[0210] Step 10.4: Construct the source interface address to the OPC UA The hash mapping is expressed as follows:

[0211]

[0212] in, Indicates the source interface address to hash mapping, Indicates the first The source interface address in the binding record. Indicates the first The OPC UA node identifier corresponding to each binding record;

[0213] Step 10.5: When subsequent protocol parsing data frames arrive, look up the corresponding OPC UA based on the original field name or source interface address. ;

[0214] Step 10.6: Perform type conversion on the field values ​​according to the data type in the runtime interface binding table. For the specified type, it converts true, false, 1, and 0 to boolean values; for integer types, it performs integer range checks and integer conversions; for floating-point types, it performs floating-point conversions; for... Type, perform string conversion;

[0215] Step 10.7: Generate The formula for updating the field value in the table is as follows:

[0216]

[0217] in, Indicates the first The protocol parses the data frame corresponding to Update the table to the field values. This represents the OPC UA node identifier of the variable node to be updated. Indicates according to data type For field values Perform type conversion. Indicates the first The state after the field values ​​are transformed. Indicates the first The original field exists in the first Protocol parsing of data frames middle;

[0218] Step 10.8: Output the above. The updated table for field values ​​serves as the data update input for the OPC UA XML information runtime service or edge runtime service.

[0219] Based on the above method, this embodiment also designs an OPC UA model construction system based on subgraph matching and constraint projection, such as... Figure 2 As shown, it includes:

[0220] The protocol parsing data frame input module is used to acquire protocol parsing data frames output by industrial gateways, protocol parsers, or edge acquisition programs.

[0221] The field attribute and source interface address extraction module is used to extract field names, data types, read and write permissions, project units, and source interface addresses.

[0222] official Template graph database building module, used for parsing official Files and build a searchable template graph database;

[0223] Multidimensional semantic alignment module, attribute constraint subgraph matching module and The constraint projection completion module is used to complete field candidate mapping, target template subgraph matching, and... Forced node completion;

[0224] The IR middle section represents the generation module, used to complete... Forced node completion generates an IR diagram;

[0225] The OPC UA XML information model generation module and runtime interface binding table generation module are used to generate standard OPC UA XML information models and source fields or source interface addresses. The binding relationship;

[0226] The UA Model Compiler compliance verification module is used to perform standard toolchain compilation verification on the generated OPC UA XML information model to verify its structural legality, reference integrity, and compilability.

[0227] The above description is merely a preferred embodiment of the present invention and is not intended to limit the invention in any way. Although the implementation process of the present invention has been described in detail above, those skilled in the art can still modify the technical solutions described in the foregoing examples or make equivalent substitutions for some of the technical features. All modifications and equivalent substitutions made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A method for constructing an OPC UA model based on subgraph matching and constraint projection, characterized in that, include: The acquired protocol parsing data frames are processed by extracting field attributes and normalizing field names to obtain a set of field nodes to be matched. Loading by official File pre-parsing construction Template diagram database, serving as a searchable template diagram database; right The candidate variable nodes in the template graph database are semantically aligned with the field nodes to be matched in multiple dimensions. The comprehensive matching score between the field nodes and the candidate variable nodes is calculated, and a candidate field mapping set is generated. Based on the OPC UA attribute compatibility constraints, illegal candidate variable nodes in the candidate field mapping set are filtered out, and a query graph is constructed based on the filtered candidate field mapping set. Using query graphs Attribute constraint subgraph matching is performed in the template graph database to determine the target template subgraph corresponding to the protocol parsing data frame; According to the target template subgraph Forced modeling rules to perform projection completion, generating The intermediate representation is used to generate the OPC UA XML information model and the runtime interface binding table for real-time updates of field equipment data.

2. The OPC UA model construction method based on subgraph matching and constraint projection as described in claim 1, characterized in that, The specific steps for extracting field attributes and standardizing field names in the acquired protocol parsing data frames are as follows: Obtain key-value pairs of raw field names and field values ​​from the protocol parsing data frame; Obtain one or more field metadata, including the field data type, read / write permissions, and engineering unit, corresponding to the original field name; and obtain one or more source interface address information, including the field register address, interface address, I / O address, or message topic, corresponding to the original field name. Perform case normalization, camelCase splitting, underscore normalization, hyphen normalization, number and letter separation, and special character removal on the original field name to obtain the initial normalized field name; The initial normalized field name is expanded by abbreviation to obtain the normalized field name; Convert the normalized field names into a set of field terms; Infer the data type of a field based on its value and metadata; Confirm field read / write permissions and project units based on field metadata; When no read / write permissions or engineering units are specified in the field metadata, the corresponding attribute will be set to an empty value or a default attribute, and the field will be retained for subsequent attribute constraint filtering.

3. The OPC UA model construction method based on subgraph matching and constraint projection as described in claim 1, characterized in that, The multidimensional semantic alignment specifically refers to: Construct candidate descriptive text for candidate variable nodes; calculate the edit distance similarity between the field node to be matched and the candidate variable nodes; Calculate the tokens between the field node to be matched and the candidate variable node. Similarity; Edit distance similarity and word elements Similarity The result is a word-based similarity score, calculated using the following formula: in, Weighting is based on word similarity. Indicates the first One field node to be matched Indicates the first One candidate variable node; A semantic encoding model is used to vectorize the text describing the field to be matched and the text describing the candidate variables, and the cosine semantic similarity between the two is calculated.

4. The OPC UA model construction method based on subgraph matching and constraint projection as described in claim 1, characterized in that, The step of filtering out illegal candidate variable nodes in the candidate field mapping set based on OPC UA attribute compatibility constraints, and constructing a query graph based on the filtered candidate field mapping set, specifically includes: Step 5.1: Construct an initial query graph based on the candidate field mapping set and field context. Then, based on the data type of the field node to be matched, process the candidate variable nodes. Compatibility filtering; Step 5.2: Based on the node category of the field to be matched in the query graph, sort the candidate variable nodes. Compatibility filtering ensures that field variable nodes only map to those in the template diagram. Type node; Step 5.3: Based on the relationship type between the field node to be matched and its parent node, perform matching on the candidate variable nodes. or Relationship Compatibility filtering; Step 5.4: Perform read / write permissions on candidate variable nodes. and Compatibility filtering; Step 5.5: Filter candidate variable nodes based on unit compatibility according to engineering units. When the unit of the field conflicts with the unit of the candidate variable and there is no preset unit conversion relationship, remove the candidate variable node. Step 5.6: Filter by the attribute constraints, and apply a rejection penalty or remove candidate variable nodes that only meet the textual or semantic similarity but do not meet the OPC UA modeling attribute constraints; Step 5.7: Construct a query graph based on the filtered candidate field mapping set.

5. The OPC UA model construction method based on subgraph matching and constraint projection as described in claim 1, characterized in that, The use of query graphs in Performing attribute-constrained subgraph matching in the template graph database to determine the target template subgraph corresponding to the protocol parsing data frame specifically includes: Step 6.1: From The template graph database loads candidate target template graphs and performs pre-filtering based on the candidate field mapping scores; Step 6.2: Initialize the candidate target node set of the node to be matched in the query graph, so that the node categories and data types are compatible and the matching score is not lower than the candidate score threshold; Step 6.3: Perform candidate domain propagation filtering based on the reference relationships between the query graph and the template graph; Step 6.4: Select the query graph node with the smallest candidate domain as the current expansion node, and select the target template node according to the candidate mapping matching score from high to low; Step 6.5: Construct an injective mapping function from query graph nodes to target template graph nodes, so that different query nodes cannot be mapped to the same target template node; Step 6.6: Determine whether the injective mapping function satisfies the structural constraints, such that the edges in the query graph are mapped to edges of the same reference type in the target template graph; Step 6.7: If the current mapping does not satisfy the structural constraints, perform backtracking and pruning; if the current mapping satisfies the structural constraints, expand the matching state. Step 6.8: When all query graph nodes have been mapped, calculate the template matching score between the query graph and the target template graph under the mapping. Step 6.9: Select the template graph with the highest matching score and that satisfies the OPC UA attribute constraints as the target template subgraph, and output the mapping relationship from the original fields to the target variable nodes.

6. The OPC UA model construction method based on subgraph matching and constraint projection as described in claim 1, characterized in that, According to the target template subgraph Forced modeling rules to perform projection completion, generating The intermediate representation specifically includes: Step 7.1: Input the target template subgraph and the matched field nodes, and obtain the nodes marked as... The set of nodes; Step 7.2: Judge one by one Does the node already exist in the query graph or field mapping results? like If a node already exists in the query graph or field mapping results, the existing node mapping will be retained. like If the node does not exist in the query graph or field mapping results, then only that node will be included. Nodes are deterministically projected from the target template subgraph to The middle represents; Step 7.3: For The source of nodes in the intermediate representation is marked: nodes retained by the query graph or field mapping results are marked as... The This indicates that the node was generated from the observation fields in the protocol-parsed data frame; it will be present in the query graph or field mapping results. Node marked as The This indicates that the node is... Constrained projection completion generation; Step 7.4: [The text appears to be incomplete and contains several grammatical errors. A more accurate translation would require The node corresponding or Reference relationships are synchronously projected to The intermediate representation forms a satisfying condition. Rules picture.

7. The OPC UA model construction method based on subgraph matching and constraint projection as described in claim 1, characterized in that, The specific process for generating the OPC UA XML information model includes: Step 8.1: Based on Intermediate representation generation Device instance nodes, and mount the device instance nodes to the OPC UA address space. ; Step 8.2: Based on Intermediate representation generation Module nodes, and through Reference relationships will module The node is attached to the device instance node; Step 8.3: Based on Intermediate representation generation Variable nodes, and according to The reference type recorded in the middle is through Alternatively, the HasProperty reference relationship can be mounted to the device instance node or module node; Step 8.4: For Variable node settings , , , , , , and Quotation; Step 8.5: Generate access levels based on variable read / write permissions. When read / write permissions are read-only, and Set to 1; when read / write permissions are set to read / write, and Set to 3; Step 8.6: Do not write static variables into the variable nodes when generating the OPC UA XML information model. This ensures that the model file only describes the stable address space structure, and the real-time values ​​of variables are updated during runtime by the runtime interface binding table. Step 8.7: Assigning to the generated nodes The It must satisfy the following form: ,in, Represents a node OPC UA node identifier; Indicates to be generated Nodes; Indicates a namespace index; Represents a node A unique integer number in the generative model.

8. The OPC UA model construction method based on subgraph matching and constraint projection as described in claim 7, characterized in that, from Extracting node source markers from intermediate representations The variable node is used to obtain its original field name, source interface address, data type, read / write permissions, and project unit. ; Indicates the OPC UA node identifier; from Extracting node source markers from intermediate representations From the variable nodes, obtain their data type, reference relationship, and... And set its source field name and source interface address to empty; Each binding record in the runtime interface binding table contains: , indicating the first The OPC UA node identifier corresponding to each binding record; , indicating the first The browsing name of the OPC UA corresponding to each bound record; , indicating the first The standard field identifier corresponding to each bound record; , indicating the first The original field names in the protocol parsing data frame corresponding to each bound record; , indicating the first The source interface address corresponding to each binding record; , indicating the first The data type of the variable node corresponding to each bound record; , indicating the first Read and write permissions for the variable nodes corresponding to each bound record; , indicating the first The node source of the corresponding variable node in each bound record; Indicates the first The binding role of the binding record includes the device instance. Module Examples Variable nodes that are bound to runtime data ; When the source of the variable node is If the original field name or source interface address exists, set its bound role to... ; When the source of the variable node is Furthermore, if the source interface address does not exist, its structural node information is retained, but it is not directly written as a source field binding node as a real-time value.

9. The OPC UA model construction method based on subgraph matching and constraint projection as described in claim 8, characterized in that, During the device operation phase, the runtime interface binding table is loaded, and the bound roles are filtered as follows: And there are variable nodes with original field names or source interface addresses; construct the source field name to OPC UA The hash mapping, and the source interface address to Hash mapping; When subsequent protocol parsing data frames arrive, the corresponding OPC UA is looked up based on the original field name or source interface address. Perform type conversion on field values ​​according to the data type in the runtime interface binding table, including... Integer, floating-point and Type conversion; generation The table updates the field values, where each update record contains... The table contains the type-converted field values ​​and conversion status, and is used as the data update input for the OPC UA runtime service or edge runtime service.

10. A system employing the OPC UA model construction method according to any one of claims 1 to 9, characterized in that, include: The protocol parsing data frame input module is used to acquire protocol parsing data frames output by industrial gateways, protocol parsers, or edge acquisition programs. The field attribute and source interface address extraction module is used to extract field names, data types, read and write permissions, project units, and source interface addresses. official Template graph database building module, used for parsing official Files and build a searchable template graph database; Multidimensional semantic alignment module, attribute constraint subgraph matching module and The constraint projection completion module is used to complete field candidate mapping, target template subgraph matching, and... Forced node completion; The OPC UA XML information model generation module and the runtime interface binding table generation module are used to generate standard OPC UA XML information models and source fields or source interface addresses. The binding relationship.

Images