../pvss.htm menu.gif basics.gif

Principle and functionality

In normal case a redundant system consists of two projects on different computers with same operating system. The same managers run on these both systems, which are provided with a redundant network connection. The redundancy is mostly hidden for the managers and the managers act as in a simple system. Actually, the data stream and dynamic are checked and controlled via the system messages of the Event Manager.

In a redundant system single system components can be controlled and provided with weighting, which is used for calculating the error status in case of errors. Components that are controlled and used when calculating the error status are e.g. managers, TCP connections, PLC connections, hard disk capacity, RAM memory etc. The weighting is a number from 0-999, which the user can assign specific to the components. The person who configures makes the decision how grave an error is, meaning which number is specified for the weighting. The crash of  a PLC connection is e.g. configured with a higher weighting as a crash of a UI. In normal case the sum of the weightings that produce the error status should be same on both computers (optimal is the error status 0). In case of errors the computer is automatically switched. This means the active computer is always the computer with the lower error status. The error calculation is executed in the CTRL script calculateState.ctl (this script is contained in pvss_scripts list). The configuration and error weighting are executed in the system overview panel. For further information see System overview panel in redundant systems.

The redu manager (WCCILredu) executes further important functions in case of a redundant system (the default number of the redu manager is 4776). The redu manager has the following tasks:

  • Redundancy state: The redundancy status (which computer is active and which is passive at the moment) is defined and given by the redu manager since the redu manager keeps all information (internal system statuses) of itself and of its partner. Furthermore the redu manager manages the error statuses of itself and of its partner. These statuses are compared to each other and the computer with the lower error status becomes automatically active (the Event Manager switches the active/passive status of the computers).

  • Exchange of system information and alive messages

  • Analysis of partner crashes.

The following figure should visualize the principle of the redundancy a little better:

 

Figure: Redundancy in WinCC OA

Redundancy-02.png

 

The figure shows a detailed presentation of both computers Server 1 and Server 2 as these are already known from the figure on the page redundancy, basics. Server 1 is in the control mode (active) and server 2 is in the hot standby mode (passive).

