Computer-implemented method for configuring component having OPC UA server in industrial plant

Through mapping tools and OPC UA ReferenceType configuration method, the OPC UA server in an industrial factory is automatically adapted, solving the communication adaptation problem between different protocols and information models, and achieving efficient and reliable inter-component communication.

CN120353795APending Publication Date: 2025-07-22ABB (SCHWEIZ) AG
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
CN202510043861.6
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Priority Date
2024-01-22
Filing Date
2025-01-10
Publication Date
2025-07-22

AI Technical Summary

Technical Problem

In the prior art, communication adaptation between different protocols and information models in industrial plants is large and error-prone, resulting in high costs.

Method used

Select the OPC UA server through the mapping tool, receive the data model, retrieve parameter relationships, build the mapping definition file, and use the OPC UA ReferenceType HasDictionaryEntry and CorrespondsTo relationship to configure the address space of the components to achieve automated adaptation between components.

Benefits of technology

It reduces the workload of adapting communication protocols and information model, improves communication efficiency, avoids manual adaptation errors, and realizes efficient communication between components.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN120353795A_ABST
    Figure CN120353795A_ABST
Patent Text Reader

Abstract

The invention relates to a method for configuring a component of a subsystem of an industrial plant, the component comprising an OPC UA server and an OPC UA data model comprising attributes of the component, the method comprising the following steps: an OPC UA client of a mapping tool selecting the OPC UA server of the component; the OPC UA client receives an OPC UA data model including an attribute list from the OPC UA server; the mapping tool retrieves a parameter list from an engineering database related to the component; the mapping tool retrieves a list of relationships between attributes of the OPC UA data model and component parameters from dictionaries in a dictionary database; for each attribute, the mapping tool checks whether the dictionary contains a relationship from the relationship list including the attribute; for each relationship including the attribute, the mapping tool adds the relationship to a mapping definition file; the mapping tool adds parameters to an address space of the OPC UA server by using the OPC UA Reference Type HasDictionaryEntry on the basis of the mapping definition file so as to configure the component; and an OPC UA client of the control unit PLC reads the parameters of the components.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] The present invention relates to the field of controlling an industrial plant or a subsystem of an industrial plant, and more particularly to the field of controlling an industrial plant including a component having an OPC UA server. More specifically, the present invention relates to a method for configuring a component having an OPC UA server in an industrial plant. The present invention also relates to a mapping tool, uses, programming elements, and a computer-readable storage medium. Background Art

[0002] To control an industrial plant, there are various communication mechanisms, protocols, and / or information models. Examples may include the so-called OPC UA and other protocols having, for example, a "controller view" of the communication within the industrial plant. Both the protocols and the information models are well-defined and widely used. However, at least some of the communication mechanisms and protocols may be incompatible with each other, such that some effort may be required to establish communication between them. Whenever cooperation between two protocols is needed, this may result in the work of adapting the protocols being costly and error-prone. Summary of the Invention

[0003] The object of the present disclosure is to provide a method for reducing the effort of adapting two protocols and / or information models for communication within an industrial plant. This object is achieved by the subject matter of the independent claims. Other embodiments are apparent from the dependent claims and the following description.

[0004] One aspect relates to a computer-implemented method for configuring a component of a subsystem of an industrial plant, the component including an OPC UA server and an OPC UA data model, the OPC UA data model including attributes of the component, the method comprising the following steps:

[0005] Step 122: Select, by an OPC UA client of a mapping tool, the OPC UA server of the component;

[0006] Step 124: Receive, by the OPC UA client of the mapping tool, the OPC UA data model of the component from the OPC UA server of the component, wherein the OPC UA data model includes a list of attributes;

[0007] Step 126: Retrieve, by the mapping tool, a list of parameters of the component from an engineering database related to the component;

[0008] Step 128: Retrieve, by the mapping tool, a list of relationships between the attributes of the OPC UA data model and the parameters of the component from a dictionary in a dictionary database;

[0009] Step 130: For each property in the property list of the OPC UA data model, the mapping tool checks whether the dictionary contains a relationship from the relationship list that includes this property;

[0010] Step 132: For each relationship that includes this property, the mapping tool adds the relationship to the mapping definition file;

[0011] Step 134: By the mapping tool, based on the mapping definition file, using the OPC UA ReferenceType HasDictionaryEntry, add parameters to the address space of the OPC UA server of the component to configure the component; and

[0012] Step 136: The parameters of the component are read by the OPC UA client of the control unit PLC.

