Neu in 5.7

Version 5.7 verlagert Logik in den Flow: Bedingungen, wiederverwendbare Funktionen und Fehlerbehandlung sind Transferobjekte, Variablen bilden Kennzahlen selbst, und Zertifikate lassen sich zentral über einen OPC UA Global Discovery Server beziehen. Diese Seite beschreibt zu jeder Neuerung einen typischen Anwendungsfall, die Projektierungsschritte, die Voraussetzungen und die Referenzseiten. Am Ende steht, was sich für bestehende Projekte ändert.

Neuerung	Wofür
Bedingung (IF)	Teile eines Flows nur unter einer Bedingung ausführen
Funktion (FX)	Einen Ablauf einmal definieren und aus vielen Flows aufrufen
Fehlerbehandlung (Try/Catch)	Fehler abfangen, Aufrufe wiederholen, Störungen melden
Change Gate	Nachgelagerte Schritte nur bei relevanter Änderung ausführen
Variablen	Variablen in Ordnern strukturieren, Zugangsdaten schützen, Kennzahlen bilden, Variablen dynamisch ansprechen
DB Log Table	In eine Tabelle schreiben, deren Struktur der OPC Router selbst anlegt und abgleicht
Zertifikate über OPC UA GDS	Zertifikate zentral beziehen und automatisch erneuern
Startmodus von Plug-in-Instanzen	Nicht benötigte Instanzen abschalten oder nur bei Bedarf starten
Automatischer Logout	Sitzungen nach Inaktivität oder Höchstdauer beenden

Bedingung (IF)

Anwendungsfall: Überschreitet eine Temperatur den Grenzwert, soll eine Meldung an das MES gehen; alle anderen Werte werden nur in die Datenbank geschrieben.

So projektieren Sie das:

1. Ziehen Sie das Transferobjekt „Bedingung (IF)“ aus der Werkzeugpalette in den Flow.
2. Legen Sie im Reiter „Eingänge“ einen Eingang Temperatur an und verbinden Sie ihn mit dem gelesenen Wert. Tragen Sie als Bedingung Temperatur > 80 ein und prüfen Sie den Ausdruck mit „Prüfen“.
3. Erstellen Sie am Diagramm-Knoten mit „THEN erstellen“ den THEN-Zweig und projektieren Sie darin die Meldung an das MES. Erstellen Sie mit „ELSE erstellen“ den ELSE-Zweig mit dem Schreibvorgang in die Datenbank. Werte, die beide Zweige brauchen, deklarieren Sie im Reiter „Eingänge“; Ergebnisse, die der Flow weiterverwenden soll, im Reiter „Ausgänge“.
4. Veröffentlichen Sie den Flow. In den Transferdetails des Objekts sehen Sie zu jedem Lauf das Bedingungsergebnis sowie den ausgeführten und den übersprungenen Zweig.

Voraussetzungen und Grenzen:

• Der THEN-Zweig ist Pflicht, der ELSE-Zweig optional. Ohne ELSE-Zweig gelten bei falscher Bedingung die Standardwerte der Ausgänge.
• Die Bedingung folgt der Syntax des Taschenrechner-Transferobjekts. Ein ELSE-IF gibt es nicht; mehrstufige Entscheidungen projektieren Sie mit verschachtelten Bedingungen.
• Jeder Zweigaufruf ist auf 30 Sekunden begrenzt – wie jeder Aufruf eines Unterablaufs, siehe Zeitlimit der Unterabläufe. Änderungen an einem Zweig wirken erst mit dem nächsten Veröffentlichen des Flows.

Referenz: Bedingung (IF)-Transferobjekt · Unterabläufe · Veröffentlichen und Status

Funktion (FX)

Anwendungsfall: 30 Anlagen liefern Daten über unterschiedliche Flows; die Aufbereitung der Werte ist überall dieselbe. Ändert sich die Aufbereitung, soll sie nur an einer Stelle gepflegt werden.

