You are here: Home › Products › LIBPF OPCUA

LIBPF OPCUA

OPC Unified Architecture interface

LIBPF OPCUA

For the process automation industry, the recently released OPC Unified Architecture (OPC UA) specification builds on the successes of the established Classic OPC standard for interoperability between enterprise information systems and industrial automation.

With OPC UA, data and functionalities can be made available as services in a vendor-independent way. The main characteristic of OPC UA are:

  1. It exposes the semantics of the data in an object-oriented fashion;

  2. It is platform-independent;

  3. It is built around a Service-Oriented Architecture (SOA).

 

LIBPF OPCUA makes it possible to expose the LIBPF objects (temperatures, pressures, flows, phases, streams etc) as OPC UA nodes via an OPC UA server interface, and to command the execution (i.e. the calculation) using the same interface.

The current implementation does not support:

  • node creation at run-time (all nodes must be instantiated using compile-time commands);
  • persistency of the objecst (all nodes are kept in memory);
  • the State Machine information model;
  • the Program abstraction.

The main difference between LIBPF OPC and LIBPF OPCUA is that the former is a Classic OPC client while the latter is an OPC UA server.

In the first case the OPC tags required to store the results of the calculations have to be manually created on the Classic OPC server of the DCS; next the tag names have to be manually configured with the soft sensor using an XML configuration file. Any change to the OPC server configuration would require a manual update of the client configuration; this is where the limited flexibility of a non-service oriented architecture becomes evident.

In the second case the configuration can be performed using any OPC UA client, requiring no client-side configuration thanks to the discover capabilities of OPC UA. The preferred use case is to have a higher level OPC UA server, i.e. the one provided by the DCS vendor, controlling the soft sensor according to the “chained server” pattern. The elected OPC UA client to perform the set-up in this case would be the generic control system maintenance user interface itself.

Document Actions