KI an der SPS-Grenze: Deterministische Inline-Bildprüfung mit Edge-GPU – ohne den Takt zu brechen

Das Problem
Inline-Bildprüfung in verketteten Anlagen ist kein „KI-Spielplatz“ – sie hängt direkt am Takt. Wenn ein Modell einmal 20 ms länger braucht als geplant, steht das Band oder die Ausschleusweiche wirft Teile falsch aus. Die zentrale Frage ist deshalb nicht „Welches Modell ist am genauesten?“, sondern: „Wie baue ich eine KI-Inferenzkette, die unter harten Echtzeitbedingungen deterministisch entscheidet und sich sauber in die SPS-Welt einfügt – ohne Safety zu kompromittieren?“

Dieser Artikel beschreibt eine Architektur, die wir in der Fertigung mehrfach produktiv ausgerollt haben: Edge-GPU als Co-Prozessor neben der SPS, deterministische Video-/Sensor-Pipeline, klare Safety-Abgrenzung, feldbustaugliche Entscheidungen in <20 ms p99, plus asynchrone Datenpfade für Nachvollziehbarkeit und Re-Training. Keine Cloud im Taktkreis, kein „Vielleicht klappt’s“-Timing.

Kernanforderungen und Latenzbudget
Beispiel: 120 Teile/min ⇒ 500 ms pro Teil. Eine Weiche benötigt 120 ms Vorlauf. Sicherheitsabschläge für Puffer/Positionierung: 80 ms. Verbleibendes KI-Budget: 300 ms. Davon gehen ab:

  • Kamera-Trigger bis Bild im RAM: 4–8 ms (Hardware-Trigger, kurzer Shutter, DMA)

  • Preprocessing (Demosaic, Resize, Normalize): 2–5 ms

  • Inferenz (Batch=1): 8–25 ms (modellabhängig, INT8 bevorzugt)

  • Postprocessing (NMS, Geometrie, Entscheidung): 2–5 ms

  • PLC-Handshakes/Signalabgabe: 1–3 ms

Ziel: p99.9 Latenz <50 ms stabil, um Jitter-resilient zu sein und mehrere Kameras/Stationen zu kombinieren. Jede Architekturentscheidung zielt darauf, Varianz zu eliminieren, nicht nur Mittelwerte zu senken.

Systemarchitektur: KI als Co-Prozessor an der SPS-Grenze

  • Sensorik:

  • Industrielle Flächen-/Zeilenkameras, Hardware-Trigger über SPS oder Encoder.

  • Belichtung synchronisiert mit Strobe; Zeitstempel am Sensor oder NIC (PTP).

  • Edge-Inferenzbox:

  • Option A: x86 + RTX (maximale Leistung, aktive Kühlung, 24/7 geeignet bei richtiger Auslegung)

  • Option B: NVIDIA Jetson Orin NX/AGX (langlebige Embedded-Plattform, geringere Leistungsaufnahme)

  • Realtime-Linux (PREEMPT_RT), CPU-Isolation (isolcpus) für I/O-Threads und Inferenz, CPU-Affinität, Hugepages.

  • GPU-Stack: TensorRT (INT8/FP16), Zero-Copy (NVMM), GStreamer/DeepStream oder V4L2 + CUDA.

  • SPS-Anbindung (Safety-getrennt):

  • Hart-echtzeitfähiger Pfad: Digitale IO-Handshakes für Go/NoGo bei <1 ms Variabilität oder Feldbus (PROFINET RT/IRT, EtherCAT) mit kleinem Payload.

  • Soft-realtime/async Pfad: MQTT/Kafka für Bild-/Metadaten in Edge-Storage.

  • Netz- und Sicherheitszonen:

  • KI-Box in Maschinenzelle (IEC 62443-Zonierung), nur minimal notwendige Ports; Einweg-Export in Werk-DMZ für Training/Analytik.

Warum keine Cloud im Taktkreis?

  • Jitter und Unverfügbarkeit schlagen direkt in Fehlentscheide um. Ein p99.9 von 20 ms auf dem Edge ist höherwertig als ein p50 von 12 ms via Cloud mit p99 bei 120 ms.

  • Datenhoheit: Produktionsbilder sind oft IP-sensitiv (Werkzeuggeometrien, Prozessfenster). On-Prem-Speicherung vereinfacht DSGVO/Vertragswerk und reduziert Angriffsflächen.

