Config
file
Config
entries are required for a redundant system. This chapter describes
the config entries required for setting up a redundant system.
The entries are automatically generated when creating a redundant
project (see also creating a redundant
system). The entries are set in the config file located in
<proj_path>/config/config.
For redundancy the config file on both computers has to contain
the following entries:
Entry |
Type |
Default |
Range |
Description |
data |
string |
"local host name, port
4897" |
"host1-1[:port1],host1-2[:port1]$host2-1[:port2],host2-2[:port2]" |
This entry defines the host
name of the Data Manager. Optionally with the port number.
Host name and port number are separated by a colon. For
redundant systems both data hosts are entered with a dollar
sign separately. The complete syntax is:
data = "host1[:port1]"
Or (in case of redundancy):
data = "host1[:port1]$host2[:port2]"
Or (in case of redundant network
connections):
data = "host1-1[:port1],host1-2[:port1]"
Or generally:
data = "host1-1[:port1],host1-2[:port1]$host2-1[:port2],host2-2[:port2]"
Default: local host name and port
4897.
Instead of specifying the host
name you can also use IP addresses, e.g. data = "192.168.154.26".
It is required that these are defined in the hosts file.
The use of IP addresses can possibly bring undesirable
effects (resolution of IP- host name when using in scripts).
If there are problems with the functionality when using
IP addresses, you have to use the host names!
Note:
This entry replaces the config entries "dataHost"
resp. "dataPort" (known from former versions)
which remain for compatibility reasons. |
event |
string |
local host name, port 4998 |
"host1-1[:port1],host1-2[:port1]$host2-1[:port2],host2-2[:port2]" |
Specifies the host names and
optional the port numbers of the Event Manager. The syntax
of this entry is the same like the syntax of the config
entry "data" (see above).
Default: local host name and port
4998.
Note:
This entry replaces the config entries "eventHost"
resp. "eventPort" (known from former versions)
which remain for compatibility reasons. |
|
Further
redundancy specific config entries are:
Entry |
Type |
Default |
Range |
Description |
linkUpDelayTime |
int |
0 |
0 - maxInt |
When the REDU managers of a
redundant system establish a connection (with each other)
the EVENT is informed
first after "linkUpDelayTime". The error states
are, however, exchanged right after the REDU-REDU connection
is established. |
portNr |
uint |
4899 |
1024 - 65535 (TCP/IP Ports) |
Server port for the Redu manager.
The entry has to be the same on both computers. |
connectToRedundantHosts |
uint |
0 |
0|1 |
This entry specifies if a manager
that normally connects to only one Event
Manager (e.g. CTRL) should connect to both Event
Managers in a redundant system. The entry can be used
in all sections except [general].
This means that all managers can build a connection to
both Event Managers.
For example:
[ctrl]
connectToRedundantHosts
= 1 |
delayChange |
int |
0 |
0|1 |
Defines whether
a redundancy switch takes place immediately, if the own
error status is worse than the
status of the redu partner, or after activeChangeInterval
seconds.
activeChangeInterval > 0 and delayChange
= 0
means that the switch takes place
immediately but the next switch will never be carried
out sooner than after activeChangeInterval
seconds.
activeChangeInterval > 0 and delayChange
= 1
means that after a change of the
error state the Redu manager determines whether the change
is really necessary. If the error state is still worse
after activeChangeInterval seconds, the switch takes place.
A possible next switch will take place after this interval
again. This timer does not work for the "manual"
switch (.Command.*) -
the commands are executed immediately (and possibly the
timer is restarted).
Note
Must be set
inside the config.redu file! |
activeChangeInterval |
int |
10 |
>= 0 |
Delays a redundancy switch by the
specified time. If activeChangeInterval
= 0, the redundancy switch takes place immediately, if
the own error status is worse than the status of the redu
partner
Note
Must be set
inside the config.redu file! |
|
The
following table contains the config entries for the split mode.
Add the entries into the [split]
section of the config file (see also chapter Redundancy
in split mode):
Entry |
Type |
Default |
Range |
Description |
splitPort |
uint |
4778 |
1024 - 65535 |
The port number at which the
second split manager (at host 2) receives connections.
|
splitHost |
string |
"" |
- |
Obsolete since version 3.7.
The host to which the split mode manager connects is always
the host of the Event manager. |
|
Additionally
you have to configure the error weighting in the overview panel
of the redundancy. For detailed information on the system overview
panel see chapter System
overview in redundant systems.
config.redu file
There are also entries in the config.redu file located in <wincc_oa_path>/config/.
Use the file with the same name in the project directory for project
specific settings. This file is automatically read after project
config file, config.level and config.[plattfrom]
files. The config.level, config.platform and config.redu files
are first read from the version directory, from the sub project
directory and thereafter from the project directory:
PROJ_PATH/config
wincc_oa_path/config.level
SUB_PROJ_PATH/config.level
PROJ_PATH/config.level
wincc_oa_path/config.platform
SUB_PROJ_PATH/config.platform
PROJ_PATH/config.platform
wincc_oa_path/config.redu
SUB_PROJ_PATH/config.redu
PROJ_PATH/config.redu
A config.level file in the project directory does
not replace a config.level file in the version directory but the
files are merged.
The config.redu configuration file contains the
settings concerning forward and copy DPs, which are relevant for
the redundancy (you can find a description of the forward and
copy DPs in this config file on the page principle
and functionality. Additionally, the file contains the settings
for connectRetries and connectDelay. The entry "connectRetries"
specifies the number of connection attempts to another manager.
There is pause "connectDelay" between the attempts.
The entries are needed when copying the database.
With the keyword fwdDp (= forward data points)
the changes of the original attributes of the specified DP element
are forwarded from the Event manager automatically to the redundant
Event manager (regardless of whether the value is set on the active
or passive Event). If the element is a node this applies for all
leaves under the node. In order to pass different elements this
keyword can be specified several times. Via passing the elements
changes that can only occur on one of the computers (e.g.
disk full, connection status to periphery) can be sent to the
other computer in a redundant system.
With the keyword fwdDpType (= forward data point
type) the changes of the original attributes of the specified
DP element are forwarded from the Event manager automatically
to the redundant Event manager like via the keyword fwdDp. The
difference between fwdDp and fwdDpType is that not a DP
element of an existing data point is specified but the element
of a DP type in the form of "Type.Element"
(e.g. "ExampleDP_Bit."
for the root element of the DP type ExampleDP_Bit). Thus,
the elements of all data points of this type independent of they
exist when the Event manager start or not, are forwarded. If the
DP element is a node this applies for all leaves under the node.
In order to forward different elements the keyword can also be
specified several times.
With the entry copyDp you can configure that the
value of a DP element (Source data point element) is copied to
another DP element (Target data point element). Changes of the
source DP elements original attribute are automatically transfered
by the Event manager to the target DP element. The target DP has
to be of the same DP type as the source DP! If the source DP element
is a node, all underlying leaves will also be copied. To duplicate
more elements, the entry copyDp can be declared several times.
Copy DPs are elements that normally are equal on both computers
like e.g. configurations or triggering of commands (GA, change
of the archive set).
With the entry
copyDpTypes all changes of the source DP elements original attribute
are copied by the Event manager to the elements of the target
DP type (analogous to copyDp).
Syntax:
[event]
copyDpTypes
= "<data point type>.<data point element>"
If two data points
of this type have the names <DPname>
and <DPname>_2,
<DPname>.<element>
will be copied to <DPname>_2.<element>.
Restriction:
<DPname> must not
end with _2.
For example:
The data points Iec_2 and Iec_2_2 will never match for a copyDpType
configuration.
If a data point is created that matches a data
point defined in the copyDP, copDpType, fwdDp or fwdDpType, the
data point will be copied or forwarded without that the project
needs to be restarted before.
The entries for Forward and Copy DPs are made in
the [event] section of this file.
#
Message and configs statistic information
[event]
copyDp = "_Stat_Configs_Refresh.SecsToRefresh"
"_Stat_2_Configs_Refresh"
copyDp = "_Stat_Connections_Refresh.SecsToRefresh"
"_Stat_2_Connections_Refresh"
fwdDpType = "_Statistics_Connections."
fwdDpType = "_Statistics_DataConfigs."
fwdDpType = "_Statistics_DriverConfigs."
fwdDpType = "_Statistics_EventConfigs."
#
DNP3 driver settings
[event]
fwdDpType = "_Dnp3Station."
#copyDpType = "_Dnp3Station.Configuration"
#copyDpType = "_Dnp3Station.Command.UnsolicitedResponse"
#copyDpType = "_Dnp3Station.Command.GQ"
#copyDpType = "_Dnp3Station.Command.DelayMeasurement"
#copyDpType = "_Dnp3Station.Command.ColdRestart"
#copyDpType = "_Dnp3Station.Command.SyncTime"
#copyDpType = "_Dnp3Station.Command.Active"
#copyDpType = "_Dnp3Station.Command.ClearIIN"
There are also other redundant specific entries
in other sections like [general], [data], etc. The entries in
parenthesis "$host1" and "$host2"
are automatically replaced via the host name of the left ($host1) and via the host name of the
right computer ($host2) .
All essential entries for the redundancy are predefined
in this file by default. You have to merely make project specific
settings (e.g. settings for the used drivers). The possible settings
are described in the config.redu per driver. Additionally
you can find for each driver a section that can be used as template
for the own project specific settings. See chapter principle
and functionality for an example on how you can adapt the
file to a project (configuration for the Applicom driver in a
redundant project).
Note
The
config entry redOldNewComp is set active by default due to the
fact that after a redundancy switch and the followed GQ all values
would be returned if redOldNewComp is deactivated. This would
lead to a lot of transmitted data which could cause a delay.
Caution
Project specific entries have to be made in
the config.redu file of the project directory!
CAUTION
If the maximum time that may be used for the
copying of the database in case of a redundant system is reached,
the following error message is shown:
(0), 2004.06.25 17:00:56.396, REDU, WARNING, 54,
Unexpected state, DataManager, recoveryTimeoutExpired, Recovery
timeout expired, aborting recovery and starting active
The maximum time that may be used for the copying has to be defined
in the config.redu file by using the entry passiveRecoveryTimeout,
e.g. passiveRecoveryTimeOut = 10.
Examples on config entries in case of different configurations
Example
1
The entries for a redundant system consisting
of two hosts (Host names Host1 and Host2):
Host1:
[general]
data =
"Host1-1,Host1-2$Host2-1,Host2-2"
event = "Host1-1,Host1-2$Host2-1,Host2-2"
Host2:
For host 2 the same entries as for the host1 are
required.
Example2
A redundant distributed system consisting of
three different systems (two redundant systems and one single)
all connected with each other:
Distributed System1 Host names System1_host1 and System1_host2)
System1 connects to System2 and System3:
[general]
data =
"System1_host1-1,System1_host1-2$System1_host2-1,System1_host2-2"
event = "System1_host1-1,System1_host1-2$System1_host2-1,System1_host2-2"
distributed = 1
[dist]
distPeer = "System2_host1$System2_host2"
2 #connect to both hosts of the
#System2 with system number 2
distPeer = "System3_host"
3 #Connect to Host3
Distributed system2 (Hostnames System2_host1 and System2_host2)
System2 connects to System1 and system3:
[general]
data =
"System2_host1-1,System2_host1-2$System2_host2-1,System2_host2-2"
event = "System2_host1-1,System2_host1-2$System2_host2-1,System2_host2-2"
distributed = 1
[dist]
distPeer = "System1_host1$System1_host2"
1 #Connect to both hosts with the
system number 1
distPeer = "System3_host"
3 #Connect to system 3
Distributed System3 (Host name System3_host)
System 3 is server for System1 and System2 and
therefore does not need a distPeer
entry.
[general]
distributed = 1
Caution
The order, in which the hosts are set in the
config file, must always be the same. This means that if e.g.
the hosts are set as follows in the data config entry:
data = "host1-1,host1-2$host2-1,host2-2"
the hosts in the distPeer
config entry must be set in the same order:
distPeer = "host1[:port1][$host2[:port2]]" system
number
Another order (distPeer = "host2[:port1][$host1[:port2]]"
system number) causes connection errors.
For more information on distributed systems see
chapter Distributed
systems, basics. How to create a redundant distributed system
is described in the chapter Example
on a redundant distributed system. |