Authentication logic for OPC UA connected devices

Abstract

A method performed by an OPC UA client (104) is provided, the method comprising importing a node set file (106) related to an OPC UA enabled automation device, the node set file defining a validation logic (108) used to validate data to be written to the automation device; preparing data to be written to the automation device; and validating the prepared data using the validation logic. A method performed by an OPC UA server (102) is also provided, the method comprising importing a node set file related to an automation device in which the OPC UA server is embedded, the node set file defining a validation logic for validating data to be written to the automation device; receiving data to be written to the automation device; and validating the received data using the validation logic.

Description

Technical Field

[0001] This invention relates to authentication logic for OPC UA connected devices. Background Technology

[0002] Automated industrial plants typically consist of numerous field devices used to implement industrial production processes. These field devices are controlled by process controllers, which are part of a distributed control system (DCS). Fieldbus communication interfaces are used to connect field devices to the process controllers. The continuous growth in functionality of field devices has led to complex parameter sets and intricate device descriptions involving detailed constraints on the environment in which parameters are used. Parameter settings can be interdependent: modifying a parameter often requires verification by combining it with other settings. Verification logic designed to protect the integrity of device settings is typically embedded in the firmware of the field devices themselves.

[0003] Verification logic can be implemented in various ways. Fieldbus standards (such as FF, HART, PROFIBUS) allow the use of standardized Electronic Device Description Languages ​​(EDDL, specified by IEC 61804) to enable engineering tools to manage device parameters. Similarly, the Field Device Tool (FDT) standard IEC 62453 allows field device vendors to provide Device Type Managers (DTMs) for managing device parameters.

[0004] The drawback of these approaches is the repetitive work involved in implementing the verification logic as either EDDL-based or DTM-based logic. Furthermore, the use of EDDL can only be achieved in conjunction with an EDD interpreter, which has high maintenance costs.

[0005] Many Industry 4.0 concepts assume that future field device connectivity will be achieved using the Open Platform Communications Unified Architecture (OPC UA). Current EDDL / FDT-based solutions are unsuitable for field devices that rely primarily on OPC UA for connectivity. Future field devices, including those with OPC UA servers, will be described using an XML schema called a node set file. The node set file describes the address space of the field device. OPC UA clients can import node set files to discover how to interact with field devices by reading / writing data or calling methods. Summary of the Invention

[0006] Therefore, there is a need to improve the verification of parameter settings for field devices in industrial automation systems. This need is addressed by the subject matter of the independent claims. Optional features are set forth in the dependent claims.

[0007] According to the first aspect, a method executed by an OPC UA client is provided. The method includes: importing a node set file associated with an OPC UA-enabled automation device, the node set file defining validation logic used to validate data to be written to the automation device; preparing the data to be written to the automation device; and using the validation logic to validate the prepared data.

[0008] The data prepared for verification may include verifying the settings in the address space of the automated device. "Automated device" specifically refers to a field device or instrument, but can be any device with OPC UA enabled.

[0009] The method may also include writing verified data to the automated device. In one example, data is written to the automated device during integration into an automated industrial plant. In another example, data is written to the automated device to convert parameters according to a first standard into parameters according to a second standard, wherein the first and second standards are incompatible with each other.

[0010] It should be understood that data can be prepared and validated in this way without automated equipment. In a favorable example, data is prepared before the OPC UA server where the automated equipment is deployed. In other words, data can be prepared without the OPC client needing to connect to the automated equipment.

[0011] Therefore, this disclosure proposes adding business logic described by Python scripts to a node set file, enabling a generic approach to verify settings in the address space of field devices connected to OPC UA without having to connect to the field devices. An OPC UA client that understands where the verification logic is stored and how to invoke and process the execution of the verification logic can prepare a valid dataset for missing field devices. Storing the verification logic in a node set file in this way reduces the workload required to create and maintain logic that protects the logical integrity of device data settings. Furthermore, the logic executed in the OPC UA client can be the same as the logic used in the OPC UA server, meaning that the logic only needs to be written once. This reduces the workload required to provide a runtime environment in device management tools. The node set file can also be used in a manner similar to a digital twin representing a device. Moreover, maintaining a runtime environment using this verification logic is easier than maintaining an EDD interpreter—especially when implemented as script logic.

