Patent Description:
Automated industrial plants typically comprise many field devices for implementing an industrial production process. Field devices are controlled by process controllers forming part of a distributed control system (DCS). Fieldbus communication interfaces are used to connect the field devices to the process controllers. Field devices are continually growing in functionality, resulting in complex parameter sets and complex device descriptions involving exhaustive conditional constraints on the circumstances under which parameters are used. Parameter settings may be interdependent: a modification to one parameter often requires a setting to be validated in combination with other settings. Validation logic that is intended to protect the integrity of the device settings is typically embedded within the firmware of the field device itself.

The validation logic may be implemented in various ways. Fieldbus standards (such as FF, HART, PROFIBUS) allow use of the standardized Electronic Device Description Language (EDDL, as specified by IEC <NUM>) to enable engineering tools to manage device parameters. Equally, the Field Device Tools (FDT) standard, IEC <NUM>, allows field device suppliers to offer a Device Type Manager (DTM) for managing device parameters.

The drawback of these solutions is the duplicated effort involved in implementing the validation logic as EDDL-implemented or DTM-implemented logic. Moreover, the use of EDDL is possible only in conjunction with an EDD interpreter that is costly to maintain.

Many "industry <NUM>" concepts assume that field device connectivity will be implemented in the future using the Open Platform Communications Unified Architecture (OPC UA). The current solutions based on EDDL/FDT do not suit field devices that will implement OPC UA as their main form of connectivity. Future field devices comprising OPC UA servers will be described by means of an XML schema called a nodeset file. A nodeset file describes the address space of the field device. An OPC UA client can import the nodeset file to discover how to interact with the field device by reading / writing data or invoking methods.

<CIT> discloses an integrity check performed on a measurement dataset for a field device on the basis of operational policies set out in a configuration dataset for the field device. <CIT> provides background information on selective address space aggregation.

There is therefore a need for improvements in the validation of parameter settings of a field device of an industrial automation system. This need is met by the subject-matter of the independent claims. Optional features are set forth by the dependent claims.

According to a first aspect, there is provided a method performed by an OPC UA client according to claim <NUM>.

Validating the prepared data may comprise validating settings in the address space of the automation device. By "automation device" is meant in particular a field device or an instrument device but the automation device could be any OPC UA-enabled device.

The method comprises writing the validated data to the automation device. In one example, the data is written to the automation device during integration of the automation device into an automated industrial plant. In another example, the data is written to the automation device to convert parameters according to a first standard to parameters according to a second standard, wherein the first and second standards are mutually incompatible.

It will be understood that the data may prepared and validated in this way in the absence of the automation device. In one advantageous example, the data is prepared before an OPC UA server of the automation device has been deployed. Stated differently, the data may be prepared without the OPC client necessarily being connected to the automation device.

The present disclosure thus proposes to add PYTHON script-described business logic to nodeset files that enables a generic approach to validating settings in the address space of an OPC UA-connected field device without necessarily being connected to the field device. An OPC UA client having knowledge of a convention specifying where the validation logic is stored, and how to invoke and handle the execution of the validation logic, can prepare valid datasets for absent field devices. Storing the validation logic in the nodeset file in this way reduces the effort needed to create and maintain the logic that protects the logical integrity of device's data settings. Furthermore, the logic executed in the OPC UA client may be the same as that used in the OPC UA server, meaning the logic needs to be written only once. The effort needed to provide a runtime environment in a device management tool is thereby reduced. The nodeset file may furthermore be used in a way akin to a digital twin representing the device. Additionally, maintenance of the runtime environment using such validation logic, particularly when implemented as scripted logic, is easier than the maintenance of an EDD interpreter.

According to a second aspect, there is provided a method performed by an OPC UA server according to claim <NUM>.

The OPC UA server may be an aggregating server. By deploying the validation logic to an aggregating server, other devices such as the client device and aggregated servers may be kept as simple as possible.

In the method of the second aspect, the automation device may operate according to a first standard that requires a first variable to be used to trigger a service and a second variable to be used as a status variable for reporting the status of the service, wherein the validation 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 that case, the validation logic may comprise status logic and trigger logic, wherein the trigger logic is configured to monitor changes to the third variable and to write, in response to a detected change, a trigger to the first variable, and wherein the status logic is configured to monitor the second variable and to write status changes in the second variable to the third variable. In this way, the validation logic can be used to bridge between mutually incompatible standards.