[0013] The subsystem of the industrial plant can include the complete plant or only a part of the industrial plant. The subsystem can include components such as at least one sensor and / or at least one actuator. The subsystem can also include one or more control units. Examples of sensors can include inductive devices, capacitive devices, resistive devices, and / or optical devices configured to sense, for example, pressure, flow, temperature, distance, and / or changes in these measurements (e.g., speed, acceleration, etc.). Examples of actuators may include pumps, compressors, vessels or pressure vessels, storage tanks, heat exchangers, furnaces, fans, cooling towers, valves, etc. Examples of control units can include one or more programmable logic controllers (PLCs). In at least some paragraphs of this text, the terms "PLC" and "control unit" are used as synonyms. Each PLC can control at least one actuator, for example, based on data from at least one sensor. An OPC UA server can be installed on each component in the component. An OPC UA client can be installed on each control unit in the control unit.

[0014] The computer-implemented method can be executed by any computer, but at least some parts of the method may require at least establishing a communication connection with the component. Similarly, for at least some parts of the method, an OPC UA client may need to be installed on the computer. At least some parts of the method can be executed by a so-called "mapping tool" (i.e., a computer on which an OPC UA client is installed, and in addition, there is a computer program product capable of executing at least part of the method described above and / or below).

[0015] Specifically, in step 122, the OPC UA server of the component is selected by the OPC UA client of the mapping tool. The selection can be done by an automated device (e.g., each time a new component is entered into the subsystem, the automated device can be based on the plan of the subsystem that identifies the component) and / or by other devices (e.g., via a script, via a command in the command line, via MDNS (also known as Bonjour), OPC UA 10000-12 discovery and global services, and / or via additional devices).

[0016] In step 124, the OPC UA client of the mapping tool receives the OPC UA data model of the component. The OPC UA data model can also be referred to as an OEM model, a DI model, OPC 10000-100, PADIM, OPC 30081, and / or other models. The OPC UA data model can include a list of attributes, e.g., a linear list, a hierarchical list, or another type of list.

[0017] In step 126, the mapping tool (or its OPC UA client) retrieves a list of parameters of the component from the engineering database related to the component. These parameters describe the so-called TargetModel (or target model) of the component. The target model can include a list of parameters, e.g., a linear list, a hierarchical list, or another type of list. The parameters can be provided by the engineering database, e.g., by a database including standardized values such as VDI 2658 or by another database that describes the component's values in a structured manner. Both the "OPC UA data model" and the "target model" are sometimes referred to as the "information model".

[0018] In step 128, the mapping tool retrieves a list of relationships between the attributes of the OPC UA data model and the parameters of the component from the dictionary in the dictionary database. The dictionary database can include one or more dictionaries. In this list of relationships, the parameters are related to the engineering database. For example, the list of relationships may be similar to Table 1.

[0019] Table 1: Two relationship rows in the dictionary database

[0020]

[0021]

[0022] The relationship list can be sorted like an array with array rows "relationship r[1], relationship r[2], …". Each array row can have a left part that describes the attributes of the OPC UA data model (column "Attributes of the OPC UA data model" in Table 1) and a right part that describes the corresponding parameters related to the engineering database (column "Parameters of TargetModel" in Table 1). In Table 1, the hierarchical list of attributes is shown in a "normal form", where each entry includes the complete hierarchy. In the example shown, "LLT100" describes the liquid level sensor and its product number, "ProcessAlarm" describes an ordered set of alarm types, "ProcessAlarm Limits" describes the alarm for the alarm type "Limits", "Level" describes that this is about the liquid level limit, and "Low" or "High" respectively describe the detailed alarm values, i.e., "filling liquid level reaches the lower limit" or "filling liquid level reaches the upper limit". Each array row can also have a right part to define the relationship. In the example shown, the right part can describe the parameters according to VDI2658. The right part can use the parameter set "AnaMon" ("analog monitoring") that can describe the parameter list standardized according to VDI2658. The example values are "VALLim" for "filling liquid level reaches the lower limit" and "VAHLim" for "filling liquid level reaches the upper limit" respectively.

[0023] In step 130, for each attribute in the list of attributes of the OPC UA data model, the mapping tool checks whether the dictionary database contains a relationship from the relationship list that includes this attribute. Taking the attribute "LLT100.ProcessAlarm.Process AlarmLimits.Level.High" from Table 1, the mapping tool will find that there is a corresponding relationship "r[2]" with the right side being "VDI2658.AnaMon.VAHLim".

[0024] In step 132, the mapping tool constructs a mapping definition file. The mapping definition file may be specific to each component, each type of component, or each category of components. For each relationship in the relationship list that includes this attribute (i.e., if the left part of the relationship is found in the dictionary database), the corresponding parameters of the component are added to the attributes of the component in the OPC UA server. Thus, the mapping definition file contains both the attributes and the corresponding parameters of the component.

