Dynamische Workflows
Ein dynamischer Workflow führt eine Transformation aus dem hetida designer für jedes Signal einer Auswahl aus, nach einem Zeitplan. Damit lässt sich eine Berechnung – etwa eine Plausibilisierung oder eine Glättung – einmal definieren und auf hunderte Signale anwenden, statt für jedes Signal ein eigenes virtuelles Signal anzulegen.
Sie finden dynamische Workflows unter Workflows im Reiter Dynamische Workflows.
Was ist daran dynamisch?
Dynamisch ist die Auswahl der Signale. Sie wird nicht beim Speichern festgeschrieben, sondern bei jedem Lauf neu aus der Asset-Auswahl und den Eigenschaftsbedingungen ermittelt. Kommt unter einem gewählten Asset ein neues Signal hinzu, das die Bedingungen erfüllt, wird es beim nächsten Lauf mitgerechnet – ohne dass jemand den Workflow anfassen muss. Fällt ein Signal aus der Auswahl heraus, wird es nicht mehr berechnet.
| Virtuelles Signal | Dynamischer Workflow | |
|---|---|---|
| Eingänge | fest auf bestimmte Signale verdrahtet | je Lauf aus der Auswahl ermittelt |
| Ergebnis | ein Signal | ein abgeleitetes Signal je Quellsignal |
| Anlegen für viele Signale | ein virtuelles Signal je Signal | eine Definition für alle |
Signalauswahl
Im Abschnitt Signalauswahl legen Sie fest, welche Signale berechnet werden. Gewählt wird im Baum neben dem Formular:
| Gewählt | Bedeutung |
|---|---|
| Asset | alle Signale unterhalb dieses Assets, auch in tieferen Ebenen |
| Signal | genau dieses Signal |
| Ausnahme | ein Signal, das trotz Auswahl nicht berechnet wird |
Ist weder ein Asset noch ein Signal gewählt, berechnet der dynamische Workflow kein Signal. Das unterscheidet ihn von einer Alarmregel, bei der eine leere Auswahl den ganzen Baum meint.
Signale, die ein dynamischer Workflow selbst erzeugt hat (abgeleitete Signale, siehe unten), werden von seiner eigenen Auswahl nie erfasst – sonst würde er beim nächsten Lauf seine Ergebnisse noch einmal berechnen.
Eigenschaftsbedingungen
Eigenschaftsbedingungen filtern die Signale der Auswahl nach ihren dynamischen Eigenschaften – geerbte Eigenschaften eingeschlossen. Berechnet wird nur ein Signal, das alle Bedingungen erfüllt.
| Bedingung | Trifft zu, wenn |
|---|---|
| ist vorhanden | das Signal die Eigenschaft mit irgendeinem Wert trägt |
| ist gleich | der Wert der Eigenschaft dem angegebenen Wert entspricht |
| ist ungleich | das Signal die Eigenschaft trägt und ihr Wert abweicht |
„Ist ungleich“ schließt also auch Signale aus, die die Eigenschaft gar nicht tragen. Wer Signale ohne eine bestimmte Eigenschaft erfassen will, wählt sie über die Signalauswahl, nicht über eine Bedingung.
Beispiel: Asset „Wasserwerk Nord“ gewählt, Bedingung signal_role ist gleich level – berechnet werden alle Füllstandssignale unterhalb des Wasserwerks, sonst nichts.
Transformation, Eingänge und Ausgänge
Als Transformation wählen Sie einen Workflow oder eine Komponente aus dem hetida designer (nur freigegebene Revisionen). Das Info-Symbol neben der Auswahl zeigt deren Dokumentation, mit der Bedeutung der Parameter.
Eingänge
Für jeden Eingang der Transformation legen Sie fest, woher der Wert kommt:
| Quelle | Wert |
|---|---|
| Gebundenes Signal | die Zeitreihe des jeweils berechneten Signals, im eingestellten Zeitfenster |
| Eigenschaft des Signals | der Wert einer Eigenschaft des berechneten Signals, auch geerbt. Ein Signal ohne diese Eigenschaft wird nicht berechnet und in der Prüfung als ausgeschlossen gemeldet |
| Konstante | ein fester Wert, für alle Signale gleich |
| Standardwert | der Standardwert, den die Transformation selbst vorgibt |
Ausgänge
| Ziel | Wirkung |
|---|---|
| Abgeleitetes Signal | das Ergebnis wird in ein eigenes Signal geschrieben, siehe unten |
| Ignorieren | das Ergebnis wird verworfen |
| URI | das Ergebnis geht an ein Ziel außerhalb der Plattform, das die Transformation unterstützt |
Abgeleitete Signale
Für jeden Ausgang mit dem Ziel Abgeleitetes Signal entsteht je berechnetem Quellsignal ein eigenes Signal. Sie müssen es nicht anlegen:
- Es entsteht automatisch neben dem Quellsignal, also unter demselben Asset bzw. Formular.
- Es entsteht beim ersten Lauf des aktiven Workflows – nicht schon beim Speichern. Ein neu gespeicherter, aber noch nicht gelaufener dynamischer Workflow hat noch keine abgeleiteten Signale.
- Sein Name folgt dem Muster am Ausgang:
{signal.name}steht für den Namen des Quellsignals,{output}für den Namen des Ausgangs. Aus{signal.name} (bereinigt)wird für das Signal „Druck Pumpe 1“ also „Druck Pumpe 1 (bereinigt)“. Ein Name darf höchstens 128 Zeichen lang sein.
Fällt ein Quellsignal aus der Auswahl heraus oder wird der dynamische Workflow gelöscht, bleibt das abgeleitete Signal mit seinen Daten erhalten. Es wird als verwaist markiert und nicht mehr weiterberechnet.
Prüfen vor dem Aktivieren
Bevor Sie einen dynamischen Workflow aktivieren, sollten Sie die Auswahl prüfen. Der Button Prüfen unten im Formular zeigt:
- ob der dynamische Workflow so lauffähig ist, und falls nicht, warum;
- welche Signale berechnet würden;
- welche Signale herausfallen und aus welchem Grund – etwa eine fehlende Eigenschaft oder eine Ausnahme.
Ein Signal, das hier fälschlich herausfällt, nehmen Sie in die Auswahl auf. Eines, das fälschlich berechnet würde, können Sie direkt aus dem Prüfergebnis heraus ausnehmen.
Zeitplan, Zeitfenster und Last
| Einstellung | Bedeutung |
|---|---|
| Aktiv | nur ein aktiver dynamischer Workflow wird ausgeführt |
| Zeitplan (Cron) | wann ein Lauf startet, z. B. 0 */5 * ? * * für alle fünf Minuten |
| Zeitfenster | welchen Zeitraum der Daten jeder Lauf liest, relativ zum Start des Laufs. Alle Signale eines Laufs werden über dasselbe Zeitfenster berechnet |
| Gleichzeitige Aufrufe | wie viele Signale dieses Workflows höchstens gleichzeitig im hetida designer berechnet werden (1–64). Begrenzt seinen Anteil an der gemeinsamen Kapazität, damit ein großer Workflow die anderen nicht verdrängt |
| Timeout je Aufruf | nach wie vielen Sekunden die Berechnung eines Signals als fehlgeschlagen gilt (1–300). Muss kürzer sein als der Abstand zweier Läufe |
Änderungen an Zeitplan oder Aktivierung wirken mit einigen Minuten Verzögerung: Die Planung gleicht ihre Aufträge nur in Abständen ab.
Läufe und Fehler
Jeder Lauf wird mit seinem Ergebnis festgehalten. Die Läufe eines dynamischen Workflows erreichen Sie über seine Zeile in der Liste, alle Ausführungen zusammen im Reiter Ausführungen.
| Status | Bedeutung |
|---|---|
| OK | alle Signale wurden berechnet, oder es gab nichts zu berechnen |
| PARTIAL | ein Teil der Signale ist fehlgeschlagen. Der Fehler liegt bei diesen Signalen, nicht beim Workflow |
| INCOMPLETE | es wurden Signale berechnet, aber nicht alle Aufrufe gingen raus – der Lauf hat bis zum nächsten Start nicht alles geschafft, oder der hetida designer antwortete nicht mehr |
| FAILED | nichts wurde berechnet, obwohl es etwas zu berechnen gab |
| SKIPPED | der Lauf hat nicht begonnen, weil der vorige noch lief oder kein Platz frei war |
Bei PARTIAL und FAILED zeigt ein Lauf die Fehler je Signal mit der Meldung des hetida designers. Erfolgreiche Berechnungen schreiben bewusst keine eigenen Einträge.
Häuft sich INCOMPLETE, ist der Workflow für seinen Zeitplan zu groß: den Abstand der Läufe vergrößern, die Auswahl verkleinern oder die gleichzeitigen Aufrufe erhöhen.
Grenzen
- Berechnet wird je Signal: ein Aufruf des hetida designers je Signal und Lauf. Eine Transformation, die mehrere Signale gemeinsam braucht, passt nicht in dieses Modell.
- Signalgruppen können nicht ausgewählt werden.
- Ein Lauf berechnet nur das aktuelle Zeitfenster. Verpasste oder übersprungene Läufe werden nicht nachgeholt.