Neu in 5.5
Version 5.5 richtet den OPC Router auf Cloud-Analysen und KI-Anwendungen aus: Produktionsdaten wandern in die Snowflake AI Data Cloud, JSON-Strukturen werden über Schemata beschrieben statt von Hand nachgebaut, MQTT-Werte stehen auch außerhalb des Ereignisses zur Verfügung, über das Model Context Protocol beantwortet eine KI Fragen auf Ihren eigenen Daten, und MQTT 5 bringt Anfrage/Antwort und verteilte Empfänger mit. 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 |
|---|---|
| Snowflake-Plug-in | Maschinendaten in die Snowflake AI Data Cloud schreiben und Ergebnisse zurückholen |
| Produktionsdaten für KI über MCP | Einer KI kontrollierten Zugriff auf Ihre Daten geben |
| JSON Schema | JSON-Strukturen zentral beschreiben, prüfen und wiederverwenden |
| MQTT Storage | Den letzten Wert eines Topics lesen, ohne auf das nächste Ereignis zu warten |
| MQTT 5 | Anfrage und Antwort über MQTT, Last auf mehrere Empfänger verteilen |
Snowflake-Plug-in
Anwendungsfall: Die Messwerte mehrerer Anlagen sollen fortlaufend in der Snowflake AI Data Cloud landen, wo sie ausgewertet werden; das Ergebnis der Auswertung soll zurück in die Produktion.
So projektieren Sie das:
- Legen Sie im Bereich Plug-ins eine Snowflake-Anbindung an und tragen Sie die Verbindungsdaten ein. Alle Abfragen und Schreibvorgänge laufen über ein Snowflake Warehouse.
- Projektieren Sie den Transfer wie bei jeder anderen Datenbank-Anbindung – das Plug-in bringt die gewohnten Datenbank-Transferobjekte mit.
- Für den Rückweg lesen Sie die Ergebnisse aus Snowflake und schreiben sie an ihr Ziel: an die Anlage, in ein Dashboard oder als Auslöser für einen weiteren Flow.
Kosten im Blick behalten: Jeder Lese- oder Schreibvorgang über das Warehouse verursacht Snowflake-Credits – auch bei aktiviertem Auto Resume / Suspend, sobald das Warehouse aktiv ist. Für Szenarien, die nur schreiben, beschreibt das Handbuch zwei kostengünstigere Wege ohne aktives Warehouse:
- über das REST-Plug-in an einen Snowpipe-Endpunkt, der die Daten asynchron in die Zieltabellen lädt;
- über das Cloud File Access-Plug-in in eine Cloud Stage (z. B. Amazon S3), aus der Snowpipe oder ein Copy-Command sie übernimmt – geeignet für periodisches oder gepuffertes Schreiben größerer Mengen.
Referenz: Snowflake AI Data Cloud-Plug-in · Verbindungseinstellungen
Produktionsdaten für KI über MCP
Anwendungsfall: Eine KI soll Fragen zur Produktion beantworten, die heute jemand von Hand aus mehreren Systemen zusammensuchen müsste – etwa „Welche Maschine arbeitet am produktivsten?", „Welche Maschinen sollten bald gewartet werden?" oder „Zu welchen Uhrzeiten sind die Maschinen am wenigsten produktiv?".
So projektieren Sie das: Das Model Context Protocol (MCP) ist ein offener Standard, über den KI-Anwendungen auf fremde Systeme zugreifen. Im OPC Router richten Sie den Zugang über das REST-Plug-in ein: Sie stellen die Daten als MCP-Werkzeug bereit und legen dabei fest, welche Abfragen die KI ausführen darf. Welche Daten in die Antwort einfließen, bestimmen Sie über die Flows dahinter – die Quellen können aus beliebigen Plug-ins stammen und in einer Antwort zusammengeführt werden.
Voraussetzungen und Grenzen: Sie benötigen eine REST-Anbindung; die Datenquellen müssen als Flows projektiert sein. Der Zugriff geht nur so weit, wie Sie ihn öffnen – die KI sieht ausschließlich, was Sie bereitstellen.
Referenz: Bereitstellung von Produktionsdaten über MCP · REST-Plug-in
JSON Schema
Anwendungsfall: Mehrere Flows tauschen dieselbe JSON-Struktur mit einem Fremdsystem aus. Bisher wurde sie in jedem Transferobjekt von Hand nachgebaut – mit dem Risiko, dass ein Feldname irgendwo abweicht.
So projektieren Sie das:
- Legen Sie im JSON Schema-Plug-in ein Schema an: Sie importieren eine vorhandene Schemadatei, erzeugen sie aus einem Beispieldokument oder schreiben sie im Editor, der die Struktur dabei live prüft.
- Wählen Sie die Ablage. Eingebettete Schemata liegen im Projekt und werden beim Export mitgesichert, stehen also auf einem anderen System ohne separaten Dateiaustausch bereit.
- Verwenden Sie das JSON Schema-Transferobjekt im Flow. Es liest, schreibt und patcht JSON-Daten und prüft sie gegen das Schema; einzelne Felder sprechen Sie über JsonPointer (RFC 6901) an, etwa
/equipment/status. - Legen Sie fest, ob das Transferobjekt immer die neueste Version des Schemas verwendet oder eine feste Version – Letzteres, wenn die Verarbeitung stabil bleiben soll.
Voraussetzungen und Grenzen: Mitgelieferte Beispielschemata wie OPC UA, Siemens IECTL oder Portainer dienen der Veranschaulichung; auf Vollständigkeit oder Funktion besteht kein Anspruch.
Referenz: JSON Schema-Plug-in · JSON Schema-Transferobjekt · Validierung
MQTT Storage
Anwendungsfall: Ein Bericht soll um 6 Uhr die aktuellen Werte mehrerer Topics zusammenfassen. MQTT liefert aber nur, wenn gerade jemand veröffentlicht – wer zum Auslösezeitpunkt nichts empfängt, hat keinen Wert.
So projektieren Sie das:
- Aktivieren Sie in der MQTT-Anbindung auf der Registerkarte Storage die Option MQTT Data Storage aktivieren. Der OPC Router legt daraufhin für alle eingetragenen Topics automatisch Subscriptions an und speichert je Topic die zuletzt empfangene Nachricht dauerhaft.
- Ziehen Sie das Transferobjekt MQTT Storage Lesen in den Flow, wählen Sie die Brokeranbindung und tragen Sie das Topic ein – Topic-Muster mit Platzhaltern sind möglich.
- Lösen Sie den Flow aus, womit Sie wollen – etwa mit einem Time-Trigger. Der gespeicherte Wert steht unabhängig vom letzten Ereignis zur Verfügung.
Voraussetzungen und Grenzen: Ohne die Option MQTT Data Storage aktivieren lässt sich das Transferobjekt nicht nutzen. Gespeichert wird nur die jeweils letzte Nachricht je Topic; ältere Werte werden überschrieben, eine Historie entsteht nicht.
Referenz: MQTT Storage Lesen-Transferobjekt · MQTT-Plug-in-Konfiguration
MQTT 5
Anwendungsfall: Ein Gerät stellt über MQTT eine Anfrage und erwartet eine Antwort – bisher mussten Sender und Empfänger die Topics dafür vorher fest vereinbaren. Und wenn ein einzelner Empfänger die Nachrichtenmenge eines Topics nicht mehr schafft, soll sich die Last auf mehrere Empfänger verteilen lassen.
So projektieren Sie das:
- Stellen Sie in der Brokeranbindung die Eigenschaft MQTT-Version auf v5.
- Für Anfrage und Antwort nutzen Sie die Angaben, die MQTT 5 an der Nachricht selbst mitführt: das Antwort-Topic, mit dem der Absender festlegt, wohin die Antwort gehen soll, und die Korrelationsdaten, die der Empfänger zurücksendet, sodass sich jede Antwort ihrer Anfrage zuordnen lässt. Über Benutzer-Eigenschaften hängen Sie der Nachricht zusätzlich frei wählbare Schlüssel-Wert-Paare an – vergleichbar mit Kopfzeilen einer HTTP-Anfrage, etwa
sensorType: temperature. So transportiert die Nachricht ihre Metadaten, ohne dass Sie den Payload dafür ändern. - Zum Verteilen der Last projektieren Sie am MQTT-Trigger eine Shared Subscription: Mehrere Clients treten mit demselben Shared-Subscription-Topic derselben Consumer-Gruppe bei und teilen die eingehenden Nachrichten unter sich auf.
Voraussetzungen und Grenzen: Alle Punkte setzen einen Broker voraus, der MQTT 5 unterstützt. Bei Shared Subscriptions müssen sich alle beteiligten Clients mit dem identischen Shared-Subscription-Topic samt gleichem Gruppennamen verbinden, sonst bilden sie keine gemeinsame Gruppe; die Shared Subscription beeinflusst nur die Verteilung der Nachrichten, nicht die Zustellgarantie.
Referenz: MQTT-Plug-in-Konfiguration
Was sich für bestehende Projekte ändert
- MQTT Storage ist nicht voreingestellt. Erst mit der Option MQTT Data Storage aktivieren legt der OPC Router die Subscriptions an und speichert Werte; vorher liefert das Transferobjekt nichts.
- Snowflake kostet mit jedem Zugriff. Ein Flow, der im Sekundentakt liest oder schreibt, hält das Warehouse aktiv. Prüfen Sie bei reinen Schreibstrecken die Wege über Snowpipe oder eine Cloud Stage.
- MQTT 5 hängt am Broker. Antwort-Topic, Korrelationsdaten, Benutzer-Eigenschaften und Shared Subscriptions stehen erst zur Verfügung, wenn die Brokeranbindung auf v5 steht und der Broker diese Version unterstützt.
- Feste Schema-Version, wo Stabilität zählt. Steht ein JSON Schema-Transferobjekt auf „neueste Version", ändert eine neue Schemaversion sein Verhalten mit.