By "validation logic" is meant logic that is intended to protect the integrity of the device settings and may alternatively be referred to as "integrity protection logic". In some implementations, the validation logic may implement so-called "business logic", which is to be understood within the context of the present disclosure as logic pertaining to the parameters or settings of the OPC UA-enabled device, and not to a method of doing business. A "parameter" may also be referred to as an "attribute".

In any aspect, the validation logic may be implemented using a PYTHON script or using any other appropriate language, especially scripting languages.

The validation logic may be stored in an appropriate manner in the nodeset file. In one example, the validation logic is stored in the nodeset file in a predetermined XML element, with the method of the first or second aspect further comprising identifying the element that contains the validation logic according to an established convention. Alternatively, in a second example, the validation logic may be stored in the nodeset file using a value attribute of a description of a UAVariable, the method of the first or second aspect further comprising identifying the UAVariable that contains the validation logic according to an established convention. Thus, the convention provides OPC UA clients and servers with the requisite knowledge concerning the location of the validation logic in the nodeset file.

In any aspect, validating the data may comprise using an information model to identify that a variable to be written is of a type that indicates a validation requirement, and executing the validation logic in relation to the variable to be written in response to the identifying. In that case, the information model may further define a status variable for carrying the result of the validation, the method further comprising modifying the status variable to indicate the result of executing the validation logic in relation to the variable to be written.

In any aspect, the validation logic may be stored in the nodeset file in encrypted form, for improved security against attackers seeking to target the validation logic.

According to a third aspect, there is provided a method comprising: creating the nodeset file according to claim <NUM>.

Any of the methods described herein may furthermore comprise the step of implementing/performing/controlling an industrial manufacturing process using an industrial automation system comprising the said automation device to which data has been written. Any of the methods may comprise the preceding step of integrating the said automation device into the industrial automation system.

According to a fourth aspect, there is provided a computer-readable data carrier or a data carrier signal carrying the nodeset file created using the method of the third aspect.

According to a fifth aspect, there is provided a computing device comprising a processor configured to perform the method of any of the first, second, and third aspects.

According to a sixth aspect, there is provided a computer program product comprising instructions which, when executed by a computing device, enable or cause the computing device to perform the method of any of the first, second, and third aspects.

According to a seventh aspect, there is provided a computer-readable data carrier or a data carrier signal carrying instructions which, when executed by a computing device, enable or cause the computing device to carry out the method of any of the first, second, and third aspects.

The invention may include one or more aspects, examples or features in isolation or combination whether or not specifically disclosed in that combination or in isolation. Any optional feature or sub-aspect of one of the above aspects applies as appropriate to any of the other aspects.

A detailed description will now be given, by way of example only, with reference to the accompanying drawings, in which:-.

<FIG> illustrates the configuration or parameterisation of a field device according to a first example.

The field device (not shown) comprises an OPC UA server <NUM>. OPC UA is a platform-independent, service-oriented client-server architecture which transports data such as control values, measurement values, and parameters, and which semantically describes the data. The OPC UA server <NUM> receives and exposes such data from the field device. The OPC UA server <NUM> supports information models which define how the data is typed and classified. The representation of the exposed data is called the address space.

An OPC UA client <NUM> is in communication with the OPC UA server <NUM>. The OPC UA client <NUM> may be an application that connects to the OPC UA server <NUM>. The OPC UA client <NUM> may be used, for example, to find data from the address space of the OPC UA server <NUM>, to read and write server data, to subscribe to certain data changes or events such as alarms, and to call server methods. Communication between the OPC UA server <NUM> and the OPC UA client <NUM> is handled by services.

The OPC UA server <NUM> is described by a nodeset file <NUM>. The nodeset file <NUM> provides a mechanism for data exchange in the OPC UA environment and may take the form of an XML file. The nodeset file <NUM> describes the address space of the OPC UA server <NUM>.

