Welche Objekte überwacht werden

Eine Regel benennt ihre Objekte nicht einzeln, sondern beschreibt sie. Das ist der Grund, warum eine Regel 200 Pumpen überwachen kann und nicht 200 Regeln nötig sind — und der Grund, warum man vor dem Speichern hinsehen sollte, wen die Beschreibung tatsächlich trifft.

Alles dazu steht im Bereich Objekte des Regelformulars.

Der Selektor: zwei Achsen, mit UND verknüpft

Achse	Feld	Bedeutung
Ort	Teilbäume	Eine Objektkennung je Zeile. Das Objekt muss unterhalb eines dieser Knoten liegen. Leer heißt: der gesamte Baum
Merkmal	Eigenschaftsbedingungen	Bedingungen auf den Eigenschaften des Objekts. Alle müssen zutreffen

„Signaltyp = Temperatur UND Teilbaum = Werk A" ist ein Selektor mit einem Teilbaum und einer Bedingung.

Ein leerer Selektor trifft alles

Sind beide Achsen leer, überwacht die Regel jedes Signal des Mandanten. Das ist erlaubt und manchmal gewollt — aber es ist der Grund, warum die Trefferliste vor dem Speichern angezeigt wird. Sehen Sie sie an.

Eigenschaftsbedingungen

Je Bedingung geben Sie eine Eigenschaft (den Schlüssel, wie ihn die dynamischen Eigenschaften tragen), einen Operator und einen Wert an:

Operator	Trifft, wenn
EXISTS	Das Objekt den Schlüssel überhaupt mit einem Wert trägt, gleich welchem. Der Wert wird ignoriert
EQUALS	Der Wert gleich dem angegebenen ist
NOT_EQUALS	Das Objekt den Schlüssel mit einem Wert trägt und dieser abweicht

Verglichen wird auf der Textform des Wertes. Es gibt bewusst keine Größer-/Kleiner-Operatoren: es gibt keinen Katalog, der einem Eigenschaftsschlüssel einen Datentyp zusichert, und Ordnungsoperatoren würden ein Typsystem suggerieren, das nicht existiert. Größenvergleiche gehören in die Bedingung der Regel, nicht in den Selektor.

Verglichen wird auf der effektiven Eigenschaft — einschließlich der geerbten. Ein einmal am Werk gepflegter Wert erfüllt die Bedingung damit für jedes Signal darunter. Trägt ein Objekt den Schlüssel nirgends in seiner Kette, trifft die Bedingung einfach nicht; das ist kein Fehler.

Handauswahl und Ausnahmeliste

Zwei Listen ergänzen den Selektor, jeweils eine Objektkennung je Zeile:

Von Hand hinzugefügte Objekte gehören zur Regel, auch wenn der Selektor sie nicht trifft.
Die Ausnahmeliste gehört nie dazu, was der Selektor auch sagt.

Die Ausnahmeliste ist das, was ein Selektor nicht ausdrücken kann: „diese Regel für dieses eine Signal abschalten". Ein einzelnes Signal auszunehmen ist deutlich billiger, als dafür einen Vererbungsbaum von Übersteuerungen aufzubauen.

Die Bindung wird bei jedem Lauf neu bestimmt

Der Selektor ist eine Abfrage, kein Schnappschuss. Er wird pro Lauf aufgelöst, nicht beim Speichern der Regel. Daraus folgen zwei angenehme Eigenschaften:

Ein später angelegtes Signal, das passt, wird ab dem nächsten Lauf mitüberwacht. Niemand muss die Regel anfassen.
Ein Signal, das den Schlüssel verliert, fällt heraus, statt die Auswertung scheitern zu lassen.

Beim Verschieben im Explorer gilt dasselbe: ein Objekt an einer neuen Stelle erbt von neuen Vorfahren und kann dadurch in eine Regel hinein- oder aus ihr herausfallen, ohne dass jemand die Regel geändert hat.

Ausgeschlossene Objekte — der wichtigste Blick

Nicht jedes Objekt, das der Selektor trifft, wird auch ausgewertet. Zwei Gründe führen zum Ausschluss, und die Prüfansicht der Regel nennt beide beim Namen:

