Details zur RDB-Verdichtung

Abfrage von RDB-Verdichtungen wenn queryRDBdirect = 1

Verdichtete Werte können über die WinCC OA Lesefunktionen dpGetPeriod(), dpGetAsynch() (Zeitparameter wird ignoriert) und dpQuery() (mit time range) abgefragt werden. Die Festlegung des Verdichtungsintervalls erfolgt im Detail des DP-Identifiers (also zwischen Config und Attribut).

Die allgemeine Syntax lautet:

<System>:<DPE-Name>:_offline._<Verdichtungsstufe>_<Verdichtungsfunktion>._value

Beispiel für 10-Tages-Mittelwert:

System_1:Pumpe_1.Stellwert:_offline._10day_avg._value

Anmerkung: In einem SQL-Statement ist nur ein "_value"-Config erlaubt. Das bedeutet, dass in der Abfrage von verdichteten Werten in einem dpQuery() nur ein "_value"-Config abgefragt werden darf.

Abfrage von Verdichtungen wenn queryRDBdirect = 0

Mittels Abfrage des _offline.._compressions Attributes durch die Funktion dpGetAsynch() können die parametrierten RDB-Verdichtungen ermittelt werden, wenn queryRDBdirect = 0 (keine direkten Leseanfragen an die Datenbank). Der Quellzeit-Parameter der Funktion wird dabei ignoriert.

Folgende Abfragen sind möglich:

Abfrage von allen Datenpunkttypen, die eine Verdichtung parametriert haben

Eine dpGetAsynch() Abfrage mit einem DpIdenifier in dem

  • System,

  • _offline Config und

  • _compressions Attribut

gesetzt sind, liefert einen dynamischen unsigned Integer mit den Datenpunkttypnummern.

Beispiel:

main()
{
  dyn_int a;
  time t = getCurrentTime();
  dpGetAsynch(t, "System1:_offline.._compressions", a);
  DebugN(a);
}

Abfrage von allen Datenpunkten, die eine Verdichtung parametriert haben

Eine dpGetAsynch() Abfrage mit einem DpIdenifier in dem

  • System,

  • Datenpunkttyp

  • _offline Config und

  • _compressions Attribut

gesetzt sind, liefert einen dynamischen unsigned Integer mit den Datenpunktnummern.

Beispiel:

main()
{
  dyn_int a;
  dpGetAsynch(1963, "System1:Valve.:_offline.._compressions", a);
  DebugN(a);
}

Abfrage von allen Datenpunktelementen eines Datenpunktes, die eine Verdichtung parametriert haben

Eine dpGetAsynch() Abfrage mit einem DpIdenifier in dem

  • System,

  • Datenpunkttyp

  • Datenpunkt,

  • _offline Config und

  • _compressions Attribut

gesetzt sind, liefert einen dynamischen unsigned Integer mit den Datenpunktelementnummern.

Beispiel:

main()
{
  dyn_int a;
  dpGetAsynch(1963, "System1:Valve.Valve1:_offline.._compressions", a);
  DebugN(a);
}

Abfrage von allen parametrierten Verdichtungen eines Datenpunktelementes

Eine dpGetAsynch() Abfrage mit einem DpIdenifier in dem

  • System,

  • Datenpunkttyp,

  • Datenpunkt,

  • Datenpunktelement,

  • _offline Config und

  • _compressions Attribut

gesetzt sind, liefert einen dynamischen unsigned Integer mit <superDetail, detail>.

Die unteren 16 Bits sind die Verdichtungsstufe (detail). Die oberen 16 Bits sind die Verdichtungsstufe, die zur Berechnung der eigenen Verdichtung verwendet wird (superDetail).

Beispiel:

Eine _3day_avg Verdichtungsstufe wird auf der Basis einer _5min_avg Verdichtungsstufe berechnet. So ist die superDetailNr. von _5min_avg in den oberen 16 Bits und die detailNr. von _3day_avg in den unteren 16 Bits enthalten.

Oracle-Jobs

Die Steuerung der Intervallberechnungen erfolgt über Jobs. Pro Intervall (z.B. 5 Stunden) gibt es einen eigenen Job, der die Berechnungen für alle Verdichtungsstufen und -funktionen, die zum Intervall gehören, durchführt.

Die Steuerung der Jobs erfolgt mit dem Oracle Job Scheduler.

Intervall-Jobs

Mit jedem neuen Verdichtungsintervall wird ein Job für das Intervall angelegt, der den Start der Berechnungszyklen steuert. Die Anzahl der Jobs muss der Anzahl der Intervalle entsprechen. Für weitere Details siehe Tabelle CSINTERVAL.

Jeder Job wird mit einer Verzögerung gegenüber "seinem" Intervall gestartet (siehe dazu Feld JOBDELAY der Tabelle CSINTERVAL).

Bevor eine Intervallberechnung nach dem Start auch tatsächlich durchgeführt wird, muss folgende Voraussetzung erfüllt sein ("zeitliche Synchronisation mit kleineren Intervallen"):

Eine Intervallberechnung wird dann ausgeführt, wenn die Letztkalkulation (LASTCALC, Tabelle CSINTERVAL) aller kleineren Intervalle (siehe SIZE_ORDER der Tabelle CSINTERVAL) nach dem berechneten Endzeitpunkt des aktuellen Intervalls liegt. Das ist notwendig, weil die Berechnung größerer Intervalle oft auf den Daten der kleineren Intervalle aufbaut (siehe Tabellen CSHISTORY_xy, CSCALCULATION und CSSTEP).