Field device configuration method based on OPC UA and ontology semantic model

Abstract

This invention relates to a field device configuration method based on OPC UA and an ontology semantic model, belonging to the field of Industrial Internet of Things (IIoT). The method includes: S1: An OPC UA combination server performs OPC UA information modeling on the field devices based on input device information; S2: A field device configuration module extracts field device configuration information and information from the address space of the OPC UA model to generate a corresponding information ontology; a PLC program supporting the IEC 61131-3 standard is converted into an executable skill model to form a functional ontology; S3: The field device configuration module accesses data in the OPC UA address space using a custom attribute function SPARQL; S4: The field device configuration module generates an XML-formatted configuration file according to the required configuration information, accesses the external information interface of the OPC UA server, and distributes the configuration information; S5: The field device configuration module distributes the configuration file to the field devices to complete control.

Description

Technical Field

[0001] This invention belongs to the field of industrial Internet of Things and relates to a field device configuration method based on OPC UA and ontology semantic model. Background Technology

[0002] In a smart factory, there are numerous field devices that acquire and control large amounts of digital and analog data, such as motor start / stop control, valve opening / closing control, and the acquisition of temperature, pressure, and flow information from various data sources. Field devices mainly include Programmable Logic Controllers (PLCs) and field I / O devices. PLCs, with their excellent programmability, reliability, real-time performance, and efficient analog and digital signal processing capabilities, are widely used in field device control. Field I / O devices primarily refer to sensors used for signal acquisition and actuators used to implement control functions. With the development of computer technology, automatic control technology, and communication technology, the field of industrial control has undergone tremendous changes. Industrial cloud platforms have become a research hotspot. However, due to the relatively closed architecture of field devices, the incompatibility of hardware systems, and the differences in programming languages ​​and instruction systems, network connectivity and information exchange are difficult, resulting in low integration efficiency of devices to the cloud. This cannot meet the social development needs of industrial internet cloud platforms. There is an urgent need to establish a unified information model for commonly used signal acquisition and control devices in the field to improve the integration efficiency of field devices to the cloud. This would enable different types of field devices to connect with the device model, obtain basic information and real-time data, complete device interconnection, and realize the functional configuration of the entire system.

[0003] In terms of field device information modeling and configuration, the OPC UA information modeling method is currently the main approach. D. Nguyen proposed an OPC UA Pub / Sub implementation method for memory-constrained sensor devices (see: D. Nguyen, P. Bellott and P.-Y. Petton, "An OPC UA PubSub Implementation Approach for Memory-Constrained Sensor Devices," 2022 IEEE 31st International Symposium on Industrial Electronics (ISIE), Anchorage, AK, USA, 2022, pp. 999-1005, doi:10.1109 / ISIE51582.2022.9831548.). This method simplifies the information model at the data publishing end or removes message layer security, and uses a remote OPC UA server as a configurator to implement publishing and subscription. However, this research requires configuration of intermediate routes in the Pub / Sub agentless mode and does not have a performance advantage in terms of real-time performance. SG Mathias et al. proposed a multi-database monitoring framework based on OPC UA (see reference: Mathias SG, Schmied S., Grossmann D. A framework for monitoring multiple databases in industries using OPC UA[J]. Journal of Ambient Intelligence and Humanized Computing, 2021, 12(1):47-56.). This framework is implemented based on the OPC UA server aggregation mechanism and database technology. Its advantage is that clients can remotely access database metadata through the aggregated address space, and another client connected to this metadata can access other database information. However, it also has drawbacks such as high access latency, duplicate aggregated nodes, and incorrect node reference relationships. A custom network controller is used to flexibly control and manage the networking of sensor nodes, and management and configuration are achieved by distributing flow tables.OPC UA can establish a unified information model for intelligent production line equipment (see: A. Chai, Y. Ma, Z. Yin and M. Li, "Real-Time Communication Model Based on OPC UA Wireless Network for Intelligent Production Line," in IEEE Access, vol. 9, pp. 102312-102326, 2021, doi:10.1109 / ACCESS.2021.3097399.), improving network connectivity and providing a standard for communication data exchange between intelligent production line equipment. However, it does not address research on methods for configuring field devices using OPC UA. Currently, middleware is mainly used for field device configuration. J. Gampig et al. introduced the concept of Asset Administration Shells (AAS) and proposed using different AASs to achieve program interaction between devices (see: J. Gampig, T.). and K. Dorofeev, "PLC Integration into Industry 4.0 Middleware: Function Block Library for the Interaction with REST and OPC UA Asset Administration Shells," 2021 26th IEEE International Conference on Emerging Technologies and Factory Automation (ETFA), Vasteras, Sweden, 2021, pp. 1-8, doi:10.1109 / ETFA45728.2021.9613267.), proposed using the PLC's runtime system as middleware to directly interact with different AASs and registries to achieve interoperability between devices. A. Zielstorff et al. proposed an AAS-based framework (see: A. Zielstorff, D. A. T. S. (and F. Schnicke, "Overcoming Challenges in Integrating Legacy Devices with Asset Administration Shells - An OPC UA Case Study," 2023 IEEE 28th International Conference on Emerging Technologies and Factory Automation (ETFA), Sinaia, Romania, 2023, pp. 1-8, doi:10.1109 / ETFA54631.2023.10275536.), which utilizes the BaSyx data bridge to support different communication protocols and achieve data configuration. However, the AAS is related to all system information of the field device's production environment, including management data, runtime, etc., making the AAS have a complex structure and making interaction with the PLC program difficult. This patent innovatively proposes a configuration method based on OPC UA and ontology semantic model. By combining OPC UA and ontology semantic model, the field device is endowed with semantics that the computer can understand, providing a foundation for the configuration of the field device.

