6) Backpressure: Frames verwerfen ist richtig
Ein verbreiteter Reflex ist: „Wir dürfen keine Frames verlieren!“ In der Steuerungskette ist das falsch. Regeln:

  • Pro Trigger genau eine Entscheidung an die SPS.

  • Kommt die Entscheidung nicht innerhalb des Budgets: TIMEOUT senden und den verspäteten Output verwerfen (nur Slow Path für Analyse).

  • Wenn die Linie beschleunigt und Trigger schneller eintreffen, muss die KI-Anwendung früh und bewusst degradieren: geringere Auflösung, weniger ROIs, vereinfachte Heuristiken – aber deterministische Deadline einhalten.

  • Puffer sind begrenzt dimensioniert (bounded). Jede Komponente hat klare Obergrenzen, und Überläufe werden zählen und melden.

7) Scheduling und Betriebssystem-Details: Jitter dort bekämpfen, wo er entsteht

  • CPU-Isolierung: Pinne Hotpath-Threads (Grabber, Inferenz, Publisher) auf isolierte Kerne. Management-Threads auf andere Kerne.

  • Speichermanagement: Warmup, Preallocation, keine „new“/„free“ im Hotpath, keine nichtdeterministischen Logger im Hotpath.

  • GPU: Deaktiviere Autoboost, fixiere Power- und Clocks, sichere thermisches Budget. Eine thermisch drosselnde GPU ist ein Jitter-Generator.

  • Netzwerk: Dediziertes VLAN für Steuerungsverkehr, keine Spanning-Tree-Neukonvergenzen im Taktbetrieb, Jumbo Frames nur, wenn durchgängig konfiguriert.

  • Prozesse: Ein Prozess pro Station statt „Megaservice“, um Ausfälle zu kapseln. Supervision mit lokalem Watchdog, nicht via Cloud.

8) Pub/Sub konkret integrieren
Ob Sie OPC UA Pub/Sub, einen UDP-Multicast auf einem lokalen Topic, oder einen on-prem Broker mit QoS-Profilen nutzen – entscheidend sind die Eigenschaften:

  • Kein Request/Response im Hotpath.

  • Best-effort Datagramme mit Sequenz und CRC – die SPS erkennt Verluste, aber blockiert nicht.

  • Feste Zykluszeit für Publishing (z. B. „publish on decision or timeout, latest by T“) – nicht „as soon as possible“.

  • Wenn Ihre SPS kein Pub/Sub kann, setzen Sie einen dünnen Gateway auf einem Industrie-PC ein, der Pub/Sub entgegennimmt und SPS-seitig über den nativen Feldbus (Profinet, EtherNet/IP, etc.) ein schmales, binäres Telegramm schreibt. Wichtig: Gateway ist zustandsarm und deterministisch, kein Business-Logik-Dump.

9) Sicherheits- und Souveränitätsprinzipien ohne Overhead

  • On-Prem by design: Keine ausgehenden Cloud-Abhängigkeiten im Steuerungspfad. Analytik kann offline synchronisieren – niemals „KI-Entscheidung via Internet“.

  • Netzsegmentierung: Steuerungsnetz strikt von IT-Netz trennen. Only one-way data diode Richtung IT ist ideal für den Slow Path, wenn praktikabel.

  • Least privilege: Der Publisher kann nur auf seinen Topic senden; die SPS liest nur ihren Topic.

  • Updates: Blue/Green für die Inferenz-Pipeline mit deterministischer Umschaltung zwischen Modellversionen. Nie „Hot-Swap“ im laufenden Takt ohne Freigabezustand.

  • Auditierbarkeit: Jede Entscheidung wird mit Hash/Witness im lokalen Journal festgehalten. Keine personenbezogenen Daten, keine unnötigen Bildspeicher im Fast Path.

10) Teststrategie: „Proof by histogram“, nicht durch Bauchgefühl

  • Closed-loop HIL: SPS-Simulation oder echte SPS, Trigger generieren im Zieltakt und worst-case Bursts.

  • Fault injection: CPU-Lastspitzen, Netzpaketverluste, GPU-Drosselung emulieren. Erwartung: TIMEOUT-Anteil steigt, aber kein Fehltrigger in der SPS.

  • Metriken: Für jede Komponente Verteilung (P50/P90/P99.9) der Latenz. Akzeptanzziel entlang des Vertrages.

  • Replays: Aufzeichnen realer Produktionsdaten (ohne Personenbezug) und deterministisch wiedergeben – Regressionstests bei jedem Modell- oder Pipeline-Update.

  • Line clearance: Tests beachten, dass Puffer leer werden müssen, bevor wieder in Produktion gegangen wird.