According to the present disclosure, the nodeset file <NUM> further comprises validation logic <NUM> for ensuring the logical integrity of the device settings. The validation logic <NUM> may comprise PYTHON script-described logic added to the nodeset file <NUM> to enable a generic approach to validating settings in the address space of the OPC UA server <NUM> of the field device without necessarily being connected to that device. Various ways of integrating the logic into the nodeset file <NUM>, along with examples of suitable validation logic, are described below.

In order to configure the field device, the OPC UA client <NUM> imports the nodeset file <NUM> to discover how to interact with the field device. During the configuration, the OPC UA client <NUM> uses the validation logic <NUM> to ensure the validity of data that is written to the OPC UA server <NUM> of the field device.

The OPC UA server <NUM> similarly uses the validation logic <NUM> to validate the data.

In this way, the OPC UA client <NUM>, being able to import the validation logic <NUM> and knowing how to invoke and handle the execution of the scripted logic, can prepare a valid dataset for the field device, even in the absence of the field device.

<FIG> illustrates the configuration of a field device according to a second example in which the OPC UA system is organized according to an aggregation architecture involving an aggregating server <NUM> and at least one aggregated server <NUM>. The aggregated server <NUM> is the OPC UA server of an entity of the automation system such as a field device. The aggregating server <NUM> connects to each underlying aggregated server <NUM> via OPC UA services and aggregates its type, instance, and structure information. Thus, a single server can be used to connect to multiple other servers and to represent their information in a unified manner. In this way, a client connecting to the aggregating server <NUM> can access the data of multiple aggregated servers <NUM> from a single source. In this example, the validation logic <NUM> is executed only by the aggregating server <NUM>, such that generic OPC UA clients may be used. In this way, the OPC UA client may be implemented on a resource-limited device that is unable to run scripted logic because of the resource consumption of a script interpreter. The notation in <FIG> (following UML graphical syntax) indicates the number of instances possible in the depicted relation. Thus, there is one ("[<NUM>]") aggregating server <NUM> that can aggregate multiple ("[n]") OPC UA servers as aggregated servers <NUM>. For the sake of the brevity and regarding the application of scripted logic, each of the aggregated OPC UA servers ("[<NUM>]") is described by one ("[<NUM>]") nodeset file <NUM>, although it will be understood that the present disclosure is not so limited. Therefore, the single ("[<NUM>]") aggregating server <NUM> can handle multiple ("[n]") nodeset files <NUM> relating respectively to the aggregated OPC UA servers <NUM>. It will be understood that some aggregated servers <NUM> may not need any additional validation logic and can be aggregated by browsing their address spaces.

In any of the examples described herein, the validation logic <NUM> may be incorporated into the nodeset file <NUM> in any one of various suitable ways.

According to a first implementation, the validation logic <NUM> is embodied as a PYTHON script and stored in the nodeset file <NUM> in the XML element designated "Extension", which can refer for example to vendor specific schemata. In this implementation, the OPC UA client is configured to identify the extension that contains the scripted function. This identification may be performed according to an established convention. Similarly, the OPC UA server may leverage the same validation logic <NUM> to protect the logical integrity of data. Advantageously, the effort required to provide the validation logic for protecting the logical integrity of data is reduced, since the validation logic needs to be written only once. A further advantage of this implementation is its ability to hide the validation logic.