[0004] Regarding the interaction of software information in the configuration of field equipment, Yameng An et al. designed an ontology-based semantic model called OntoPLC, which combines the characteristics of ontology. This model enables PLC equipment project files to be automatically ported between different development environments (see reference: Y.An, F.Qin, B.Chen, R.Simon and H.Wu, "OntoPLC: Semantic Model of PLC Programs for Code Exchange and Software Reuse," in IEEE Transactions on Industrial Informatics, vol.17, no.3, pp.1702-1711, March 2021, doi:10.1109 / TII.2020.2997360.). By providing a unified formal description of the semantics in PLC equipment programs that support the IEC 61131-3 standard, heterogeneous information interaction is achieved at the semantic level. However, the PLC code library of this software ontology model is currently incomplete and the method is complex. Fischer, B., employed a variant management method combining variable models and database assistance to address the documentation and planned reuse issues of legacy control software (see: Fischer, B. Vogel-Heuser, EEEstévez and M. Male, "VarApp: Variant Management App for IEC 61131-3 Compliant Legacy Software," 2020 IEEE Conference on Industrial Cyberphysical Systems (ICPS), Tampere, Finland, 2020, pp. 269-276, doi:10.1109 / ICPS48405.2020.9274774.). This research converts software variants into PLCopen XML format, thereby enabling the documentation, configuration, and generation of control software based on IEC 61131-3. However, this paper primarily focuses on building variable models for machine production lines, and the variant documentation uses manual model building, which is labor-intensive, error-prone, and difficult to migrate to model building for different PLC devices, lacking universality.A. Peitz, P. used OPC UA to perform modular semantic modeling of automated tape placement machines and their components. Device configuration was achieved through predefined object and variable instances in the OPC UA address space (see: A. Peitz, P. Striet, M. Emonts, K. Fischer and C. Brecher, "Design of a semantic information model for automated tape placement systems using OPC-UA," 2021 26th IEEE International Conference on Emerging Technologies and Factory Automation (ETFA), Vasteras, Sweden, 2021, pp. 1-8, doi:10.1109 / ETFA45728.2021.9613216.). However, in this paper, objects, variables, and methods are created using custom types and predefined forms. When components need to be added or removed from the machine, or when object attributes change, the entire OPC UA server needs to be redesigned, resulting in low configuration flexibility. Summary of the Invention

[0005] In view of this, the purpose of this invention is to provide a field device configuration method based on OPC UA and ontology semantic model.

[0006] To achieve the above objectives, the present invention provides the following technical solution:

[0007] A field device configuration method based on OPC UA and ontology semantic model includes the following steps:

[0008] S1: The OPC UA combination server performs OPC UA information modeling on the field devices based on the input device information, enabling the field devices to complete communication and data transmission between the field I / O devices and the PLC devices based on a unique ID;

[0009] S2: The field device configuration module extracts field device configuration information and information from the address space of the OPC UA model to generate the corresponding information ontology; it converts PLC programs that support the IEC 61131-3 standard into executable skill models to form functional ontology.

[0010] S3: The field device configuration module accesses data in the OPC UA address space using the custom attribute function SPARQL to enable interaction between the device body and the configuration data;

[0011] S4: The field device configuration module generates an XML-formatted configuration file based on the required configuration information, and distributes the configuration information by accessing the external information interface of the OPC UA server;

[0012] S5: The field device configuration module sends the configuration file of the field device to the field device to complete the corresponding control function.

[0013] Furthermore, in step S1, the OPC UA combined server performs OPC UA information modeling on the field devices based on the input device information, specifically including:

[0014] Field I / O device information modeling includes a static attribute set and a dynamic attribute set; the static attribute set includes basic information about the field I / O devices; the dynamic attribute set includes the current status information of the field I / O devices.

[0015] PLC Equipment Information Modeling: An OPC UA server is embedded in the PLC equipment to handle requests from OPC UA clients, send signals to the PLC equipment, and execute necessary programs. The PLC equipment is responsible for collecting information from field I / O devices and performing corresponding control functions on the reading and writing of current switch quantities and data volumes. The OPC UA server queries the PLC program's namespace to obtain the corresponding data structures and attributes, creates an information model, and creates instances of variables in shared memory. The values ​​of variables in the OPC UA server's address space are updated by the upper-level client and the PLC program, while the variable types and names are updated by the OPC UA server.

[0016] Furthermore, in step S2, constructing the information ontology specifically includes:

[0017] The OPC UA client connects to the OPC UA server, reads and analyzes the address space array of the OPC UA server, which associates each address space index with its corresponding address space; the OPC UA client recursively browses the address space of the OPC UA server and creates a Resource Description Framework (RDF) model for each address space; OPC UA nodes are mapped to RDF resources, and OPC UA references are mapped to RDF properties; for each reference between two OPC UA nodes, an RDF statement is created in the model; additional vocabulary of ontology language is added to the set of RDF-based models;

[0018] A three-tier architecture is used to map the OPC UA information model to the ontology model. The entire model mapping is divided into three layers: metamodel, model, and instance. The OPC UA address space model of the PLC device is located at the top layer, serving as the metamodel of the OPC UA information model. The address space stores the unique IDs of the field I / O devices. The ontology language OWL, which serves as the semantic description, is also located at the top layer. The OPC UA models and ontology models of various field devices are located in the middle model layer. OPC UA model instances and instances are located in the instance layer, with instances corresponding to specific PLC devices and field I / O devices in the field.

[0019] Furthermore, the steps for constructing an information ontology are as follows:

[0020] S211: Read the information in the address space of the OPC UA information model and create a unified representation of OWL Full semantics. The specific mapping rules are as follows:

[0021] Create a unique label for each resource based on the name of the OPC UA node;

[0022] All resources corresponding to OPC UA nodes of node classes ObjectType, VariableType, or DataType are declared as owl:Class;

[0023] All resources corresponding to the OPC UA node of the node class ReferenceType are declared as owl:ObjectProperty;

[0024] All resources corresponding to the OPC UA node that serves as the source of the HasTypeDefinition reference are declared as individuals of the corresponding class;

[0025] All resources corresponding to the OPC UA node that serves as the source of the HasSubtype reference are declared as the parent class of the corresponding class;

[0026] All object properties are declared as symmetric properties;

