Zeitplan, Fenster und Entprellung
Die meisten überraschenden Ergebnisse einer Regel kommen nicht aus der Bedingung, sondern aus der Zeitlogik: wie oft läuft die Regel, welchen Zeitraum sieht sie dabei, und wann darf sie einen Alarm anlegen oder klären. Diese Seite beschreibt genau das.
Ausführungsrhythmus
Der Rhythmus ist ein Quartz-Cron-Ausdruck mit sechs Feldern (Sekunde, Minute, Stunde, Tag, Monat, Wochentag) und dem Platzhalter ?:
| Ausdruck | Bedeutung |
|---|---|
0 * * * * ? | Jede Minute |
0 */5 * ? * * | Alle 5 Minuten |
0 */10 * ? * * | Alle 10 Minuten |
0 0 * ? * * | Zu jeder vollen Stunde |
0 0 8,20 * * ? | Täglich um 8:00 und 20:00 |
Das ist Absicht und keine Lücke. Die beiden Hälften einer Regel rechnen bewusst verschieden:
- Der Zeitplan folgt immer UTC.
0 0 6 * * ?feuert also um 6:00 UTC — in Mitteleuropa um 7:00 Ortszeit im Winter und um 8:00 im Sommer. - Der Zeitbereich folgt der eingestellten Zeitzone. „Gestern“ ist damit der Kalendertag, den Ihre Schicht erlebt hat — und am Umstellungstag entsprechend 23 oder 25 Stunden lang.
Für die meisten Regeln spielt das keine Rolle: Ein Rhythmus wie „alle 5 Minuten“ oder „stündlich“ feuert in jeder Zeitzone gleich oft. Wichtig wird es nur bei einer festen Tageszeit — etwa einer Regel, die vor der Frühschicht laufen soll. Rechnen Sie die gewünschte Ortszeit dann in UTC um, und denken Sie an die Sommerzeit.
Der Grund für UTC beim Rhythmus: Jeder Tag ist damit exakt 24 Stunden lang und die Läufe bleiben vergleichbar. In Ortszeit gäbe es außerdem Zeitpunkte, die es nicht gibt oder die zweimal vorkommen — 2:30 Uhr am Umstellungssonntag. Eine Regel darauf würde einmal im Jahr ausfallen und einmal doppelt laufen.
Das Fenster
Jeder Lauf betrachtet einen Zeitbereich, angegeben als Von und Bis. Beide Felder nehmen relative Ausdrücke:
| Ausdruck | Bedeutung |
|---|---|
now | Der Ausführungszeitpunkt |
now-15m | 15 Minuten davor |
now-24h | 24 Stunden davor |
now-1M-2d | Ein Monat und zwei Tage davor (Verschiebungen lassen sich aneinanderreihen) |
now/d | Auf den Beginn des Tages abgeschnitten |
now-1d/d | Erst verschieben, dann abschneiden — now-1d/d bis now/d ist „gestern" |
Einheiten: s Sekunden, m Minuten, h Stunden, d Tage, w Wochen, M Monate, y Jahre, Q Quartale. Ein absoluter Zeitpunkt in ISO-Schreibweise ist ebenfalls erlaubt, für eine laufende Regel aber selten sinnvoll.
Das Fenster ist halboffen: der Beginn gehört dazu, das Ende nicht. Ein Messwert genau auf der Grenze wird damit von zwei aufeinanderfolgenden Läufen genau einmal gesehen und nicht doppelt.
Gelesen werden die Werte, die die Zeitreihe regulär liefert — für ungültig erklärte und gelöschte Punkte bleiben außen vor.
Die eine Regel, die man kennen muss
Das Fenster muss mindestens den Abstand zweier Ausführungen abdecken.
Ein 5-Minuten-Fenster auf stündlichem Rhythmus lässt 55 Minuten je Stunde ungeprüft — und kein Ergebnis sagt das. Die Regel läuft, meldet brav „Bedingung nicht erfüllt" und hat den Großteil der Zeit nie angesehen.
Die Prüfansicht warnt, wenn Fenster und Rhythmus nicht zusammenpassen. Gemessen wird dabei der größte Abstand der nächsten Ausführungen, nicht der nächste: ein Zeitplan wie 0 0 8,20 * * ? feuert zweimal täglich in ungleichem Abstand, und der lange Abstand entscheidet, wie viel Zeit unbeobachtet bleibt. Die Warnung verhindert das Speichern nicht — die Einstellung ist erlaubt, sie ist nur fast nie gemeint.
Ein etwas größeres Fenster als nötig ist unschädlich: ein Zeitraum, der schon einmal betrachtet wurde, verändert nichts (siehe unten).
Der Wert vor dem Fenster
Zusätzlich zum Fenster liest ein Lauf den letzten Messwert davor — verfügbar als preceding.value und preceding.time. Zurückgeschaut wird dabei doppelt so weit wie das Fenster lang ist, höchstens aber 24 Stunden. Liegt in dieser Strecke kein Punkt, bleibt preceding leer.
Dieser Punkt ist der Grund, warum eine Lücke, die schon vor dem Fenster begonnen hat, überhaupt erkennbar ist.
Entprellung: vier unabhängige Mittel
Ohne Entprellung ist jede erfüllte Bedingung sofort ein Alarm und jede nicht erfüllte sofort das Ende — bei verrauschten Messwerten also eine Alarmliste im Sekundentakt. Vier Felder, alle optional, alle als ISO-8601-Dauer (PT5M, PT30M, PT2H):
| Feld | Wirkung |
|---|---|
| Anhebeverzögerung | Die Bedingung muss so lange durchgehend erfüllt sein, bevor ein Alarm entsteht |
| Abfallverzögerung | Die Bedingung muss so lange durchgehend nicht mehr erfüllt sein, bevor der Alarm klärt |
| Rückfallbedingung | Ein eigener Ausdruck für das Klären, statt der Verneinung der Bedingung |
| Kontinuitätstoleranz | Größter Abstand zweier Messwerte, bis zu dem ein Lauf als ununterbrochen gilt |
Die Verzögerungen gelten je Regel, nicht je Stufe.
Wie eine Verzögerung gemessen wird
Über die Folge der Fenster, nicht innerhalb eines Fensters. Ein Ausdruck sieht immer nur ein Fenster; die Dauer ist eine Eigenschaft der Folge. Der erste Lauf mit erfüllter Bedingung markiert also nur den Zeitpunkt, und der Alarm entsteht, sobald ein späterer Lauf mindestens die Anhebeverzögerung nach dieser Marke endet.
Bei einem 20-Minuten-Rhythmus wirkt eine 5-Minuten-Anhebeverzögerung erst nach 20 Minuten — vorher gibt es keinen zweiten Lauf, der sie feststellen könnte. Das liegt in der Sache, nicht an der Umsetzung.
Umgekehrt wäre die Messung innerhalb eines Fensters falsch, und zwar auf eine Weise, die leicht zu übersehen ist: eine Bedingung wie values.max() > 80 ist von einem einzigen Punkt einer ganzen Stunde erfüllt. Das als „eine Stunde durchgehend erfüllt" zu zählen, würde die Verzögerung völlig aushebeln.
Echte Hysterese über die Rückfallbedingung
Ohne Rückfallbedingung klärt ein Alarm, sobald die Bedingung nicht mehr erfüllt ist — bei einem Messwert, der um den Grenzwert pendelt, also im Wechsel auf und zu. Eine eigene Rückfallbedingung setzt eine zweite Schwelle:
Bedingung: values.size() > 0 && values.max() > props.level_max
Rückfallbedingung: values.size() > 0 && values.max() < props.level_max - 10.0
Der Alarm geht über dem Grenzwert auf und erst 10 cm darunter wieder zu. Zusammen mit der Abfallverzögerung lassen sich Wertabstand und Zeitabstand unabhängig einstellen.
Kontinuitätstoleranz
Die Toleranz sagt, bis zu welchem Abstand zweier Messwerte ein Lauf als ununterbrochen gilt. Ohne sie würden zwei Läufe zu beiden Seiten eines Datenlochs wie eine durchgehend erfüllte Bedingung aussehen — und genau den Fehlalarm erzeugen, gegen den die Entprellung existiert.
Das Feld hat bewusst keinen Vorgabewert, denn jeder Vorgabewert wäre eine Annahme über die Abtastrate. Leiten Sie ihn vom Signal ab: liefert ein Sensor alle 5 Minuten, sind PT15M drei ausgefallene Punkte — großzügig genug für einen Aussetzer, streng genug für einen echten Ausfall.
Das Regelfeld Kontinuitätstoleranz heißt intern maxGap, und es gibt außerdem die Ausdrucksfunktion maxGap(). Das sind verschiedene Dinge:
- Das Feld steuert die Entprellung: bis zu welcher Lücke ein Lauf noch zählt.
- Die Funktion liefert die größte Lücke im Fenster als Wert, mit dem Sie in einer Bedingung rechnen können.
Eine Regel zur Lückenerkennung nutzt oft beide gleichzeitig.
Was den Fortschritt einer Verzögerung verwirft
Drei Ereignisse setzen einen angelaufenen Fortschritt zurück:
| Ereignis | Wirkung |
|---|---|
| Eine Beobachtungslücke | Beginnt das Fenster nach dem Ende des letzten betrachteten Zeitraums, wurde die Strecke dazwischen nie angesehen. Der Fortschritt wird verworfen und neu aufgebaut. Ein offener Alarm bleibt dabei stehen: unbeobachtete Zeit kann keinen Alarm klären |
| Eine Datenlücke über der Toleranz | Der Lauf gilt nicht als ununterbrochen, der Fortschritt beginnt von vorn |
| Eine geänderte Bedingung oder Rückfallbedingung | Der Fortschritt wird verworfen. Geänderte Verzögerungen wirken dagegen einfach ab dem nächsten Lauf |
Und ein Fall, in dem bewusst nichts passiert: ein Fenster, das nicht später endet als der bereits betrachtete Zeitraum, verändert gar nichts. Deshalb sind eine Wiederholung und ein überlappender Nachlauf harmlos.
Wenn ein Lauf kein Ergebnis liefert
Jeder Lauf endet für jedes Objekt in einem von drei Zuständen:
| Zustand | Bedeutung |
|---|---|
| Erfüllt | Die Bedingung hält; die getroffene Stufe liefert die Kritikalität |
| Nicht erfüllt | Die Bedingung wurde ausgewertet und hält nicht |
| Kein Ergebnis | Der Lauf konnte für dieses Objekt nichts feststellen — eine gelesene Eigenschaft fehlt, der Ausdruck ist an den Daten gescheitert, oder eine Grenze wurde überschritten |
Kein Ergebnis weckt nicht und klärt nicht. Der Alarmzustand bleibt unverändert: ein offener Alarm bleibt offen, ein Objekt ohne Alarm bekommt keinen. Ein Fehler in der Überwachung darf keine Entwarnung sein.
Scheitert nicht ein einzelnes Objekt, sondern die Ausführung selbst — etwa die Datenabfrage —, ist das ein Fehlschlag der Regel, nicht 200 Fehlschläge ihrer Signale. Drei Fehlschläge hintereinander erzeugen einen Alarm über die Regel selbst; ein erfolgreicher Lauf setzt den Zähler zurück.