[0012] According to a second aspect, a method performed by an OPC UA server is provided. The method includes: importing a node set file associated with an automation device in which an OPC UA server is embedded, the node set file defining validation logic used to validate data to be written to the automation device; receiving the data to be written to the automation device; and using the validation logic to validate the received data.

[0013] An OPC UA server can be an aggregation server. By deploying authentication logic to the aggregation server, other devices, such as client devices and the aggregated server, can be kept as simple as possible.

[0014] In the second aspect of the method, the automated device can operate according to a first standard that requires the use of a first variable to trigger a service and a second variable as a state variable for reporting the service's status. Verification logic is configured to represent the first and second variables using a single third variable according to a second standard that is incompatible with the first standard. In this case, the verification logic may include state logic and triggering logic, wherein the triggering logic is configured to monitor changes in the third variable and, in response to a detected change, trigger a write to the first variable, and wherein the state logic is configured to monitor the second variable and write state changes in the second variable to the third variable. In this way, verification logic can be used to bridge incompatible standards.

[0015] "Verification logic" refers to logic designed to protect the integrity of device settings and may be alternatively referred to as "integrity protection logic." In some implementations, verification logic may implement so-called "business logic," which, in the context of this disclosure, should be understood as logic relating to the parameters or settings of a device with OPC UA enabled, rather than logic relating to the methods of doing business. "Parameters" may also be referred to as "attributes."

[0016] In any respect, the verification logic can be implemented using Python scripts or any other suitable language (especially scripting languages).

[0017] Validation logic can be stored in a node set file in an appropriate manner. In one example, the validation logic is stored within a predefined XML element in the node set file; the first or second approach also includes identifying the element containing the validation logic according to established conventions. Alternatively, in a second example, the validation logic can be stored in the node set file using a value attribute describing a UAVariable; the first or second approach also includes identifying the UAVariable containing the validation logic according to established conventions. Therefore, this convention provides OPC UA clients and servers with the necessary knowledge about the location of the validation logic in the node set file.

[0018] In any respect, the validation data may include using an information model to identify the type of variable to be written that indicates a validation requirement, and executing validation logic associated with the variable to be written in response to that identification. In this case, the information model may also define state variables to carry the results of the validation, and the method further includes modifying the state variables to indicate the result of executing the validation logic associated with the variable to be written.

[0019] In any respect, the verification logic can be stored in encrypted form in the node set file to improve security against attackers who attempt to target the verification logic.

[0020] According to the third aspect, a method is provided, comprising: creating a node set file as described with respect to the first and second aspects.

[0021] Any method described herein may also include the step of using an industrial automation system to implement / execute / control an industrial manufacturing process, the industrial automation system including the automated equipment with written data. Any method may include the foregoing step of integrating the automated equipment into the industrial automation system.

[0022] According to the fourth aspect, a computer-readable data carrier or data carrier signal is provided that carries a node set file created using the method of the third aspect.

[0023] According to a fifth aspect, a computing device is provided, including a processor configured to perform the methods of any one of the first, second, and third aspects.

[0024] According to a sixth aspect, a computer program product including instructions is provided, which, when executed by a computing device, cause or enable the computing device to perform any one of the first, second, and third aspects.

[0025] According to a seventh aspect, a computer-readable data carrier or data carrier signal carrying instructions is provided, which, when executed by a computing device, causes or enables the computing device to perform any one of the methods of the first, second, and third aspects.

[0026] This invention may include one or more aspects, examples, or features, either individually or in combination, whether specifically disclosed in the combination or individually. Any optional feature or sub-aspect of one of the foregoing aspects may be applied, as appropriate, to any of the other aspects.

[0027] These and other aspects of the invention will become apparent and will be illustrated with reference to the embodiments described below. Attached Figure Description

[0028] Specific embodiments will now be given by way of example only, with reference to the accompanying drawings, wherein:

[0029] Figure 1 The diagram illustrates the configuration of the field equipment according to the first example;

[0030] Figure 2 The diagram illustrates the configuration of the field equipment according to the second example;

[0031] Figure 3 This illustrates a non-hierarchical, asymmetric reference type for variables;

[0032] Figure 4 It shows the result of Figure 3 The script to which the reference of the type shown is targeted;

[0033] Figure 5 The diagram illustrates the concept of node set integrity protection;

[0034] Figure 6 The illustration shows an example use case involving script parameter verification performed in relation to a field device conforming to the PA-DIM model specified by OPC UA;

[0035] Figure 7 The illustration shows another example use case involving bridging to IEC 61499; and

[0036] Figure 8 The illustration shows a computing device that can be used according to the devices and methods disclosed herein. Detailed Implementation

[0037] Figure 1 The illustration shows the configuration or parameterization of the field equipment according to the first example.

[0038] The field device (not shown) includes an OPC UA server 102. OPC UA is a platform-independent, service-oriented client-server architecture that transmits data such as control values, measurements, and parameters, and semantically describes the data. The OPC UA server 102 receives and exposes such data from the field device. The OPC UA server 102 supports an information model that defines how data is categorized and classified. The representation of the exposed data is called the address space.

[0039] OPC UA client 104 communicates with OPC UA server 102. OPC UA client 104 can be an application connected to OPC UA server 102. OPC UA client 104 can be used, for example, to look up data in the address space of OPC UA server 102, to read and write server data, to subscribe to certain data changes or events (such as alerts), and to invoke server methods. Communication between OPC UA server 102 and OPC UA client 104 is handled by a service.

[0040] The OPC UA server 102 is described by a node set file 106. The node set file 106 provides a mechanism for data exchange within the OPC UA environment and can take the form of an XML file. The node set file 106 describes the address space of the OPC UA server 102.

[0041] According to this disclosure, node set file 106 also includes verification logic 108 for ensuring the logical integrity of device settings. Verification logic 108 may include logic described in a PYTHON script added to node set file 106 to enable a generic method to verify settings in the address space of the OPC UA server 102 of the field device without having to connect to the device. Various ways of integrating logic into node set file 106 and examples of suitable verification logic are described below.

[0042] To configure the field device, OPC UA client 104 imports node set file 106 to discover how to interact with the field device. During configuration, OPC UA client 102 uses authentication logic 108 to ensure the validity of data written to the OPC UA server 102 of the field device.

[0043] OPC UA server 102 similarly uses verification logic 108 to verify data.

[0044] In this way, the OPC UA client 104, which is capable of importing verification logic 108 and knows how to call and process the execution of script logic, can prepare a valid dataset for field devices, even in the absence of field devices.

[0045] Figure 2The illustration shows a configuration of a field device according to a second example, where an OPC UA system is organized according to an aggregation architecture involving an aggregation server 202 and at least one aggregated server 204. The aggregated server 204 is an OPC UA server for entities within the automation system, such as field devices. The aggregation server 202 connects to each underlying aggregated server 204 via an OPC UA service and aggregates their type, instance, and structure information. Therefore, a single server can be used to connect to multiple other servers and represent their information in a unified manner. In this way, clients connected to the aggregation server 202 can access data from multiple aggregated servers 204 from a single source. In this example, the verification logic 108 is executed only by the aggregation server 202, making it possible to use a generic OPC UA client. In this way, an OPC UA client can be implemented on resource-constrained devices where script logic cannot run due to the resource consumption of the script interpreter. Figure 2 The symbols (following the UML diagram syntax) indicate the number of possible instances in the depicted relationship. Therefore, there exists an aggregation server 202 (“[1]”) that can aggregate multiple (“[n]”) OPC UA servers as aggregated servers 204. For brevity and considering the application of script logic, each aggregated OPC UA server (“[1]”) is described by a (“[1]”) node set file 106, but it should be understood that this disclosure is not limited thereto. Therefore, a single (“[1]”) aggregation server 202 can handle multiple (“[n]”) node set files 106, each associated with an aggregated OPC UA server 204. It should be understood that some aggregated servers 204 may not require any additional verification logic and can be aggregated by browsing their address space.