[0027] For all object properties that have the corresponding OPC UA ReferenceType property InverseName set, a reverse object property will be created;

[0028] Declare all attributes of the OPC UA node and its associated OPC UA attributes as annotation attributes;

[0029] S212: Instantiate field devices by using the abstract OPC UA model through a unified semantic description, redefine concepts using SPARQL rules, construct a graph transformation, transform the generated OPC UA OWL Full ontology into a specific domain ontology, and use the OWL DL language for unified semantic representation, further transforming it into a graph instance.

[0030] Furthermore, step S2 involves constructing the functional ontology, specifically including:

[0031] For industrial control scenarios with multiple modular devices, the PLC device code with modular functions is generated into a functional ontology model, and then the OPC UA calls the ontology to generate executable skill descriptions to realize the control functions of field IO devices.

[0032] Develop ontology descriptions for existing skill implementations and design Skill-Up functions to automatically generate complete skills. Within the Skill-Up framework, automatically generate a complete executable skill model based on annotations, including the calling interface and ontology description.

[0033] Furthermore, in step S3, the field device configuration module modifies the data information in the ontology by setting corresponding variables through the custom attribute function SPARQL, and passes the modified configuration information to the corresponding node in OPC UA. The OPC UA service passes the configuration information to the field device entity, and specifies that the node returns the corresponding result, thereby realizing the interaction between the ontology and the configuration information. The ontology reads and modifies the node information corresponding to the address space of OPC UA, and the OPC UA server modifies and updates the data in the address space to realize the control function configuration of the field device. For the functional code implemented by the PLC, it is converted into an executable skill model and then into a callable functional service. The logic control function of the PLC is realized according to the constraints of the skill model.

[0034] Furthermore, step S4 specifically includes:

[0035] Based on the characteristics of different field I / O devices, the static and dynamic attributes of the field I / O devices are determined, a field I / O device configuration model is established, and XML is used to describe the information model. The information model has the function of transmission, reading and writing between different systems. The configuration information is distributed by accessing the external information interface of the OPC UA server.

[0036] The field device configuration module determines the bus configuration information based on the characteristics of different field network configuration information. The field device configuration module fills the field network configuration information into the OPC UA protocol stack and transmits the Modbus configuration information through XML language. It then distributes the information through the OPC UA information interface to update the field device network configuration information.

[0037] Furthermore, in step S5, the OPC UA combined server, as the OPC UA device status information acquisition end, acquires the operating status information of industrial field equipment in real time, providing real-time data for the next step of field equipment information ontology instance mapping; the information ontology and the functional ontology are the foundation for the equipment to realize control functions, the equipment provides logical entities for the realization of control functions, and the functional ontology provides specific control implementation methods;

[0038] The real-time status information of field devices is obtained through OPC UA and converted into semantic data. Then, the nodes and attributes are extended through the information ontology. The executable skill model and data in the address space are called through the unique node ID in OPC UA. The XML format configuration file is passed to the field IO device through OPC UA to realize the control function configuration of the field IO device.

[0039] Furthermore, in step S5, the specific configuration process is as follows:

[0040] First, the field device configuration module transmits the obtained configuration information to the OPC UA combined server;

[0041] The OPC UA combination server generates an OPC UA model based on the configuration information and extracts the node information in the OPC UA through the defined mapping rules to generate the corresponding ontology;

[0042] The generated entity accesses the address space of the OPC UA server through the SPARQL function, modifies the data information that needs to be configured, and finally sends the configuration information to the field device entity through the OPC UA service.

[0043] The beneficial effects of this invention are as follows:

[0044] In terms of building field device-related models, most methods rely on OPC UA technology to standardize configurations. However, given the diverse types of industrial field devices and the large number of OPC UA servers across different networks, this patent introduces an ontology semantic model. This reduces model construction complexity and fully utilizes efficient semantic query tools such as SPARQL to improve query efficiency and effectively shorten response time. By using Web Ontology Language (OWL) to semantically describe the configuration information of field devices, the patent expands the node information and attributes of OPC UA, enhancing the semantic expressive power of the data. Furthermore, through the interaction between the ontology and configuration information, configuration files are generated and distributed to field devices via OPC UA. This not only enriches configuration functionality and increases configuration flexibility and scalability but also improves configuration efficiency.

[0045] Currently, the reuse of PLC code supporting the IEC 61131-3 standard in field devices is achieved through model matching. However, different platforms have different unique functional blocks, algorithms, functions, and corresponding internal logic structures, resulting in a huge workload for model construction and a high risk of errors. This patent researches a field device model configuration method based on OPC UA and ontology semantic models. It uses a combination of OPC UA and ontology semantic models to describe the functions of field devices, significantly reducing development workload and making it more feasible. Simultaneously, the OPC UA model makes it possible to unify different functional interfaces, executing the mapping of field device functions through interface calls to achieve unified configuration of field device functions.

[0046] In summary, this solution primarily addresses the challenge of unified configuration for field devices. The innovation of the proposed solution lies in: combining the characteristics of OPC UA and ontology semantic models to instantiate field devices, achieving interconnection and interoperability between them through OPC UA, and semantically describing device functions as executable skills, providing richer semantic information for OPC UA nodes and increasing configuration flexibility and scalability. Furthermore, leveraging the features of OPC UA, a unified field device interface and information exchange format are designed to enable device information interaction and function configuration.

[0047] Other advantages, objectives, and features of the invention will be set forth in part in the description which follows, and in part will be apparent to those skilled in the art from the following examination, or may be learned from practice of the invention. The objectives and other advantages of the invention can be realized and obtained through the following description. Attached Figure Description

[0048] To make the objectives, technical solutions, and advantages of the present invention clearer, the preferred embodiments of the present invention will be described in detail below with reference to the accompanying drawings, wherein:

[0049] Figure 1 A diagram illustrating the configuration architecture of field devices based on OPC UA and ontology semantic models;

[0050] Figure 2 A flowchart of a field device configuration method based on OPC UA and ontology semantic model;