[0025] In step 134, the mapping definition file of the component is used to configure the component. Configuring the component includes: the mapping tool uses OPC UA ReferenceType HasDictionaryEntry to add parameters to the address space of its OPC UA server based on the mapping definition file. The configuration can include: the mapping tool uploads the mapping definition file to the OPC UA server of the component. This ReferenceType constructs an indicator from the description of the attribute value (e.g., the left part of a row in Table 1) to the description of the parameter value (e.g., the right part of a row in Table 1). Advantageously, the "right part" only exists once, but more than one point can point to it, thus reducing the amount of memory required in the component. Therefore, the OPC UA data model is enriched by the data and / or aspects of the TargetModel.

[0026] In step 136, the PLC (control unit) configured to control the component "perceives" the relationship of the mapping definition file of the component. To this end, the OPC UA client of the PLC reads the parameters of the component. The PLC with an OPC UA client can access the OPC UA server of the component, more specifically: access its address space. The PLC knows the concept of the address space of the OPC UA server and thus can find the "HasDictionaryEntry" relationship. This relationship is usually specified as "References" (e.g., of the OPC UA ReferenceType). Since the PLC knows the "right part", after reading the relationship of the component, it can address the component by communicating via conventional OPC UA communication (i.e., using the "left part" of the relationship).

[0027] This method can reduce or even avoid the workload of adapting two protocols and / or information models for communication within an industrial plant (i.e., for retrieving measurement (and other) values from sensors and / or for controlling the actions performed by actuators). Once the dictionary database is established, i.e., once the dictionary database contains all the relationships related to the industrial plant or subsystem, the methods described above and / or below can be automatically executed. In addition, the method is "generic" in a way that it can be applied to almost all types of "right parts" that are semantically equivalent to the OPC UA description. And, it is "generic" in a way that it can be applied to a wide variety of components (i.e., to a wide variety of sensor types and / or actuator types) and can also be applied to a wide variety of control units.

[0028] In various embodiments, the method further includes the following steps, which can be performed when operating the component (e.g., during production runs in an industrial plant and / or subsystem).

[0029] In step 142, the OPC UA client of the PLC requests values from the component, such as measurement values, alarm values, and / or other types of values. This can be done via conventional OPC UA communication.

[0030] In step 144, the OPC server of the component can provide the value to the PLC of the subsystem. This communication can also be done via conventional OPC UA communication.

[0031] Thus, it is possible to use the "two worlds" (OPC UA and, for example, VDI2658) for accessing and controlling components in an industrial plant, including all their benefits. And advantageously, since the adaptation can be done by an automation device, no complex error-prone manual adaptation or transformation is required. Further, for service personnel and / or other personnel operating the plant, the communication between the entities of the plant (such as components and controllers) will be similar to conventional OPC UA communication.

[0032] One aspect relates to a computer-implemented method for configuring a component of a subsystem of an industrial plant, the component including an OPC UA server and an OPC UA data model, the OPC UA data model including attributes of the component. The method includes steps 122 to 132 as described above and / or below.

[0033] Further, the method includes step 138. In step 138, the mapping tool configures the parameters of the OPC UA server of the component based on a mapping definition file by using the OPC UAReferenceType CorrespondsTo relationship. Using the CorrespondsTo ReferenceType means that for each attribute entry (column "Attributes of the OPC UA data model" in Table 1), a parameter entry (column "Parameters of the TargetModel" in Table 1) is entered into the address space of the OPC UA server of the component. This advantageously enables the component to perform a "right-to-left" mapping, i.e., a mapping from the parameter entries of the TargetModel to the attribute entries of the OPC UA data model of the component.

[0034] In addition, in this case, it is possible to use the "two worlds" for accessing and controlling components in an industrial plant, including all their benefits. And furthermore, since the adaptation can be done by an automation device, no complex manual adaptation is required.

[0035] In various embodiments, the method further includes the following steps, which can be performed when operating the component (e.g., during production runs in an industrial plant and / or a subsystem).

[0036] In step 152, the OPC UA client of the PLC requests parameter values from the component. The PLC may only know the TargetModel of the component. From the perspective of the PLC, this may be similar to only using the TargetModel. The TargetModel request can be executed according to VDI 2658, for example, by a request that can be executed according to VDI 2658, such as an OPC UA service that reads or writes variables (such as "VDI2658.AnaMon.VAHLim").

