Redundant OPC Server Configured By Exaopc-RD Virtual OPC Server

OKAYASU Shinji¹ KATAOKA Norikatsu¹ MINE Shini-ichirou¹ KATASE Eiji¹

We have developed the Exaopc-RD, virtual OPC server software, for configuring a redundant OPC server that supports the OPC specification Data Access (DA), Alarm Event (A&E) and Historical Data Access (HDA) interfaces. Exaopc-RD is installed on the OPC client, and provides a redundancy function in a 2-OPC server/1-OPC client configuration. Exaopc-RD enables the use of redundant OPC server functions without the need to rewrite existing client programs. In consideration of the features of each OPC server, a master/standby switching system, in which a "Warm Standby" mode is defined for the DA server and a "Hot Standby" mode is defined for the A&E server, is used for enabling redundancy. Exaopc-RD provides the HDA server, which is placed as a backup function for the DA and A&E servers, with an additional function for automatically storing data while the client is down. As a result, in a 2-OPC server/1-OPC client configuration, Exaopc-RD can achieve a redundant OPC server for minimizing the loss of process data even if one of the two servers or the client fails due to a hardware or software problem.

1. Industrial Automation Systems Business Division

INTRODUCTION

Exaopc provides interfaces compliant with each of the DA, A&E and HDA specifications laid down by the OPC Foundation. Ever since Exaopc was put on the market in 1999, it has been used by many OPC client programs including Plant Information Management System (PIMS), advanced operation support packages and advanced control packages as a common interface for looking up process data.

Though Exaopc so far has been highly acclaimed as a high- performance, high-reliability OPC server, OPC servers in many cases are required to supply data more stably and be able to avert data loss caused by hardware problems, for example, in client programs such as PIMS that expect continuous process data over prolonged operation.

With this release, we have put onto the market the Exaopc- RD, virtual OPC server software that provides a function for configuring a redundant OPC server so that the OPC client program can continuously look up process data in the event of hardware or software trouble.

CONFIGURATION OF REDUNDANT OPC SERVER

 

Figure 1 Configuration of Redundant OPC Server

The redundant OPC server configuration in Figure 1 is made up of a total of three Windows machines, two OPC servers (real OPC servers) and an OPC client, and is achieved by installing the virtual OPC server software (Exaopc-RD), that controls the redundancy function, on the client machine.

During normal operation, one of the real OPC servers functions as a master server, while the other real OPC server functions as a standby server. When Exaopc-RD receives an OPC interface call from the client, the client's request is conveyed to the real OPC server by calling the method as the virtual OPC client to the master server. When the master server returns the result of the method to the virtual OPC client, Exaopc-RD returns that result to the OPC client, and the method call invoked by the OPC client is completed. On the other hand, Exaopc-RD performs only the required initial setup on the standby real OPC client via the virtual OPC client beforehand to prepare the standby real OPC client so that control can be transferred in the event that the master real OPC client fails.

In the case of the DA interface, for example, the master server registers all data requested by the client OPC to the real OPC server and also updates the cache. Data read/write requests issued by the client are also executed on the master server. All tasks up to registration of data on the real OPC server are performed on the standby server, which stands by with updating of the cache in an inactive state. If a fault causes the master real OPC server to fall into an inoperable state, Exaopc-RD detects this to switch the standby server to a control state, and initiate regular operation such as cache updating as an OPC server (Warm Standby mode). This mode achieves redundant lookup of process data access without increasing the communications load with the PCS (Process Control System) one layer down in the system configuration. The turnaround time for switching-over is about 30 seconds, and data loss can be limited to one cycle's worth of data at maximum in the case of 1-minute cycle data.

In the case of the A&E interface, a mode (Hot Standby mode) is adopted where alarms and notifications are received on both the master and standby servers, and Exaopc-RD receives and merges both of these as cases where alarm and event omissions will cause major damage on the OPC client are anticipated. For this reason, alarm and event omissions will occur only when both of the two real OPC servers fail simultaneously.

As a result, the OPC client can continuously access process data without being aware of faults on the real OPC server only by changing the connected OPC server to Exaopc-RD and without changing the existing OPC interface program.

PRINCIPLES OF REDUNDANT OPERATION

Fault Detection and Transfer of Control

Figure 2 Fault Detection and Transfer of Control by Exaopc-RD

Figure 2 shows the relationship between Exaopc-RD and the real OPC servers. With Exaopc-RD, the virtual OPC client executes the requests received from the OPC client via the OPC interface on whichever of the two real OPC servers is the master. If Exaopc-RD detects a fault on the master OPC server during execution of the request, Exaopc-RD transfers control to the standby OPC server and again calls up the same OPC method on this standby OPC server. In addition, if there is temporarily no OPC method call from the client, the Exaopc-RD periodic monitoring thread periodically calls up the monitoring method for the OPC interface on both the master and standby OPC servers to quickly detect faults on the real OPC servers.