[0051] Figure 3 Information model diagram designed for field I / O devices;

[0052] Figure 4 This is a diagram of the OPC UA information model for a PLC device.

[0053] Figure 5 Build a graph for the ontology library;

[0054] Figure 6 This is a schematic diagram illustrating the conversion between OPC UA and the ontology model;

[0055] Figure 7 A flowchart for configuring field devices based on OPC UA and ontology semantic model. Detailed Implementation

[0056] The following specific examples illustrate the implementation of the present invention. Those skilled in the art can easily understand other advantages and effects of the present invention from the content disclosed in this specification. The present invention can also be implemented or applied through other different specific embodiments, and various details in this specification can be modified or changed based on different viewpoints and applications without departing from the spirit of the present invention. It should be noted that the illustrations provided in the following embodiments are only schematic representations of the basic concept of the present invention. Unless otherwise specified, the following embodiments and features can be combined with each other.

[0057] The accompanying drawings are for illustrative purposes only and are schematic diagrams, not actual pictures. They should not be construed as limiting the invention. To better illustrate the embodiments of the invention, some parts in the drawings may be omitted, enlarged, or reduced, and do not represent the actual product dimensions. It is understandable to those skilled in the art that some well-known structures and their descriptions may be omitted in the drawings.

[0058] In the accompanying drawings of the embodiments of the present invention, the same or similar reference numerals correspond to the same or similar components. In the description of the present invention, it should be understood that if terms such as "upper," "lower," "left," "right," "front," and "rear" indicate the orientation or positional relationship based on the orientation or positional relationship shown in the drawings, they are only for the convenience of describing the present invention and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation. Therefore, the terms used to describe positional relationships in the drawings are only for illustrative purposes and should not be construed as limiting the present invention. For those skilled in the art, the specific meaning of the above terms can be understood according to the specific circumstances.

[0059] like Figure 1 As shown, this paper describes the field device configuration architecture based on OPC UA and ontology semantics proposed in this solution. The Industrial Internet of Things (IIoT) continuously integrates various sensors and controllers with sensing and monitoring capabilities, as well as information communication and intelligent analysis technologies, into all aspects of the industrial production process. This improves manufacturing efficiency, and optimizing current field device and network configurations is a significant evolutionary trend in field-level IIoT. How to execute efficient and unified configuration of field devices to complete personalized and customized production tasks and achieve flexible development of production systems is of great importance. Therefore, research on field device configuration methods to address field device communication and data interaction issues is crucial.

[0060] The architecture is divided into a top-down layer: user layer, data layer, and device layer. The data layer interacts with the user layer and device layer through northbound and configuration interfaces, respectively. The functions of each layer are as follows:

[0061] The user layer, or human-computer interaction interface, allows users to submit configuration requirements through a browser and call northbound interfaces, enabling information interaction and management with the data layer.

[0062] The data layer primarily consists of a field device configuration module based on OPC UA and an ontology semantic model. This module comprises three main parts: an OPC UA combo server, an ontology library, and the field device configuration module. The OPC UA combo server centralizes all field device data in its address space. It connects to devices such as PLCs via OPC UA clients to read data from the field devices. The ontology library stores semantic information about the field devices, supporting the generation of configuration files and providing more detailed semantic descriptions for OPC UA nodes. The field device configuration module generates corresponding configuration files based on user configuration requirements, calling data from the ontology to implement the corresponding configuration functions.

[0063] The equipment layer mainly consists of field I / O devices and PLC devices. Here, PLC devices refer to those that support the IEC 61131-3 standard. The PLC devices mainly control the field I / O devices, while the field I / O devices mainly provide the PLC with corresponding real-time data and actuators.

[0064] The basic tasks of the two types of interfaces are as follows:

[0065] Northbound interface: Provides an interface for the user layer to receive configuration information;

[0066] Configuration interface: Provides an interface for field devices that supports management and configuration functions.

[0067] This invention provides a field device configuration method based on OPC UA and ontology semantic model, targeting... Figure 1 The field device configuration architecture shown is based on OPC UA and an ontology semantic model. At the user level, device information for PLC devices, fieldbus networks, and field I / O devices is input. To facilitate communication between field devices and enable configuration information dissemination, the configuration information of the field devices needs to be modeled. For field device communication, an OPC UA client-server communication model is used to achieve communication access between PLC devices and field I / O devices. Furthermore, the ontology semantic model is combined to expand the OPC UA information model, providing a more accurate description of field device information and relationships between devices. The ontology semantic model provides more attributes, relationships, and constraints to enrich the semantic meaning of device descriptions, more accurately describing device characteristics, functions, and behaviors. Finally, OPC UA objects, attributes, methods, and other elements are mapped to the entities of the field devices to achieve functional configuration of the field devices. An application environment has been developed to write PLC programs, converting functional programs into corresponding executable skill models. Through various OPC UA services and mechanisms, control commands, device status, and other information are transmitted to the devices to achieve interactive linkage control and complete the functions of the field device configuration module.

[0068] like Figure 2 As shown, the steps of the field device configuration method based on OPC UA and ontology semantic model are as follows:

[0069] Step 1: The OPC UA combination server performs OPC UA information modeling on the field devices based on the input device information, enabling the field devices to complete communication and data transmission between the field I / O devices and the PLC devices based on a unique ID;

[0070] Step 2: The field device configuration module extracts field device configuration information and information from the address space of the OPC UA model to generate the corresponding information ontology, defining richer semantic information for nodes and attributes in the address space; and converts PLC programs that support the IEC 61131-3 standard into executable skill models to form functional ontology.

[0071] Step 3: The field device configuration module accesses the data in the OPC UA address space using the custom attribute function SPARQL to realize the interaction between the device body and the configuration data;

[0072] Step 4: The field device configuration module generates an XML configuration file based on the required configuration information, and distributes the configuration information by accessing the external information interface of the OPC UA server.

[0073] Step 5: The field device configuration module sends the configuration file of the field device to the field device to complete the corresponding control function.