[0037] After receiving the request, the component processes the parameter values in step 154. When the read request refers to sensor values, the processing may include: receiving the value from the sensor front end. The value is mapped to the corresponding parameter of the TargetModel. In step 156, this value is used to respond to the PLC's read request. After receiving a write request that refers to the setpoint of an actuator, the component copies the received value to the corresponding attribute of the OEM model, which may include sending the value to the action part, such as a motor, valve, heater, etc. In step 156, the result of the actuation request is converted into a write response, which is sent to the PLC. In short, step 152 is related to read requests or write requests, step 154 is related to mapping (possibly bidirectional), and step 156 is related to responses.

[0038] In various embodiments, providing values to or from the OPC UA server includes conversion between the data types of the values. For example, a value with a data type of "float" can be converted to "integer" or "boolean". For example, the value "1.2m" can be transformed into "integer: 120cm" or "boolean: reached upper limit".

[0039] In various embodiments, the method further includes steps related to the preparation of a dictionary. The preparation steps include:

[0040] In step 112, the attributes of the OPC UA data model of the OPC UA server are requested. This request can be executed by a preparation tool. The preparation tool can be executed on the same computer as the computer used for the mapping tool, or on a different computer. In step 114, the parameters of the engineering database are requested. This can be done before, after, or in parallel with step 112. In step 116, a dictionary is constructed that includes a list of relationships between at least some of the attributes of the OPC UA data model and at least some of the parameters of the component.

[0041] In various embodiments, retrieving (step 126) a list of parameters of a component from an engineering database further includes: retrieving a list of abstract data types of the component. The abstract data types can include, for example, subroutines, data classes, and / or their attributes, etc. In this way, not only values can be converted and / or used in "two worlds", but also executable code can be converted and / or used in "two worlds".

[0042] Note that the preparation step can alternatively be completed by using different methods, at least because its result can be used for the steps starting from step 122.

[0043] In various embodiments, the engineering database includes parameters of components according to VDI 2658. This enables the advantageous use of the well-defined and well-known standard VDI 2658, also for use in an OPC UA environment.

[0044] One aspect relates to a mapping tool configured to perform the method described in any one of the foregoing claims. At least for performing some parts of the method, the mapping tool can include an OPC UA client.

[0045] One aspect relates to the use of a mapping tool for configuring components of a subsystem of an industrial plant as described above and / or below.

[0046] One aspect relates to a computer program product including instructions that, when executed by a computer on a mapping tool as described above and / or below, cause the computer and / or controller to perform the method described in any one of the foregoing claims.

[0047] One aspect relates to a computer-readable storage medium on which the computer program or computer program product as described above is stored.

[0048] In other words, the current field device (component) implements a standardized information model according to the companion standards registered by the OPC UA Foundation in at least some cases. (The DI model is also known as OPC 10000-100, the PADIM is also known as OPC 30081, etc.). Thus, the model-aware OPC UA client has a business logic for understanding the data model of such devices. In at least some projects, an engineering tool can be used, which refers to the standard VDI 2658. This engineering tool is about creating process automation solutions based on the modular method specified in VDI 2658. This method envisions an information model that provides data abstraction for all components required to create an automation solution for a process industry. This abstraction can be achieved in so-called "common data classes" (CDCs); for example, see Figure 6aThe example shown. Since components such as sensors and / or actuators are used in modules of automation solutions, a CDC corresponding to the functionality of the instrumented device (also known as field device or component) can be found. As an example, a temperature transmitter (sensor) can be represented by AnaMon (“analog monitoring”) specified in VDI 2658. However, even if an instrument with OPC UA connectivity implements one of the standardized information models in the standardized information model, integrating the instrument into a VDI 2658-related automation solution may require a large amount of manual mapping effort. This is because the models of the instrument and the CDC are only similar and may be semantically equivalent but not identical. Furthermore, the PADIM model only defines a “framework” for describing the signals of field devices, for example, based on NE 131 (see, for example, reference.opcfoundation.org / PADIM / v100 / docs / 8.3). As of today, only engineers can define and / or implement the mapping between the parameters of the instrument and the attributes of the CDC. This requires experts to understand the semantics of the parameters. And although OPC UA envisions means to support the representation of semantic information, it cannot be taken for granted that the actual implementation of the data model (OPC UA - address space) will take advantage of these opportunities.

[0049] To better understand what is found in the address space of the OPC UA server of an instrument, the PADIM model utilizes the OPC UA-specified concept of a dictionary. This can enable the automatic interpretation of the data found in the address space. However, in the case of focusing on the semantics specified by ECLASS / CDDIRDI, this does not help with the mapping on the attributes defined by the CDC. Additionally, the understanding of the semantics of individual parameters may not be able to describe the functional consistency existing between the attributes of the CDC. A device can implement the modular concept defined by the DI model. If a device implements multiple instances of various CDCs, the dictionary approach of adding semantics may not be sufficient. Proper mapping also needs to consider the functional consistency of the attributes within the CDC. Additionally, the individual measurement functions of a device can be represented by the variance of similar CDCs (example AnaMon / AnaView).