So projektieren Sie das:

1. Legen Sie in der Vorlagen-Oberfläche („Templates & FBs“) mit „Neue Funktion“ eine Funktion an. Deklarieren Sie im Dialog den Kontrakt: die Eingänge (z. B. Rohwert) und Ausgänge (z. B. Wert) mit Datentyp.
2. Projektieren Sie im Designer der Funktion die Aufbereitung zwischen Scope-Eingang und Scope-Rückgabe – mit denselben Transferobjekten wie in einem Flow.
3. Ziehen Sie in jeden der 30 Flows das Transferobjekt „Funktion (FX)“ und wählen Sie die Funktion aus. Die Ein- und Ausgänge des Kontrakts erscheinen als Items am Objekt und werden wie üblich verdrahtet.
4. Veröffentlichen Sie die Flows.

Ändern: Bearbeiten Sie die Funktion in der Vorlagen-Oberfläche und veröffentlichen Sie die aufrufenden Flows erneut. Der Veröffentlichen-Baum zeigt die betroffenen Flows als geändert an und wählt sie zum Veröffentlichen vor; nicht neu veröffentlichte Flows laufen mit der bisherigen Fassung weiter. Ändern Sie den Kontrakt (Ein- oder Ausgänge), öffnen und übernehmen Sie zusätzlich die Aufrufstellen, damit deren Items angepasst werden.

Abgrenzung zu Vorlagen: Sind ganze Flows bis auf einzelne Werte gleich, verwenden Sie Vorlagen und Instanzen. Funktionen eignen sich für einen gleichen Teilablauf in sonst unterschiedlichen Flows. Beides lässt sich kombinieren: Auch eine Vorlage kann eine Funktion aufrufen.

Voraussetzungen und Grenzen:

• Funktionen dürfen andere Funktionen aufrufen. Ringverweise werden abgewiesen; die Aufruftiefe ist begrenzt (Standardwert 16).
• Je Aufrufstelle läuft höchstens ein Aufruf gleichzeitig; für seine Dauer gilt das Zeitlimit der Unterabläufe.
• Beim Kopieren einer Aufrufstelle in ein anderes Projekt über die Zwischenablage wird die Funktion nicht mitkopiert – verwenden Sie den Datei-Export.

Referenz: Funktionsbausteine · Veröffentlichen und Status · Mit Vorlagen arbeiten

Fehlerbehandlung (Try/Catch)

Anwendungsfall: Ein Auftragsdatensatz lässt sich nicht in das ERP-System schreiben. Statt dass der Flow abbricht, soll der OPC Router den Schreibvorgang wiederholen und erst nach dem endgültigen Fehlschlag den Schichtleiter per E-Mail informieren – mit der Fehlermeldung im Text.

So projektieren Sie das:

1. Ziehen Sie das Transferobjekt „Fehlerbehandlung (Try/Catch)“ in den Flow und deklarieren Sie im Reiter „Eingänge“ die Werte des Auftrags, die beide Zweige brauchen.
2. Erstellen Sie am Diagramm-Knoten mit „TRY erstellen“ den TRY-Zweig und projektieren Sie darin den Schreibvorgang in das ERP-System.
3. Aktivieren Sie „Fehlgeschlagene TRY-Aufrufe automatisch wiederholen“ und stellen Sie „Maximale Wiederholungen“ und „Wartezeit zwischen Versuchen“ ein. Lassen Sie „CATCH-Ausführung“ auf „Nur beim endgültigen Fehlschlag“.
4. Erstellen Sie mit „CATCH erstellen“ den CATCH-Zweig und projektieren Sie darin ein E-Mail-Transferobjekt. Verbinden Sie den Ausgang CatchError des Scope-Eingangs mit dem Nachrichtentext – auf Wunsch auch CatchFailedStep (Schrittnummer des fehlgeschlagenen Objekts) und CatchAttempt (Nummer des Versuchs).
5. Veröffentlichen Sie den Flow. Der Status-Ausgang Recovered des Transferobjekts zeigt dem Flow an, dass eine Störung behandelt wurde; in den Transferdetails sehen Sie jeden Versuch einzeln.