[0074] Specifically, in the first step, the industrial field network contains a large number of digital and analog data acquisition and control devices, such as motor start / stop, valve opening / closing, and various data acquisition objects including temperature, pressure, and flow. These sensors and actuators are called field I / O devices. These field I / O devices can connect to PLC devices to jointly realize data acquisition, monitoring, and control functions. However, various industrial field devices typically use different industrial communication protocols to complete data interaction. Different industrial communication protocols often differ in their communication protocol architecture, data interaction format, and even underlying communication infrastructure, which hinders the interconnection and interoperability between industrial field devices. The OPC UA client / server communication model can encapsulate the complex data structures of different protocols within the information model of the OPC UA server, enabling communication and data exchange between field devices at the information layer.

[0075] Field I / O device information modeling: Based on the characteristics of the field devices, the entire field equipment is divided into PLC devices and field I / O devices. Field I / O devices mainly include sensors and actuators. Sensors are mainly used to collect various information about the physical environment and then transmit the information to the controller through an interface; actuators are mainly used to change the state of the device and execute the instructions transmitted by the controller PLC device; the PLC device, as the controller, receives the information transmitted by the sensors, processes it according to predefined processing rules, generates instructions, and transmits the instructions to the actuators through an interface.

[0076] For sensors and actuators, as OPC UA servers, they do not need to provide historical data functions, and the information model and address space of field I / O devices are relatively simple. In addition, publish and subscribe are not services that the standard requires to be supported, and implementing the publish and subscribe function requires a lot of system resources. Therefore, the publish and subscribe service was also partially selected.

[0077] To address these characteristics, this study examines the instantiation of information models, focusing on field I / O devices. Information model instantiation involves transforming an abstract information model into actual data objects. Static attribute sets primarily include basic information about the field I / O devices (model, device IP, device ID, port number, etc.), while dynamic attributes include the current status information of the field I / O devices, such as the specific temperature value of a temperature sensor or the status of a valve. The process of using the information model is essentially the instantiation process, which involves instantiating various information objects from the static and dynamic attribute sets of the field I / O devices. In essence, it involves transmitting the current status information from the field I / O device's information model to the PLC device in a service-oriented manner.

[0078] Figure 3 The information model diagram designed for field I / O devices includes static and dynamic attribute sets. Basic information about the field I / O devices includes device model, device IP, device ID, and port number. The field I / O device model includes basic model and type information. For field network communication, the field I / O devices require IP address, device ID, and port number information. Dynamic attributes enable reading and writing of the field I / O device status, facilitating data acquisition and control. The input and output parameters of the dynamic attributes need to be defined.

[0079] PLC Equipment Information Modeling: The combined server integrates both the OPC UA client and server. Upward, it provides the server with access to control commands transmitted from the cloud server to the PLC equipment. Downward, it provides the client with the ability to establish information models of field I / O devices at the device layer within the server's address space and obtain node information in real time. For OPC UA, all data and information are stored in the address space and the nodes mapped to it. The address space provides a unified information interface for the client; each physical device corresponds to a node in the address space, and multiple devices within a system can be managed based on the node IDs assigned to them in the address space. Storing data in the combined server during the entire system's communication process effectively reduces the resource burden on the PLC, which is significant for ensuring the system's real-time performance and stability.

[0080] In building the PLC model, an OPC UA server needs to be embedded in the PLC. This server communicates with the PLC program, which supports the IEC 61131-3 standard, via shared memory. The OPC UA server processes requests from OPC UA clients and sends signals to the PLC devices to execute necessary programs. The PLC is responsible for collecting information such as device IDs and data types from field I / O devices. The data from field I / O devices is mainly divided into two categories: switch signals, primarily for logic control; and data signals, including those from temperature sensors and pressure sensors. Corresponding control functions are completed by reading and writing current switch signals and data signals. When creating the information model, the OPC UA server queries the PLC program's namespace to obtain the corresponding data structures and attributes.

[0081] The structures and data in the namespace can be easily converted into object nodes and variable nodes in the OPC UA information model. Using the namespace provided by the PLC program, the OPC UA server generates the information model and creates instances of variables in shared memory. The values ​​of variables in the OPC UA server address space are updated by the upper-level client and the PLC program, while the variable types and names are updated by the OPC UA server. The specific construction of the OPC UA model for the PLC device is as follows: Figure 4 As shown.

[0082] Specifically, in the second step, by modeling the device information using OPC UA, the device information and data are stored in the OPC UA address space in the form of nodes and attributes. This enables field devices to communicate with each other through unique IDs. However, OPC UA nodes typically use identifiers to identify nodes and attributes, and these identifiers themselves do not provide sufficient semantic information. Users find it difficult to understand the meaning of nodes and attributes, requiring a formal semantic to more accurately describe node and attribute information. Furthermore, PLC device programs supporting the IEC 61131-3 standard, due to the diversity of their data structures, the complexity of their functions, and their scalability, also require a formal semantic to achieve complex data processing. Achieving this formal semantic using only the OPC UA model is difficult. Introducing an ontology based on the Web Ontology Language (OWL) can provide richer semantic information for nodes and attributes and enable better processing of PLC device program data.

[0083] In this solution, the OPC UA combined server constructs an information model for field I / O devices. The field device configuration module extracts the node and attribute information of the field I / O devices mapped in the OPC UA address space by building an OPC UA client, and performs semantic description of the extracted information to enrich the meaning of nodes and attributes. Finally, it generates the corresponding information ontology according to the mapping rules. The field device configuration module abstracts the PLC program information according to the mapped application's functional implementation, generates corresponding executable skills, and transforms them into a functional ontology. The information ontology and functional ontology together constitute the ontology library, such as... Figure 5 As shown.

[0084] In this solution, the field device configuration module creates an OWL model and maps node and attribute information from the OPC UA address space to the ontology, enabling interaction between the OPC UA information model and the ontology. During implementation, the Apache Jena Framework is used to process OWL data. A custom function accesses the OPC UA server and retrieves its runtime data. The software module extracts the OPC UA information model stored in the OPC UA server and automatically converts it to OWL, thus ensuring successful mapping.