Grund	Bedeutung	Was zu tun ist
Eigenschaft fehlt	Ein Eigenschaftsschlüssel, den die Bedingung liest, ist nirgends in der Kette des Objekts gepflegt — nicht am Objekt und nicht bei einem Vorfahren	Den Wert pflegen, am besten weit oben in der Hierarchie, oder das Objekt aus dem Selektor nehmen
Keine Messreihe	Das Objekt hat keine gespeicherten Messwerte: keine Zeitreihe zu seiner externen Kennung, oder es ist ein flüchtiges Signal, dessen Werte nur innerhalb einer Workflow-Ausführung existieren	Die Datenzufuhr prüfen oder das Objekt ausnehmen

Solche Objekte werden ausgeschlossen und gemeldet, nicht als fehlerhaft ausgewertet. Das ist Absicht: würde die Regel sie mitrechnen, hätte sie nach drei Läufen einen Alarm über sich selbst — und bei einem breit greifenden Selektor wäre die Selbstüberwachung damit wertlos.

Die Kehrseite müssen Sie kennen: ein ausgeschlossenes Objekt ist still unbewacht. In der Alarmliste sieht das genauso aus wie ein Objekt, an dem alles in Ordnung ist. Nach dem Anlegen einer Regel — und nach jeder Änderung an der Hierarchie — lohnt der Blick in die Prüfansicht.

Eine Regel, viele Grenzwerte

Das ist der Kern des Zusammenspiels mit den dynamischen Eigenschaften: die Bedingung gehört zur Regel, der Grenzwert zum Objekt.

Bedingung der Regel:   values.size() > 0 && values.max() > props.level_max

Standort Nord:  level_max = 320   ─┐
Standort Süd:   level_max = 285    ├── eine Regel, vier Grenzwerte
Standort West:  level_max = 410    │
Standort Ost:   level_max = 260   ─┘

Der Ausdruck nennt props.level_max; welchen Wert das ist, entscheidet jedes Signal selbst — über seine eigene Eigenschaft oder eine geerbte von Standort oder Werk. Ein Grenzwert wird damit einmal am Werk gepflegt und nur an den Ausnahmen abweichend gesetzt.

Vier Namensräume stehen in einem Ausdruck bereit, und sie überlappen sich nicht:

Namensraum	Inhalt
`params.x`	Konstanten, die zur Regel gehören
`props.x`	Effektive Eigenschaften des Signals, einschließlich geerbter
`asset.props.x`	Eigenschaften des Assets, an dem das Signal hängt — ausdrücklich die Asset-Ebene, nicht die Überlagerung in `props`
`siblings.<name>.props.x`	Eigenschaften eines Nachbarobjekts, über seinen Namen angesprochen

Zwei Feinheiten, die im Alltag zählen:

Ein leeres Feld ist kein Wert. Eine Eigenschaft ohne Inhalt — auch ein leerer Text — ist in der Auswertung nicht vorhanden. has(props.x) antwortet dann falsch, und ein Lesen von props.x ist ein Fehler. Das entspricht dem Vererbungsverhalten: ein leeres Feld bedeutet „von oben übernehmen", nicht „hier leer".
Zahlen kommen als Kommazahlen an. Ein als 80 gepflegter Grenzwert vergleicht sich damit sauber gegen jedes Aggregat, das immer eine Kommazahl ist. Texte und Wahrheitswerte bleiben unverändert.

Ein fehlender Schlüssel ist ein Fehler, kein „nicht erfüllt"

Liest eine Bedingung props.level_max an einem Objekt, das den Schlüssel nicht hat, endet der Lauf für dieses Objekt ohne Ergebnis — er weckt und klärt nichts. Deshalb schließt die Regel solche Objekte von vornherein aus, statt sie scheitern zu lassen. Wer das nicht möchte, prüft im Ausdruck selbst mit has(props.level_max).

Der Selektor: zwei Achsen, mit UND verknüpft​

Eigenschaftsbedingungen​

Handauswahl und Ausnahmeliste​

Die Bindung wird bei jedem Lauf neu bestimmt​

Ausgeschlossene Objekte — der wichtigste Blick​

Eine Regel, viele Grenzwerte​