|
Factory Automation
Vertical Integration of OPC in Ethernet
Dr. Rainer Beudert, INAT GmbH
As head electro design engineer, responsable project engineer or planner of
future production lines you may be faced with the decision of introducing OPC as
the standard interface or not. How do you decide? What questions should you ask
yourself? INAT proposes a state-of-the-art solution: OPC Tube.
Why choose OPC?
The replacement of proprietary solutions with open, manufacturer-independent
standards is a trend that is being observed in all areas of the industry. After
all it offers customers the capability of assembling their systems to meet their
own performance profiles. OPC started making a name for itself back in 1998 when
it offered the linking of visualisation systems and similar. Initially smiled at
condescendingly (“who would think of using Microsoft for automation tasks?”),
Ole for Process Control has developed into a familiar name for many plant
engineers and even mechanical engineers when it comes to inexpensive, flexible
and scaleable connection of automation hardware to standard software components.
Despite this, one asks the following question prior to implementing an OPC
project to link visualisation systems, databases and similar: What is the
maximum number of data points from one controller that I can handle via OPC?
What update rates can I achieve with OPC? What influence does my own particular
hardware and my bus interface have and what effect does the system design of the
PC on which the OPC server and the OPC client are installed have?
Just how fast is OPC actually?
There have already been several reports on the performance of the OPC
interface under laboratory conditions. One of these is by Lange/Iwanitz in their
book “OLE for Process Control. Grundlagen, Implementierung und Anwendung”
(Hüthig Verlag 2002) or by Hadlich/Szczepanski in their article “Die Performance
von OPC beim zyklischen Datentransport” (ifak Systems 1999). One of the primary
results from these measurements is the strong dependence of processor
performance on the CPU of the OPC server computer as well as the load of this
computer due to additional processes or applications. However, what effects do
the other components have in such a data chain such as, for example, in figure 1
of the INAT OPC Server TCPIPH1 in an S5/S7 environment.
This OPC Server was developed for the OPC link of S5/S7 controllers via Ethernet
but also for the link of Wago, Beckhoff and Phoenix terminals and MODICON
controllers via Modbus on TCP. Recently the link of Allen Bradley controllers
via EtherNet/IP has been added to the function scope. In such a chain of
communication, the network design, the performance of the CPU of the controller,
and last but not least, the performance of the Ethernet interface being used
(INAT S7-TCP/IP or CP 443-1 of Siemens, echolink or Wago) should be considered
as well as the OPC interface.
> The CPU/CP interface
When the data from only one controller are polled with the INAT OPC Server and
any client, the limiting factors are suspected on the controller side. Tests
showed that, regardless of the CP used, the greater the number of points the
more data flow is affected by the CPU/CP interface of the data. The blocking
limits, the CP-specific access procedure and the data structure on the PLC play
a decisive role here. For performance reasons the Ethernet CPs do not wait until
a complete Ethernet frame is ready for data transfer but send the data to the
Ethernet instead as soon as the blocking limit is reached.
>> The effect of the network design
In the times of shared media (Yellow Cable, BNC), the Ethernet infrastructure
had a negative effect on the entire data transmission and naturally also OPC
performance especially when the loads were great. In modern networks the use of
powerful switching technology allows the influence of the network and its
components to be disregarded, at least from the viewpoint of the controller. A
data rate of 100 Mbps in Fast Ethernet can almost never be totally utilised by
even the most powerful of controllers.
>> The network interface on the server
The link of the OPC server computer to the network is more critical. If a
particularly great number of communication nodes is to be connected with this
server, the use of powerful Fast Ethernet or gigabit network cards is
indispensable. In a singular communication chain with Rockwell TestOPC Client,
INAT OPC Server and an S7-416 with Ethernet-CP (S7-TCP/IP, CP 443-1), the data
are transferred up to the particular blocking limit in the single-digit
millisecond range. With such layouts, the bottleneck is usually the CP or the
CPU.
Things become interesting when the INAT OPC Server establishes several
connections to various controllers. Depending on the general conditions, 20,000
items in poll mode (as fast as possible) from 5 to 15 controllers at a refresh
rate of approx. 2 seconds are not unusual. In event-controlled send/receive
direct mode, many more data points can still be monitored due to the lower net
amount of transmission.
Can I also exchange OPC data via the Internet?
If you want to use OPC server and OPC client on widespread computer systems,
the data are exchanged via the DCOM interface. Whatever functions very well in a
local network causes massive problems when crossing to the Internet or passing
firewalls.
With OPC Tube INAT offers a solution with which the DCOM interface is addressed
as a simple COM interface. This makes communication over network boundaries
possible. OPC Tube makes DCOM into a simple TCP/IP Socket communication which
handles network boundaries and firewalls very easily. The client which is
browsing for a remote server will find this OPC server in its list of local
server entries.
Can two OPC servers exchange data directly?
Since most of today’s visualisation systems offer OPC interfaces which
process the data of any OPC server, OPC is also often presented as a software
bus. This means that various communication partners connect to a common medium
to exchange data. This model does not work for communication of OPC servers
among themselves since the current widely used OPC DA standard does not include
this. However, actual practice frequently shows that it is necessary to exchange
data between automation components. A solution to this is offered by the INAT
OPC Router which, as OPC client, defines the participating components simply as
data source and data sink. As the standard OPC client, the OPC router ensures
that data are exchanged not only between two servers but also between servers
and databases without time-consuming programming.
Summary
The OPC and Ethernet standards make vertical data transport from controller
to application very simple and transparent, no matter whether visualisation,
database or archivation. Even manufacturer-independent communication between
different hardware components is possible. Time-consuming programming and
expensive engineering work are replaced by inexpensive, powerful standard
solutions for the implementation of automation tasks. <<
|