[0046] In any of the examples described herein, verification logic 108 may be incorporated into node set file 106 in any of a variety of suitable ways.

[0047] According to the first implementation, the verification logic 108 is embodied as a Python script and stored in an XML element designated as "Extension" in the node set file 106, which may refer to, for example, a vendor-specific pattern. In this implementation, the OPC UA client is configured to identify the extension containing the script function. This identification can be executed according to established conventions. Similarly, the OPC UA server can utilize the same verification logic 108 to protect the logical integrity of the data. Advantageously, the work required to provide verification logic for protecting the logical integrity of the data is reduced because the verification logic only needs to be written once. Another advantage of this implementation is its ability to hide the verification logic.

[0048] According to the second implementation, the PYTHON script is stored in node set file 106 using the value attribute described by the UAVariable. In this implementation, the OPC UA client is configured to identify the UAVariable containing the script function. This identification can be executed again according to established conventions. An advantage over the first implementation is that the second implementation enables debugging (inspection) of the script function on the OPC UA server. Furthermore, if no node set file is available, the OPC UA client can immediately import the verification logic 108 from the OPC UA server. (Since the node set file 106 represents at least a portion of the address space, providing script logic in the value of the variable makes the script available by reading the node set file 106 or reading (e.g., via an OPC UA read service) the value of the variable. The script logic 108 can enter the address space of the OPC UA server in any suitable manner.) Another advantage is that the PYTHON script can be modified if the UAVariable is writable.

[0049] In the second implementation, a reserved namespace can be used to create the information model to avoid conflicts with other application-specific content in the address space. The reserved namespace defines a non-hierarchical asymmetric reference type 300 named "HasValidation," for example, as... Figure 3 As shown in the image. The reverse name can be "Validates". A reference of type "HasValidation" targets variable 400, which stores PYTHON script 404 in a string, as shown in the image. Figure 4 As shown in the diagram. In this way, any writable element in the address space can reference the verification logic 108. If a value is written to variable 402 that references the verification logic 108, the OPC UA client can load and execute the PYTHON script 404 via a variable of type "HasValidation" 300. The OPC UA client 104 provides an execution environment that includes a PYTHON script interpreter and callback interfaces that enable reading and writing of other data in the address space. By established convention, the PYTHON verification script 404 sets an output flag indicating the result of the integrity check. Furthermore, the same script 404 can be executed internally within the device-embedded OPC UA server 102, and the result of this script execution is reflected in another status variable. In this way, the execution of the verification logic is triggered after a write operation.

[0050] The information model can also establish conventions defining how PYTHON scripts, such as 404 errors, can access variables in the address space. These conventions can be used to enable script 404s to collect data needed for verification, and / or to repair settings and indicate the validity of datasets.

[0051] Figure 5 The concept of node set integrity protection is illustrated. Since a Python script 404 could present a target to an attacker, asymmetric encryption methods such as PKI can be used to protect the node set file 106 from unauthorized modification. The node set file 106 can be protected using a signature 502 created with the private key 504, while the same signature 502 and the content of the node set file 106 can be verified using the public key 506. The private key 504, public key 506, and node set file 106 were created during the development 508 of the OPCUA server 102. The private key 504 is stored securely. The public key 506 is derived from the private key 504. The private key 504 is used to encrypt the signature 502 of the node set file 106. The signature 502 hashes the node set file 106 to represent the contents of the compressed form of the node set file 106.

[0052] Figure 6 The illustration depicts an example use case involving scripted parameter verification performed in relation to a field device conforming to the PA-DIM model specified by OPC UA. The field device (not shown) operates using a set of parameters, where parameter V2 depends on the values ​​of parameters V1 and V3, i.e., V2 = f(V1, V3). Aggregation server 202 aggregates the field device's parameters by using proxy parameters V1', V2', and V3' to represent the field device's parameters. Verification logic 108 is configured to monitor changes in parameter V1', which in turn monitors changes in the aggregated parameter V1. If V1 changes, V1' also changes, triggering the execution of verification logic 108. Since V2 depends on the values ​​of parameters V1 and V3, verification logic 108 reads the value of parameter V3 through its proxy parameter V3'. Verification logic 108 calculates V2' and writes the new value to V2', which is then forwarded to V2.

