Server communication overview

In order to establish server communication in FrontVue, configuring an OPC server is essential.

OPC originated as an acronym for Object linking and embedding for Process Control. OPC defines a standard interface for communication between software components either on the same computer or on different computers connected over a network. It is based on the COM/DCOM (Component Object Model / Distributed COM) client/server group of standards from Microsoft. A software component that has OPC client capability can (in theory) communicate with and retrieve information from any software component that is an OPC server.

 FrontVue is an OPC client. It uses one or more OPC servers to collect data from the outside world. Typically an application developed for the HMI will use an OPC server provided by one of the many PLC manufacturers or a third party industrial communication vendor.

OPC Implementation in the HMI

The OPC implementation within the HMI uses a flexible design to allow for the support of current and new OPC standards without the need for major redesign. To do this, the HMI employs a gateway between itself and the OPC server. This gateway is known as the Communication Manager. The current Communication Manager supports three server types.

• OPC Data Access - This type of OPC server is used to provide real time data that is used by most of the animation features in the HMI. The version supported is standard OPC Data Access 2.0. In FrontVue a server of this type is referred to as the RTDS (Real Time Data Server).

• OPC Alarm Access - This type of OPC server is used to provide alarm data for the Alarm Viewer. The version supported is proprietary to FrontVue. In FrontVue, a server of this type is also known as the RTAS (Real Time Alarm Server).

• OPC Historic Data Access - This type of OPC server is used to provide historic data for both the Trend and Log Viewers. The version supported is proprietary to FrontVue. In FrontVue, a server of this type is also known as the HDS (Historic Data Server).

Clusters

The HMI has also been designed to support physically independent redundant servers. In order to do this, the concept of a cluster has been introduced. A cluster is an ordered group of prioritized servers. Each of the servers allocated to a cluster must have an identical structure. A priority or rank is used when attempting to make an OPC connection. If the server ranked first fails then an attempt will be made to connect with the second server and so on. For non-redundant operation, a cluster with just one server is created.

Each OPC server you configure is made a member of one of the clusters. When referring to variables within an OPC server you use the cluster name. The HMI automatically directs references to the server currently connected.

A typical implementation of OPC within the HMI may be visualized as follows. In this example there is one of each of the three server types configured. Show picture

• DataServerType - OPC Data Access. One OPC server, ModbusExplorer, of this type is configured. ModbusExplorer is a general purpose OPC server that could be used with any OPC compliant application.

• AlarmServerType - OPC Alarm Access. One OPC server, FVAlarmServer, of this type is configured. FVAlarmServer is FrontVue specific.

• HisDataServerType - OPC Historic Data Access. One OPC server, FVHistoricServer, of this type is configured. FVHistoricServer is FrontVue specific.

The example also has three clusters configured. With only one server attached to each cluster there is no redundancy.

• The cluster named RTDS contains one OPC Data Access server, ModbusExplorer, and hence provides real time data to the HMI.

• The cluster named RTAS contains one OPC Alarm Access server, FVAlarmServer, and hence provides alarm data to the Alarm Viewer.

• The cluster named HDS contains one OPC Historic Data Access server, FVHistoricServer, and hence provides historic data to the Trend and Log Viewers.

Naming OPC Variables

The OPC standard allows for a flexible approach to variable naming with either a flat or hierarchical naming scheme. The variable names are determined entirely by the OPC server. The HMI requests a list of names from the server, which is then displayed in the Variable Browser.

Most OPC servers use a hierarchical naming scheme of one form or another. Some servers allow variables to be named in a way that represents the outside world, whilst others use names that represent locations of a data table in a PLC or other piece of equipment. Each variable name has one or more elements (also known as branches and leaves) separated by decimal points. The following are all valid variable names.

Process.Engine1.Compressor1.B1
Process.Engine1.Compressor1.A1
CARD1.DATABASE.B1
Node1.DataTable3_256
Simulation.Square Waves.Int4
B1

Value, Timestamp and Quality

For each variable (OPC item) used in an animation, the HMI expects the server to provide the item's properties of Value, Timestamp and Quality (known as VTQ). Normally only the item's value is displayed but, by the use of two special suffixes, the quality or timestamp may be displayed.

The following example shows the use of this with variable names within the HMI:

Process.Engine1.Compressor1.B1#_T
Process.Engine1.Compressor1.A1#_Q

Other variable properties

In addition to the Value, Quality and Timestamp, certain animation types expect a linked variable to support additional properties. For example, a register variable linked to a bargraph animation would require a minimum and maximum value. Most of these additional properties are optional; a default or user configured value is used if they are not available.

If an OPC variable supports additional properties that are accessible by the HMI they will be displayed in the Variable Browser and may also be used in an animation in their own right. For example you could display the minimum and maximum values of a register.

The following shows an example of the naming of additional properties.

Process.Engine1.Compressor1.M1
Process.Engine1.Compressor1.M1.Min
Process.Engine1.Compressor1.M1.Max
Process.Engine1.Compressor1.M1.UnitText