In
redundant systems you can switch to so called split mode. In split
mode the redundant server couple is split in two single systems.
One system continues to work "active", communicates
with the periphery, forwards value changes, etc. The other system
can be used for testing new configurations and configurations
without interfering the running operation.
After
the tests with new configurations are completed the state automatically
returns to normal (redundancy) on the basis of one of the both
servers (keep the original configuration or establish the new
configuration).
In
the split mode the message logic in the message and command direction
is considerably different than message logic in redundancy. This
page describes in more detail the functionality and use of the
split mode.
The
switching to the split mode is executed via the Split mode button in the system
overview panel (see also System
overview panel with redundancy).
Figure: Redundant system in split
mode
The figure shows in an easy form the functionality
of the split mode. As already mentioned the redundant system is
split. Via the separation an "active" and a test system
are generated. The active system continues to work normally and
takes care of the operating terminals. Contrary to the redundancy
the Event Managers of both systems
are active. The UIs are connected
to both Event Managers.
The split manager is active during the split mode
(the Redu manager is not active) and exchanges data between the
systems. The data for the exchange can be specified via the data
point groups SplitGet[_2] and
SplitConnect[_2]. SplitGet[_2] is the default name of the
copyDPGroup. This group contains DPs that are copied when
both split managers receive the connection. This is a one-time
balancing. When the split managers connect, they execute a dpGet()
on these DPs and transfer the values to the other split manager.
SplitConnect[_2]
is the default name of the connectDpGroup.
This group contains the DPs that are transferred in the split
mode every time something changes. This means when the split managers
connect they execute a dpConnect on these DPs and transfer the
changes to the other split manager.
For more information on the data point groups see
chapter data
point groups, basics.
Internal system states are exchanged between the computers
by default (DPEs are contained in both DP groups that are responsible
for the connection state, disk space, working memory, monitoring
of the redundant network etc.). In order to exchange project specific
data points between the both systems in split mode the existing
DP groups have to be extended.
 Note
If you want to exchange data between the both
systems in the split mode the Split manager has to be entered
into the console and started. If no data has to be exchanged between
the systems the Split manager is not necessary. When creating
a new project the Split manager is entered into the console by
default and is started automatically when starting the project.
Different data sets on both systems, which have
an essential influence on the functionality and handling in the
split mode concerning the message and command direction, result
from different configurations on the test system (create/delete
data points).
 Example:
Using the split mode
Switch the server, which
should normally continue to work, active in the system overview
panel (click on the Preferred
button - CAUTION: can be executed only when the error status
is the same on both computers) Switch to the split mode
(click on the Split
mode button in the system overview panel).
NOTE
When switching to split mode and switching
the driver, the "active driver"
button is greyed out for the local UI
(on which the UI was switched)
for 30 seconds.
The driver on the system,
which continues to work, remains active (Active driver button). Start another User Interface
with the command line option "-data hostname[:port]"
and "-event
hostname[:port]", which connects to the
test system or open the ASCII manager panel. Change the configuration
(create/ delete data points) on the test system with the started
UI. At changes with the aid
of the ASCII Manager panel the right host name has to be shown
at the connection information in the panel so that the changes
are executed on the right computer and in the right database.
Via the button Switch
you can select the right computer (test system) where the
changes should be executed ,in the ASCII manager panel (see
also ASCII
panel). Create e.g. the data point "TestDP_split
of type "ExampleDP_Float". Test the changed configuration
on the test system. If the changes are satisfying
set the driver on the test system active in order to connect
the new configuration to the periphery.
Note
In order to set the driver active on the test
system the PLC has to be suited to the new configuration so that
new created DPs can be used with the PLC!
All other UIs
can be used during the whole time. Switch again to the redundancy
mode (click on the Redundancy button). As basis
for the redundancy the computer with the changed configuration
(=test system) is used, the other restarts and adopts the
new configuration via the automatic recovery when starting.
Note
The PARA module in the normal UI
(this means in the UI that was
not started with "-data hostname[:port]"
and "-event hostname[:port]")
is connected in split mode to both computers! Note that the creating/deleting
of data points with this UI is
executed on both computers. The UI
has to be switched explicit on the desired computer to make changes
(there is a context menu for the switching - see context
menu for the UIs)!
 Caution
