opc illustration

7/30/2019 OPC Illustration

1/6

2000 CPPA TECHNICAL SESSION

D:\CONFERENCES\CPPA 2000 OPC 1

USING OPC TO INTEGRATE CONTROL SYSTEMS FROM COMPETING VENDORS

Eric J. Byres, P. Eng. Tan-Trung Nguyen, P. Eng.Artemis Industrial Networking Laurentide Controls

30 Gostick Place 18000 Rte Transcanadienne

North Vancouver, BC V7M 3G3 Kirkland, QC H9J 4A1

Email: [email protected] Email: [email protected]

ABSTRACTAs it evolves, the typical industrial plant will find it has a myriad of different control systems and communications networks

Interconnecting these dissimilar systems can be difficult and expensive, yet vital to efficient production. Alcan Smelters was faced

with such a problem when it wanted to upgrade its Hydrate-2 plant in Jonquiere, Quebec the new design had resulted in six

process control systems and seven different process communications networks. This paper looks at the techniques selected to ease

this integration based on the OLE For Process Control (OPC) standard. Also discussed are the results of staging and loading test

to prove the robustness of this single standard OPC strategy.

Keywords: OPC, Ethernet, TCP/IP, PLC, DCS, Local Area Networks, Network Integration

1. TOO MANY NETWORKS

In an ideal world, process control integration would be simple buy all the computer, instrumentation and electrical equipment from

a single vendor and connect it all together using a single network standard. But real life is never that simple; rarely are the PLCDCS, drives, motor controls, field instrumentation and data historian all purchased from the same vendor. And even when they are

the vendor will usually have a number of different vintages or models of equipment that will not interconnect cleanly.

Alcan Smelters and Chemicals Ltd. was faced with just this problem as they started to upgrade their Hydrate-2 plant in Jonquire

Quebec. The plant has separate vendors for PLC, DCS and motor control and these used four different types of control networks

(Allen-Bradley Remote I/O (RIO), Allen-Bradley Data Highway Plus (DH+), Fisher-Provox Data Highway (DH) and Ethernet). With

the planned addition of three new networks (DeviceNet, ControlNet and Profibus) to connect overload relays and variable speed

drive controllers, the plant would be faced with seven different process network systems. Alcan wanted to rationalise this collection

of networks and allow centralised data management of all process data.

2. A STANDARD NETWORK INFRASTRUCTURE

2.1 Network Cabling

The first step in consolidating the numerous networks was to select a common cabling strategy. For this, Alcan chose fibre optic

cable for all communications cabling outside the control room or rack room. The fibre was a tight-buffered 62.5/125?m multimode

fibre with steel armoured protection and a 48 fibre count. While the noise immunity and high data carrying capacity of fibre optic

cable was a factor, the primary reason was that fibre cabling was the only system that could provide a single medium suitable for the

very wide range of communications needs in the Alcan facility[1].

2.2 Network Connectivity

Ethernet and TCP/IP were chosen be the site standard for all non-critical process information traffic. This simplified a number of

connections because these two protocols have become the dominant communications technologies and are common to nearly

every manufacturer of process control equipment. The question of Ethernets non-deterministic nature was resolved in two ways:

1. The bulk of all process data was shown not to be time critical and thus scheduling was not an issue. This includes the data

from the variable speed drive controllers and overload relays, plus most of the PLC and DCS data.

2. Current Ethernet technologies, such as use of switches, have addressed earlier issues about Ethernet's determinism[2][3].

As for the critical process data (such as the PLC to DCS link or the PLC to remote I/O connections), the issues are more clouded

Vendor connectivity issues tend to dominate, rather than pure technology issues. As well, some equipment did not have Etherne

interfaces, such as the overload relays. Thus, some non-site standard solutions were still required, such as using DeviceNet for the

overload relays. Wherever possible, these protocols were converted to Ethernet using a gateway.


2/6



2.3 Application Layer Standards

Fibre optics, Ethernet and TCP/IP are not sufficient in themselves to create a functional network. They require additional applicatio

layer protocols to actually carry out the tasks over the network, such as sending or receiving a specific data file. The combination o

OLE for Process Control (OPC) and Microsofts DCOM (distributed component object model) was selected for this function.

3. WHAT IS OPC?

OPC is a standard set of interfaces, properties, and methods for use in process-control and manufacturing-automation applications

It is based on Microsoft's OLE (now ActiveX), COM (component object model) and DCOM (distributed component object model)technologies. These technologies define how individual software components can interact and share data[4].

Many people heard of OLE (object linking and embedding) and have used its capabilities whenever spreadsheet is added to a wor

processing document. OLE allows the spreadsheet application to dynamically update the information in the word processing

document. Typically the user isnt required to do even the slightest configuration beyond the click of a mouse. The OLE

specification completely defines how the spreadsheet (in this case the OLE server) will format and send data to the word processor

document (in this case the OLE client).

OPC adds a number of features to the OLE specification to address requirements for use in process control. For example, an OLE

server does not check to see if the data is actually received by a client. It just sends and forgets. Since this is clearly not sufficient

