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

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:

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.gifNote

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.gifCaution

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

caution.gifCAUTION

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.gifExample 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.

example.gifExample2

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.gifCaution

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.

 

page_top.gif

V 3.11 SP1

Copyright ETM professional control GmbH 2013 All Rights Reserved