Voraussetzungen und Grenzen:

• Die Wiederholung ist standardmäßig ausgeschaltet und führt den kompletten TRY-Zweig erneut aus. Sie eignet sich nur für Abläufe, die mehrfach ausgeführt werden dürfen. Prüfen Sie beim Schreiben in ein ERP-System, ob ein Datensatz beim zweiten Versuch doppelt entstehen kann – z. B. indem der TRY-Zweig vor dem Schreiben abfragt, ob der Auftrag bereits vorhanden ist.
• Ohne CATCH-Zweig wird ein endgültiger Fehlschlag nicht als Fehler gemeldet; es gelten die Standardwerte der Ausgänge.
• Ein Fehler im CATCH-Zweig lässt den Transfer fehlschlagen.
• Während der Versuche und Wartezeiten ist der Transfer des Flows belegt; für den Zweigaufruf gilt das Zeitlimit der Unterabläufe.
• Für die E-Mail-Benachrichtigung benötigen Sie eine E-Mail-Anbindung des E-Mail-Plug-ins.

Referenz: Fehlerbehandlung (Try/Catch)-Transferobjekt · Unterabläufe

Change Gate

Anwendungsfall: Ein Zählerwert wird sekündlich gelesen. In die Datenbank – oder an MQTT, REST oder eine Datei – soll nur ein Wert gelangen, der sich gegenüber dem zuletzt geschriebenen Wert um mindestens 5 geändert hat, spätestens aber alle 10 Minuten.

So projektieren Sie das:

1. Ziehen Sie das Transferobjekt „Change Gate“ in den Flow. Legen Sie im Reiter „Schwellwert-Eingänge“ einen Eingang für den Zählerwert an, wählen Sie den Änderungsmodus „Absolute Schwelle“ und tragen Sie als Schwellwert 5 ein.
2. Aktivieren Sie im Bereich Zeit den Heartbeat und stellen Sie 10 Minuten ein.
3. Erstellen Sie mit „Subflow erstellen“ den Subflow und projektieren Sie darin das Schreiben in die Datenbank. Die überwachten Werte stehen im Subflow am Scope-Eingang bereit.
4. Veröffentlichen Sie den Flow. Bleibt das Gate geschlossen, wird nur der Subflow übersprungen; der Transfer endet erfolgreich.

Voraussetzungen und Grenzen:

• Die Schwellenmodi setzen numerische Werte voraus.
• Die Vergleichsbasis wird nicht dauerhaft gespeichert. Nach einem Neustart der Laufzeit beginnt der Vergleich neu; mit „Ersten Zyklus durchlassen“ öffnet das Gate dann beim ersten Zyklus.
• Mit aktivem Heartbeat erhält das Ziel in dem eingestellten Abstand auch unveränderte Werte.
• Für den Aufruf des Subflows gilt das Zeitlimit der Unterabläufe.

Referenz: Change-Gate-Transferobjekt

Variablen

Ordner

Anwendungsfall: Ein Projekt hat mehrere hundert Variablen; sie sollen nach Anlagen und Themen gegliedert sein.

So projektieren Sie das: Legen Sie im Variablen-Plug-in über „Neuer Ordner“ Ordner und Unterordner an und verschieben Sie Variablen per Drag-and-drop. Beim Anlegen einer Variable wählen Sie den Ordner im Feld „Ordner“. Der Namensfilter durchsucht den gesamten Baum.

Grenzen: Variablen aus älteren Projekten, deren Name bereits ein / enthält, bleiben nach dem Update flache Variablen, bis Sie ihnen im Bearbeiten-Dialog einen Ordner zuweisen.

Zugangsdaten als Secret