for process control applications, OPC adds the ability for acknowledgement of server/client transactions.

The real value of OPC is that it provides a common interface for communicating with diverse process-control devices, regardless o

the controlling software or devices in the process. Before OPC was developed, application developers had to develop specificcommunications drivers for each control system they wished to connect with. For example, one Human Machine Interface (HMI)

vendor developed over 100 drivers for different DCS and PLC systems.

HMIApplication

DCSDriver 1

PLCBrand A Driver 2

PLCBrand B Driver 3

OPCPlatform

DCSOPC Srvr 1

PLCBrand A OPC Srvr 2

PLCBrand B OPC Srvr 3

HMI

Application

OPC DriverOPC Client

Before OPC After OPC

Figure 1: Prior to the development of OPC, applications vendors needed to develop separate communications drivers for each type

of controller they wished to connect to. With OPC they only needed to develop a single OPC driver.

With OPC, application vendors no longer need to develop separate drivers for each new network or new processor. Instead, they

create a single optimized OPC driver for their product. This communicates to other OPC servers designed and sold by the

manufacturers of the other networks and controllers.

It is important to understand that OPC does not eliminate the need for drivers. It is up to each manufacturer to develop OPC driver

for their specific product, since they are best suited to build the driver that will take full advantage of their particular controller

However, once an OPC driver exists for a piece of equipment or an application, it is a simple matter to integrate its data with other

OPC compliant devices.

4. TEST SYSTEM ARCHITECTURE

A realistic plant architecture had to be assembled to test the different OPC clients and OPC servers that Alcan was expecting to use

in the finished facility. Three levels of networking were built:

? ? The information network using Ethernet and TCP/IP.


3/6


4/6



Figure 2: The OPC Test Architecture To duplicate a typical industrial facility, the OPC testing used a three layer hierarchy of communications to integrate the various

field devices, controllers, networks and applications. All OPC software ran in the central OPC server platform.


5/6


6/6



OPC Server

ComputerSingle Pentium II 400Mhz

128MegRAM4 Gigabytes Hard Disk

2 Ethernet AdaptersWindows NT 4.0 Workstation

Figure 4: During the OPC performance test the CPU loading

went up to 52% and the memory usage rose to 105 Mbytes, on a

transfer rate of 300,000 values/minute.

5.3 Reliability Tests

As the first reliability test, the OPC server computer was

rebooted to determine how it would recover. The DeltaV and

Provox OPC servers run as Windows NT services and started

normally. The RsLinx OPC server is only started when an OPC

client tried to initialize with it. When the OPC-Mirror is started, it

loads itself as a service and had no problems. The two OPC

clients both worked well but had to be loaded as NT

applications to prevent synchronization problems on startup.

As the second reliability test, we severed the communication

links to each device, one at a time, and watched to see if every

data consumer marked the data as bad, if the data loss from one

system impacted another and if the data streams recovered once

the link was restored. As each link was disconnected, the PI

server identified the data as bad and as each link was re-

established, the status went to normal. The only problem was

that different error indications were reported depending on the

failed system.

6. CONCLUSIONSThese tests clearly showed the advantages of the OPC architecture and indicated that even a relatively small OPC server could

handle data rates far in excess of those found in most process control environments. It also showed that multiple vendors OPC

software could coexist on a single computer and, in fact this was the optimum configuration for OPC.

The effects of a communications link failure were correctly handled by all OPC applications and the system automatically recovered

when the link was restored. Only the failure of the entire OPC Server Platform would cause unrecoverable link loss and this only

occurred in a few of the OPC products. This would suggest that redundant OPC servers be used if the OPC data is mission critica

for the process.

Finally OPC configuration was significantly simpler than configuring separate application drivers because it:

? ? Does not require intermediate data mapping that has to be maintained.

? ? Provides the information in its native format and syntax.

? ? Provides a browser to facilitate configuration.

From these tests, Alcan has determined that OPC is ready for the production environment and will be the primary process data

transfer mechanism when the new plant starts up in the Spring of 2000.

SPECIAL THANKS TO:

Andr Lalancette, Jocelyn Moore and Bertin Schmidt from the ALCAN engineering team who requested the OPC testing.

Vincent Landry and Martin Jett from COGEXEL for their support for OSI-PI products.

Gerry St-Amand from Rockwell Automation for his support with Allen-Bradley products.

Alden Hagerty, Gord Gillespie, Gerry Murenbeeld and Laura Moroz of the Artemis Networking team for their editing assistance.

REFERENCES

[1] BYRES, E. J., What Superintendents and Engineers need to Know about Fibre Optics, Pulp and Paper Canada 99 (8): T270-273

[2] BOGGS, D. R. et al, Measured Capacity of an Ethernet: Myths and Reality, Western DigitalResearch Report 88/4, Sept. 1988

[3] BYRES, E. J.,Ethernet to Link Automation Hierarchy, InTech Magazine, June 1999, P45

[4][5] OPC FOUNDATION, OLE for Process Control - Data Access Standard, Version 1.0A, September 11, 1997

opc illustration

Documents