Funktionsbeschreibung und Anwendung
Der RuleEngine-Block dient der Beschreibung von Zustandsübergängen anhand einlaufender Nachrichten in Abhängigkeit von Vorbedingungen. Dabei können Form und Inhalt der Ausgangsnachricht frei definiert werden.
Es existiert ein Kontext in dem Informationen abgelegt werden können, die bei der Auswertung der Bedingungen oder in der Ausgangsnachricht verwendet werden können. Der Kontext kann initial mit Informationen gefüllt werden.
Es gibt eine Menge von "RuleSets", welche (Vor-)Bedingungen beinhalten.
Jedes RuleSets kann eine Menge von "Rules" enthalten, die ebenfalls über Bedingungen verfügen.
Weiterhin können ein "defaultRuleSet" sowie in RuleSets "defaultRules" angelegt werden, die keine Bedingungen enthalten.
Jede Bedingung muss einen boolschen Zustand zurückgeben. Jede Bedingung, die keinen boolschen Zustand zurückgibt, ist automatisch "Falsch" (false). In den Bedingungen kann auf Inhalte des Kontextes und der eingehenden Nachricht (header & body & context) zugegriffen werden. Damit eine "Rule" zutrifft, müssen alle Bedingungen von dieser erfüllt sein.
Zuerst werden die Bedingungen der definierten RuleSets der Reihe nach, von RuleSet-1 ausgehend, geprüft. Sobald ein RuleSet die Bedingungen erfüllt, wird dieses RuleSet für die weitere Verarbeitung der Nachricht ausgewählt. Erfüllt kein RuleSet die Bedingung, wird das defaultRuleSet gewählt, sofern es angegeben ist, andernfalls erfolgt ein Abbruch.
Anschließend werden im ausgewählten RuleSet die Rules geprüft. Die Reihenfolge der Prüfung ist abhängig von der definierten „Evaluation Stategy“ (FirstMatch, BestMatch oder LeastMatch). Entsprechend kann eine Überprüfung der weiteren im RuleSet enthaltenen "Rules" übersprungen, die „zutreffendste“ oder die letzte zutreffende "Rule" everwendet werden. Erfüllt keine Rule die Bedingungen erfolgt ein Abbruch. Folglich wird im Rule Engine-Block nur ein RuleSet und darin nur eine Rule verarbeitet.
Das Ergebnis einer "Rule" wird in dem Kontext abgelegt, der Inhalt des Kontext wird gepatched. Es können gezielt Inhalte aus dem Kontext nach dem Patchen entfernt werden.
Wird das angegebene Message Template nicht gefunden, wird das Message Template "default" genommen.
Die Ausgangsnachricht wird anhand des Message Templates erzeugt.
Ist in dem Message Template kein Header definiert, werden die Informationen "source" und "scope" aus der Eingangsnachricht übernommen.
Ist in dem Message Template Header kein "source" und/oder "scope" definiert, werden die Informationen aus der Eingangsnachricht übernommen.
Ist in dem Message Template kein Body definiert, enthält die Ausgangsnachricht keine Informationen im Body.
Nach dem Erfüllen einer "Rule" wird eine Ausgangsnachricht an alle zugewiesenen Input bzw. Output Topics gesendet.
Bezeichnungen und Syntax
Die in der folgenden Tabelle erläuterten Parameter sind in einer beispielhaften Konfiguration und deren Abbildungen im folgenden Absatz zu finden.
| Parameter | Beschreibung |
|---|---|
Name | Name der Blockinstanz |
Context | Optionaler Bereich, in dem Variablen mit oder ohne initialen Inhalt initialisiert werden. Jedes Contextelement kann in den Bedingungen verwendet werden. |
Context – Name | optional, Name des Contextelementes |
Context – Value | optional, Inhalt des Contextelementes |
RuleSets | Zusammenstellung von Bedingungspfaden/ Zustandsüberwachungen. Es können beliebig viele erstellt werden. Die angelegten RuleSets erscheinen als Reiter unterhalb der Eingabemöglichkeit. Die Namen können nicht geändert werden – RuleSetsn, n steht hierbei für eine fortlaufende Zahl. Hier kann auch ein „DefaultRuleSet“ definiert werden. |
RuleSets – Evaluation Strategy | Es kann zwischen FirstMatch, BestMatch oder LeastMatch, also erster, bester oder letzter Übereinstimmung, entschieden werden. Die Voreinstellung ist „FirstMatch“. |
RuleSets – DefaultRuleSet | Zu befüllen wie ein normales RuleSet mit Rules – jedoch ohne Bedingungen. In diesem RuleSet können wiederum Rules angelegt werden, die diverse Bedingungen enthalten. |
RuleSets – conditions | optional, Globale Bedingung(en) damit in diesem RuleSet die Rules auf Übereinstimmung geprüft werden. |
RuleSets – conditions – Name | optional, Bezeichnung der Bedingung eingeben |
RuleSets – conditions – Value | optional – sofern kein Name/ key definiert wurde, Wert aus dem Context, body, header oder selbstdefiniert |
RuleSets – Rules | Es kann zwischen den Reitern per Pfeiltasten gewechselt werden. Zusammenstellung von Bedingungspfaden/ Zustandsüberwachungen zur Verfeinerung der Bedingungspfade. Es können beliebig viele erstellt werden. Die angelegten Rules erscheinen als Reiter unterhalb der Eingabemöglichkeit. Die Namen können nicht geändert werden – Rules-n, n steht hierbei für eine fortlaufende Zahl. Hier kann auch ein „DefaultRule“ definiert werden. |
RuleSets – Rules – Context | Beliebige Anzahl von Contextelementen |
RuleSets – Rules – Context – Name | Name des Contextelementes |
RuleSets – Rules – Context – Value | Inhalt des Contextelementes |
RuleSets – Rules – Into | Folgeblock bestimmen, wenn notwendig |
RuleSets – Rules – Obsolete context | Hier können Elemente des Context entfernt werden. |
RuleSets – Rules – outputTopic | Optionale Eingabe eines Outputtopics, bei keiner Angabe, werden alle Informationen, bis auf den Context verworfen. |
RuleSets – Rules – into | Optionale Eingabe eines Blocknamens zur internen Weiterverarbeitung |
RuleSets – Rules – Message Template | Optionale Eingabe eines Namens für das Messagetemplate zur Erstellung der Outputnachricht |
Message Templates | Beliebig viele Vorlagen für die Ausgabe von Nachrichten und Daten. Es können hier alle Elemente aus dem Nachrichtenbereich Header und Body bearbeitet werden. |
Message Templates – Header – Name | optional, Name des zu erstellenden keys |
Message Templates – Header – Value | optional, sofern kein Name/ key definiert wurde, Wert aus dem Context, Body, Header oder selbstdefiniert |
Message Templates – Body – Name | optional, Name des zu erstellenden keys |
Message Templates – Body – Value | optional, sofern kein Name definiert wurde, Wert aus dem Context, Body, Header oder selbstdefiniert |
Output Topic | Name des modulinternen Output Topic, um Output-Nachrichten auf die Edge Broker Topic(s) zu mappen. |
Verwendung von Elementen aus Header, Body und Context:
case sensitive Namensverwendung
Um das Element source aus dem Nachrichtenbereich Header zu erhalten, muss header_ für den zu verwendenden Bereich und source für das Element eingegeben werden. → header_scope
Verwendung einer Zeichenkette/ String
Eine Zeichenkette wird mit einem vorangehenden „ ‘ „ und einem abschließenden „ ‘ „ gekennzeichnet. Bsp.: ‘Zeit verstrichen‘
Werden die Zeichen nicht verwendet, so wird die Eingabe wie eine Variable verwendet.
Beispielkonfiguration Rule Engine-Block
Die schrittweise Konfiguration des Stream Processors mit dem Block Rule Engine wird am folgenden Beispiel dargestellt. Es werden Daten eines OPC UA Servers verarbeitet. Die Reihenfolge sollte wie beschrieben erfolgen, da so alle angezeigten Auswahlmöglichkeiten im Zuge der Konfiguration zur Verfügung stehen. Auswahlwahlmöglichkeiten stehen immer erst nach einem Speichervorgang zur Verfügung.
Voraussetzung: Im Modul OPC UA wurde ein OPC UA Server vollständig mit dem Output Topic „OpcuaOut1“ konfiguriert (Pollgroup im OPC UA-Modul).
Nun werden die Grundeinstellungen im Stream Processor konfiguriert - Input Edge Topics, Input Switch mit den zugehörigen Topics, Output Topics und ein RuleEngine-Block mit dem Namen "UsingRules" (Grundeinstellungen im Stream Processor)
Es folgt die Definition der Message Templates "default" und "Rule1":
default: Änderung des Inhaltes des Headers von Source mit einer Zeichenfolge und des Inhaltes Zusatzinformation mit einer Zeichenfolge im Body (Einstellungen in Message Template "default")
Rule1: Änderung des Inhaltes des Headers von Source mit einer Zeichenfolge und Scope mit dem Inhalt eines Elementes vom Context. Der Body wird mit Werten aus dem ursprünglichen Body - statUint und dynUint – befüllt und mit während der Abarbeitung der Rules generierten Werten – Kontext1 und Zusatz (Einstellungen in Message Template "Rule1").
Anschließend wird der Context des Block "UsingRules" konfiguriert: hier optional die Eingabe von Kontext mit Inhalten (befüllter Context, erstelltes DefaultRuleSet und RuleSet-2).
Es folgt die Konfiguration der RuleSets:
DefaultRuleSet (DefaultRuleSet ausgefüllt)
Evaluation Strategy eintragen: FirstMatch
Rules: Add Default → DefaultRule erstellt
Context und Into wurden leer gelassen
Im Obsolete Context werden die Elemente Kontext2 und Kontext3 entfernt
OutputTopic mit OUTBlock und Message Template mit default angeben
Ruleset-2 (Ruleset-2 Rule1 ausgefüllt)
Evaluation Strategy eintragen: FirstMatch
Rules: Add Rule → Rule-1 erstellt
In Conditions wird der Name mit – dynUint >= 35000 – eingetragen.
In Conditions wird die Bedingung mit – body_dynUint >= 30000 – eingetragen.
Im Context werden zwei Elemente mit einem neuen Wert beschrieben:
RulesetTest mit der Zeichenfolge 'RuleSet2 Rule1'
Kontext1 mit der Zeichenfolge 'dynUint >= 35000'
Into wird leer gelassen, es soll keine Folgeverarbeitung in anderen Blöcken stattfinden
Obsolete Context wird leer gelassen
OutputTopic mit OUTBlock und Message Template mit Rule1 angeben
Sind die RuleSets erstellt, müssen die Rules mit ihren Bedingungen konfiguriert werden.
Rules: Add Rule → Rule-2 erstellt (Ruleset-2 Rule2 ausgefüllt)
Conditions
Name: dynUint kleiner gleich 10000 – dies ist nur eine Beschreibung der Bedingung.
Value: body_dynUint ⇐ 10000 – dies ist die Bedingung
Im Context werden zwei Elemente mit einem neuen Wert beschrieben:
RulesetTest mit der Zeichenfolge 'RuleSet2 Rule2'
Kontext1 mit der Zeichenfolge 'dynUint ⇐ 10000'
Into wird leer gelassen, es soll keine Folgeverarbeitung in anderen Blöcken stattfinden
Obsolete Context wird leer gelassen
OutputTopic mit OUTBlock und Message Template mit Rule1 angeben
Mit dieser Konfiguration kann nun über den MQTT oder über andere Schnittstellen die fertige Nachricht ausgegeben werden.