[0050] Based on a type-based infrastructure, the target model can represent the mapping of the vendor / device-specific model by simply setting a reference between a variable in the target model and any variable in the device-specific model. The elements in such a solution may include:

[0051] (i) There are known (i.e., easy to find) root nodes where the OPC UA client can start browsing the target model. Referring to the VDI 2658 example, here the OPC UA client finds all CDC instances implemented by the OPC UA server of the device. Example: If the device has two sensors, the OPC UA server will represent two instances of CDC AnaMon.

[0052] (ii) Before adding the proposed solution, it may not matter what information model the device implements. Using predefined references (e.g., the reference "CorrespondsTo") may be sufficient.

[0053] (iii) During runtime, the OPC UA server can synchronize the values of variables connected, for example, by means of the predefined reference "CorrespondsTo". This includes conversions between data types.

[0054] An alternative could be to create a VDI-based facade model on top of the existing PADIM information structure, perhaps using the so-called HasDictionaryEntry reference as defined by OPC UA. The PADIM model already has some references to the IRDI space of the CDD that describes the NE131 kernel. Additionally, a dictionary can be added that represents the common data categories and their attributes specified by VDI 2658. The multi-dictionary system is described in OPC UA Part 19. This method can be easily applied to add VDI2658-CDC specific mappings to any address space. This extension will be found in the device firmware.

[0055] As of today, many devices may be ready to be integrated into industrial systems running on VDI 2658. However, there are other standards for VDI 2658, and more are upcoming. Therefore, it may be advantageous to support a "generic" mapping that is already ready for additional information models to be supported by the device. Although such embedded applications run under constrained resources, the solution envisions the concept of late production steps. Here, the mapping is uploaded according to the customer's order. Essentially, this step is similar to uploading a module to the firmware that extends the address space defined by the OEM.

[0056] To further clarify, the present disclosure is described with reference to the embodiments shown in the drawings. These embodiments are to be considered only as examples and not as limitations. BRIEF DESCRIPTION OF THE DRAWINGS

[0057] These drawings depict:

[0058] Figure 1 Schematically depicts a scenario in an industrial plant according to an embodiment;

[0059] Figure 2 Schematically depicts another scenario in an industrial plant according to an embodiment;

[0060] Figure 3a and Figure 3b Depicts a message sequence diagram according to an embodiment;

[0061] Figure 4 Depicts a flowchart according to an embodiment;

[0062] Figure 5a and Figure 5b Depicts an example of an OPC UA server according to an embodiment;

[0063] Figure 6 depicts an example of CDC AnaMon specified according to VDI 2658 according to an embodiment;

[0064] Figure 6b Depicts an example or excerpt of the OPC UA server address space (OEM model) for which a mapping should be defined;

[0065] Figures 7a to 7c Depicts an example of uploading a module that will extend the address space defined by the OEM to the firmware according to an embodiment. Detailed Description

[0066] Figure 1A scenario in an industrial plant according to an embodiment is schematically illustrated. The industrial plant includes an industrial subsystem 20, which includes at least one control unit PLC 32 and at least one component, namely, at least one sensor 36 and / or at least one actuator 34. The components 34, 36 may interact with the process 25 of the industrial subsystem 20. The industrial process may be configured for producing and / or manufacturing substances, such as materials and / or compounds. The components 34, 36 may respectively include OPC UA servers 35 and 37. The PLC 32 may include an OPC UA client 33. The PLC 32 may use the OPC UA services represented by the control line 31 to control the components 34, 36. To configure the components 34, 36, the scenario may further include a mapping tool 10, which at least includes a processor (μP 14) and an OPC UA client 12. The mapping tool 10 may be configured to construct a mapping definition file 18. The constructed mapping definition file 18 may be configured to access an engineering database 40 and a dictionary database 16. The dictionary database 16 includes at least one dictionary 17. The dictionary 17 contains a list of relationships between at least some of the attributes in the OPC UA data model (also referred to as the "OEM model") of the components 34, 36 and at least some of the parameters of the components 34, 36, where the parameters are related to the engineering database 40. After the mapping definition file 18 is constructed, the mapping definition file 18 may be uploaded to the components 34, 36, thereby enabling the mapping between the attributes and the parameters of the OPC UA data model.