[0053] In addition to the device integration examples mentioned above, write-triggered verification logic can also be used to bridge the gap between control applications with incompatible design principles.

[0054] In particular, Figure 7The illustration depicts another example use case involving bridging to IEC 61499. According to IEC 61499, control functions (services) are triggered by writing to a variable (“event”) and their completion status is reported via a separate variable (“feedback”). Conversely, according to VDI 2658, control functions (state machines) are managed by means of a single variable written to trigger execution, and status feedback is passed through the same variable. Due to these different design principles, a programmable logic controller (PLC) applying IEC 61499 cannot be used in a modular automation system applying VDI 2658. Although VDI 2658 runs on OPCUA, an aggregated OPC UA server 202 implementing the verification logic 108 as described herein can be configured to bridge the gap between different standards (VDI 2658 / IEC 61499). The address space of the aggregated server 202 represents a service object defined in VDI 2658 with control and status variables (V1). The variable V1 is used to represent (aggregate) the control object of another PLC's OPC UA server 204 conforming to IEC 61499. One variable (V1a) is used to trigger a service, while the other variable (V1b) is used as a service status reporting variable. Variables V1a' and V1b' are aggregated representations of variables V1a and V1b, respectively. In this case, the verification logic 108 includes state logic 108a and trigger logic 108b. The trigger logic 108b monitors changes in variable V1 and writes the resulting trigger to the proxy variable V1a', which is then forwarded to the aggregated variable V1a. The state logic 108a monitors the proxy variable V1b' to detect changes occurring in the aggregated state variable V1b and writes the state change on variable V1b' back to variable V1.

[0055] The method described in this paper can be extended to the application logic of automated devices, for example, to various parts of the firmware, including logic related to I / O functions that handle hardware details, protocol stacks, general mathematical libraries, etc.

[0056] See now Figure 8 The illustration shows a high-level diagram of an exemplary computing device 800 that can be used according to the systems and methods disclosed herein. The computing device 800 includes at least one processor 802 that executes instructions stored in memory 804. For example, the instructions may be instructions for implementing functionality described as being performed by one or more of the components discussed above, or instructions for implementing one or more of the methods described above. The processor 802 can access memory 804 via a system bus 806. In addition to storing executable instructions, memory 804 may also store session inputs, scores assigned to session inputs, etc.

[0057] The computing device 800 also includes a data storage 808 accessible by the processor 802 via the system bus 806. The data storage 808 may include executable instructions, log data, etc. The computing device 800 also includes an input interface 810, which allows external devices to communicate with the computing device 800. For example, the input interface 810 can be used to receive instructions from external computer devices, users, etc. The computing device 800 also includes an output interface 812, which interfaces the computing device 800 with one or more external devices. For example, the computing device 800 can display text, images, etc., through the output interface 812.

[0058] External devices intended to communicate with computing device 800 via input interface 810 and output interface 812 can be included in an environment that provides a user interface of virtually any type to which the user can interact. Examples of user interface types include graphical user interfaces, natural user interfaces, and so on. For example, a graphical user interface can accept input from a user using multiple input devices such as a keyboard, mouse, remote control, etc., and provide output on an output device such as a display. Furthermore, a natural user interface allows the user to interact with computing device 800 in a manner unconstrained by input devices such as keyboards, mice, remote controls, etc. Instead, a natural user interface can rely on speech recognition, touch and stylus recognition, on-screen and near-screen gesture recognition, air gestures, head and eye tracking, voice and speech, vision, touch, gestures, machine intelligence, and so on.

[0059] Furthermore, although illustrated as a single system, it should be understood that computing device 800 can be a distributed system. Therefore, for example, several devices can communicate via a network connection and collaboratively perform tasks described as being performed by computing device 800.