When Exaopc-RD detects a fault, it switches the OPC interface call on subsequent real OPC servers from the existing master OPC server to the standby OPC server. At the same time, migration of periodic processing such as DA server cache updating that is performed only on the master OPC server is also implemented during the control of transfer.

Real OPC Server

Figure 3 Software Configuration of Exaopc

Figure 3 shows the software configuration of the Exaopc OPC interface package, or the real OPC server. With Exaopc, only the DA server and A&E server communicate with PCS, access process data, and receive alarms and events. The HDA server automatically detects requests issued by the DA and A&E clients, and stores data, and alarms and events on its own managed database.

As a result, the DA and A&E clients can obtain past process data, and alarms and events via the HDA interface without using separate method calls for data storage. Though the interface for historically acquiring alarms and events is not provided in the OPC specification, an original historical event acquisition interface is defined on the Exaopc HDA server, and an additional function for historically retrieving alarms and events while the client is down is provided.

Inter-server Synchronization

 

Figure 4 Inter-server Synchronization and HDA Data Storage

Exaopc-RD is configured by independent OPC servers on each of the DA, A&E and HDA interfaces. Exaopc-RD monitoring and switching processes shown in Figure 2 also function independently of each of these servers. However, note, that simultaneous master/standby switching on those three interfaces is required when replacement of hardware, for example, because of a malfunction. This is why StatusManager, a status monitoring process for coordinating three interfaces, exists on Exaopc-RD as shown in Figure 4. StatusManager learns of switching operation on a real OPC server performed by one of DA, A&E and HDA, issues the switching instruction to the other real OPC server, and executes control so that three interfaces are switched simultaneously. StatusManager is also provided with a function for notifying the user of switching that occurs.

Automatic Data Storage on HDA Server

Though the HDA server, one of the real OPC servers, acquires data from the DA server, the HDA server cannot acquire data from the standby DA server on its own PC as the DA server has suspended data acquisition. For this reason, both of the master and standby DA servers function so that data is acquired from the master DA server as described as follows. (See HDA server in Figure 4.)

1. During regular operation, the HDA server connects to the local DA server running on its own PC if it is in master state and to the remote DA one if it is in standby state according to the master/standby status instructed by the Exaopc-RD StatusManager in order to store historical data. Furthermore, the standby HDA server executes data acquisition processing (equalization) from the master HDA server while the standby HDA server is down while the standby HDA server is starting up so that it can recover down data.
2. When there is a control transfer instruction from StatusManager, the recovery process is executed after both the master and standby HDA servers are restarted and then next, regular data storage process in (1) is executed.
3. As alarms and events are being received also on the standby A&E server, both the master and standby HDA servers are connected to the A&E server on the same PC at all times so that alarm and events storage processing is performed.

EFFECTIVENESS OF A REDUNDANT CONFIGURATION

As described below, Exaopc-RD provides OPC server functions for minimizing data loss even if a fault occurs on one of the two OPC servers or on a client PC.

1. Even if hardware or software trouble occurs on one of the real OPC servers, the following advantages can be expected on the OPC client as the OPC interface can be used via the other OPC server:
   a. Data loss on the DA interface can be minimized, and increased traffic on the control bus caused by a redundant configuration can be avoided. (Warm Standby mode)
   b. Alarms and events can be continuously received on the A&E interface. (Hot Standby mode)
   c. Process data can be continuously and historically referred to on the HDA interface.
2. Even if the OPC client is down, the following advantages can be expected after the client is recovered as data, and alarms and events while the client is down are automatically stored on the HDA server of the real OPC server:
   a. Process data while the client is down can be recovered on the HDA interface.
   b. Alarm and events data while the client is down can be recovered on Exaopc's original historical interface.
3. The user can use all of the above redundancy functions without rewriting OPC client programs.

CONCLUSION

Exaopc-RD achieves software redundancy compliant with each of the OPC specification DA, A&E and HDA interfaces. Of these interfaces, the HDA interface is provided with an additional function for automatic storage of process data if Exaopc is used as the real OPC server. This is an extremely useful function for PIMS and other programs that require continuous data as it prevents the loss of process data even if either of two OPC servers and the OPC client is down.

Though Exaopc-RD is a software-based redundancy function, a more solid redundancy function can be configured by using a fail-tolerant machine as the client PC, or by establishing two independent Ethernet lines between the client and real OPC servers.

REFERENCES

1. "OPC Data Access Custom Interface Specification Version 2.05a," OPC Foundation, 2001
2. "OPC Alarms and Events Version 1.02", OPC Foundation, 1999
3. "OPC Historical Data Access Specification Version 1.1," OPC Foundation, 2001
4. Terashima Nobuhiko, Okayasu Shinji, "Exaopc OPC Interface Package," Yokogawa Technical Report, Vol. 43, No.3, 1999, pp. 13-17 (in Japanese)

• Exaopc is a registered trademark of Yokogawa Electric Corporation.
• Windows is a registered trademark of Microsoft Corporation.