[0067] Figure 2 Another scenario in an industrial plant according to an embodiment is schematically illustrated. Reference numerals identical to those used for Figure 1 represent the same or similar entities. Specifically, Figure 2An example of components 34, 36 is shown. Examples of component 34 as a sensor include a temperature transmitter, a pressure transmitter, and a flow transmitter. Examples of component 36 as an actuator include a positioner. Components 34, 36 are respectively connected to a communication network represented by control line 31 via their OPC UA servers 35 or 37. Control line 31 is shown as a bus (which may represent an Ethernet-based connection), and can also have any topology. Further, a PLC 32 is also shown, and this PLC 32 is also connected to control line 31 via its OPC UA client 33. PLC 32 can be configured to control components 34, 36. Additionally, a mapping tool 10 is shown, and this mapping tool 10 is connected to control line 31 via its OPC UA client 12. Mapping tool 10 can access an engineering database 40 and a dictionary database 16 (both not shown), which can be integrated in the computer components of mapping tool 10 and / or can be arranged anywhere externally. Note that the sensors, actuators, and control units shown are only for example purposes. In fact, the methods described above and / or below are "generic" in a way that it can be a wide variety of sensors, actuators, and control units.

[0068] Figure 3a and Figure 3b A message sequence diagram according to an embodiment is shown. In particular, Figure 3a A computer-implemented method for configuring components 34, 36 of a subsystem 20 of an industrial plant according to an embodiment is depicted (see for example Figure 1 ), the components 34, 36 including OPC UA servers 35, 37 and an OPC UA data model, the OPC UA data model including attributes of components 34, 36. The method includes step 112, which includes: requesting the attributes of the OPC UA data model of OPC UA servers 35, 37. In step 114, the parameters of the engineering database 40 are requested. Steps 112 and 114 can be executed in any order (e.g., in parallel or one step after another). In step 116, a dictionary 17 is constructed, the dictionary including a list of relationships between at least some of the attributes of the OPC UA data model and at least some of the parameters of components 34, 36.

[0069] In step 122, the OPC UA client 12 of the mapping tool 10 selects the OPC UA servers 35, 37 of the components 34, 36. In step 124, the OPC UA client 12 of the mapping tool 10 receives the OPC UA data models of the components 34, 36 from the OPC UA servers 35, 37 of the components 34, 36. The OPC UA data model includes a list of attributes. In step 126, the mapping tool 10 retrieves a list of parameters of the components 34, 36 from the engineering database 40 related to the components 34, 36. In step 128, the mapping tool 10 retrieves a list of relationships between the attributes of the OPC UA data model and the parameters of the components 34, 36 from the dictionary 17 in the dictionary database 16. In step 130, for each attribute in the list of attributes of the OPC UA data model, (the mapping tool 10) checks whether the dictionary 17 contains a relationship including this attribute from the list of relationships. In step 132, for each relationship including this attribute, (the mapping tool 10) adds the relationship to the mapping definition file 18. In step 134, (the mapping tool 10) configures the components 34, 36 by adding parameters to the address space of the OPC UA servers 35, 37 of the components 34, 36 based on the mapping definition file 18 by using OPC UA ReferenceType HasDictionaryEntry. In step 136, the OPC UA client 33 of the control unit (PLC) 32 reads the parameters of the components 34, 36.

[0070] When operating the components, in step 142, the OPC UA client 33 of the PLC 32 requests values from the components 34, 36. In step 144, the OPC servers of the components 34, 36 provide the values to the PLC 32 of the subsystem 20.

[0071] Figure 3b A computer-implemented method for configuring components 34, 36 of an industrial plant subsystem 20 according to an embodiment is depicted (see, for example, Figure 1 ), the components 34, 36 including OPC UA servers 35, 37 and an OPC UA data model, the OPC UA data model including attributes of the components 34, 36. Steps 112 to 132 may be similar or identical to steps 112 to 132 described above (i.e., related to Figure 3a ).

[0072] In step 138, the mapping tool 10 configures the parameters of the OPC UA servers 35, 37 of the components 34, 36 based on the mapping definition file 18 by using the OPC UA ReferenceType CorrespondsTo relationship. When operating the components, in step 152, the OPC UA client 33 of the PLC 32 requests values from the components 34, 36. In step 154, the components 34, 36 process the values based on the mapping definition file 18. In step 156, the OPC servers of the components 34, 36 provide the values to the PLC 32 of the subsystem 20.

