H1: Deterministische Inline-Bildprüfung an der SPS: Wie man asynchrone KI-Inferenz in den Feldbustakt zwingt

Einstieg
Das Kernproblem der visuellen Inline-Inspektion ist nicht die Modellgenauigkeit, sondern der Takt: Eine SPS lebt in einem zyklischen, deterministischen Weltbild. Ein KI-Modell auf GPU nicht. PoCs funktionieren am Labortisch, scheitern aber an der Linie, weil sie Jitter ins Taktgefüge injizieren. Dieser Artikel beschreibt konkret, wie man eine asynchrone KI-Pipeline so architekturiert, dass sie sich einer SPS-Logik deterministisch unterordnet – inklusive Handshake-Signalen, Zeitbudgetierung, Pufferung, Zeitstempeln, Edge-Hardware und Failover-Pfaden.

1) Anforderungen sauber schneiden: Zeit, Qualität, Sicherheit
Bevor Architektur: drei harte Entscheidungen.

  • Latenzbudget und Jittergrenzen: Wie viele Millisekunden zwischen „Teilstück ist im Prüfbereich“ und „SPS braucht IO-Entscheidungsbit“ sind maximal zulässig? Entscheidend ist nicht nur die mittlere Latenz, sondern die 99,9-Perzentil-Jittergrenze. Definieren Sie sie explizit.
  • Verluststrategie: Was passiert, wenn ein Frame oder ein Ergebnis zu spät kommt? Möglichkeiten: (a) Teile ausschleusen, (b) Linie kurz anhalten, (c) bestmögliche Heuristik statt ML-Ergebnis, (d) Prozessfenster enger stellen. Ohne definierte Degradationsstrategie bleibt es Glücksspiel.
  • Rückverfolgbarkeit: Muss jede Entscheidung mit einem synchronisierten Zeitstempel und einer Teile-ID nachvollziehbar sein? Wenn ja, planen Sie harte Zeitstempel (Hardware/Driver-Level) und korrelierbare IDs vom Sensor bis zur SPS.

2) Architekturprinzip: SPS taktet, KI folgt
Der Grundsatz: Die SPS steuert den Takt und gibt das Inspektionsfenster vor. Die KI verarbeitet in diesem Fenster und liefert ein deterministisches, valides Ergebnis – oder ein definiertes Timeout-Signal.

Empfohlenes Signalmuster (vereinfachtes Vier-Phasen-Handshaking):

  • SPS setzt „Inspect_Req“ (Digital-IO oder Feldbus-Flag) synchron zum Bewegungs-/Aufnahmefenster.
  • Vision-PC löst hardwaregetriggert die Kamera aus (oder bestätigt, dass ein Frame zu diesem Request verarbeitet wird) und setzt „Inspect_Ack“.
  • Nach Inferenz setzt Vision „Inspect_Valid“ und schreibt „Inspect_Result“ (OK/NOK/Klasse).
  • SPS liest „Inspect_Valid“ in ihrem Zyklus und quittiert mit „Inspect_Clear“. Vision löscht Valid/Result und ist bereit für den nächsten Takt.

Wichtig:

  • Zeitstempel (capture_ts, inference_start_ts, result_ts) werden im Vision-System erfasst und für Traceability persistiert.

  • „Inspect_Valid“ altert. Wenn es nicht rechtzeitig kommt, setzt Vision explizit „Inspect_Timeout“. Die SPS darf nie aus stillem „Nicht-Valid“ eine positive Aussage ableiten.

3) Datenpfad: Von Trigger über Frame zu deterministischem Ergebnis
Hardwarepfad

  • Triggerung: Bevorzugt Hardware-Trigger von der SPS (optisch isolierte Digitaleingänge an Kamera/Framegrabber). So vermeiden Sie Scheduling-Jitter von Software-Triggern.

  • Kamera-Interface: Für harte Latenzpfade sind CoaXPress/Camera Link HS oder deterministisches GigE-Vision mit PTP-Zeitsynchronisierung praxiserprobt. USB3 ist in der Fertigung wegen Host-Jitter und Kabel-/EMV-Themen oft eine schlechte Wahl.

  • Beleuchtung: Strobe mit fester Belichtungszeit, synchronisiert zum Trigger. Konstante Leuchtdichte vermeidet algorithmische Latenzschwankungen durch automatische Belichtungsanpassungen.

