ABBIndustrial Networks Connecting Controllers via OPC

single PCI card/OPC server combination product that supports slave redundancy

could be found on the market. However, Woodhead offers an API to control their

PROFIBUS multi-slave card. That is, it would be possible to program an own

redundancy logic for the PCI card. The OPC server, which has to support redundancy as well, needs to be adjusted or reprogrammed. Implementing this redundancy brainpower in the personal computer, one of the two cards has to be

the active card while the other is in standby mode to appear transparently to the

AC800M bus master.

Since the SST-PBMS-PCI card neither does support line redundancy, we would

have to insert two cards in one computer and implement the line redundancy logic

as computer software. As a far less laborious alternative, the RLM01 introduced

earlier can be inserted.

The automation company Comsoft offers a hardware device called PRS to implement master redundancy in PROFIBUS DP systems [38]. It is intended to connect

two masters with the same address to one PROFIBUS. If one master fails, the device, which contains a galvanic switch, changes to the other master. The switchover

can also be initiated from outside via PROFIBUS itself or an additional Ethernet

connection. The device is intended for implementing master redundancy, which

is already done in our case. But, according to Comsoft, it is possible to “misuse”

the device for implementing slave redundancy and therefore replacing a software

solution [39]. However, logic to force a switchover would be needed anyway in order

for the system to work properly

6.2.3 OPC Communication

It is of course necessary that the OPC servers for both bus interface cards are running, as well as the bridging software, e.g. Kepware LinkMaster. In addition it

would be possible to add specific redundancy management software on the computers and interconnect them via (redundant) network and DCOM to the servers

located on the second computer. That would theoretically allow the setup of a completely redundant system, coping with the outage of two different OPC servers or

PCI cards at the same time, for example. Figure 6.5 shows the setup of such a completely redundant system. The black lines stand for OPC communication while the

three dotted arrows symbolize the redundancy communication (RedCom) between

two components.

There are different redundancy manager programs (RedMgr) available on the

market, for example Matrikon’s Redundancy Broker [40] or Kepware’s RedundancyMaster [41]. They act as a server on one side while acting as a client on the other

side, able to connect to redundant servers. The decision which server has to be considered the active one depends on the quality of the OPC connection and/or can

be configured with additional checks of values. The software therefore also allows

a restricted view on the transported data. However, these programs also insert an

additional delay in communication, and from the computers point of view they are

a weakness themselves since most likely all OPC connections are canceled if the

program fails. Therefore it would also be possible to use different products at the

same time, increasing the chance that one product keeps running when the other

fails. However, a very interesting alternative is the software OPCFailover of Jemmac Software. While its function is the same as the classical redundancy managers,

it does not insert a further relay, which also means no delay and no single point

of failure. This is reached by just managing the OPC connection, always pointing

to an active real OPC server, instead of acting as a proxy. As a drawback of this

solution it is to mention that it does not support the periodical check of OPC values

yet [42].

However, the introduction of such redundancy managers only makes sense if

the OPC servers are implemented transparently redundant, meaning that only one

sever is active at the time and without the need to send/receive some variables

twice. This is not the case at the moment. The imaginary dashed green and red

RedCom links in Figure 6.5 would have to be implemented first as discussed in the

previous sections. Otherwise the OPC bridging software in PC1 will for example

not match the variables defined in AF100 OPC Server of PC2. Dependent on

the brainpower of both OPC server logics, maybe also the OPC bridges are not

allowed to run concurrently and need an own (gray) redundancy communication.

Matrikon’s OPC Data Manager supports such a layout.

Subsuming, there is one big advantage in implementing redundancy for the OPC

connections in our system: It allows the simultaneous outage of several unequal

parts of both computers. As a further consequence of the presumed transparent

redundancy of the OPC servers, no variables have to be defined and sent twice in

the controllers, there for saving transmission time. Unfortunately, there is also an

considerable number of disadvantages:

• The support of transparent redundancy for both OPC server pairs is missing

and has to be implemented first in order to establish a clean solution for OPC

connection redundancy. This work is a huge programming task not to be

underestimated.

• When using classical redundancy managers, also an extra delay and another