[0085] First, the OPC UA client connects to the OPC UA server and begins analyzing the address space by reading the server's address space array, which associates each address space index with its corresponding address space. Next, the OPC UA client recursively browses the OPC UA server's address spaces and creates an RDF (Resource Description Framework) model for each address space. OPC UA nodes are mapped to RDF resources, and OPC UA references are mapped to RDF properties. Furthermore, for each reference between two OPC UA nodes, an RDF statement is created in the model. If such a statement involves resources in different address spaces, thus requiring a different model, it can be added to the model corresponding to the namespace with the higher index. In this way, each address index contains only the statement for the corresponding model.

[0086] The above transformation yields a set of RDF-based models, which require the addition of more specific ontology language vocabulary, such as RDFS, OWL DL, or OWL Full. OWL Full allows for the use of object attributes to associate individuals and classes with similar flexibility, making it well-suited for addressing the problem of OPC UA creating new objects. Therefore, using OWL Full to represent the OPC UA address space makes the model more accurate.

[0087] In the specific mapping process, this solution uses a three-tier architecture to implement the mapping from the OPC UA information model to the ontology model, such as... Figure 6 As shown, the entire model mapping is divided into three layers: metamodel, model, and instance. The OPC UA address space model of the PLC device is located at the top layer, serving as the metamodel of the OPC UA information model. The address space stores the unique IDs of the field I / O devices. The Ontology Language (OWL), which provides semantic description, is also located at the top layer. The OPC UA models and ontology models of various field devices are located in the middle model layer. OPC UA model instances and instances are located in the instance layer, with instances corresponding to specific PLC devices and field I / O devices within the field devices. The entire conversion process consists of two main steps:

[0088] The first step is to read the information in the address space of the OPC UA information model and create a unified representation of OWL Full semantics. The specific mapping rules are as follows:

[0089] 1) Create a unique label for each resource based on the name of the OPC UA node.

[0090] 2) All resources corresponding to OPC UA nodes of node class ObjectType, VariableType, or DataType are declared as owl:Class.

[0091] 3) All resources corresponding to the OPC UA node of the node class ReferenceType are declared as owl:ObjectProperty.

[0092] 4) All resources corresponding to the OPC UA node that serves as the source of the HasTypeDefinition reference are declared as individuals of the corresponding class.

[0093] 5) All resources corresponding to the OPC UA node that serves as the source of the HasSubtype reference are declared as the parent class of the corresponding class.

[0094] 6) All object properties (with the corresponding OPC UA ReferenceType property Symmetric set) are declared as symmetric properties.

[0095] 7) For all object properties with the corresponding OPC UA ReferenceType property InverseName set, a reverse object property will be created.

[0096] 8) Declare all attributes of the OPC UA node and its associated OPC UA attributes as annotation attributes.

[0097] The second step instantiates the field devices from the abstract OPC UA model through a unified semantic description. This step primarily involves transformation at the model layer. Using SPARQL rules, concepts are redefined, a graphical transformation is constructed, and the generated OPC UA OWL Full ontology is converted into a specific domain ontology. Furthermore, a unified semantic representation is achieved using the OWL DL language, further transforming it into graphical instances. This process extracts the node and attribute information corresponding to the field devices from the OPC UA and converts this information into an information ontology.

[0098] After constructing the information ontology, OWL semantics is used to extend the description of the relationship between PLC devices and field I / O devices. Compared to using OPC UA alone, this allows for a more accurate description of the relationship. For example, the ontology can more accurately describe semantic information such as the type, unit, and value range of nodes and attributes. Simultaneously, the ontology provides the foundation for calling executable skills. Field I / O devices provide objects for PLC device programs, and PLC device programs provide signal processing functions for the devices, jointly realizing the functions of industrial application scenarios. Since the PLC devices implement the functions of the field I / O devices through programs, the programs need to be abstracted into skill attributes of the field I / O devices. The field device configuration module abstracts and describes the functions implemented by the PLC program at the semantic level, executes the corresponding mapping application, instantiates the functions implemented by the field I / O devices into executable skills, describes the skills using ontology semantics, converts them into corresponding configuration files, and finally distributes the configuration through OPC UA, completing the unified configuration of field device control functions.

[0099] (1) Construction of the functional ontology model of field equipment

[0100] In modular industrial control scenarios involving multiple devices, each module provides a set of predefined functions. These modular functions do not have high requirements for semantic hierarchy; they do not need to be implemented from a detailed perspective. Only an abstract description of the functions is needed, treating them as skill models for invocation. This requires generating a functional ontology model from the PLC device code for this capability, and then having the OPC UA call this ontology to generate executable skill descriptions, thereby implementing the control functions of the field I / O devices.

[0101] (2) Generation and invocation of executable skill models

[0102] This solution uses the Java programming language to develop ontology descriptions for existing skill implementations and designs Skill-Up functions to automatically generate complete skills. Within the Skill-Up framework, users only need to add additional information about the skill in the form of Java annotations. Skill-Up automatically generates a complete executable skill model based on these annotations, including the API and ontology description.

[0103] In the Skill-Up instance, two numbers are added together and the sum is returned. After successful deployment, the result can be invoked via OPC UA. The first annotation, @Skill, marks this class as a skill. Skill-Up will read the class at runtime and convert it into a skill. The class is passed as an option to this annotation, and this class is set as the interface to be automatically invoked.

[0104] `@SkillParameter` and `@SkillOutput` are annotations used to specify which attributes are accessible from outside the skill. Parameters can be passed to the skill to set variables related to skill execution. Afterward, the output can be retrieved as the result of the skill execution. The actual skill behavior implemented in traditional Java methods can be annotated with state annotations such as `@Starting`, `@Execute`, and `@Completing`. Using these annotations ensures that a behavior is executed only in the correct state.

