Deterministische KI→SPS-Integration: Warum Pub/Sub und harte Deadlines REST und Client/Server schlagen

Einstieg
Das konkrete Problem: Ein Computer-Vision-System entscheidet in 8–25 ms, ob ein Teil i.O. oder n.i.O. ist – aber die SPS braucht das Ergebnis deterministisch innerhalb von 20 ms nach dem Trigger, sonst fährt der Greifer ins Leere oder wirft i.O.-Teile aus. Viele Teams integrieren solche Systeme mit REST, gRPC oder „schnell mal OPC UA Client/Server“. Das funktioniert auf dem Labortisch, bricht aber in der Linie unter Jitter, Backpressure und Verbindungs-Glitches zusammen. Dieser Beitrag beschreibt eine Architektur, die in Produktionsumgebungen stabil läuft: on-prem, Pub/Sub statt Abfrage, harte Deadlines mit explizitem Timeout-Resultat, bounded Queues und ein „zwei-Kanäle“-Design (schneller Steuerungskanal zur SPS, separater, verlusttoleranter Datenkanal zum MES/Analytics).

Hauptteil

1) Lastenheft statt Bauchgefühl: Was „deterministisch“ wirklich heißt
Bevor irgendetwas gebaut wird, muss das Latenzbudget als Vertrag stehen. Typisch in diskreter Fertigung:

  • Ereignis: Kamera-Trigger vom Sensor oder SPS-Ausgang.

  • Budget: z. B. 20 ms vom Trigger bis zum Eingang in der SPS, inklusive Netzwerk.

  • Jittergrenze: 99.9% der Zyklen innerhalb des Budgets; darüber: definiertes Fallback-Verhalten.

  • Ergebnisformat: minimal steuerungsrelevant (OK/NOK, optional Pose, optional ROI-Index).

  • Backpressure-Regel: Niemals Ergebnisse puffern, die einen späteren Trigger „überholen“ könnten. Alte Ergebnisse verwerfen, wenn der nächste Trigger kommt und die Entscheidung nicht rechtzeitig da ist.

  • Störfall-Politik: Wenn die KI nicht rechtzeitig liefert, publiziere explizit „TIMEOUT“; SPS behandelt TIMEOUT deterministisch (z. B. Ausschleusen oder Bypass je nach Sicherheitskonzept).

Diese Punkte sind keine „nice to have“, sondern akzeptanzkritisch. Ohne harte Deadlines und klares Störfallverhalten werden Sie in der Linie immer wieder Ghost-Fehler sehen.

2) Anti-Pattern aus der Praxis
Wir sehen regelmäßig folgende Muster, die in Produktion scheitern:

  • REST/gRPC zur SPS-Brücke: HTTP/gRPC sind gut für Konfiguration, schlecht für Zykluskommunikation mit harten Deadlines. TCP-Recovery, Head-of-line-Blocking und Garbage Collection auf dem Edge-PC erzeugen Jitter-Spitzen.

  • OPC UA Client/Server zum Variablen-Pollen: Polling führt zu Phasenverschiebungen zwischen Trigger und Lesezyklus. Unter Last verpasst die SPS das Zeitfenster oder liest ein „altes“ Ergebnis.

  • Datenbank als „Bus“: Ergebnis in DB schreiben, SPS liest es aus. Das ist eine Einladung für Latenzspitzen, Transaktions-Contention und „stale reads“.

  • Unbounded Queues: Frames und Inferenz-Ergebnisse werden gepuffert, „damit nichts verloren geht“. Ergebnis: Der Auswerter trifft eine Entscheidung zu Frame n, während der physische Teil n+2 längst am Auswerfer ist.

  • Ein-Kanal-Design: Dasselbe Ergebnisobjekt wird sowohl zur SPS als auch zur Historisierung gestreamt. Sobald die Historisierung klemmt (Netzwerk, Storage), blockiert der Steuerungspfad.

