Der Pfad für geschlossene Regelschleifen verbindet den Policy-Worker (xLSTM) mit Ihren industriellen Endpunkten. Fünf Transport-Optionen decken verschiedene Deployment-Formen ab; ein watchdog-getriebener Sicherheits-Fallback hält die Schleife geordnet, wenn der Policy-Worker seinen Deadline verpasst. Die Lizenz-Stufe variiert pro Transport — siehe Tabelle unten.
| Transport | Status | Lizenz-Stufe | Typischer Einsatz |
|---|---|---|---|
| WebSocket | GA | Standard+ | Sub-Tick-Latenz, 50–100 Hz Schleifen |
| Modbus TCP | GA | Standard+ | Bestehende industrielle Anlagen, Antriebe, Sensoren |
| OPC-UA | Preview | Pro+ | SPS-Flotten, herstellerübergreifende Industrie |
| MQTT (Sparkplug B), Publish | GA | Pro+ | Policy-Aktionen an die Aktor-Flotte senden |
| MQTT (Sparkplug B), Subscribe | Preview | Pro+ | Beobachtungen aus der Sensor-Flotte ziehen |
| File-Tail (Test) | GA | Standard+ | Deterministische Test-Rigs, Dev-Schleifen |
WebSocket, Modbus, MQTT-Publish und der deterministische File-Tail-Transport sind in 5.0 GA. OPC-UA wird durch 5.0 RC1 als Preview ausgeliefert — der C++-Quellcode liegt im Release, die open62541-Bibliothek wird mit dem nächsten Cluster-RPM-Schnitt mitgebündelt. MQTT-Subscribe (Beobachtungen aus einer Sparkplug-B-Sensor-Flotte über den Policy-Worker ziehen) bleibt über die 5.0-Linie Preview; der per-Binding-Hintergrund-Subscriber und Ringpuffer landet in 5.1. Siehe Bekannte Probleme für den aktuellen Preview-Status.
Die Regelschleife tickt mit einer von Ihnen gewählten Rate (typischerweise 10–100 Hz). Bei jedem Tick:
Dauert ein Schritt länger als der Watchdog-Timeout, übernimmt die Schleife den konfigurierten Sicherheits-Fallback und zählt den Miss. Wiederholte Misses lösen einen Zustandswechsel aus; anhaltende Misses können die Bindung an einen Failover-Worker übergeben, sofern konfiguriert.
Wenn die Regelschleife schneller tickt, als HTTP-Round-Trip-Latenz komfortabel erlaubt, hält der WebSocket-Transport eine langlebige Verbindung zum Policy-Worker offen. Der IoT-Worker streamt Beobachtungen; der Policy-Worker streamt Aktionen zurück. Kein Verbindungsaufbau pro Tick; die Latenz fällt auf den reinen Netzwerk-Round-Trip plus Inferenz-Zeit.
Wann sinnvoll: 50–100 Hz Regelschleifen, jitter-empfindliche Workloads, alles wo der Verbindungs-Overhead pro Anfrage im Latenz-Budget weh tut.
Fehler-Modi: Bricht der WebSocket ab, geht die Bindung sofort in degraded. Der Sicherheits-Fallback greift, während im Hintergrund eine Neuverbindung läuft.
Modbus über TCP ist das Arbeitspferd-Protokoll für ältere industrielle Antriebe, Sensoren und SPSen. Der Modbus-Transport liest Beobachtungs-Register, sendet sie an den Policy-Worker und schreibt die geprüfte Aktion auf die konfigurierten Modbus-Adressen zurück. GA in 5.0.
Wann sinnvoll: Integration mit Motor-Antrieben, Frequenzumrichtern, Energiezählern, Wasseraufbereitungs-Anlagen — überall, wo Modbus bereits das operative Protokoll ist. Lässt sich gut mit WebSocket auf der Policy-Seite kombinieren, wenn die Modell-Anfrage latenz-kritisch ist, der Aktor aber mit Modbus-Polling-Raten zufrieden ist.
Fehler-Modi: Verbindungs-Verlust wird vom Watchdog erkannt; der Sicherheits-Fallback greift, und die Bindung wandert in den Failover-Zustand, sofern konfiguriert.
Der OPC-UA-Transport bindet die Regelschleife über das OPC-UA-Protokoll an eine SPS. Ein Satz OPC-UA-Tag-Werte wird abonniert; der IoT-Worker stellt daraus die Beobachtung zusammen; der Policy-Worker liefert die Aktion; der IoT-Worker schreibt die Aktion auf die konfigurierten OPC-UA-Schreib-Tags zurück. Pro+-Stufe. Preview durch 5.0 RC1 — der C++-Quellcode liegt im Release; die open62541-Bibliothek wird mit dem nächsten Cluster-RPM-Schnitt mitgebündelt und schaltet den Transport auf GA.
Wann sinnvoll: Bestehende SPS-Infrastruktur, herstellerübergreifende industrielle Flotten — alles, wo OPC-UA der etablierte Integrations-Punkt ist. Die Plattform spricht OPC-UA direkt, ohne hersteller-spezifische Zwischenschicht.
Fehler-Modi: Die OPC-UA-Session wird vom selben Watchdog überwacht. Bricht die SPS-Verbindung ab, greifen Sicherheits-Fallback und Neuverbindung.
Der MQTT-Transport mit Sparkplug-B-Namensraum verteilt Beobachtungen und Aktionen über einen MQTT-Broker an eine Sensor-/Aktor-Flotte. Zwei Hälften mit unterschiedlichem Status in der GA: Publish (Aktionen an Aktor-Topics) ist GA — der IoT-Worker schickt geprüfte Policy-Ausgaben über einen Publish-Pfad pro Aktor in Ihre Sparkplug-B-Flotte. Subscribe (Beobachtungen aus Sensor-Topics) bleibt Preview — das Ziehen von Beobachtungen durch den Policy-Worker braucht einen Hintergrund-Subscriber pro Bindung plus Ring-Buffer; landet in der 5.0-Patch-Linie. Pro+-Stufe auf beiden Hälften.
Wann sinnvoll: Verteilte Sensor-Flotten, bei denen die Aktoren nicht beim Policy-Worker stehen; IoT-Umgebungen mit MQTT-Sparkplug-B als Telemetrie-Standard; Deployments, bei denen ein Policy-Worker viele unabhängige Regelschleifen über einen Broker bedient.
Fehler-Modi: MQTT-Zustellung ist auf der Aktor-Seite per Konfiguration höchstens-einmal (Steuerbefehle sollen nicht wiederholt werden); der Watchdog erkennt Publish-Backpressure oder Broker-Disconnect und greift mit dem Sicherheits-Fallback ein.
Der Watchdog ist die Verteidigungslinie zwischen einem unhealthy Policy-Worker und Ihren Aktoren. Er erzwingt ein Latenz-Budget pro Tick — übersteigt ein Tick es, verwirft der IoT-Worker die verspätete Aktion und wendet einen konfigurierten Fallback an. Drei Modi:
Null (oder den konfigurierten Null-Wert des Aktors) auf jedem Ausgang schreiben. Sicherer Standard, wenn „keine Anweisung“ ein Ruhezustand ist — Robotik-Gelenke, Motordrehmoment, Pumpendrehzahl.
Die zuletzt geprüfte Aktion erneut schreiben. Setzt fort, was der Aktor gerade tat. Sinnvoll, wenn die letzte Aktion bekannt-sicher war und ein abruptes Anhalten schlechter wäre als das Weiterführen — z. B. einen bewegenden Roboter ausrollen statt notbremsen.
Die letzte Aktion halten, die alle Sicherheits-Prüfungen (Clamps, Limits, NaN) bestanden hat. Stärker als Einfrieren, weil die jüngste Aktion übersprungen wird, wenn sie sich einer Sicherheits-Grenze näherte.
Der Zustandsautomat: ein einzelner verpasster Tick setzt die Bindung in degraded; anhaltende Misses jenseits einer konfigurierbaren Schwelle lösen Failover auf einen Backup-Policy-Worker aus (falls konfiguriert) oder stoppen die Bindung ganz (falls nicht). Die Konfigurations-Wahl liegt pro Bindung bei Ihnen.
Für Regelschleifen, die nicht stehenbleiben dürfen, konfiguriert die Admin eine Failover-Strategie pro Bindung:
Zum breiteren Robotik-/Industrie-Kontext: Robotik und Fabriken. Zur vollständigen Protokoll-Abdeckung des IoT-Workers: Funktions-Katalog § 10. Konkrete Deployment-Fragen: office@eldric.ai.