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 |
Beide Hälften einer Regel rechnen in der Zeitzone des Mandanten:
- Der Zeitplan:
0 0 6 * * ?feuert das ganze Jahr um 6:00 Ortszeit, im Sommer wie im Winter. Eine Regel „vor der Frühschicht“ tragen Sie also so ein, wie Sie sie meinen. - Der Zeitbereich: „Gestern“ ist der Kalendertag, den Ihre Schicht erlebt hat, und am Umstellungstag entsprechend 23 oder 25 Stunden lang. Eine eigene Zeitzone hat eine Regel nicht.
Für die meisten Regeln spielt die Zeitzone keine Rolle: Ein Rhythmus wie „alle 5 Minuten“ oder „stündlich“ feuert in jeder Zeitzone gleich oft, auch in der Stunde, die es bei der Umstellung auf Winterzeit zweimal gibt – er läuft in beiden. Wichtig ist sie nur bei einer festen Tageszeit. Um die Umstellung auf Sommerzeit gibt es eine Uhrzeit nicht (2:30 Uhr am Umstellungssonntag im März), um die Umstellung auf Winterzeit gibt es sie zweimal (2:30 Uhr im Oktober). Ein Zeitplan auf genau diese Uhrzeit läuft im März im Moment der Umstellung, also um 3:00 Uhr, und im Oktober nur einmal.
Bis zur Version mit dieser Änderung lief der Zeitplan in UTC. Regeln mit fester Tageszeit laufen seitdem 1 bis 2 Stunden früher, wenn Sie die Ortszeit damals in UTC umgerechnet haben. Prüfen Sie solche Regeln.
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, die Zeitangaben unter ihnen 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.
Aufbau einer ISO-8601-Dauer
Anhebeverzögerung, Abfallverzögerung und Kontinuitätstoleranz sind Zeitdauern in der Schreibweise der Norm ISO 8601, ebenso die Benachrichtigungspause. Eine solche Dauer beginnt immer mit P (Period); danach folgt jede Einheit als Zahl mit ihrem Kennbuchstaben, von der größten zur kleinsten. Stunden, Minuten und Sekunden stehen hinter einem T (Time):
| Teil | Bedeutung |
|---|---|
P | Steht am Anfang jeder Dauer |
D | Tage zu je 24 Stunden — P2D sind 2 Tage |
T | Trennt die Tage von Stunden, Minuten und Sekunden; ohne Tage folgt es direkt auf das P |
H | Stunden — PT2H sind 2 Stunden |
M | Minuten — PT30M sind 30 Minuten |
S | Sekunden — PT45S sind 45 Sekunden |
Einheiten, die Sie nicht brauchen, lassen Sie weg — mindestens eine muss aber dastehen, und die Reihenfolge ist fest. Tage, Stunden und Minuten sind ganze Zahlen: anderthalb Stunden schreiben Sie als PT1H30M, nicht als PT1.5H. Zusammengesetzt sieht das so aus:
| Dauer | Bedeutung |
|---|---|
PT1H30M | 1 Stunde und 30 Minuten |
PT2M30S | 2 Minuten und 30 Sekunden |
P1DT12H | 1 Tag und 12 Stunden |
P7D | 1 Woche |
Vor dem T steht M für Monate: P5M sind nicht fünf Minuten, sondern fünf Monate. Monate nimmt die Plattform aber nicht an, ebenso wenig Wochen (W) und Jahre (Y) — das Feld weist eine solche Dauer als ungültig zurück. Längere Zeiträume schreiben Sie in Tagen.
Gespeichert wird die Länge, nicht die Schreibweise: Eine gespeicherte Regel zeigt ihre Dauern in Stunden, Minuten und Sekunden — aus P1D wird PT24H, aus PT90M wird PT1H30M.
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.