[0073] Figure 4 A flowchart according to an embodiment is shown. Reference numerals identical to those used for Figure 3a and / or Figure 3b represent the same or similar entities. Figure 4 The flowchart of includes several sub - flowcharts. Sub - flowchart 110 includes steps 112 to 116, which are related to the preparation of the dictionary 17 (for example, see Figure 1 ). Sub - flowchart 120 includes steps 122 to 136, which are related to configuring the components 34 and 36 by using the reference type called HasDictionaryEntry. Sub - flowchart 121 includes steps 122 to 138, which are related to configuring the components 34 and 36 by using the reference type called CorrespondsTo. Sub - flowchart 140 includes steps 142 and 144, which can be used for an industrial subsystem using components that have been configured by using the reference type called HasDictionaryEntry. Sub - flowchart 150 includes steps 152 to 156, which can be used for an industrial subsystem using components that have been configured by using the reference type called CorrespondsTo.

[0074] Figure 5a and Figure 5b show an example of the OPC UA servers of the components 34, 36 according to an embodiment. Figure 5a and Figure 5b show example attributes of the OPC UA data model on the left side. Figure 5a and Figure 5b show example parameters of the TargetModel on the right side. Figure 5a and Figure 5b The left side of may have the same semantics as the left side of "Attributes of the OPC UA Data Model" (or "OEM Model") in Table 1 (see above), Figure 5a and Figure 5bThe right side may have the same semantics as the right side of Table 1, "Parameters of TargetModel". These examples show the standardized parameter values according to VDI 2658. In the drawings, the hierarchies of both the attributes and the parameters are clearly visible. In Figure 5a it shows the result of configuring components 34, 36 by using a reference type called HasDictionaryEntry. This relationship constructs an indicator from the description of the attribute value (e.g., the left part of a row in Table 1) to the description of the parameter value (e.g., the right part of a row in Table 1). The "right part" advantageously occurs only once, but more than one indicator can point to it, thus reducing the amount of memory required in the component. Figure 5b it shows the result of configuring components 34, 36 by using a bidirectional reference type called CorrespondsTo. Using the CorrespondsTo relationship means that for each attribute entry ("Attributes of the OPC UA Data Model" in Table 1), the parameter entry ("Parameters of TargetModel" in Table 1) is entered into the address space of the OPC UA server of the component. This advantageously enables the component to perform a "from right to left" mapping, i.e., a mapping from the parameter entry of TargetModel to the attribute entry of the OPC UA data model of the component.

[0075] Figure 6a As an example, a segment of a parameter list according to an embodiment is shown. For a general device called "AnaMon" ("Analog Monitoring"), the shown parameters are standardized according to VDI 2658. The specification VDI 2658 defines a set of common data classes (CDCs) and their sets of attributes. The AnaMon list includes administrative values such as OSLevel, and also includes values such as VSclMin or VSclMax for V→ values (process / sensor), Scl→ scale, and Max→ maximum value. This list is an example of the values of "TargetModel", i.e., the bottommost values of the hierarchical list on the "right side" of Table 1.

[0076] Figure 6b It shows an attribute list according to an embodiment, i.e., an excerpt of the OPC UA address space. This list is an example of the values of the "OPC UA data model", i.e., the bottommost values of the hierarchical list on the "left side" of Table 1. This list clearly shows that the OPC UA data model is at least semantically equivalent to TargetModel, but uses a different structure and a different format.

[0077] Figures 7a to 7c It shows an example of uploading a module that extends the OEM-defined address space to the firmware according to an embodiment. Figure 7aShows how to create a mapping definition using the services specified by OPC UA and upload it to the device. The small internal picture is selected to illustrate the TargetModel supported by the component after upload. Figure 7b Shows how to create a mapping definition using the JTAG interface, which is part of the MCU board, and upload it to the device. This step can be performed during the production of the device. The mapping is constructed in sequence. Figure 7c Illustrates the relationship between the OEM model and the TargetModel and how these elements are related to the firmware and the mapping.

[0078] List of reference numerals

[0079] 10 Mapping tool

[0080] 12 OPC UA client of the mapping tool

[0081] 14 Microprocessor

[0082] 16 Dictionary database

[0083] 18 Mapping definition file

[0084] 20 Industrial subsystem

[0085] 25 Industrial process

[0086] 31 Control line

[0087] 32 Control unit, such as PLC

[0088] 33 OPC UA client of the PLC

[0089] 34 Actuator

[0090] 35 OPC UA server of the actuator

[0091] 36 Sensor

[0092] 37 OPC UA server of the sensor

[0093] 39 Communication mapping tool - component

[0094] 40 Engineering database

[0095] 110, 120, 121, 140, 150 subgraphs

[0096] 112 to 156 steps

Claims