3) Zielarchitektur: On-Prem Pub/Sub plus harter Steuerungskanal
Wir empfehlen ein zweigeteiltes Design:

  • Fast Path (Steuerung): Deterministische, verbindungslose Publisher→Subscriber-Kommunikation im lokalen Netz (z. B. UDP-basierter Pub/Sub-Mechanismus). Die SPS oder ein Gateway ab SPS-Seite abonniert die „Entscheidung“-Themen. Keine Blockaden, keine Request/Response, kleine fixe Nachrichtenstrukturen.

  • Slow Path (Daten): Asynchroner, verlusttoleranter Stream aller Metadaten (Bilder, Heatmaps, Metriken) an MES/Analytics. Das kann ein on-prem Broker sein, ein Fileshare mit „append-only“-Ordnern oder ein lokaler Event-Stream. Der Fast Path darf niemals auf den Slow Path warten.

Wesentliche Bausteine auf dem Edge-Rechner:

  • Trigger-Listener: Konsumiert SPS-Trigger (z. B. digitaler Eingang via IO-Karte, oder logische Events via Feldbus).

  • Frame Grabber: Greift den Frame synchron zum Trigger. Zeitstempel via monotonic clock, PTP-synchron falls vorhanden.

  • Inferenz-Worker: Pinning auf dedizierte Kerne, feste Batchgröße 1, deterministische Pre-/Postprocessing-Pfade, keine unbounded Allocations im Hotpath.

  • Deadline Manager: Verfolgt pro Trigger-ID das verbleibende Budget. Wenn Timer abläuft, publiziert er TIMEOUT mit der Trigger-ID. Kommt später doch ein Ergebnis, wird es verworfen oder nur im Slow Path abgelegt – niemals noch an die SPS gesendet.

  • Result Publisher: Sendet eine kompakte, fixe Struktur auf den Steuerungs-Topic.

Wesentliche Bausteine an der SPS-Seite:

  • Subscriber/Adapter: Entgegennahme der Ergebnisstruktur, Plausibilitätsprüfung (Sequenz, Zeit), Mapping auf Bits/Variablen. Kein aktives Polling.

  • Watchdog/Heartbeat: Erkennt Publisher-Ausfall. Definiertes Failover (z. B. sofortiger Bypass oder sicheres Ausschleusen).

  • Entkopplung zur Aktorik: Die Entscheidung wird genau einem physikalischen Teil zugeordnet (Konzept der „Transportverzugsstrecke“ berücksichtigen).

4) Nachrichtenformat: Klein, konstant, prüfbar
Die Steuerung braucht nicht das Bild, sondern eine Entscheidung. Bewährt hat sich:

  • Header

  • version: uint8

  • station_id: uint16

  • seq_no: uint32 (fortlaufend, bei Neustart reset)

  • trigger_ts: uint64 (ns seit boot, monotonic)

  • compute_ts: uint64 (ns, Zeitpunkt der Entscheidung)

  • Payload

  • verdict: enum {OK, NOK, TIMEOUT, SENSOR_ERROR}

  • confidence: uint16 (0..1000 = 0..100.0%)

  • roi_count: uint8 (max N, z. B. 4)

  • rois[N]: je roi {x,y,w,h: uint16 oder uint32, je nach Skalierung}

  • error_code: uint16 (0 falls kein Fehler)

  • Footer

  • crc32: uint32

Eigenschaften:

  • Fixe Maximalgröße (leichte SPS-Deserialisierung).

  • Prüfbarkeit (CRC), Sequenzprüfung gegen Verlust/Verwechslung.

  • TIMEOUT ist ein normaler, gültiger Zustand – kein „still silent fail“.

5) Zeit und Synchronisation: Ereigniszeit schlägt Systemzeit
Entscheidend ist die Korrelation von Trigger und Entscheidung:

  • Nutze eine monotone Uhr für trigger_ts und compute_ts – vermeide wall-clock in der Steuerungskette.

  • Optional PTP im Maschinen-Netz, wenn mehrere Kameras/Stationen korreliert werden müssen. Wenn nicht verfügbar, reicht eine monotone Prozesszeit, solange alles auf demselben Knoten konsistent ist.

  • In der SPS verknüpfe die Entscheidung mit der physischen Teileposition anhand der bekannten Transportverzögerung (z. B. n Takte bis zum Auswurf).