ABBIndustrial Networks Connecting Controllers via OPC

hand, also status information has to be communicated. If a component fails it can

for example be very important that the redundant part is able to recover the most

recent values in order to take over the communication.

6.1.4 Stand-by modes

There are different modes of redundancy. Sometimes, the redundant parts run in

parallel (load balancing) but can take the whole load in case the second system

stops working, as for example with water pumps or internet web servers. This kind

of redundancy is sometimes also referred to as hot standby with load balancing.

With line redundant bus systems, the sending component usually writes on both

lines whereas the receiving part chooses the line to read from.

In contrary there exist modes where only one part of a redundant pair can be

active, while the other part is in a standby mode ready to take over. Dependent

on the level of stand-by we talk about cold, warm or hot stand-by. Cold stand-by

usually means that the redundant system first has to start up and gather necessary

information before it is able to take over the communication, causing a comparatively long delay. Hot stand-by in contrary means that the redundant part is all

the time up and running and even knows status information of the active system,

always ready to take over the shortest possible amount of time. Warm stand-by at

last is something in between.

In bus systems, where normally the different bus subscribers are addressed, the

“flying redundancy” concept as in the CI854A can be used. That is, the active

communication interface and the backup interface always have the same address,

independent of which is the active one and which the backup. As a consequence, the

active and the passive interface have to switch addresses if a switchover takes place.

The advantage of this implementation is, that the backup slave has a valid address

and therefore can be reached as well, to receive status information, for example.

Moreover, such a switchover is transparent for the other bus subscribers. However, if there is an error during the switchover, it can happen that both redundant

components have the same address, the effects of which would be devastating.

6.1.5 Power Supply Redundancy

A lot of controllers and automation components are prepared to be connected to

two different power sources to further avoid outages. Establishing redundant power

supply, however, is a topic on its own and not covered by this Master’s Thesis.

6.2 Considerations

In this section we will make considerations on redundancy for the different parts

of our test system. Please notice that we omit a solution using only one personal

computer, since, in our opinion, this is the weakest part of our system, and numerous

software parts (e.g. the bridging programs) cannot be installed/run twice in order

to increase availability. We therefore aim at two PCs right away.

6.2.1 AC160 Side Devices

The AC160 controller and AF100 fieldbus provide a sophisticated redundancy concept. Thus, it is very common to insert two redundant processor modules as well

as two communication interfaces into one rack. For other bus participants this

configuration works transparently, so they do not care which PM/CI combination

is currently in use and which is in stand-by mode. All communication interfaces

already support line redundancy with two ports, this is also true for the CI527 PCI

cards.

Not only controllers are included in the redundancy concept, but also OPC

servers. That is, if two personal computers with CI527 and AC100 OPC Servers

are connected to the same AF100 bus, both servers can provide data sent from the

controller. Unfortunately, the redundancy concept is limited as this will not work in

the opposite direction when using DSPs, which are vital for our application: Only

one of the two servers is allowed writing to a specific variable on the controller.

However, since we need to transmit a lot more values from AC160 to AC800M than

vice versa, the OPC server redundancy concept helps us a great deal anyway: We

do not have to define and send all these values twice (it is to mention here that

defining and sending variables in AC160 is considerably less comfortable than in

AC800M).

In contrary, if we want redundancy for receiving variables, we have to define the

receiving DSPs twice. The according redundancy brainpower must then be placed

in the controller program code itself, that is, the code has to compare each received

data pair and then decide how to proceed. In other words, the redundancy of the

OPC servers/PCI cards is not transparent from the view of the AC160. Achieving

this transparency would only be possible by modifying the OPC server to support

transparent redundancy when writing DSPs to the controller, or by the development

and insertion of a specific hardware device between the AC160 and the PC.

6.2.2 AC800M Side Devices

Similar to the AC160, the AC800M supports processor module and communication

interface redundancy for PROFIBUS as shown in Figure 6.3. In order to increase

the availability of the CEX bus, also the redundancy link module BC810 is inserted

[10].

In contrary, the Woodhead PROFIBUS card and OPC server does not support slave redundancy and therefore limits the concept. It is to add, that no