If a UI is
connected to only one Event Manager
in a redundant system in the split mode and the function isRedundant()
is called the returned value is FALSE!
When opening the system overview panel via this UI
the own redundant system is shown as single system!
Note
If the project is stopped on both hosts during
a recovery process (this means that the recovery process could
not be finished) and then redu host 1 is started, it may occur
that the Data Manager cannot start-up as possibly the RAIMA is
defect. In this case start the second host first, so that the
data on the first host can be subsequently recovered.
Note
Problems can occur when manager numbers are
assigned automatically in a redundant system! This case occurs
when you proceed as follows:
1. A UI is
started via the console (without command line options), which
connects to both computers and receives a number from the Data
Manager (Active as well as passive) (e.g. the number 1).
2. Subsequently a UI
with the options "-data
hostname[:port]" and "-event hostname[:port]"
is started via the console and receives a number from particular
Data manager to which the connection is built (e.g. number 2).
3. Another UI
is started via the console (without command line options) which
connects to both managers again and receives the number 3 from
the Data manager on the first computer (since number 1 and 2 of
this Data manager are already assigned), the number 2 from the
Data manager of the second computer (since this Data manager has
sonly assigned the number 1 so far).
In this case the third UI
is terminated with an error message. In order to prevent this
assign explicit a higher manager number to a UI
that should connect to a specific computer (e.g. "-num
20")!
Figure: Data space on both systems
is different
Messages in the message direction
With the aid of the following graphics the run
of the messages in the split mode is visualized. In the graphics
the left side is to be regarded as active and the right side as
test system. In addition you have to distinguish for which data
space (either for a DP, which exists only in the active system
or only in the test system or on both computers) the value, which
is reported from the periphery, is defined for.
Figure: Message in the message
direction - 1. Data point in the active system, 2. Data point
in both systems, 3. Data point "TestDP_split"
in test system
The first figure shows the message logic in case
that the value that is reported from the periphery is represented
on an element in the active system. The UI
has to be switched on the active computer.
The UI`s between
the computers are switched via the context menu for the UIs, which is opened via the system
overview panel.
Figure:
Context menu for the UIs
With the entry Switch
UI to eiwrk017 or Switch
UI to eiwrk028 you
switch a UI on the Event
Manager of the active or on the Event Manager of the test system.
The setting defines which servers values will be accepted (the
values of the other server will be discarded, see description
below). It is to consider, that commands will still be sent to
both server, regardless of the selection for the "Switch
UI" option.
The second figure (see "Message in the message
direction") shows the message direction in case that the
value received from the periphery, is represented on an element,
which exists on both systems. It does not make a difference on
which computer the UI is switched
on. The drivers on both systems process the value from the periphery
and forward this to the Event
Manager. Both Event Managers
again forward the value to UI.
Finally the UI decides from which
Event it accepts the value. The
other value is discarded.
If the element is located on the test system (like
the new created data point "TestDP_split"
in the example), the UI has to
be connected to the right side. This case is shown in the third
figure.
Messages in the command direction
The message logic for messages in the command direction
is described with the aid of graphics. The left system is to be
regarded as active and the right system as test system.
Figure: Message in the command
direction - 1. Data point in the active system, 2. Data point
in both systems, 3. Data point "TestDP_split"
in the test system
The first figure shows the message logic in case
that the value, which is sent to the periphery, is only set on
one data point element in the active system. The UI
has to be switched on the active computer when setting the value.
The switching of the UIs between
the computers takes place in the context menu for the UIs,
which is opened via the system overview panel (see also context
menu for the UIs). Additionally
the driver has to be active on the system that also shows the
element whose value is passed to the periphery. (in the figure
above the active driver is marked green). The switching of the
active driver takes place in the system overview panel via the Active
driver button.
The second figure shows the message logic in case
that the value, which is sent to the periphery, is set on an element
that exists on both systems. Thereby it does not make a difference
on which computer the UI is switched
or which driver is active. The UI
sends the value to both events, these again to the drivers and
the active driver passes the value to the periphery. The other
driver discards the value.
In the third figure the element is located in the
test system (as the data point "TestDP_split"
created in the example) and the UI
has to be connected to the right side. In this case the driver
on the right side (test system) has to be active.
The system overview panel in the split mode looks
like in the following figure:
Figure: system overview panel in split mode
In the system overview panel the system with the
active driver is visible (in the figure above the table "Driver" is activated on
the computer eiwrk017).
Via the button Active
Driver you can switch the driver on the desired system
active, on the other system the table "Driver" is grayed out.
If the redundant project is additionally distributed
(this means that the redundant system is connected to further
WinCC OA systems)
there are two additional buttons with the name Active Dist and Active
Event in the split mode. Via the button Active
Dist you specify which Dist Manager should be active. Since
the single systems communicate via the Dist Manager in a distributed
system and the Dist manager always contacts the active Event
Manager, the active Dist Manager has to be specified in the split
mode (since both Event Managers
are active in this case).
With Active Event
you don't set the Event-Manager (both Event-Manager have to be
active in order to process received messages), however, you specify
which SplitActive is active.
Although both Events have to be active in the split
mode, only one Event is allowed to forward messages to the other
system (only one Event may forward dpSets to external systems,
otherwise the commands would be processed twice in the external
system). Since both Events are active, another flag is needed
to control this. The _ReduManager.SplitActive flag.
The Redu manager data point element SplitActive
is TRUE for the active Event
side.
It's possible to activate the three managers on
different systems, however it makes more sense to activate them
on the same system.
The Redu manager data point element SplitMode
contains the information whether the SplitMode is activated or
not.
NOTE
_Driver1.DC element can be used as a command
but not for a response from the driver. The element is used in
the split mode to switch the driver!
In addition to the already specified entries you
can see the computer name the UI
is connected to (... - Eiwrk028) in the system overview panel
(see System
overview in redundant systems). Via the button Redundancy
the state returns to redundancy. Before the state returns to redundancy
a query (if the original or the new configuration should be used)
is executed. Choose the computer whose configuration you want
to use from the pop-up window. The project on the other computer
is restarted.
Figure: return to redundancy pop-up
window
While the project on the other computer is restarting,
it will be hidden in the system overview panel.
Figure: system overview panel during
the restart of the redundancy partner
|