Anwendungsfall: Ein API-Schlüssel wird in mehreren REST-Aufrufen gebraucht und soll weder in der Oberfläche noch im Status lesbar sein.

So projektieren Sie das: Legen Sie eine Variable vom Typ Secret String an und setzen Sie den Wert über den Passwort-Dialog. Verwenden Sie die Variable als Quelle für den HTTP-Header des REST-Transferobjekts. Der Wert wird verschlüsselt gespeichert, überall maskiert angezeigt und nur am Ziel des Transfers im Klartext eingesetzt.

Grenzen: Für Secrets ist keine Aufbewahrung und keine Aggregation möglich; der Wert gilt als Initialwert der Konfiguration.

Kennzahlen über ein Zeitfenster (Aggregation)

Anwendungsfall: Der Verbrauchswert einer Anlage geht sekündlich in eine Variable. In die Datenbank soll alle 15 Minuten nur der Mittelwert des Zeitfensters – statt 900 Einzelwerten.

So projektieren Sie das:

1. Legen Sie eine globale Variable Verbrauch mit numerischem Typ an und aktivieren Sie die „Aufbewahrung“.
2. Aktivieren Sie im Bearbeiten-Dialog „Aggregation aktivieren“, stellen Sie die „Fensterdauer“ auf 15m und wählen Sie unter „Kennzahlen“ z. B. Average, Min und Max.
3. Schreiben Sie den Messwert wie bisher mit dem Variablen-Transferobjekt in Verbrauch. Die Kennzahlen erscheinen als eigene Variablen Verbrauch.Average, Verbrauch.Min und Verbrauch.Max unterhalb der Quelle und werden am Ende jedes Zeitfensters fortgeschrieben.
4. Legen Sie einen zweiten Flow mit einem Variablen-Trigger auf Verbrauch.Average an, der den Wert in die Datenbank schreibt. Der Trigger löst genau dann aus, wenn ein neues Zeitfenster abgeschlossen ist.
5. Schalten Sie die Konfiguration produktiv und starten Sie die Laufzeit neu.

Voraussetzungen und Grenzen:

• Aggregation ist nur für globale Variablen mit Aufbewahrung möglich, nicht für Secrets. Für nicht-numerische Typen steht nur Count zur Verfügung.
• Die Zeitfenster liegen auf einem festen Raster der koordinierten Weltzeit (UTC). Ein Zeitfenster wird mit dem ersten Schreibvorgang nach seinem Ende abgeschlossen; ein Fenster ohne Schreibvorgang liefert keinen neuen Wert, die Kennzahl-Variable behält den letzten Fensterwert.
• Ein Time-Trigger, der die Kennzahl-Variable zyklisch liest, liegt nicht auf dem Fensterraster und kann noch das vorherige Fenster lesen. Verwenden Sie den Variablen-Trigger.
• Änderungen an der Aggregations-Konfiguration greifen nach dem Produktivschalten mit dem Neustart der Laufzeit.

Variablen dynamisch lesen und schreiben

Anwendungsfall: Der Variablenname entsteht erst zur Laufzeit, z. B. aus einer Anlagen-ID.

So projektieren Sie das: Verwenden Sie die Transferobjekte „Variablen – Dynamisches Lesen“ bzw. „Variablen – Dynamisches Schreiben“ und übergeben Sie den Variablennamen über den Eingangspin. In Vorlagen können Sie stattdessen im Variablen-Transferobjekt und im Variablen-Trigger einen Pfad mit Platzhaltern angeben, z. B. {Anlage}/Temperatur.

Grenzen: Eine dynamisch geschriebene neue Variable existiert zunächst nur in der Laufzeit; in die Konfiguration übernehmen Sie sie mit „In Konfiguration übernehmen“.

Referenz: Variablen-Plug-in · Variablen – Dynamisches Lesen · Variablen – Dynamisches Schreiben · Variablen-Trigger

DB Log Table