Softwarepfad

  • Capture: DMA in vorallokierte, gepinnte Host-Puffer (keine Allokationen im Hot Path). Wenn verfügbar, Zero-Copy/GPUDirect vom Framegrabber in die GPU.

  • Preprocessing: Farbkonvertierung, Zuschneiden, Normalisierung auf GPU (CUDA/OpenCL) oder via GStreamer mit geeigneten GPU-Plugins. CPU-Preprocessing erzeugt oft unnötigen Jitter.

  • Inferenz: Engine vorab kompiliert (keine JIT im Betrieb), Warm-Up beim Start, fest eingestellte Batchgröße = 1 für minimale Latenz. Quantisierte Modelle (INT8/FP16) nutzen, wenn Qualitätsbudget es erlaubt.

  • Postprocessing: NMS, Schwellen, Geometriekonversion ebenfalls auf GPU, Ergebnisse als kleine Strukturen an CPU.

  • IO/Handshake: Ergebnisbits über schnelle Digitalschnittstelle oder zyklisch via Feldbus. Ergebnis wird erst mit Valid markiert, wenn komplett geschrieben.

Pufferung

  • Lock-free Ringpuffer für Frames und Inferenzjobs. Jeder „Inspect_Req“ erzeugt ein „Inspection Ticket“ mit (ticket_id, expected_pose_window, deadline_ts). Nur Tickets mit rechtzeitigem Frame-Eingang werden zur Inferenz eingeplant – alle anderen gehen in Timeout-Path.

  • Backpressure: Wenn die Inferenz länger als das Deadline-Budget dauert, setzt die Pipeline frühzeitig „Timeout“ und verwirft weitere Tickets, statt Latenz aufzustauen.

4) Zeit-Synchronisation und Identität der Teile

  • PTP-basierte Zeitsynchronisation (IEEE 1588) zwischen Kamera, Vision-PC, ggf. SPS-Gateway. Ziel: sub-millisekundengenaue Korrelation. Klassisches NTP ist für strikte Korrelation oft zu grob.

  • Teile-Tracking: Wenn mehrere Teile parallel im Sichtfeld/auf dem Transfer sind, braucht es eine „ID-Übernahme“ (z. B. von einer vorgelagerten Lichtschranke/Encoder-Position). Die SPS übergibt die erwartete Teile-ID im Inspect_Req oder sie wird im Vision-System aus Encoder-/Positionsdaten plus Triggerindex berechnet. Ohne sauberes Mapping drohen Zuordnungsfehler („falsches Teil als OK markiert“).

5) Determinismus absichern: Betriebssystem, GPU, Speicher
Betriebssystem

  • Linux mit PREEMPT_RT oder industrielles RTOS, CPU-Kerne für Vision-Threads isolieren (isolcpus), CPU-Affinität setzen, C-States/Turbo abschalten, tickless Kernel/Low-Latency-Optimierungen aktivieren.

  • Threads: SCHED_FIFO für zeitkritische Threads (Capture, Inferenz-Scheduler, IO), Prioritäten sauber staffeln (Capture > IO > Inferenz-Worker > Logging).

  • Interrupt-Affinität: NIC-/Framegrabber-Interrupts auf dedizierte Kerne pinnen.

GPU

  • Fixe Performance-States, keine Auto-Clock-Skalierung. Thermische Reserven einplanen (Gehäuse, konstantes Lüfterprofil), damit es unter Last nicht drosselt.

  • Engine-Preload/Warmup: Erste Inferenz-Aufrufe sind oft langsamer; den Pipeline-Start außerhalb des Produktionsfensters durchführen.

  • Ressourcenabschottung: Bei Mehrkamera-Setups Streams und CUDA-Kontexte so planen, dass keine unkontrollierten Interferenzen entstehen. Wenn verfügbar, Hardware-Unterteilung/Partitionierung verwenden; sonst harte Quoten/Separation über Prozessgrenzen.

Speicher/IO

  • Keine Heap-Allokationen im Hot-Path. Vorab-Pools für Bilder/Workitems.

  • Pinned Memory und Page-Lock für Host↔GPU Transfers.

  • Zero-Copy Wege nutzen, wo verfügbar. Sonst Transfers batched, aber ohne zusätzliche Latenz – Batchgröße 1 für Low-Latency.