Entwicklung in einem redundanten Projekt

Redundanz und Wertänderungen mittels CTRL/API Manager

In einem redundanten System werden Wertänderungen nur durch den Event Manager des aktiven Host Prozesses bearbeitet. Der Event Manager des passiven Hosts verwirft erhaltene Wertänderungen sofort, ausgenommen hiervon sind Wertänderungen die durch einen Treiber übertragen werden.

Im Falle eines Treibers werden auf dem passiven Host die erhaltenen Wertänderungen in eine spezielle Queue im Speicher aufgenommen, die sogenannte Déjà vu Queue. Im Falle eines Redundanzwechsels beginnt der nun aktive Event Manager die Werte innerhalb der Queue abzuarbeiten, wodurch ein Werteverlust verhindert wird.

Im normalen Betrieb erhält der passive Host Werte über den momentan aktiven Event Manager. Dadurch wird sichergestellt, dass beide redundanten Hosts ein gleiches Prozessabbild haben.

Dieses Vorgehen kann im Falle eines Redundanzwechsels zu einem Werteverlust führen wenn Datenpunktwerte von einem Manager gesetzt werden welcher nur zu seinem eigenen Redundanz Host verbunden ist. Dies gilt nicht für UI Manager da diese standardmäßig mit beiden Hosts des redundanten Systems verbunden sind.

Beispiel

System Konfiguration:

• Ein redundantes System mit Control Manager die auf beiden redundanten Hosts laufen und die Summe der Werte von DP1 und DP2 als Ergebnis auf den dritten Datenpunkt DP3 schreiben.
• Der Benutzer löst eine Wertänderungen für DP1 aus, welcher eine Neuberechnung der Summe innerhalb des CTRL Managers auf beiden Systemen auslöst.

Gehen wir von folgender Situation aus:

1. Die Berechnung kann auf dem passiven Host etwas schneller abgeschlossen werden und das Ergebnis wird an den eigenen Event Manager mittels dpSet gesetzt, welcher diese Wertänderung verwirft.
2. Während der noch laufenden Berechnung auf dem aktivem Host erfolgt ein Redundanzwechsel, dadurch wird dieser Host nun der passive Host.
3. Wenn die Berechnung des CTRL Managers nun auf diesem Host abgeschlossen wird und an den Event Manager gesendet wird verwirft auch dieser Host die Wertänderung, da er nun der passive Host ist.

Durch dieses Verhalten gehen die berechneten Werte verloren. Um dieses Problem zu umgehen muss der CTRL Code entsprechend geschrieben und zusätzliche Konfigurationen vorgenommen werden.

Die goldenen Regeln sind:

1. Die Déjà vu Queue für den CTRL Manager mittels Config Eintrag aktivieren.

[ctrl_2]
requestDejaVu = 1

1. Die Verwendung des gleichen Zeitstempels für die dpSet() Funktion innerhalb des CTRL Managers für beide redundanten Hosts.

Beispiel

Das Beispiel unterhalb demonstriert wie diese Regeln praktisch umgesetzt werden können.

// 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);
}