[0105] When Skill-Up runs, instances of states are constructed. Based on the state annotations of the executable skills, the skill's implementation behavior is injected into the state machine instance as an action to be performed in the specified state. In this case, the addition of two numbers will only be performed when the state machine is in the Execute state. After completing this behavior, the state machine will transition to the next state. To control state commands such as start, stop, or abort, callable interfaces are automatically generated. Depending on the skill type, Skill-Up generates callable methods that set input parameters and implement the skill output when the skill is completed.

[0106]

[0107] Specifically, in the third step, after constructing the information ontology and functional ontology, the interconnection between field devices and the mapping between field I / O devices and PLC programs are achieved, unifying the configuration information at the semantic level. To enable the configuration of device control functions, further semantic information needs to be transformed into configuration information that field devices can recognize, generating configuration files. These files are then distributed to field devices via OPC UA communication. In this solution, SPARQL attribute functions are defined to achieve the interconnection between the information model and information services, completing the interaction and distribution of configuration files.

[0108] The field device configuration module modifies data information in the ontology by setting corresponding variables using custom SPARQL attribute functions, and then passes the modified configuration information to the corresponding node in OPC UA. The OPC UA service then passes the configuration information to the field device entity, and specifies that the node should return the corresponding result, thereby realizing the interaction between the ontology and the configuration information. In the specific implementation, two custom attribute functions, `value` and `histValue`, are defined. These functions use information stored in the ontology to retrieve the OPC UA endpoint URL and OPC UA node ID to connect to the OPC UA server and request the required data. If the node's Read service is available, data is retrieved during the SPARQL query, and the value is assigned to the SPARQL variable. The `histValues` attribute function returns a timestamp and its associated value, which are bound to the specified SPARQL variable and applied to each OPC UA node in the ontology. This allows SPARQL to be used to update or insert new data. By reading and modifying the node information corresponding to the OPC UA address space through the ontology, and by the OPC UA server modifying and updating the data in the address space, the control function configuration of the field device can be realized. The functional code implemented by the PLC is transformed into an executable skill model, which is then transformed into a callable functional service. The logic control function of the PLC is realized based on the constraints of the skill model.

[0109] Specifically, in the fourth step, (1) on-site IO device configuration information

[0110] Based on the characteristics of different field I / O devices, the static and dynamic attributes of these devices are determined, and a field I / O device configuration model is established. XML is used to describe the information model, which includes the basic attributes and configuration information of the field I / O devices. Simultaneously, an ontology clearly defines the information of various attributes in OPC UA, as well as their references and inheritance relationships, facilitating the identification and parsing of the same information model across different environments and languages. The information model has the capability to transmit, read, and write between different systems, and configuration information is distributed by accessing the external information interface of the OPC UA server.

[0111]

[0112]

[0113] (2) Fieldbus network configuration information

[0114] Based on the characteristics of different field network configuration information, the field device configuration module determines the bus configuration information. The field device configuration module fills the field network configuration information into the OPC UA protocol stack and transmits the Modbus configuration information through XML. It can be distributed through the OPC UA information interface to update the field device network configuration information.

[0115]

[0116]

[0117] Specifically, in step five, the combined server, acting as the OPC UA device status information acquisition end, acquires real-time operational status information of industrial field equipment, providing real-time data for the next step of mapping field equipment information ontology instances. Information ontology and functional ontology are the foundation for equipment to implement control functions; the equipment provides logical entities for the implementation of control functions, while the functional ontology provides specific control implementation methods. The real-time status information of field equipment acquired through OPC UA is converted into semantic data, and then the nodes and attributes are expanded through the information ontology to further describe the node type, unit, value range, etc., providing rich semantic information for OPC UA nodes and improving the scalability of OPC UA configuration. The executable skill model and data in the address space are called through the unique node ID in OPC UA, and the XML format configuration file is passed to the field IO device through OPC UA to realize the control function configuration of the field IO device. The specific configuration process is as follows: First, the field equipment configuration module passes the acquired configuration information to the combined server. Then, the combined server generates an OPC UA model based on this information and extracts the node information in OPC UA to generate the corresponding ontology according to the defined mapping rules. The generated entity accesses the OPC UA server's address space via SPARQL functions, modifies the necessary configuration data, and finally distributes the configuration information to the field device entities via the OPC UA service. Figure 7 As shown.

[0118] Those skilled in the art will understand that all or part of the steps in the methods of the above embodiments can be implemented by a program instructing related hardware. The program can be stored in a computer-readable storage medium. When the program is executed, it can implement the steps of the method. The storage medium may be, for example, ROM / RAM, magnetic disk, optical disk, etc.

[0119] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and are not intended to limit it. Although the present invention has been described in detail with reference to preferred embodiments, those skilled in the art should understand that modifications or equivalent substitutions can be made to the technical solutions of the present invention without departing from the spirit and scope of the present invention, and all such modifications or substitutions should be covered within the scope of the claims of the present invention.

Claims