According to a second implementation, the PYTHON script is stored in the nodeset file <NUM> using the value attribute of the description of a UAVariable. In this implementation, the OPC UA client is configured to identify the UAVariable that contains the scripted function. This identification may again be performed according to an established convention. The advantage as compared to the first implementation is that the second implementation supports debugging (inspection) of scripted functions on the OPC UA server. Moreover, an OPC UA client can import the validation logic <NUM> from the OPC UA server immediately if there is no nodeset file available. (Since the nodeset file <NUM> represents at least a part of the address space, the approach of providing the scripted logic in the value of a variable makes the script available either by means of reading the nodeset file <NUM> or reading (e.g., via the OPC UA Read Service) the value of the variable. The scripted logic <NUM> may enter the OPC UA server's address space in any appropriate manner. ) A further advantage is that, if the UAVariable is write-enabled, the PYTHON script may be modified.

In the second implementation, an information model may be created using a reserved namespace to avoid conflicts with other application-specific content of the address space. The reserved name space defines a non-hierarchical, asymmetric reference type <NUM> named "HasValidation", for example, as shown in <FIG>. The inverse name may be "Validates". A reference of type "HasValidation" targets a variable <NUM> storing the PYTHON script <NUM> in a string, as shown in <FIG>. In this way, any writable element in the address space can refer to the validation logic <NUM>. If a value is written for a variable <NUM> that refers to the validation logic <NUM>, by virtue of the variable having the type "HasValidation" <NUM>, the OPC UA client can load and execute the PYTHON script <NUM>. The OPC UA client <NUM> provides an execution environment comprising a PYTHON script interpreter and a call back interface that enables reading and writing of other data of the address space. According to the established convention, the PYTHON validating script <NUM> sets an output flag indicating the result of the integrity check. Furthermore, the same script <NUM> may executed inside the device embedded OPC UA server <NUM>, with the result of that script execution being reflected in a further status variable. In this way, execution of the validation logic is triggered post-write.

The information model may furthermore establish a convention defining how a PYTHON script such as <NUM> can access variables of the address space. The script <NUM> may be enabled according to the convention to collect data needed for the validation and/or to fix settings and to indicate the validity of the data set.

<FIG> illustrates the nodeset integrity protection concept. Asymmetric cryptography methods like a PKI can be used to protect the nodeset file <NUM> against illicit modifications, since the PYTHON script <NUM> may present a target for attackers. The nodeset file <NUM> may be protected using a signature <NUM> that is created with a private key <NUM>, while the same signature <NUM> and the content of the nodeset file <NUM> can be validated with a public key <NUM>. The private key <NUM> and public key <NUM>, as well as the nodeset file <NUM>, are created during development <NUM> of the OPC UA server <NUM>. The private key <NUM> is kept in a safe place. The public key <NUM> is inferred from the private key <NUM>. The private key <NUM> is used to encrypt the signature <NUM> of the nodeset file <NUM>. The signature <NUM> hashes the nodeset file <NUM> so as to represent a compressed form of the content of the nodeset file <NUM>.

<FIG> illustrates one example use case involving scripted parameter validation performed in relation to a field device following the OPC UA specified PA-DIM Model. The field device (not shown) runs using a parameter set in which the parameter V2 depends on the values of parameters V1 and V3, i.e., V2 =f (V1, V3). The aggregating server <NUM> aggregates the parameters of the field device by representing them using the proxy parameters V1', V2' and V3'. The validation logic <NUM> is configured to monitor changes in parameter V1', which monitors the changes in the aggregated parameter V1. If V1 changes, V1' change as well, which triggers the execution of the validation logic <NUM>. Since V2 depends on the values of parameters V1 and V3, the validation logic <NUM> reads the value of parameter V3 through its proxy parameter V3'. The validation logic <NUM> calculates V2' and writes a new value to V2' which is in turn forwarded to V2.

Aside from the device integration examples described above, write-triggered validation logic can be used to bridge between control applications that are incompatible by their design principles.

In particular, <FIG> illustrates a further example use case involving bridging to IEC <NUM>. According to IEC <NUM>, control functions (services) are triggered by writing one variable ("Event") and the status of completion is reported through a separate variable ("Feedback"). In contrast, according to VDI <NUM>, a control function (state-machine) is managed by means of a single variable that is written to trigger an execution and the status feedback is communication through the same variable. Under the different design principles, a programmable logic controller (PLC) applying IEC <NUM> cannot be used in a modular automation system that applies VDI <NUM>. While VDI <NUM> runs on OPC UA, the aggregating OPC UA server <NUM> implementing validation logic <NUM> as described herein can be configured to bridge between the different standards (VDI2658 / IEC <NUM>). The address space of the aggregating server <NUM> represents a VDI <NUM> defined service object with the control & status variable (V1). This variable V1 is used to represent (aggregate) the control objects of the OPC UA server <NUM> of another PLC that follows IEC <NUM>, in which one variable (V1a) is used to trigger a service while another variable (V1b) is used as the status reporting variable. Variables V1a' and V1b' are aggregated representations of variables V1a and V1b, respectively. The validation logic <NUM> in this case comprises status logic 108a and trigger logic 108b. The trigger logic 108b monitors changes to variable V1 and writes the resulting trigger to the proxy variable V1a', to be forwarded to the aggregated variable V1a. The status logic 108a monitors the proxy variable V1b' for changes made in the aggregated status variable V1b, and writes status changes on variable V1b' to the variable V1.

The approaches described herein can be extended towards the application logic of the automation device, for example to parts of the firmware comprising logic relating to I/O functions dealing with the hardware specifics, protocol stacks, generic math libraries, etc..

Referring now to <FIG>, a high-level illustration of an exemplary computing device <NUM> that can be used in accordance with the systems and methodologies disclosed herein is illustrated. The computing device <NUM> includes at least one processor <NUM> that executes instructions that are stored in a memory <NUM>. The instructions may be, for instance, instructions for implementing functionality described as being carried out by one or more components discussed above or instructions for implementing one or more of the methods described above. The processor <NUM> may access the memory <NUM> by way of a system bus <NUM>. In addition to storing executable instructions, the memory <NUM> may also store conversational inputs, scores assigned to the conversational inputs, etc..

The computing device <NUM> additionally includes a data store <NUM> that is accessible by the processor <NUM> by way of the system bus <NUM>. The data store <NUM> may include executable instructions, log data, etc. The computing device <NUM> also includes an input interface <NUM> that allows external devices to communicate with the computing device <NUM>. For instance, the input interface <NUM> may be used to receive instructions from an external computer device, from a user, etc. The computing device <NUM> also includes an output interface <NUM> that interfaces the computing device <NUM> with one or more external devices. For example, the computing device <NUM> may display text, images, etc. by way of the output interface <NUM>.

It is contemplated that the external devices that communicate with the computing device <NUM> via the input interface <NUM> and the output interface <NUM> can be included in an environment that provides substantially any type of user interface with which a user can interact. Examples of user interface types include graphical user interfaces, natural user interfaces, and so forth. For instance, a graphical user interface may accept input from a user employing input device(s) such as a keyboard, mouse, remote control, or the like and provide output on an output device such as a display. Further, a natural user interface may enable a user to interact with the computing device <NUM> in a manner free from constraints imposed by input device such as keyboards, mice, remote controls, and the like. Rather, a natural user interface can rely on speech recognition, touch and stylus recognition, gesture recognition both on screen and adjacent to the screen, air gestures, head and eye tracking, voice and speech, vision, touch, gestures, machine intelligence, and so forth.

Additionally, while illustrated as a single system, it is to be understood that the computing device <NUM> may be a distributed system. Thus, for instance, several devices may be in communication by way of a network connection and may collectively perform tasks described as being performed by the computing device <NUM>.

Various functions described herein can be implemented in hardware, software, or any combination thereof. If implemented in software, the functions can be stored on or transmitted over as one or more instructions or code on a computer-readable medium. Computer-readable media include computer-readable storage media. Computer-readable storage media can be any available storage media that can be accessed by a computer. By way of example, and not limitation, such computer-readable storage media can comprise FLASH storage media, RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to carry or store desired program code in the form of instructions or data structures and that can be accessed by a computer. Disk and disc, as used herein, include compact disc (CD), laser disc, optical disc, digital versatile disc (DVD), floppy disk, and Blu-ray disc (BD), where disks usually reproduce data magnetically and discs usually reproduce data optically with lasers. Further, a propagated signal is not included within the scope of computer-readable storage media. Computer-readable media also includes communication media including any medium that facilitates transfer of a computer program from one place to another. A connection, for instance, can be a communication medium. For example, if the software is transmitted from a website, server, or other remote source using a coaxial cable, fiber optic cable, twisted pair, digital subscriber line (DSL), or wireless technologies such as infrared, radio, and microwave, then the coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio and microwave are included in the definition of communication medium.

Alternatively, or in addition, the functionally described herein can be performed, at least in part, by one or more hardware logic components.

Claim 1:
A method comprising, by an OPC UA client (<NUM>):
importing a nodeset file (<NUM>) pertaining to an OPC UA-enabled automation device, wherein the nodeset file describes an address space of an OPC UA server (<NUM>) of the automation device and further comprises validation logic (<NUM>) used to validate data to be written to the automation device;
preparing data to be written to the automation device;
using the validation logic to validate the prepared data; and
writing the validated data to the automation device;
the method further comprising performing an industrial manufacturing process using an industrial automation system comprising the said automation device to which data has been written.