Determinismus in der Bildpipeline

  • Triggerung:

  • Hardware-Trigger vom SPS-Ausgang oder Encoder (Line-Scan: deterministisch pro Wegstrecke).

  • PPS/Line-Sync zwischen Kamera, Strobe und Fördertechnik.

  • Zeitbasis:

  • PTP/IEEE 1588 in der Zelle; NIC mit Hardware-Timestamp (z. B. Intel i210). Falls Feldbus PTP nicht mitführt, lokale GMUhr auf KI-Box, Drift überwachen.

  • Frame-Ingest:

  • DMA von Kameraschnittstelle (GigE Vision über GVSP mit Jumbo Frames, oder CoaXPress/Camera Link, falls Bandbreite/Determinismus kritisch).

  • Zero-Copy über NVMM (Jetson) oder GPUDirect RDMA (x86+RTX, wenn suportet) zur Vermeidung von Kopierjitter.

  • Preprocessing:

  • Fixed-graph Implementierung (CUDA-kernel, TensorRT plugins), keine Python-Loops im Taktpfad.

  • Farbraum und Normalisierung identisch zur Trainingspipeline; Parameter als Versionsartefakte versionieren.

  • Inferenz:

  • Batch=1, persistent kernels, TensorRT Engine vorab gebaut (keine JIT beim Start des Produktionslaufs).

  • Quantisierung INT8 mit repräsentativer Kalibrierung; p99-Latenz prüfen, nicht nur Durchschnitt.

  • Postprocessing:

  • NMS/Geometrie in GPU oder fest zugewiesenem CPU-Kern, alloziertes Memory vor-heißen, keine Allokationen im Hot Path.

  • Garbage Collection:

  • Kein GC im Taktpfad. Wenn Python unvermeidlich, Prozesse trennen: Hot Path in C++/CUDA, Steuerung/Monitoring in Python separat.

Modellauswahl unter Latenzrestriktionen

  • Detektion:

  • YOLOv8/YOLOX-n/s, PP-YOLOE-s; export nach ONNX, dann INT8/FP16 TensorRT.

  • Für sehr kleine Defekte: höhere Inputauflösung + sparsames Backbone (CSPDarknet-Tiny mit sorgfältigem Augmenting).

  • Segmentierung:

  • Lightweight-UNet-Varianten, Fast-SCNN; Patch-basierte Verfahren bei hohen Auflösungen mit Tile-Overlap = 0 (oder minimal), sonst Randartefakte.

  • Klassifikation:

  • EfficientNet-Lite/MobileNetV3 für Gut/Schlecht auf ROI; ROI-Erzeugung deterministisch, keine dynamische Zuschneide-Logik zur Laufzeit.

Edge-Hardware: x86+RTX vs. Jetson Orin

  • x86+RTX:

  • + Höchste Rohleistung, GPUDirect, flexible NICs/Framegrabber.

  • – Höherer Energiebedarf, thermisch/EMV aufwändiger.

  • Empfohlen bei Multi-Kamera >4 Streams @ >120 FPS oder rechenintensiver Segmentierung.

  • Jetson Orin:

  • + Kompakt, robust, geringe Leistungsaufnahme, DeepStream/ISP integriert.

  • – Limitierte PCIe-Lanes, INT8 gut, aber enge Speicherbandbreite.

  • Empfohlen bei 1–3 Kameras, <60 FPS/Stream, knappem Schaltschrankplatz.

  • Gemeinsames:

  • NVMe für Ringpuffer, lüfter- und staubtaugliches Gehäuse, USV an der Zelle, Watchdog-HW.

SPS-Integration: drei geprüfte Muster
1) Digitale IO-Handshakes (hartdeterministisch)

  • Signale: part_present, decision_ready, pass/fail, heartbeat.

  • Vorteil: Keine Feldbus-Latenz/Jitter, Safety-getrennt. Ideal für Ausschleusklappen/Marker.

  • Nachteil: Nur Booleans/kleine Enums, erweiterte Metadaten nur über Nebenpfad.

2) Feldbus-Record (PROFINET/EtherCAT) für deterministische Datensätze

  • Zyklus 1–4 ms, kleine UDT mit Timestamp, Teil-ID, Klasse, Confidence, ROI-Index.

  • SPS-OB-Verarbeitung garantiert; bei Zyklusüberschreitung: definierter Timeout-Fallback.

3) Asynchroner Nebenpfad (MQTT/Kafka) für Bilder/Analytics

  • Out-of-band, kein Einfluss auf Takt.

  • Nutzbar für Traceability, Root Cause, Re-Training.

  • Write-ahead-Log lokal; Netzwerkunterbrechungen puffern.