1. A field device configuration method based on OPC UA and ontology semantic model, characterized in that: Includes the following steps: S1: The OPC UA combination server performs OPC UA information modeling on the field devices based on the input device information, enabling the field devices to complete communication and data transmission between the field I / O devices and the PLC devices based on a unique ID; S2: The field device configuration module extracts field device configuration information and information from the address space of the OPC UA model to generate the corresponding information ontology; the PLC program supporting the IEC 61131-3 standard is converted into an executable skill model to form a functional ontology; in step S2, the construction of the information ontology specifically includes: The OPC UA client connects to the OPC UA server, reads and analyzes the address space array of the OPC UA server, which associates each address space index with its corresponding address space; the OPC UA client recursively browses the address space of the OPC UA server and creates a Resource Description Framework (RDF) model for each address space; OPC UA nodes are mapped to RDF resources, and OPC UA references are mapped to RDF properties; for each reference between two OPC UA nodes, an RDF statement is created in the model; additional vocabulary of ontology language is added to the set of RDF-based models; A three-tier architecture is used to map the OPC UA information model to the ontology model. The entire model mapping is divided into three layers: metamodel, model, and instance. The OPC UA address space model of the PLC device is located at the top layer, serving as the metamodel of the OPC UA information model. The address space stores the unique IDs of the field I / O devices. The ontology language OWL, which serves as the semantic description, is also located at the top layer. The OPC UA models and ontology models of various field devices are located in the middle model layer. OPC UA model instances and instances are located in the instance layer, with instances corresponding to specific PLC devices and field I / O devices in the field. The steps for constructing an information ontology are as follows: S211: Read the information in the address space of the OPC UA information model and create a unified representation of OWL Full semantics. The specific mapping rules are as follows: Create a unique label for each resource based on the name of the OPC UA node; All resources corresponding to OPC UA nodes of node classes ObjectType, VariableType, or DataType are declared as owl:Class; All resources corresponding to the OPC UA node of the node class ReferenceType are declared as owl:ObjectProperty; All resources corresponding to the OPC UA node that serves as the source of the HasTypeDefinition reference are declared as individuals of the corresponding class; All resources corresponding to the OPC UA node that serves as the source of the HasSubtype reference are declared as the parent class of the corresponding class; All object properties are declared as symmetric properties; For all object properties that have the corresponding OPC UA ReferenceType property InverseName set, a reverse object property will be created; Declare all attributes of the OPC UA node and its associated OPC UA attributes as annotation attributes; S212: Instantiate field devices by using the abstract OPC UA model through a unified semantic description, redefine concepts using SPARQL rules, construct a graph transformation, transform the generated OPC UA OWL Full ontology into a specific domain ontology, and use the OWL DL language for unified semantic representation, further transforming it into a graph instance. S3: The field device configuration module accesses data in the OPC UA address space using the custom attribute function SPARQL to achieve interaction between the entity and the configuration data. In step S3, the field device configuration module modifies the data information in the entity by setting corresponding variables using the custom attribute function SPARQL, and passes the modified configuration information to the corresponding node in the OPC UA. The OPC UA server passes the configuration information to the field device entity and specifies that the node should return the corresponding result, thereby achieving interaction between the entity and the configuration information. The entity reads and modifies the node information corresponding to the OPC UA address space, and the OPC UA server modifies and updates the data in the address space to achieve the configuration of the control function of the field device. For the functional code implemented by the PLC, it is converted into an executable skill model and then into a callable functional service. The PLC's logic control function is implemented according to the constraints of the skill model. S4: The field device configuration module generates an XML-formatted configuration file based on the required configuration information, and distributes the configuration information by accessing the external information interface of the OPC UA server; S5: The field device configuration module sends the configuration file of the field device to the field device to complete the corresponding control function.

2. The field device configuration method based on OPC UA and ontology semantic model according to claim 1, characterized in that: Step S1, the OPC UA combination server, performs OPC UA information modeling on the field devices based on the input device information, specifically including: Field I / O device information modeling includes a static attribute set and a dynamic attribute set; the static attribute set includes basic information about the field I / O devices; the dynamic attribute set includes the current status information of the field I / O devices. PLC Equipment Information Modeling: An OPC UA server is embedded in the PLC equipment to handle requests from OPC UA clients, send signals to the PLC equipment, and execute necessary programs. The PLC equipment is responsible for collecting information from field I / O devices and performing corresponding control functions on the reading and writing of current switch quantities and data volumes. The OPC UA server queries the PLC program's namespace to obtain the corresponding data structures and attributes, creates an information model, and creates instances of variables in shared memory. The values ​​of variables in the OPC UA server's address space are updated by the upper-level client and the PLC program, while the variable types and names are updated by the OPC UA server.

3. The field device configuration method based on OPC UA and ontology semantic model according to claim 1, characterized in that: Step S2 involves constructing the functional ontology, specifically including: For industrial control scenarios with multiple modular devices, the PLC device code with modular functions is generated into a functional ontology model. Then, the OPC UA information model is used to call the functional ontology model to generate executable skill descriptions, thereby realizing the control functions of field IO devices. Develop ontology descriptions for existing skill implementations and design Skill-Up functions to automatically generate complete skills. Within the Skill-Up framework, automatically generate a complete executable skill model based on annotations, including the calling interface and ontology description.

4. The field device configuration method based on OPC UA and ontology semantic model according to claim 1, characterized in that: Step S4 specifically includes: Based on the characteristics of different field I / O devices, the static and dynamic attributes of the field I / O devices are determined, a field I / O device configuration model is established, and XML is used to describe the information model. The information model has the function of transmission, reading and writing between different systems. The configuration information is distributed by accessing the external information interface of the OPC UA server. The field device configuration module determines the bus configuration information based on the characteristics of different field network configuration information. The field device configuration module fills the field network configuration information into the OPC UA protocol stack and transmits the Modbus configuration information through XML language. It then distributes the information through the OPC UA information interface to update the field device network configuration information.

5. The field device configuration method based on OPC UA and ontology semantic model according to claim 1, characterized in that: In step S5, the OPC UA combined server, as the OPC UA device status information acquisition end, acquires the operating status information of industrial field equipment in real time, providing real-time data for the next step of field equipment information ontology instance mapping; the information ontology and the functional ontology are the foundation for the equipment to realize control functions. The equipment provides logical entities for the realization of control functions, while the functional ontology provides specific control implementation methods. The real-time status information of field devices is obtained through OPC UA and converted into semantic data. Then, the nodes and attributes are extended through the information ontology. The executable skill model and data in the address space are called through the unique node ID in OPC UA. The XML format configuration file is passed to the field IO device through OPC UA to realize the control function configuration of the field IO device.

6. The field device configuration method based on OPC UA and ontology semantic model according to claim 5, characterized in that: In step S5, the specific configuration process is as follows: First, the field device configuration module transmits the obtained configuration information to the OPC UA combined server; The OPC UA combined server generates an OPC UA model based on the configuration information and extracts the node information in the OPC UA through the defined mapping rules to generate the corresponding ontology. The generated entity accesses the address space of the OPC UA server through the SPARQL function, modifies the data information that needs to be configured, and finally sends the configuration information to the field device entity through the OPC UA service.

Images