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", wobei jede einzelne eine Menge von "Rules" enthalten kann.
Jedes "RuleSet" hat Bedingungen.
Jede "Rule" in einem "RuleSet" hat Bedingungen.
Jedes "RuleSet" kann eine "defaultRule" beinhalten, diese besitzt keine Bedingung.
Es kann neben den "RuleSets" auch ein "defaultRuleSet" existieren, wobei dieses keine Bedingungen enthält.
Das "defaultRuleSet" kann wiederrum eine Menge von "Rule" sowie eine "defaultRule" beinhalten.
Jede Bedingung muss einen booleschen Zustand zurückgeben.
Jede Bedingung, die keinen booleschen 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.
Je nach Einstellung „Evaluation Stategy“: FirstMatch, BestMatch oder LeastMatch kann eine Überprüfung der weiteren "Rules" übersprungen, die „zutreffendste“ oder die letzte zutreffende "Rule" eines "RuleSets" verwendet werden.
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 MessageTemplate nicht gefunden, wird das MessageTemplate "default" genommen.
Die Ausgangsnachricht wird anhand des MessageTemplates erzeugt.
Ist in dem MessageTemplate kein Header definiert, werden die Informationen "source" und "scope" aus der Eingangsnachricht übernommen.
Ist in dem MessageTemplate Header kein "source" und/oder "scope" definiert, werden die Informationen aus der Eingangsnachricht übernommen.
Ist in dem MessageTemplate kein Body definiert, enthält die Ausgangsnachricht keine Informationen im Body.
Nach dem Erfüllen einer "Rule" wird eine Ausgangsnachricht an alle "Into" und/oder das Output Topic 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.