Whitepaper

OPC Performance Testing—Laurentide Controls

Nov-05—Page 1

TM

OPC Performance Testing—Laurentide Controls

This paper documents the results of OPC performance tests involving the DeltaV system, PROVOX,
Allen-Bradley, Oil Systems, and Gensym G2 by Laurentide Controls of Montreal, Quebec.

© Emerson Process Management 1996—2007 All rights reserved.

DeltaV, the DeltaV design, SureService, the SureService design, SureNet, the SureNet design, and PlantWeb are marks of one of the Emerson
Process Management group of companies. All other marks are property of their respective owners. The contents of this publication are presented for
informational purposes only, and while every effort has been made to ensure their accuracy, they are not to be construed as warrantees or guarantees,
express or implied, regarding the products or services described herein or their use or applicability. All sales are governed by our terms and conditions,
which are available on request. We reserve the right to modify or improve the design or specification of such products at any time without notice.
 Whitepaper
OPC Performance Testing—Laurentide Controls OPC P
Nov-05—Page 2

TM

Contents
The ALCAN Jonquière Smelter plant wants to know the performance of OPC ................................................... 4
OPC Performance Testing at Laurentide Controls .................................................................................................. 4
Why OPC? .................................................................................................................................................................... 4
System architecture demonstrating the OPC functionality .................................................................................... 6
The DeltaV system.................................................................................................................................................... 6
The PROVOX system ............................................................................................................................................... 6
The OPC server specification ................................................................................................................................... 6
The Allen-Bradley programmable controllers ........................................................................................................... 6
The PI historian ......................................................................................................................................................... 6
The G2 application .................................................................................................................................................... 6
Data paths ................................................................................................................................................................. 7
Demonstrating OPC .................................................................................................................................................... 7
Performance................................................................................................................................................................. 9
Reliability.................................................................................................................................................................... 10
Conclusion ................................................................................................................................................................. 11
 Whitepaper
OPC Performance Testing—Laurentide Controls OPC P
Nov-05—Page 3

TM

Figures
Figure 1. OPC performance test architecture ............................................................................................................... 5
Figure 2. DeltaV OPC Mirror application ....................................................................................................................... 8
Figure 3. OPC data flow ................................................................................................................................................ 9
Figure 4. OPC performance test results...................................................................................................................... 11
 Whitepaper
OPC Performance Testing—Laurentide Controls OP
Nov-05—Page 4

TM

The ALCAN Jonquière Smelter plant wants to know the performance of

OPC
In an ideal world, process control integration would be simple – buy 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 is the PLC, DCS, drives, motor control, field instrumentation and data historian all purchased
from the same vendor. And even when it is, the vendor will usually have many different vintages or models of
equipment that will not interconnect cleanly.

Alcan Smelters and Chemicals Ltd. were faced with just this problem as they started to upgrade their Hydrate-2
plant in Jonquière, Quebec. The plant had separate vendors for the PLC, DCS and control drivers. These used
four different types of control networks, including Allen-Bradley Remote I/O (RIO), Allen-Bradley Data Highway
Plus (DH+), Emerson Process Management 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 network systems. Alcan wanted to
rationalize this collection of networks and allow centralized data management of all process data.

OPC Performance Testing at Laurentide Controls

Laurentide Controls promotes the merits of OPC to meet information integration needs and proposed to
demonstrate the OPC functionality. Products available from the primary process control equipment suppliers of
the Alcan Jonquiére facility would be used to develop and prove the planned architecture.

Why OPC?
To develop an open and interoperable OPC creates a common interface for all applications and platforms. This
avoids inter-application custom integration, and reduces the cost of implementing and maintaining applications.
Less time is spent integrating interface standards based upon the functional requirements of OLE/COM and
DCOM technology. OPC creates interoperability between automation/control applications, field systems/devices,
and business/office applications.

Before the acceptance of OPC as a standard for information exchange in industrial applications, each control
system had to have a customized driver so client applications could access the data. Performance and
functionality issues for drivers were necessary criteria in choosing an application. Now with a client application
that has the OPC client functionality, users can integrate information from any vendor that has an OPC server and
vendors will not need to develop new drivers for new networks or new processors.

OPC will not eliminate drivers. It is now up to the manufacturer to develop drivers for their specific products. It is
the manufacturer of a controller that is best suited to build the driver that will take full advantage of that controller.
The OPC server has the driver for the specific network and/or controller. The OPC client establishes an
application to application link to the OPC server using the COM technology from Microsoft.
 Whitepaper
OPC Performance Testing—Laurentide Controls OP
Nov-05—Page 5

TM

In today's operating systems, processes are shielded from each other. COM enables a client application that
needs to communicate with a component in another process to do so in a completely transparent fashion. It
intercepts calls from the client and forwards them to the component in the other process. When client and
component reside on different machines, DCOM simply replaces the local inter-process communication with a
network protocol. Neither the client nor the components are aware that the wire that connects them has just
become a little longer.

Figure 1. OPC performance test architecture

 Whitepaper
OPC Performance Testing—Laurentide Controls OP
Nov-05—Page 6

TM

System architecture demonstrating the OPC functionality