1. A computer-implemented method for configuring components (34, 36) of a subsystem (20) of an industrial plant, the components (34, 36) including OPC UA servers (35, 37) and an OPC UA data model, the OPC UA data model including attributes of the components (34, 36), the method comprising the steps of: Step 122: Selecting, by an OPC UA client (12) of a mapping tool (10), the OPC UA servers (35, 37) of the components (34, 36); Step 124: Receiving, by the OPC UA client (12) of the mapping tool (10), from the OPC UA servers (35, 37) of the components (34, 36), the OPC UA data model of the components (34, 36), wherein the OPC UA data model includes a list of attributes; Step 126: Retrieving, by the mapping tool (10), a list of parameters of the components (34, 36) from an engineering database (40) related to the components (34, 36); Step 128: Retrieving, by the mapping tool (10), from a dictionary (17) in a dictionary database (16), a list of relationships between the attributes of the OPC UA data model and the parameters of the components (34, 36); Step 130: For each attribute in the list of attributes of the OPC UA data model, checking, by the mapping tool (10), whether the dictionary (17) contains a relationship from the list of relationships that includes the attribute; Step 132: For each relationship that includes the attribute, adding, by the mapping tool (10), the relationship to a mapping definition file (18); Step 134: Configuring, by the mapping tool (10), the components (34, 36) by adding the parameters to the address space of the OPC UA servers (35, 37) of the components, based on the mapping definition file (18), using OPC UA ReferenceTypeHasDictionaryEntry; And Step 136: Reading, by an OPC UA client (33) of a control unit PLC (32), the parameters of the components (34, 36).

2. The computer-implemented method according to claim 1, further comprising the steps of: Step 142: Requesting, by the OPC UA client (33) of the PLC (32), a value from the components (34, 36); and Step 144: Providing, by the OPC server of the components (34, 36), the value to the PLC (32) of the subsystem (20).

3. A computer-implemented method for configuring components (34, 36) of a subsystem (20) of an industrial plant, the components (34, 36) including OPC UA servers (35, 37) and an OPC UA data model, the OPC UA data model including attributes of the components (34, 36), the method comprising the steps of: Step 122: The OPC UA client (12) of the mapping tool (10) selects the OPC UA servers (35, 37) of the components (34, 36); Step 124: The OPC UA client (12) of the mapping tool (10) receives the OPC UA data model of the components (34, 36) from the OPC UA servers (35, 37) of the components (34, 36), where the OPC UA data model includes a list of attributes; Step 126: The mapping tool (10) retrieves a list of parameters of the components (34, 36) from the engineering database (40) related to the components (34, 36); Step 128: The mapping tool (10) retrieves a list of relationships between the attributes of the OPC UA data model and the parameters of the components (34, 36) from the dictionary (17) in the dictionary database (16); Step 130: For each attribute in the list of attributes of the OPC UA data model, the mapping tool (10) checks whether the dictionary (17) contains a relationship from the list of relationships that includes the attribute; Step 132: For each relationship that includes the attribute, the mapping tool (10) adds the relationship to the mapping definition file (18); And Step 138: The mapping tool (10) configures the parameters of the OPC UA servers (35, 37) of the components (34, 36) based on the mapping definition file (18) by using the OPC UA ReferenceType CorrespondsTo relationship.

4. The computer-implemented method according to claim 1, further comprising the following steps: Step 152: The OPC UA client (33) of the PLC (32) requests a value from the components (34, 36); Step 154: The components (34, 36) process the value based on the mapping definition file (18); And Step 156: The OPC server of the components (34, 36) provides the value to the PLC (32) of the subsystem (20).

5. The method according to claim 2 or 4, where providing (144, 156) the value to the OPC UA servers (35, 37) or providing (144, 156) the value from the OPC UA servers (35, 37) includes a conversion between the data types of the values.

6. The method according to any one of the preceding claims, further comprising the following steps: Step 112: Request the attributes of the OPC UA data model of the OPC UA servers (35, 37); Step 114: Request the parameters of the engineering database (40); And Step 116: Construct a dictionary (17) that includes the list of relationships between at least some of the attributes of the OPC UA data model and at least some of the parameters of the components (34, 36).

7. The method according to any one of the preceding claims, The retrieval (126) of the parameter list of the components (34, 36) from the engineering database (40) further includes: retrieving a list of abstract data types of the components (34, 36).

8. The method according to any one of the preceding claims, wherein the engineering database (40) includes parameters of the components (34, 36) according to VDI 2658.

9. A mapping tool (10) configured to perform the method according to any one of the preceding claims.

10. Use of a mapping tool (10) according to claim 9 for configuring components (34, 36) of a subsystem (20) of an industrial plant.

11. A computer program product comprising instructions which, when executed by a computer (12) on a mapping tool (10) according to claim 9, cause the computer and / or controller to perform the method according to any one of claims 1 to 8.

12. A computer-readable storage medium having stored thereon the computer program according to claim 11.