The UIs of the operating terminals are connected to both Event Managers in redundancy case. However, only data of the active system is shown on both UIs. The Event Manager of the passive system is restricted to communication with the Event Manager of the active system for balancing of the process data (it does not send any data to the connected UIs or discards the messages of the drivers. You can see this in the figure with the switch in the UIs or at the passive Event Manager.

The message logic (messages and commands) is illustrated via the following figures:

Driver message

Figure: Messages in the message direction

Redundancy-03.png

 

The message in the message direction is processed as follows:

  1. Both drivers receive a message from the periphery (this does not always happen since the driver receives the different values at different times when a polling is configured. This means that the driver receives a message only on one computer). On the active system the value is passed to the Event Manager and the passive system discards the message.

  2. The Event Manager on the active system sends the value to all registered managers. Via the redundant network connections the value is sent to the passive Event Manager. On the passive system again the value is sent to all managers registered at the Event Manager.

  3. The value is sent to UI`s of both operating terminals only by the active Event.

note.gifNote

The same behavior also applies for values, which are sent by other managers (e.g. CTRL, API)!

Driver command

Figure: Messages in the command direction

Redundancy-04.png

 

The message in the command direction is processed as follows:

  1. A value is changed on the UI of the operating terminal 1. The change is sent to the Event Manager of the active system. The passive Event Manager does not accept any change from UI.

  2. The Event Manager on the active system sends the value to all registered managers. Via the redundant network connection the value is sent to the passive Event Manager. On the passive system the value is passed to all managers registered at the Event Manager.

  3. The value change is passed to the periphery via the driver on the active system. The driver on the passive system discards the value changes and does not pass any data to the periphery.

note.gifNote

This behavior in the command direction applies specific only for driver!

 

Since the database is identical on both computers the same DPs exist on both computers. These DPs always have the same value and name on both computers. For the DPs described so far (in the command and message direction) this was wished. The behavior of the message logic in the message and command direction was already described in the previous paragraphs.

 

Furthermore, there are data point elements for internal states (e.g. disk space, RAM memory, connection to the peripehery, ...) . The information of these data point elements may be different on both computers and has to be known on both computers. This case is solved different in the redundancy:

 

  • DP`s containing Information for internal states exist twice with different names (once with the Postfix "_2" and once without postfix) on each computer. That kind of internal DPE for the display of the connections state to periphery (PLC) is e.g. _apc_equipment.ConnState (the data point _apc_equipment  of type  _Apc_Equ is created in the system when creating an Applicom device. See chapter Applicom driver, basics for further information on the Applicom driver. In case of redundancy also the data point apc_equipment_2 is automatically created.

  • The left computer is responsible for data point without postfix, the right computer sets the "_2" data point. Assuming that the Applicom driver looses the connection to the periphery the element _apc_equipment.ConnState would be set on the left computer in case of normal driver logic (left computer is active, right computer is passive). If connection would be lost on the right computer this would discard the value (since it is passive) and the "_2" data point is not set. So that this kind of behavior does not occur there are so called "Forward DPs". Forward DPs are set and passed to other computers (the DPE _apc_equipment.ConnState is a such forward DP). Thus, it can be guaranteed that the information is always available on both computers.

  • The data point _apc_equipment does, however, not only consist of the element .ConnState but also of elements, which contain configurations or trigger commands (e.g.  _apc_equipment.Board, _apc_equipment.Channel, _apc_equipment.Protocol, ...). The value of these DPEs should be identical on the left and on the right computer in normal case. So that such DPEs are identical on both computers there are so called  "Copy DPs". Copy DPs adopt the set value to the DPEs of the both computers. Thus, if the e.g. the element _apc_equipment.Channel is set to "3" the value "3" is also set on the element _apc_equipment_2.Channel.

Settings concerning forward and copy DPs (especially in case of project specific adjustments) are executed in the configuration file config.redu in the directory <proj_path>/config (see also configuration files for redundancy).

 

example.gifExample: Configuration for the Applicom driver

  1. Open the file config.redu in the directory <wincc_oa_path>/config.

  2. Copy the section for the settings of the Applicom driver into the clipboard:

[event]

#copyDpType = "_Apc_Equ.Protocol"

#copyDpType = "_Apc_Equ.GeneralQuery"

#copyDpType = "_Apc_Equ.Active"

#copyDpType = "_Apc_Equ.InternalPollList"

#copyDpType = "_Apc_Equ.Board"

#copyDpType = "_Apc_Equ.Channel"

#copyDpType = "_Apc_Equ.ChannelEqNum"

#copyDpType = "_Apc_Equ.ReduConn.Board"

#copyDpType = "_Apc_Equ.ReduConn.Channel"

#copyDpType = "_Apc_Equ.ReduConn.ChannelEqNum"

#copyDpType = "_Apc_Equ.ReduConn.Active"

#copyDpType = "_Apc_Equ.ReduEqu.Board"

#copyDpType = "_Apc_Equ.ReduEqu.Channel"

#copyDpType = "_Apc_Equ.ReduEqu.ChannelEqNum"

#copyDpType = "_Apc_Equ.ReduEqu.Active"

#copyDpType = "_Apc_Equ.ReduEqu.ReduConn.Board"

#copyDpType = "_Apc_Equ.ReduEqu.ReduConn.Channel"

#copyDpType = "_Apc_Equ.ReduEqu.ReduConn.ChannelEqNum"

#copyDpType = "_Apc_Equ.ReduEqu.ReduConn.Active"

#copyDpType = "_Apc_Equ.ReduControl.Equ.SpsTag"

#copyDpType = "_Apc_Equ.ReduControl.Equ.MonMode"

#copyDpType = "_Apc_Equ.ReduControl.Equ.CmdMode"

#copyDpType = "_Apc_Equ.ReduControl.Equ.Switch"

#copyDpType = "_Apc_Equ.ReduControl.Conn.SpsTag"

#copyDpType = "_Apc_Equ.ReduControl.Conn.MonMode"

#copyDpType = "_Apc_Equ.ReduControl.Conn.CmdMode"

#copyDpType = "_Apc_Equ.ReduControl.Conn.Switch"

  1. Create a new file with the name config.redu  in the directory <proj_path>/config.

  2. Add the section for the settings of the Applicom driver from the clipboard to the newly created file.

  3. Adjust the settings in the this file according to your project. Remove comment characters before the "copyDpType".

  4. There is also an element, which can be different on both computers, above the copy DPs. Therefore this element is also configured as forward DP:

fwdDpType = "_Apc_Equ."

note.gifNote

This element should not be changed in the config.redu file!

 

With the key word "fwdDpType" (like fwdDp) all changes on this DP element are passed from the Event Manager automatically to the redundant Event Manager. Contrary to "wdDp" a DP element of an existing data point is not specified but the element of a DP type in the form  "Type.Element" (e.g. "ExampleDP_Bit." for the root element of the DP type "ExampleDp_Bit").  Thus, the corresponding elements of all data points of this type are forwarded.

Split mode at redundancy

The split operation at redundant systems is a separation of both redundant servers whereas one server remains active. The second server can be used for tests of new configurations and configurations. The advantage is that this can be executed at runtime on a plant without adverse effect on the active system.

You can freely choose which system remains active when using the split mode (switching the UIs to this system) and which system is used for test purposes. After finishing the tests the system returns to the redundancy operation on the basis of a system. This means that if the test was successful the system is synchronized with the control system when the system returns to the redundancy mode and the new configuration is used on both systems. If the old system should remain redundant the test system is synchronized with the control system and the redundancy runs with the settings, which existed before switching to the split mode.

For detailed information on the split mode see chapter System overview in redundant systems and Redundancy in split mode.

Redundancy behavior of the passive event

The redundancy behavior, which is used since WinCC OA release 3.5, provides that the value changes on the passive event will not be discarded till it is not sure that the active event processed/passed them.

Behavior before 3.5 version

Good case:
 

Time Stamp      Event Manager (1|2)          Description

--------------------------------------------------------------------------------------------------------------------------------------------------------

10:00:00                  Event 1(active)                 Gets value change 1

10:00:01                  Event 2 (passive)              Gets value change 1

10:00:02                  Event 2 (passive)              Discards value change 1

10:00:03                  Event 1(active)                  Processes value change 1 and passes it to Event 2

 

Critical case - Breakdown of the active event - data loss:

 

Time Stamp      Event Manager (1|2)          Description

---------------------------------------------------------------------------------------------------------------------------------------------------------

10:30:00                  Event 1(active)             Gets value change 2

10:30:01                  Event 2 (passive)          Gets value change 2

10:30:02                  Event 2 (passive)          Discards value change 2

10:30:03                  Event 1 (active)            Breakdown -> no passing to Event 2!

 

Behavior after 3.5 version

Good case:
 

Time Stamp      Event Manager (1|2)          Description

--------------------------------------------------------------------------------------------------------------------------------------------------------

10:00:00                  Event 1(active)              Gets value change 1

10:00:01                  Event 2 (passive)           Gets value change 1

10:00:02                  Event 2 (passive)           Ignores value change 1 <- NEW

10:00:03                  Event 1(active)               Processes value change 1 and passes it to Event 2

10:00:22                  Event 2 (passive)           Discards value change 1
 

 

Critical case - Breakdown of the active event:

 

Time Stamp      Event Manager (1|2)          Description

--------------------------------------------------------------------------------------------------------------------------------------------------------

10:30:00                  Event 1 (active)               Gets value change 2

10:30:01                  Event 2 (passive)             Gets value change 2

10:30:02                  Event 2 (passive)             Ignores value change 2 <- NEW

10:30:03                  Event 1 (active)               Breakdown ->  no passing to Event 2!

10:30:13                  Event 2 (passive)             Detects the breakdown of the active event and processes

all value changes, which have not been processed yet

10:30:14                  Event 2 (now active)        Processes value change 2

 

Taking sender into account

As this behavior of the redundancy should only be used in case of a failure (breakdown, disconnect, etc.), the sender of the value change is also taken into account.

 

Time correction in case of the same sender

 

When in the process image is saved that the last vale change was sent by driver 1 with the time stamp 10:00:01 and the currently processed value change by the event has been also received from driver 1, but with the time stamp 10:00:00, then a time correction is used instead of this redundancy behavior. Time correction means that the time stamp will be corrected to <last_value_change> + 1 millisecond (in that case 10:00:00 + 1 millisecond)..

 

Different senders

 

When in the process image is saved that the last vale change was sent by driver 2 with the time stamp 10:00:01 and the currently processed value change by the event has been also received from driver 1, but with the time stamp 10:00:00, the event detects that a redundancy switch had been executed and discards this value change.

 

Simultaneous value changes and general query

Simultaneous value changes from different drivers (senders) will be discarded.

In case of a general query all values, which have not been changed, will be send with the same time stamps, what may happen that they will be discarded by this redundancy behavior. Thus this redundancy behavior will not be used in case of a general query.

 

page_top.gif

V 3.11 SP1

Copyright ETM professional control GmbH 2013 All Rights Reserved