11) Migration von Client/Server zu Pub/Sub ohne Stillstand

  • Parallelbetrieb: Bestehenden C/S-Pfad beibehalten, Pub/Sub zusätzlich einspeisen. SPS-seitig zwei Kanäle empfangen, aber nur einer aktiv.

  • Schattenmodus: Pub/Sub-Entscheidungen im Schatten gegen C/S-Entscheidungen vergleichen; nur Metriken in das MES schreiben.

  • Umschaltung: Definierter Zeitpunkt (z. B. Schichtwechsel) mit Freigabeprozedur. Rollback-Pfad vorhanden.

  • Bereinigung: Nach Stabilisierung C/S abschalten, Telemetrie und Slow Path entkoppeln.

12) Beobachtbarkeit und Governance: Ohne Telemetrie bleibt es Zufall
Eine deterministische Architektur ohne durchgängige Observability ist in der Praxis nicht haltbar. Minimale Anforderungen:

  • End-to-end Trace-ID pro Trigger von SPS-Event bis SPS-Eingang Entscheidung.

  • Zeitbudget-Metriken auf jeder Stufe, live visualisiert in der Linie.

  • Ereignisjournal mit Modellsignatur, Konfiguration, Software-Build – reproduzierbar in der Testumgebung.

  • Governance: Wer hat wann welches Modell freigegeben, unter welchen Testmetriken?

Wir betreiben das über einen lokalen Observability- und Governance-Stack (z. B. mit unserem Alpi-M), strikt on-prem, DSGVO-konform, ohne US-Cloud-Abhängigkeiten. Ziel ist kein „Nice Dashboard“, sondern ein Werkzeug, um Jitterursachen zu isolieren und Änderungen kontrolliert auszurollen. (→ alpitype.de/leistungen/)

Praxisbeispiele aus Fertigung und Instandhaltung

  • Visuelle Endkontrolle in der Montage (Takt 600 ms, Deadline 30 ms): Migration von REST→Pub/Sub senkte den 99.9%-Jitter von 18 ms auf 4 ms. TIMEOUTs wurden als normaler, seltener Zustand behandelt; SPS-Logik wurde explizit erweitert.

  • Textilfertigung, Fadenüberwachung (kontinuierlicher Prozess): Kein diskreter Trigger, sondern Schwellwert-getriggerte „Events“. Pub/Sub half, Peaks von Event-Bursts deterministisch zu drosseln: maximal N Entscheidungen pro Sekunde an die SPS, Rest nur an den Slow Path. Die SPS verhält sich dann zustandsbasiert („Störung aktiv“), nicht eventbasiert.

  • Bahn-Fahrzeugprüfung in der Werkstatt: Mehrere Kameras an einer Linie; Korrelation von Kameras via monotone Zeit statt unsauberer Systemzeit brachte die Wiederholbarkeit. Ergebnisse wurden in ein festes, kleines Telegramm pro Achse komprimiert, SPS-Auswertung deterministisch.

Fazit
Wer KI in die Steuerungskette bringt, muss sich wie ein Steuerungsingenieur verhalten: harte Deadlines, deterministische Pfade, klar definierte Störfälle. Pub/Sub mit kleinen, festen Telegrammen schlägt REST und klassisches Client/Server, weil es Jitterquellen eliminiert und Backpressure kontrolliert. On-Prem ist hier kein Ideologiestreit, sondern eine physikalische Notwendigkeit: Latenz, Determinismus und Souveränität verlangen lokale Kontrolle. Alles, was nicht für den Aktuator nötig ist, gehört in den separaten, verlusttoleranten Datenkanal. Wer so baut, hat Linien, die nicht „manchmal spinnen“, sondern reproduzierbar laufen – und Modelle, die unter Governance- und Observability-Kontrolle stehen, statt im Blindflug zu operieren.

FAQ