Anwendungsfall: Eine neue Messwertreihe soll in eine Datenbanktabelle protokolliert werden, die noch nicht existiert.

So projektieren Sie das:

1. Ziehen Sie das Transferobjekt „DB Log Table“ aus der Werkzeuggruppe „Datenbank“ in den Flow.
2. Wählen Sie auf der Registerkarte „Log Table“ die Datenquelle, tragen Sie den Tabellennamen ein und definieren Sie die Spalten mit Name, Datentyp, Pflichtfeld und Standardwert. Markieren Sie die Spalte als Primärschlüssel, über die ein vorhandener Datensatz aktualisiert statt neu eingefügt werden soll.
3. Legen Sie auf der Registerkarte „Optionen/Verhalten“ fest, was bei abweichenden, überzähligen und fehlenden Spalten geschieht.
4. Verbinden Sie die Eingänge der Spalten und veröffentlichen Sie den Flow. Beim ersten Transfer legt der OPC Router die Tabelle an.

Voraussetzungen und Grenzen:

• Der Datenbankbenutzer benötigt das Recht, Tabellen anzulegen und – für „Korrigieren“ – zu ändern.
• „Korrigieren“ löscht abweichende oder überzählige Spalten samt Daten.
• Verfügbar für die Anbindungen Microsoft SQL Server, Oracle, SAP HANA, MySQL, PostgreSQL und MS Access; bei SQLite, ODBC und OLE DB legt der OPC Router die Tabelle an und ergänzt fehlende Spalten, ändert oder entfernt vorhandene Spalten aber nicht.

Referenz: DB Log Table-Transferobjekt

Zertifikate über OPC UA GDS

Anwendungsfall: 40 Installationen in mehreren Werken kommunizieren per OPC UA. Die Zertifikate sollen zentral von der IT ausgestellt, erneuert und gesperrt werden, ohne jede Installation einzeln zu pflegen.

So projektieren Sie das:

1. Legen Sie unter Zertifikate – Zertifikate über OPC UA GDS eine neue GDS Anwendung an: GDS Server URL, Anmeldedaten und Clientzertifikat. Prüfen Sie die Angaben mit „Verbindung testen“.
2. Klicken Sie im Tab Anwendung auf „Registrieren“ und danach auf „Zertifikat anfordern“. Warten Sie ggf. auf die Genehmigung durch den GDS-Administrator.
3. Stellen Sie in den Plug-in-Anbindungen, die dem GDS vertrauen sollen, „Akzeptierte Zertifikate“ auf „GDS“ und wählen Sie das vom GDS ausgestellte Zertifikat aus – in den Auswahllisten erkennen Sie es am Namen der GDS Anwendung.
4. Schalten Sie die Konfiguration produktiv.
5. Für die weiteren Installationen exportieren Sie die Konfiguration und importieren sie dort. Verwenden Sie in Application URI und Anwendungsname den Platzhalter ${hostname}, damit jede Installation unter einer eigenen Kennung beim GDS registriert wird.

Voraussetzungen und Grenzen:

• Erforderlich sind eine Enterprise-Lizenz je Installation und ein Global Discovery Server im Unternehmen.
• Sperrungen und erneuerte Zertifikate übernimmt der OPC Router mit dem nächsten Abruf (Standard alle 5 Minuten, einstellbar von 1 Minute bis 24 Stunden). Bestehende Verbindungen verwenden sie ab dem nächsten Verbindungsaufbau.
• Wann ein Zertifikat erneuert wird, bestimmt der GDS.
• Ist der GDS nicht erreichbar, arbeitet der OPC Router mit den zuletzt abgeholten Zertifikaten weiter.
• Das HTTPS-Zertifikat der Weboberfläche und selbst importierte Zertifikate verwalten Sie weiterhin in der Zertifikatsverwaltung.

Referenz: Zertifikatsverwaltung über OPC UA GDS

Startmodus von Plug-in-Instanzen

