Development for Redundant Projects

Redundancy and value changes from CTRL/API Manager

In a redundant system, only Event manager on the active host processes the values changes. On the other hand, the Event manager on the passive host per default discards the value changes immediately, except they are coming from a driver.

In case of drivers the Event manager on the passive host, put the value change into a special queue in memory (the so called deja vue queue). In case of a redundancy switch, the new active Event processes the values in its deja vue queue again, which avoids loss of values.

In normal operation, the passive host in the end receives the value from the current active Event. In that way it is ensured that both redundant host have exactly the same process image.

This behavior can result in a value loss, in case of a redundancy switch over, when setting values on data points from a Manager, which is only connected to its own redundant host. For UI managers this cannot happen, because they are connected per default to both redundant hosts.

Example

System configuration:

• Redundant System with Control Manager running on both redundant hosts, which calculates the sum out of two values DP1 and DP2 and writes the result on a third data point DP3.
• User triggers a value change s on DP1, which triggers calculation of the sum value within the CTRL managers on both hosts

Let’s assume the following situation:

1. The calculation on the passive host is finished a bit faster and sends the result to its Event Manager via dpSet, which discards the value change.
2. During still running calculation on the active host, a redundancy switch over occurs, which means that this host is now the passive one.
3. When the calculation is finished the CTRL manager sends the result value to its Event, which is now the passive one and also discards the value change

In the end, the calculated summary value is lost.

To overcome this, the CTRL code has to be written in a specific way and some special configuration has to be taken into account.

The golden rules are:

1. Active the deja vu queue for the CTRL manager via config entry

[ctrl_2]
requestDejaVu = 1

1. Use a single source timestamp for the dpSet() in CTRL on both redundant hosts

Example

The example below demonstrates how these rules can be achieved.

// description
// How to set values from CTRL Manager in redundant system without 
// losing values
// example given: connect on 2 dps, calculae the sum and write the 
// value on a different DP
// prerequisites:
// * one ctrl on each redu host started with the same number e.g.:2
// * config entry set
// [ctrl_2]
// requestDejaVu = 1
main()
{
  // always subscribe at least to value + time
  dpConnect("work_sum",true,"ExampleDP_Arg1.:_online.._value",
                 "ExampleDP_Arg1.:_online.._stime",
                 "ExampleDP_Arg2.:_online.._value", 
                 "ExampleDP_Arg2.:_online.._stime");
}
work_sum(string sDp1Value, float fVal1, string sDp1Time, time tTime1,
         string sDp2Value, float fVal2, string sDp2Time, time tTime2)
{
  // To avoid value loss, we need the config entry requestDejaVu = 1
  // and the exact same timestamp for the dpSet on both redu hosts
  // this can be ensured by taking the timestamp from the Callback
  // example: take the largest timestamp as common timeStamp for the dpSet
  time tCommonTime = tTime1;
  if (tTime2 > tTime1)
    tCommonTime = tTime2;
  dpSetTimed(tCommonTime, "ExampleDP_Rpt1. ", fVal1 + fVal2);
}

This avoids the loss of value changes, but on the other hand can lead to duplicated values after the redundancy switch, because the deja vue queue is processed again after redundancy switch.