Vertical Integration

Author: Dr. Rainer Beudert, published (in German) Elektronik Praxis 4/2004, S. 38–39, PDF

As head electro design engineer, responsible project engineer or planner of future production lines you are faced with the decision of introducing OPC as the standard interface. But you ask yourself the following questions. Why should I choose OPC anyway? Just how fast is OPC actually? Can two OPC servers communicate directly with each other. What products are available to me for the planned OPC project? Can I also exchange OPC data via the Internet. What do I need on the hardware side to be able to communicate via OPC? Examples of applications and products will now be used to present practical solutions surrounding the topic of OPC and Ethernet.

Why should I choose OPC anyway?

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“ (Hthig 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.

Figure 1: One for many: With ISO (H1), ISO on TCP (RFC1006), TCP/IP, Modbus on TCP and EtherNet/IP, the INAT OPC Server meanwhile covers many controller families in addition to Siemens S5/S7.

The INAT OPC Server TCPIPH1 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.

Figure 2: With OPC Tube OPC communication also functions via Internet

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.

Figure 3: Direct data transport between two OPC Servers is achieved with the OPC Router

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.