Realistic plant architecture had to be assembled to test the different OPC clients and OPC servers. Three levels
of networking were built:
„ The information network using Ethernet and TCP/IP
„ The controller networks with DeltaV Control Network, PROVOX Data Highway and Allen-Bradley
ControlNet
„ The fieldbus using DeviceNet.
The DeltaV system
„ ProfessionalPLUS engineering station which also acted as the operator interface.
„ M5 controller
„ Application Station with the DeltaV OPC server and the OPC Mirror OPC client application.
The PROVOX system
„ ENVOX configuration software running on a VAX/ALPHA station
„ OWP operator station using VAXLN and X-terminal
„ SRX/IFC controller
„ PROVOX application server with the PROVOX OPC server.
The OPC server specification
„ Single Pentium II 400Mhz
„ 128MegRAM ECC
„ 2 Ethernet adapters at 10Mhz
„ 4 gigabytes Hard disk UDMA
„ Windows NT 4.0 /w service pack 3.
The Allen-Bradley programmable controllers
„ PLC-5/40B with 1785-ENET Ethernet piggyback adapter.
„ PLC-5/20C with ControlNet ports.
„ ControlLogix gateway with processor, Ethernet card and DeviceNet Card.
„ RSLinx version 2.00.97 with the OPC server.
„ RsLogic5 and RsLogic5000 programming software
„ DeviceNet Manager Software.
The PI historian
„ PI server
„ PI OPC client driver
„ PI process book.
The G2 application
„ G2 application
„ G2 OPC bridge from Matrikon.
 Whitepaper
OPC Performance Testing—Laurentide Controls OP
Nov-05—Page 7

TM

Data paths

Three OPC servers each were providing information from their devices. Three OPC clients were configured to
access information from all three OPC servers.

Demonstrating OPC
Each controller was programmed to iterate ten values from 0 to 1,000 at its fastest scan time.

„ The DeltaV M5 controller used a counter block that iterated at 0.1 seconds with an auto reset at its
target of 1,000.

„ The PROVOX SRX Controller used a LCP/FST code to ramp analog output tags at each 0.1
seconds. Those points were then targeted to the PROVOX application server.

„ The PLC-5/40B and the PLC-5/20C used timers at 0.01 seconds and preset at 1,000. The ‘timer
done’ bit was used to reset the timer.
 Whitepaper
OPC Performance Testing—Laurentide Controls OP
Nov-05—Page 8

TM

Figure 2. DeltaV OPC Mirror application

The OPC Mirror is an OPC client application from Emerson Process Management. It maps data from one OPC
server to another. Before configuring the OPC Mirror, we had to define the data recipient in the PROVOX and
DeltaV. We defined the CHIP AI point for PROVOX, and we defined control module input attributes in DeltaV.
Data mapping between DeltaV and PROVOX is intuitive since OPC Mirror can browse the structure of the
PROVOX and DeltaV OPC server. The RSLinx OPC server did not support the OPC browse method thus the
address of the data was manually entered. The OPC server did not support ‘‘SYMBOL’’ defined in PLC-5 but did
support tags from the ControlLogix processor.
 Whitepaper
OPC Performance Testing—Laurentide Controls OP
Nov-05—Page 9

TM

We first tried the PI-OPC driver loaded in the PI-Server computer and had to define the PROVOX OPC server
object that was redirected using DCOM to the CHIP/NT computer. This method worked but the application to
application initialization took 30 seconds. This was corrected by having the PI-OPC driver as a local client to the
OPC server; the initialization took less then a second.

Both the PI-OPC driver and the G2-Matrikon OPC bridge did not like the special characters (spaces and square
brackets) used to name the OPC server and the items by RSLinx. Per the OPC specification, the naming
convention format is to use UNICODE. OSI and Matrikon will have to correct this problem.

Figure 3. OPC data flow

Performance
Once the OPC servers and the OPC clients functionality were demonstrated with 10 data values from each
processor at a 1 second rate and a ½ second rate, we needed to see the impact on performance as the amount
of information was increased.

The number of timers of the PLC-5/40E with the Ethernet piggyback card was modified to 5,000 timers at 0.01
seconds.

We monitored the CPU of the OPC server and the memory loading from the Windows NT task manager as we
configured the PI-OPC driver to monitor all 5,000 timers at the 1 second scan rate and the OPC server to scan at
the 0.5 seconds rate from the PLC-5.

We noticed a small increase in memory usage, from 103Meg to 105.2Meg of RAM. The CPU loading jumped
from 5% to 52% utilization.

Since all 5,000 values were constantly changing, we estimated that the PI historian was storing 300,000 values
per minute. After an hour at this rate, we had to disconnect the network connection to the PI server because it
was receiving data faster then it could store.
 Whitepaper
OPC Performance Testing—Laurentide Controls OP
Nov-05—Page 10

TM

Reliability
For the first reliability test, the OPC server computer was rebooted to determine how it would recover.

The DeltaV OPC server and the PROVOX OPC server are Windows NT services and started normally. The
RSLinx OPC server starts when an OPC client tries to initialize with it. When the OPC Mirror is started, it loads
itself as a service. The PI OPC driver and the G2/Matrikon OPC bridge are Windows NT tasks.
For the second reliability test, we severed the communication links to each device, one at a time, and watched 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. We noticed different error indications were reported depending on the failed system.
 Whitepaper
OPC Performance Testing—Laurentide Controls OP
Nov-05—Page 11

TM

Conclusion
The Laurentide Controls performance testing shows there are distinct advantages to using the OPC architecture.
„ Provides the most direct path to the equipment that generates the information.
„ 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.
ALCAN Jonquiére was satisfied with the performance of OPC as demonstrated by Laurentide Controls. They will
include OPC in their next project that requires process and maintenance data centralization.

Figure 4. OPC performance test results

Special thanks to Tan-Trung Nguyen of Laurentide Controls for authoring this whitepaper and André Lalancette,
Jocelyn Moore and Bertin Schmidt from the ALCAN Jonquière engineering team to request the OPC
demonstration. Thanks also to 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, and Eric J.
Byres from Artemis for his support.