Anwendungsfall: Eine Anlage steht für mehrere Wochen still; ihre Anbindung soll in dieser Zeit keine Verbindungsversuche erzeugen. Eine Testanbindung soll nur laufen, solange ein Flow sie tatsächlich verwendet.

So projektieren Sie das: Wählen Sie in der Instanzliste des Plug-ins in der Spalte „Startmodus“ den Wert „Deaktiviert“ für die stillstehende Anlage und „Auto“ für die Testanbindung. Schalten Sie die Konfiguration produktiv.

Verhalten:

• „Auto“ startet die Instanz, solange ein aktivierter Flow oder eine aktivierte Vorlage sie verwendet, und stoppt sie wieder, wenn das nicht mehr der Fall ist.
• Flows, die eine deaktivierte Instanz verwenden, bleiben aktiv; betroffene Transferobjekte zeigen den Status „PlugIn deaktiviert“.
• Instanzen, die nicht gestartet sind, zählen nicht zur Lizenzprüfung der Extension Suite.

Referenz: Plug-in-Instanzen aktivieren und deaktivieren

Automatischer Logout

Anwendungsfall: Angemeldete Sitzungen an gemeinsam genutzten Arbeitsplätzen sollen nach einer Zeit ohne Aktivität enden, und keine Sitzung soll länger als einen Arbeitstag bestehen.

So konfigurieren Sie das: Setzen Sie die globalen Standardwerte über die Umgebungsvariablen OR_WEB_SESSION_INACTIVITY_TIMEOUT_MINUTES und OR_WEB_SESSION_TIMEOUT_HOURS des Management-Dienstes. In der Benutzerverwaltung passen Sie beide Zeiten je Benutzer an oder schalten sie ab.

Voraussetzungen und Grenzen: Beide Timeouts sind im Auslieferungszustand ausgeschaltet. Geänderte Zeiten gelten ab der nächsten Anmeldung des Benutzers.

Referenz: Benutzerverwaltung – Automatischer Logout

Was sich für bestehende Projekte ändert

• Begriffe: „Verbindung“ heißt jetzt „Flow“, „Verbindungspfeil“ heißt „Item Link“. Die Umbenennung betrifft die Oberfläche und die Dokumentation; das Kapitel dazu finden Sie unter Flows bauen. Die Begriffe dieser Fassung – darunter Unterablauf, Funktion (FX), Kontrakt, Scope-Eingang und Scope-Rückgabe – erklärt das Glossar.
• .NET 10: Der OPC Router läuft auf .NET 10. Auf Systemen mit CET-fähigem Prozessor muss Windows vollständig aktualisiert sein, sonst starten die Dienste nicht – siehe Systemvoraussetzungen.
• MongoDB-Plug-in: Der aktualisierte Treiber setzt mindestens MongoDB 4.2 voraus – siehe MongoDB Plug-in.
• Metriken: Je Metrik werden höchstens 128 Zeitreihen (Attributkombinationen) einzeln geführt; überzählige Zeitreihen fasst die Metrikerfassung in einem gemeinsamen Overflow-Punkt zusammen. Anlagen mit mehr Attributkombinationen auf einer Metrik heben das Limit mit der Umgebungsvariablen OR_METRICS_CARDINALITY_LIMIT an (2000 entspricht dem bisherigen Verhalten) – siehe Metriken-Export.
• Automatischer Logout: Beide Timeouts sind ausgeschaltet, bis Sie sie aktivieren.
• Variablen: Namen mit / aus älteren Projekten bleiben flache Variablen, bis ein Ordner zugewiesen wird. Aggregations-Einstellungen greifen nach dem Produktivschalten mit dem Neustart der Laufzeit.
• Unterabläufe: Änderungen an Zweigen und Funktionen wirken erst mit dem nächsten Veröffentlichen des aufrufenden Flows.
• Startmodus: Bestehende Plug-in-Instanzen erhalten den Startmodus „Immer aktiv“; ihr Verhalten ändert sich nicht.