CEP (Complex Event Processing)
Inhaltsverzeichnis
- Überblick
- Bildschirmaufbau — EQL-Bildschirm der Automatisierungsgruppe
- Abfrage-Bildschirm (
/query/index) - Statement-Bildschirm (
/statement/index) - Referenz zum Trigger-Bildschirm
- Anwendungsszenarien
- Häufig gestellte Fragen
- Verwandte Bildschirme
Überblick
Die CEP(Complex Event Processing)-Funktion ist eine Rule-Engine, die in Echtzeit-Event-Streams nach bedeutsamen Mustern sucht und sofort Aktionen (Speicherung, Veröffentlichung, Alarm) ausführt. Im linken Menü wird sie derzeit als EQL-Abfrage und Statements innerhalb der Gruppe Automatisierung angezeigt.
| Untermenü | Interne URL | Verwendungszweck |
|---|---|---|
| EQL-Abfrage | /query/index | Temporäre EQL(Event Query Language)-Abfragen an den Echtzeit-Stream senden, um Resultate sofort zu sehen |
| Statements | /statement/index | Abfrage von Domänenregeln (Status/Aggregation/Event/Befehl) auf Asset-Ebene |
Die Resultate der CEP-Regeln werden automatisch mit den Asset-Triggern (z. B. flow_on_asset_event) im Flow verknüpft.
Bildschirmaufbau — EQL-Bildschirm der Automatisierungsgruppe
| Bildschirm | Hauptbenutzer | Zusammenfassung |
|---|---|---|
| Abfrage | Betriebsanalyst | Sofortige Ausführung einer EQL-Zeile, um Resultate im Echtzeit-Stream zu sehen |
| Statements | Operator | Abfrage des Status und der Ausführungsstatistiken von Domänenregeln, die im Asset registriert sind |
Abfrage-Bildschirm (/query/index)
Auf diesem Bildschirm werden temporäre EQL-Abfragen erstellt und mit der ▶-Schaltfläche sofort ausgeführt, um Resultate aus dem Echtzeit-Stream anzuzeigen.
Oben — Abfragespeicherung und Verlauf
🔍 쿼리 [💾 이 쿼리를 저장] [↩ 마지막 쿼리] [▼ 이력 ▼]
| Schaltfläche | Funktion |
|---|---|
| Diese Abfrage speichern | saveQueryHistory() — Aktuelle EQL als Favorit speichern |
| Letzte Abfrage | loadLastQuery() — Zuletzt ausgeführte Abfrage aufrufen |
| Verlaufs-Dropdown | loadQueryHistory() — Gespeicherte Abfrageverläufe im Dropdown anzeigen (Scrollen bis max. 400px) |
Abfragen, die im EQL-Eingabefeld oben oder im linken Menü erstellt wurden, werden automatisch an diesen Bildschirm übermittelt und können dort ausgeführt werden.
EQL-Eingabebereich
Großes Eingabefeld mit schwarzem Rahmen (textarea[name=epl], Höhe 8 Zeilen) + zwei Symbole oben rechts.
| Symbol | Funktion |
|---|---|
| ▶ (Play, weiß) | runQuery() — EQL ausführen |
| ⚙ (Zahnrad, grau) | resultConfig() — Dialog für Anzeigeoptionen der Resultate (display_count, expire_time, result_format, Chart-Optionen usw.) |
Ausführungsresultat-Bereich
Im Header des Resultat-Bereichs wird Folgendes angezeigt:
| Element | Anzeige |
|---|---|
| Links | ⚪ "Abfrageergebnis" + (bei gespeicherter Abfrage) [배치시간=..., EQL ID=...] |
| Rechts | ▶ Start / ⏸ Stop-Schaltflächen (Pause beim Empfang von Echtzeit-Resultaten) |
Resultat-Chart (query_result_chart, 160px)
- Anzeige der Eingangszählung (
input_count_cur) und der Eingänge pro Minute (input_count_min) oben rechts. - Sobald Resultatdaten eingehen, füllt sich das Chart (Echtzeit-Linienchart).
- Vor dem Dateneingang: "Warten auf Chart-Daten..." (rotierendes Symbol).
Resultat-Tabelle (query_result_table)
| Spalte | Beschreibung |
|---|---|
| # | Zeilennummer |
| Ausgabezeit | Zeitpunkt, an dem EQL das Resultat emittiert hat |
| Zeilenanzahl | Anzahl der Zeilen pro Emission |
| Daten | Resultatinhalt im JSON- oder Tabellenformat |
Wenn die Ausführung nicht gestoppt wird, sammeln sich die Daten in der Resultat-Tabelle kontinuierlich an. Durch Klicken auf die Schaltfläche Stop oder durch die Ausführung einer neuen Abfrage wird die Akkumulation beendet.
Referenz zum Trigger-Bildschirm
Ein separates Menü für Trigger existiert im linken Menü nicht. In Installationsumgebungen, in denen der ursprüngliche Bildschirm /trigger/index oder interne APIs betrieben werden, dienen die folgenden Inhalte nur als Legacy-Referenz. Für neue Automatisierungen verwenden Sie bitte primär die Trigger-Knoten im Flow sowie den Pfad Automatisierung > EQL-Abfrage / Statements.
Hier werden benutzerdefinierte Trigger verwaltet, die EQL-Matching-Resultate an externe Nachrichtenkanäle veröffentlichen oder in einem Storage speichern.
Obere Werkzeuge
⚡ 트리거 [➕ 트리거 추가] [↻]
Listenabelle
Rechts im Header des Listenbereichs befinden sich drei Schaltflächen: Ausgewählte Trigger bereitstellen / Aufheben / Alle neu bereitstellen.
| Spalte | Breite | Beschreibung |
|---|---|---|
| Auswahl | 50px | Checkbox für Massenbereitstellung/-aufhebung |
| Status | 80px | Badge für bereitgestellt/aufgehoben |
| Trigger-ID | 110px | Systemseitig zugewiesene ID |
| Trigger-Name | Beschreibung | Automatisch | Vom Operator festgelegte Metadaten |
| MQ-Streaming | 70px | Verwendung von MQ-Veröffentlichung (Y/N) |
| Storage-Speicherung | 70px | Speicherung der Resultate im Storage (Y/N) |
| Gesamtausführungen | 70px | Akkumulierte Anzahl der Matchings |
| Letztes Ausführungsdatum | 110px | Zeitpunkt des letzten Matchings |
| Fehler | 70px | Akkumulierter Fehlerzähler |
| Registrierungsdatum | 110px | Zeitpunkt der Registrierung |
| Letztes Änderungsdatum | 110px | Zeitpunkt der letzten Änderung |
| Aktion | 80px | Schaltflächen zum Bearbeiten/Löschen |
Am unteren Ende der Seite wird ein Informationskasten angezeigt.
Verwendung benutzerdefinierter Trigger Sie können benutzerdefinierte Trigger hinzufügen, die Aktionen ausführen, wenn bestimmte Bedingungen erfüllt sind. Diese können zusätzlich via MQ gestreamt oder in einem Storage gespeichert werden.
Trigger hinzufügen/bearbeiten
Über die Schaltfläche Trigger hinzufügen gelangen Sie zum Formularbildschirm (/trigger/form).
1) Basic Info fieldset
| Eingabe | Pfad | Breite | Bemerkung |
|---|---|---|---|
| Trigger-ID | trigger_id | 200px | Schreibgeschützt — Systemseitig zugewiesen |
| Trigger-Name | trigger_name | 450px | Leicht identifizierbarer Name |
| Beschreibung | trigger_desc | 600 × 100px (textarea) | Verwendungszweck des Triggers |
2) EQL fieldset
| Eingabe | Pfad | Beschreibung |
|---|---|---|
| EQL | epl | 8 Zeilen textarea — Erstellung der EQL-Abfrage (SELECT ... FROM ... WHERE ...) |
| ▶ Testlauf | (Symbol) | runQuery() — Sofortiger Testlauf der geschriebenen EQL. Das Resultat wird in der Tabelle Abfrageergebnis (graph_query_result) darunter angezeigt |
Tabelle der Abfrageergebnisse (Vorschau des Testlaufs):
| Spalte | Beschreibung |
|---|---|
| Ausgabezeit | Zeitpunkt, an dem EQL das Resultat emittiert hat |
| Daten | Resultatinhalt |
3) Streaming fieldset
| Eingabe | Pfad | Beschreibung |
|---|---|---|
| MQ-Ausgabe | use_mq (Checkbox) | Ob Resultatdaten an einen externen Nachrichtenkanal veröffentlicht werden sollen |
| Protokoll | mq_protocol (Selektor) | MQTT oder KAFKA |
| Destination | mq_destination (450px) | Ziel-Topic/Kanal — Trenner: KAFKA -, MQTT /. Beispiel: device-machine-topic-1 oder device/machine/topic_1 |
4) Storage-Speicherung fieldset
| Eingabe | Pfad | Beschreibung |
|---|---|---|
| Storage-Speicherung | use_storage (Checkbox) | Ob Resultatdaten in den Storage geladen werden sollen |
Da die Tabelle für Trigger-Resultate fixiert ist, sind die Definitionen für Tabellenname und Spalten derzeit deaktiviert.
Formularabschluss
| Schaltfläche | Funktion |
|---|---|
| Liste(☰) | Zurück zur Trigger-Liste |
| Speichern (Blau) | Speicherung nach Validierung. Das Speichern allein führt noch nicht zur Bereitstellung; erst über die Listenansicht muss Ausgewählte Trigger bereitstellen geklickt werden, damit die Regel aktiv wird |
Alle neu bereitstellen
| Schaltfläche | Position | Funktion |
|---|---|---|
| Alle neu bereitstellen | Rechts im Header des Listenbereichs (🔁) | Massenhafte Neubereitstellung aller registrierten Trigger. Verwendung nach Neustart der Rule-Engine oder Systeminspektion |
Betriebsablauf
- Trigger hinzufügen → EQL-, Streaming- und Storage-Optionen eingeben → Speichern
- Trigger in der Liste markieren → Ausgewählte Trigger bereitstellen klicken → Status ändert sich zu "Bereitgestellt"
- Zur temporären Deaktivierung: Aufheben klicken → Status ändert sich zu "Aufgehoben"
- Nach Inspektion: Alle neu bereitstellen für Gesamtreaktivierung
Statement-Bildschirm (/statement/index)
Auf diesem Bildschirm werden der Status und die Ausführungsstatistiken von Domänenregeln (Status/Aggregation/Event/Befehl) auf Asset-Ebene abgefragt.
Obere Suche und Filter
√ 스테이트먼트 [유형 ▼] [검색 ...] [조회] [↻]
| Steuerelement | Option | Beschreibung |
|---|---|---|
Typ-Selektor (search_type) | Alle Typen, Status(CONTEXT), Aggregation(AGGREGATION), Event(EVENT), Befehl(COMMAND) | Filter für die vier Regeltypen |
Sucheingabe (txt) | (250px) | Placeholder: "Suche ..." — Schlüsselwörter für Regelname/Asset-ID/Beschreibung |
| Abfrage | (Rot + 🔍) | search() — Aktualisierung der Liste basierend auf den Bedingungen |
| Aktualisieren | (Rot + ↻) | refresh() — Bildschirminhalt aktualisieren |
Die vier Regeltypen
| Code | Bezeichnung | Bedeutung |
|---|---|---|
CONTEXT | Status | Definition des aktuellen Zustands des Assets (Betrieb/Stopp/Anomalie) via EQL |
AGGREGATION | Aggregation | Aggregation von Mittelwerten, Maximalwerten etc. über ein bestimmtes Zeitfenster |
EVENT | Event | Veröffentlichung eines Domänen-Events bei einem bestimmten Muster (z. B. Schwellenwertüberschreitung) |
COMMAND | Befehl | Veröffentlichung eines Befehls(flow_on_asset_command) an das Asset bei einem Regel-Matching |
Listenabelle
| Spalte | Breite | Beschreibung |
|---|---|---|
| Status | 80px | Badge für aktiv/inaktiv |
| Zugeordnete Asset-ID | 150px | Kennung des Assets, dem die Regel zugewiesen ist |
| Typ | 80px | Einer der vier Typen (siehe obige Tabelle) |
| Statement-Name | Automatisch | Name der Regel |
| Beschreibung | 300px | Notiz zur Regel |
| Gesamtausführungen | 80px | Akkumulierte Anzahl der Regel-Matchings |
| Letztes Ausführungsdatum | 120px | Zeitpunkt des letzten Matchings |
| Fehler | 60px | Akkumulierter Fehlerzähler |
| Registrierungsdatum | 120px | Zeitpunkt der Regelregistrierung |
| Details | 50px | Aufruf des Detailbildschirms der Regel(/statement/view) |
Statements erstellen — Erforderliche Felder nach Typ
Statements werden an Anlagen gebunden. Wählen Sie im Asset-Baum die Anlage aus und öffnen Sie den Reiter Registry → Statement hinzufügen (nur für ADMIN sichtbar). Dieser Bildschirm(/statement/index) dient der Abfrage und dem Betrieb.
Die SELECT der EQL müssen alle für den jeweiligen Typ festgelegten Ausgabefelder liefern, damit die Speicherung erfolgt. Dies liegt daran, dass die Platform die Werte unter diesen Namen ausliest. Andere Felder sind frei wählbar.
| Typ | Name des Dialogs | Erforderliche Felder |
|---|---|---|
EVENT | Event | timestamp · plugin · name · color · from_timestamp · to_timestamp · value |
CONTEXT | Kontext | timestamp · plugin · key · value |
AGGREGATION | Aggregation | timestamp · plugin · key · value |
COMMAND | Befehl | timestamp · plugin · key · value |
| Feld | Bedeutung |
|---|---|
timestamp | Event-Zeitpunkt (epoch ms) |
plugin | Ursprungs-Plugin (OEE, RAM, EMS usw.) |
key | Elementname (Name des Status, der Aggregation oder des Befehls) |
value | Wert |
name | Event-Name |
color | Anzeigebezeichnung Farbe |
from_timestamp · to_timestamp | Start- und Endzeitpunkt (epoch ms) |
Felder werden über ... AS 칸 ausgegeben oder es wird ein gleichnamiges Feld ausgewählt. SELECT * wird nicht akzeptiert, da der Feldname nicht im Satz enthalten ist. Bei Auswahl des Typs ändert sich der Hinweis Erforderliche Felder für diesen Typ, und falls der Editor leer ist, wird die entsprechende Vorlage ausgefüllt.
SELECT
timestamp AS timestamp,
'-' AS plugin,
'' AS key,
'' AS value
FROM Point(tag_id = '...')
Der Dialog ist so konzipiert, dass vor der Speicherung eine EQL-Ausführung(▶) zur Validierung erfolgt. Wenn Felder fehlen, wird die Speicherung abgelehnt (HTTP 422, asset_statement.eql.missing_columns), und die fehlenden Felder erscheinen in einem orangefarbenen Kasten unter dem EQL-Editor.
Im EQL des AGGREGATION-Statements fehlen erforderliche Felder: key. In der SELECT-Ausgabe (... AS Feld) müssen timestamp, plugin, key und value vollständig ausgegeben werden.
Die gleichen Regeln gelten für die Konsole, V5, Plugin-Anwendungen (ISO), Plugin-Templates und MCP validate_eql. Werte, die nicht zu den vier Typen gehören, werden als asset_statement.eql.unknown_type abgelehnt.
Detailansicht
Durch Klicken auf die Schaltfläche Details in der Liste gelangen Sie auf einen separaten Bildschirm(/statement/view/{asset_id}/{statement_name}), auf dem Folgendes eingesehen werden kann (siehe unten Statement-Detailbildschirm).
- EQL-Inhalt der Regel
- Verlauf der Ausführungsergebnisse
- Ausführungstrend/Aggregation
- Trend der Analyseperformance
- Statusverlauf
Statement-Detailbildschirm
Analyseeinsicht (statement/view.jsp, 715 Zeilen), die über die Details-Schaltfläche erreicht wird. Alle Betriebsdaten einer Regel sind auf einem Bildschirm gebündelt.
Oben — Identifikations-Header
√ 스테이트먼트 | {statement_name} [ {asset_id} ] [← 목록] [↻]
| Schaltfläche | Funktion |
|---|---|
| Liste(←) | Zurück zu /statement/index |
| Aktualisieren | Bildschirm neu laden |
Panel 1 — Statement-Informationen (Tabelle mit 5 Spalten)
| Spalte | Breite | Beschreibung |
|---|---|---|
| Status | 250px | Aktiv/Inaktiv + Zeitpunkt der letzten Ausführung |
| Statement-Name | Automatisch | Name der Regel |
| Zugeordnetes Asset | 200px | Asset-Domänen-Badge — Klick führt zum Asset-Baum |
| Typ | 200px | Status(CONTEXT), Aggregation(AGGREGATION), Event(EVENT), Befehl(COMMAND) |
| Registrierungsdatum | 160px | Zeitpunkt der Regelregistrierung |
EQL-Inhalt fieldset
Der EQL-Abfrageinhalt der Regel wird unverändert angezeigt. Der Text kann kopiert und im Abfrage-Bildschirm für einen Testlauf eingefügt werden.
Eingabe/Ausgabe fieldset
| Bereich | Anzeige |
|---|---|
| Eingangsreihen | Liste der Tags und Event-Typen, die als Eingang der Regel dienen |
| Ausgangsreihen | Domänen-Event-Typen, die von der Regel veröffentlicht werden |
| Fehlerzähler zurücksetzen | Setzt nur den akkumulierten Fehlerzähler auf 0 zurück(resetErrorCount(asset_id, statement_name)) |
Panel 2 — Verlauf der Ausführungsergebnisse (Tabelle mit 4 Spalten)
| Spalte | Breite | Beschreibung |
|---|---|---|
| Ausführungszeit | 160px | Zeitpunkt der Regelausführung |
| Resultat | 60px | Erfolg (Grün) / Fehler (Rot) |
| Resultatwert / Fehlermeldung | Automatisch | Bei Erfolg Resultatinhalt, bei Fehler die Fehlermeldung |
| Kopieren | 50px | 📋 — Kopiert Resultatwert/Fehlermeldung in die Zwischenablage |
Panel 3 — Ausführungstrend-Chart
| Element | Beschreibung |
|---|---|
| Header | 📊 "Ausführungstrend" |
| Schaltflächen | Toggle für Heute(switchTrendDay(0)) / Gestern(switchTrendDay(-1)) |
| Chart | Akkumulierte Balken für Erfolg/Fehler pro Stunde über 24h (Serien: Erfolg, Fehler) |
Panel 4 — Ausführungsaggregation
| Element | Beschreibung |
|---|---|
| Header | 📊 "Ausführungsaggregation" |
| Schaltflächen | Toggle für Heute(switchAggDay(0)) / Gestern(switchAggDay(-1)) |
| fieldset 1 | Minutengenaue Aggregation (Zähler pro Stunde, durchschnittlicher Durchsatz usw.) |
| fieldset 2 | Priorität oder Ergebnisverteilung |
Panel 5 — Trend der Analyseperformance
| Element | Beschreibung |
|---|---|
| Header | 🖥 "Trend der Analyseperformance" |
| Schaltflächen | Toggle für Heute(switchCpuDay(0)) / Gestern(switchCpuDay(-1)) |
| Chart | Zeitreihe der CPU-Nutzung/Bearbeitungszeit für die Regelverarbeitung — zur Identifizierung ressourcenintensiver Regeln |
Panel 6 — Statusverlaufstabelle
| Spalte | Beschreibung |
|---|---|
| Änderungszeit | Zeitpunkt der Statusänderung der Regel (Aktivierung, Aufhebung, Neubereitstellung usw.) |
| Status | Geänderter Status |
Wird verwendet, um den Lebenszyklus der Regel zu verfolgen (wann sie aktiviert, deaktiviert oder geändert wurde).
Nutzungsmuster
| Analysefluss | Bildschirmfluss |
|---|---|
| Diagnose fehlerhafter Regeln | Verlauf der Ausführungsergebnisse → Fehlermeldung → Kopieren → EQL-Inhalt prüfen → Testlauf im Abfrage-Bildschirm |
| Identifizierung schwerer Regeln | Trend der Analyseperformance → Zeitfenster mit hoher CPU-Auslastung → EQL-Inhalt vereinfachen |
| Analyse der Matching-Verteilung | Ausführungstrend + Aggregation → Matching-Muster pro Stunde |
| Instandhaltung von Betriebsregeln | Statusverlauf → Verfolgung der Aktivierungs-/Deaktivierungspunkte |
Anwendungsszenarien
| Szenario | Bildschirm | Ablauf |
|---|---|---|
| Sofortige Prüfung des aktuellen Linienstatus | Abfrage | SELECT * FROM AssetData.win:time(1 sec) WHERE asset_id='LINE-A' in EQL-Eingabefeld eingeben → ▶ |
| Test und Deployment einer neuen Alarmregel | Trigger | Hinzufügen → EQL schreiben → ▶ Testlauf → Resultat prüfen → Speichern → Bereitstellen |
| Weiterleitung von Asset-Events an externes SCADA | Trigger | EQL-Matching-Nachrichten an MQTT-Topic scada/line-a/events veröffentlichen |
| Prüfung von Regeln auf Asset-Ebene | Statements | Typ=EVENT + Suche nach Asset-ID → Liste aktiver Regeln + Ausführungsanzahl |
| Verdacht auf Regel-Überlastung | Statements | Prüfung beginnend bei Regeln mit höchsten Gesamtausführungen → EQL/Eingang in Details prüfen |
| Empfang von Regelergebnissen in Automatisierungen | Flow | Domänenregelergebnisse direkt über flow_on_asset_event-Trigger empfangen |
Häufig gestellte Fragen
F. Ist EQL das Gleiche wie SQL?
A. Die Syntax ist ähnlich, aber EQL ist eine Event-Processing-Sprache, der Konzepte wie Zeitfenster und Streams hinzugekommen sind. Beispiel: Point.win:time(5 sec) verarbeitet nur Daten der letzten 5 Sekunden, während Point.win:length(100) die letzten 100 Datensätze verarbeitet.
F. Werden im Abfrage-Bildschirm ausgeführte Abfragen gespeichert? A. Eine reine Ausführung über ▶ ist temporär. Damit eine Abfrage in den Favoriten gespeichert wird, muss die Schaltfläche Diese Abfrage speichern geklickt werden. Für einmalige Analysen ist eine Speicherung nicht erforderlich.
F. Ich habe einen Trigger gespeichert, aber er funktioniert nicht. A. Durch das Speichern wurde lediglich die Definition registriert. Markieren Sie den Trigger in der Liste und klicken Sie auf Ausgewählte Trigger bereitstellen, damit dieser in der Rule-Engine registriert wird und das Matching beginnt.
F. Wie muss die Destination eines Triggers definiert werden? A. Die Trenner variieren je nach Protokoll:
- KAFKA: Trennung durch Bindestrich(
-) — Beispiel:device-machine-topic-1 - MQTT: Trennung durch Schrägstrich(
/) — Beispiel:device/machine/topic_1
F. Die Suche im Statement-Bildschirm liefert keine Ergebnisse. A. Prüfen Sie, ob im Typ-Selektor "Typ" (Alle) ausgewählt ist. Zudem erfolgt bei der Asset-ID eine Teilstring-Suche.
F. Die Gesamtausführungszahl ist ungewöhnlich hoch.
A. Wahrscheinlich ist das Eingangsfenster der Regel zu schmal oder die Matching-Bedingung zu weit gefasst. Prüfen Sie die EQL über die Schaltfläche Details oder nutzen Sie Trigger-Muster(*_pattern) im Flow zur Vorfilterung von Nachrichten.
F. Das Ergebnis des EQL-Testlaufs beim Trigger ist leer.
A. Zum Zeitpunkt des Tests flossen möglicherweise keine Daten ein, oder das Fenster der EQL ist so groß, dass das erste Matching verzögert erfolgt. Warten Sie etwa eine Minute oder verkürzen Sie das Fenster (win:time(1 sec)) für den Test.
F. Wie stoppe ich einen Trigger vorübergehend? A. Markieren Sie den Trigger in der Liste und klicken Sie auf Aufheben. Zur Reaktivierung nutzen Sie Ausgewählte Trigger bereitstellen.
F. Werden Regeln automatisch Assets zugewiesen? A. Je nach Konfiguration der Betriebsumgebung können bei der Asset-Registrierung Standard-Domänenregeln automatisch zugewiesen werden. Prüfen Sie die aktuell angewendeten Regeln im Statement-Bildschirm. Hinzufügungen oder Entfernungen erfolgen über den Systemadministrator oder den Asset-Konfigurationsbildschirm.
F. Ich möchte EQL-Resultate automatisch verarbeiten.
A. Sie können Domänenregelergebnisse über Asset-Trigger(flow_on_asset_event/flow_on_asset_alarm usw.) im Flow automatisch empfangen und in Folgeaktionen (Arbeitsauftrag, E-Mail, externer API-Aufruf) überführen.
Verwandte Bildschirme
- Datenpunkte — Zeitreihen-Tag-Daten, die als EQL-Eingang dienen
- Alarme — Betriebs畫面 für Alarme, die durch Trigger ausgelöst werden
- Flow — Automatisierte Verarbeitung von Regelergebnissen über Asset-Trigger
- Fabrikverwaltung — Zuweisung von Regeln im Asset-Baum
- Statuscode-Definition — Statuscodes (NORMAL/WARN/ERROR), die von Regeln bewertet werden
- Diagnose — Fehlerprotokolle während der Regelverarbeitung