[0060] The various functions described herein can be implemented in hardware, software, or any combination thereof. If implemented in software, the functions can be stored or transmitted as one or more instructions or code on a computer-readable medium. Computer-readable media include computer-readable storage media. A computer-readable storage medium can be any available storage medium that can be accessed by a computer. By way of example and not limitation, such computer-readable storage media can include FLASH storage media, RAM, ROM, EEPROM, CD-ROM or other optical disc storage, disk storage or other magnetic storage devices, or any other medium that can be used to carry or store the required program code in the form of instructions or data structures and that can be accessed by a computer. Disks and optical discs as used herein include compact discs (CDs), laser discs, optical discs, digital versatile discs (DVDs), floppy disks, and Blu-ray discs (BDs), where disks typically reproduce data magnetically, and optical discs typically reproduce data optically using lasers. Furthermore, the propagation of signals is not included within the scope of computer-readable storage media. Computer-readable media also include communication media, including any medium that facilitates the transfer of a computer program from one place to another. For example, a connection can be a communication medium. For example, if software is transmitted from a website, server, or other remote source using coaxial cable, fiber optic cable, twisted pair, digital subscriber line (DSL), or wireless technology (such as infrared, radio, and microwave), then coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technology (such as infrared, radio, and microwave) are all included in the definition of communication media. Combinations of the above should also be included within the scope of computer-readable media.

[0061] Alternatively or additionally, the functionality described herein can be performed at least in part by one or more hardware logic components. For example, but not limited to, illustrative types of hardware logic components that can be used include field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), system-on-a-chip (SoCs), complex programmable logic devices (CPLDs), etc.

[0062] It should be understood that, in addition to the functions mentioned, the circuit described above may also have other functions, and these functions may be performed by the same circuit.

[0063] The applicant hereby separately discloses each individual feature described herein, as well as any combination of two or more such features, provided that such features or combinations can be implemented based on the entire specification and in conjunction with common general knowledge of those skilled in the art, regardless of whether such features or combinations of features solve any problem disclosed herein, and without limiting the scope of the claims. The applicant notes that aspects of the invention can consist of any such individual feature or combination of features.

[0064] It should be noted that embodiments of the present invention are described with reference to different categories. In particular, some examples are described with reference to methods, while others are described with reference to devices. However, those skilled in the art will understand from the description that, unless otherwise stated, any combination of features involving different categories, in addition to any combination of features belonging to one category, is also considered to be disclosed in this application. However, all features can be combined to provide synergistic effects that are not merely the simple addition of features.

[0065] Although the invention has been illustrated and described in detail in the accompanying drawings and the foregoing description, such illustrations and descriptions should be considered exemplary rather than limiting. The invention is not limited to the disclosed embodiments. Other variations of the disclosed embodiments will be understood and implemented by those skilled in the art through study of the drawings, the disclosure, and the appended claims.

[0066] The word "including" does not exclude other components or steps.

[0067] The indefinite articles “one” or “one” do not exclude the plural. Furthermore, the articles “one” and “one” used in this text should generally be interpreted as meaning “one or more”, unless otherwise stated or clearly indicated from the context as referring to the singular form.

[0068] A single processor or other unit can implement several of the functions described in the claims.

[0069] The fact that certain measures are described in mutually different dependent claims does not mean that a combination of these measures cannot be used advantageously.

[0070] Computer programs can be stored / distributed on suitable media, such as optical or solid-state media provided with or as part of other hardware, but can also be distributed in other forms, such as via the Internet or other wired or wireless communication systems.

[0071] Any reference numerals in the claims should not be construed as limiting the scope.

[0072] Unless otherwise stated, or as can be clearly seen from the context, the phrase “A and / or B” as used herein is intended to mean all possible permutations of one or more of the listed items. That is, the phrase “X includes A and / or B” is satisfied by any of the following instances: X includes A; X includes B; or X contains both A and B.

Claims

