Configuration files for redundancy

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:

Config Entries - Redundancy (Optional)

These optional config entries allow additional configuration of the redundancy feature.

Config Entries - Split Mode

Following config entries allow additional configuration for the split mode. See also Redundancy in split mode

[split] splitPort

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.[platform] 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.

fwdDp

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. See also [event] fwdDP

fwdDpType

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). The corresponding elements of all data points of this type are forwarded irrespective of whether they existed when starting the Event manager. 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. See also [event[ fwdDpType

New forward data point types (fwdDpType) and forward data points (fwdDp) are not automatically recognized at runtime. Restart the EVENT manager in the WinCC OA console so that the new types are recognized.

dpSet with several elements with and without fwdDPs

If dpSets with several elements are executed in a dpSet call simultaneously and thereby elements with and without fwdDPs are used in the dpSet call consider the following:

The fwdDP setting of the first element of the dpSet list is used for ALL DPEs in the dpSet:

Thus, if the 1. element is a fwdDP, all elements of the dpSet call are written on the passive side and transferred to the active side. If the 1. element is not a forwardingDP, the elements are not transferred.

copyDp

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 copy 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). See also [event] copyDp

copyDpTypes

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). See also [event] copyDpType

Syntax:

[event]
copyDpType = "<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>.

<DPname> must not end with _2. as in this case they are not copied, e.g.: The data points Iec_2 and Iec_2_2 are not copied with copyDpType.

EXAMPLE

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 the config.redu 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.State"
copyDpType = "_Dnp3Station.Configuration"
copyDpType = "_Dnp3Station.Command"

In a redundant system different datapoints are generally used for the left and for the right system in drivers. Different datapoints are necessary because different status information must be displayed separately (e.g. left system _Dnp3StationA and right system _Dnp3StationA_2).

The fwdDpType entry is necessary so that you can set a datapoint also on the passive system (the passive driver has to set it's connection state for the station).

The entry copyDpType simplifies the configuration since the entry copies the DPE values automatically to the *_2 datapoint and the configuration DPs remain synchronous.

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 the config.redu 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.reduper 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.

The config entry [event] redOldNewComp is enabled by default for redundant systems. This setting prevents that a GQ after a redundancy switch would return all values and therefor lead to a lot of transmitted data and corresponding delays.

Project specific entries have to be made in the config.redu file of the project directory!

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.

After exceeding the recovery timeout the data manager automatically tries to restart the recovery.

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 Host 3

Please note, that for the [dist] distPeer connection no redundant network is used.

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 = "System3_host"
#Connect to Host 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

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.