1. A method executed by an OPC UA client, the method comprising: Import a node set file related to the automation device with OPC UA enabled, wherein the node set file describes the address space of the OPC UA server (102) of the automation device and also includes verification logic used to verify the data to be written to the automation device. Data to be written into the automated device; Use the verification logic to verify the prepared data; as well as The verified data is written to the automated device; The method also includes using an industrial automation system to perform an industrial manufacturing process, the industrial automation system including the automated equipment to which data has been written.

2. The method of claim 1, wherein the data is prepared before the OPC UA server is deployed with the automation equipment.

3. The method according to any one of claims 1 to 2, wherein the verification logic is implemented using a Python script.

4. The method according to any one of claims 1 to 2, wherein the validation logic is stored in the node set file as a predetermined XML element, and the method further includes identifying the element containing the validation logic according to established conventions.

5. The method according to any one of claims 1 to 2, wherein the verification logic is stored in the node set file using the value attribute described by the UAVariable, and the method further includes identifying the UAVariable containing the verification logic according to established conventions.

6. The method of any one of claims 1 to 2, wherein verifying the data includes using an information model to identify whether the variable to be written is of a type indicating a verification requirement, and in response to the identification, performing the verification logic associated with the variable to be written.

7. The method of claim 6, wherein the information model further defines a state variable for carrying the result of the verification, and the method further includes modifying the state variable to indicate the result of performing the verification logic associated with the variable to be written.

8. The method according to any one of claims 1 to 2, wherein the verification logic is stored in encrypted form in the node set file.

9. A method performed by an OPC UA server, the method comprising: Import a node set file associated with the automation device in which an OPC UA server is embedded, the node set file describing the address space of the OPC UA server and also including verification logic used to verify the data to be written to the automation device; Receive data to be written to the automated equipment; as well as The received data is verified using the verification logic. The method also includes using the verified data to parameterize field devices and using an industrial automation system to perform an industrial manufacturing process, the industrial automation system including the automated devices to which the data has been written.

10. The method of claim 9, wherein the OPC UA server is an aggregation server.

11. The method of claim 9 or 10, wherein the automated device operates according to a first standard, the first standard requiring the use of a first variable to trigger a service and the use of a second variable as a status variable for reporting the status of the service, wherein the verification logic is configured to use a single third variable to represent the first variable and the second variable according to a second standard that is incompatible with the first standard.

12. The method of claim 11, wherein the verification logic includes state logic and trigger logic, wherein the trigger logic is configured to monitor changes in the third variable and, in response to a detected change, write a trigger to the first variable, and wherein the state logic is configured to monitor the second variable and write state changes in the second variable to the third variable.

13. The method according to any one of claims 9-10 and 12, wherein the verification logic is implemented using a Python script.

14. The method of any one of claims 9-10 and 12, wherein the validation logic is stored in the node set file as a predetermined XML element, the method further comprising identifying the element containing the validation logic according to established conventions.

15. The method of any one of claims 9-10 and 12, wherein the verification logic is stored in the node set file using a value attribute described by the UAVariable, the method further comprising identifying the UAVariable containing the verification logic according to established conventions.

16. The method of any one of claims 9-10 and 12, wherein verifying the data includes using an information model to identify whether the variable to be written is of a type indicating a verification requirement, and in response to the identification, performing the verification logic associated with the variable to be written.

17. The method of claim 16, wherein the information model further defines a state variable for carrying the result of the verification, and the method further includes modifying the state variable to indicate the result of performing the verification logic associated with the variable to be written.

18. The method according to any one of claims 9-10 and 12, wherein the verification logic is stored in encrypted form in the node set file.

19. A method comprising: Create a node set file as claimed in claim 1 or 9, the node set file relating to an automation device with OPC UA enabled, wherein the node set file describes the address space of the OPC UA server (102) of the automation device and includes the verification logic used to verify the data to be written to the automation device.

20. A computing device comprising a processor configured to perform the method according to any one of the preceding claims.

21. A computer-readable medium comprising instructions that, when executed by a computing device (800), cause the computing device to perform the method according to any one of claims 1-19.

Images