Deterministische Latenz in KI-gestützter visueller Inspektion: SPS-Handshake, Pipelining und Fallbacks im Edge-Betrieb

Das Problem: In vielen Fertigungslinien muss eine visuelle Inspektion innerhalb fester Taktzeiten entscheiden, ob ein Teil gut oder schlecht ist. Von der Teileerkennung bzw. dem Trigger bis zum Signal an die SPS bleiben oft weniger als 50 ms – bei Bandgeschwindigkeiten um 1 m/s und wenigen Millimetern Abstand zwischen Entscheidungs- und Auswurfpunkt ist jeder Jitter kritisch. Klassische IT-Architekturfehler (Cloud-Inferenz, Message-Bus-in-der-Mitte, Python im Hot-Path) machen aus einem funktionierenden Modell ein nicht integrierbares System. Dieser Artikel beschreibt eine Architektur, die in der Praxis deterministische Latenz erreicht: Hardware-Trigger, Zero-Copy-Pipelines, thread-pinning, SPS-Handshake über deterministische IO und saubere Fallback-Strategien.

Warum „echtzeitfähig“ in der Computer-Vision meist an der Integration scheitert
Das KI-Modell ist selten der Flaschenhals. In vielen Proof-of-Concepts liegt die reine Inferenzzeit bei 5–20 ms. Die verlorene Zeit versteckt sich in:

  • Trigger-Jitter: Software-Trigger aus der SPS via Ethernet statt Hardware-Trigger am Sensor.

  • Kopier-Overhead: Mehrfaches Kopieren von Frames zwischen User-Space, GPU und Libraries.

  • Ungeeigneter Scheduler: Batch-orientierte GPU-Einstellungen, dynamische Frequenzen, OS-Jitter.

  • Kommunikationsdesign: OPC UA via Client/Server für harte Taktentscheidungen; asynchrone Queues ohne Backpressure.

  • Sicherheitslogik: Kein definierter Timeout-Pfad – die Anlage wartet, bis die Vision antwortet, und blockiert den Takt.

Eine deterministische Architektur zwingt diese Punkte in einen klaren, messbaren Pfad. Das ist kein „nice to have“, sondern die Voraussetzung, damit die Linie unter Last und bei Störungen stabil läuft.

Systemarchitektur: Von der Kamera bis zur SPS in unter 50 ms
Komponenten:

  • Kamera/Sensorik: Industriekamera mit Hardware-Trigger, Strobe-Ausgang für Beleuchtung.

  • Beleuchtung: Getriggert, kurze Pulsdauer, hohe Intensität, um kurze Belichtungszeiten zu ermöglichen.

  • Edge-Rechner: x86 mit dGPU oder Jetson/embedded x86. Realtime-taugliches Linux.

  • Inferenz-Engine: TensorRT, OpenVINO oder ONNX Runtime in explizitem Batch=1, ohne Auto-Batching.

  • SPS-Anbindung: Entweder diskrete IO (24V) für Handshake/Ergebnis oder echtzeitfähiger Feldbus. OPC UA ist Beobachtung/Diagnose, nicht Echtzeit-Entscheidungspfad.

  • Zeitsynchronisation: PTP (IEEE 1588) über Kamera, Edge-Box und SPS, wenn die Triggerung zeitkritisch mit Fördertechnik korrelieren muss.

Empfohlener Datenfluss:
1) Hardware-Trigger: Die SPS oder ein Lichtschranken-Sensor triggert direkt die Kamera (TTL/Optokoppler). Optional sendet die SPS gleichzeitig ein „Inspect_Request“-Signal über diskrete IO an die Edge-Box.
2) Aufnahme & Beleuchtung: Strobe synchron zur Belichtung. Belichtungszeit 0,2–2 ms je nach Optik/Beleuchtung – kurze Belichtungen minimieren Bewegungsunschärfe und damit Rechenaufwand in der Vorverarbeitung.
3) Zero-Copy-Transfer: Verwenden Sie Treiber/SDKs, die Direct Memory Access (DMA) und Zero-Copy in die Verarbeitungspipeline ermöglichen. Beispiel: GStreamer mit NVMM auf Jetson, oder GPUDirect/DMABUF auf x86/dGPU. Ziel: Kein „Mat“-Kopieren pro Stage.
4) Vorverarbeitung auf GPU: Resize, Farbkonvertierung, Normalisierung in einer GPU-Pipeline. Keine Python-Schleifen für Bildoperationen.
5) Inferenz: Engine optimiert und kalibriert auf Zielhardware. Fixierter Power/Clock-Mode, Batch=1, asynchrone CUDA-Streams, vorgewärmte Engine (kein On-the-fly Build).
6) Postprocessing: Minimal, ideal GPU-seitig (z. B. Top-K, NMS). Nur das Ergebnis (Good/Bad/Fehlercode) wandert in den CPU-Kontext.
7) Ergebnis an SPS: Über diskrete IO-Ergebnisbits oder deterministischen Feldbus. Fester Timeout-Pfad, falls kein Ergebnis rechtzeitig vorliegt.
8) Telemetrie asynchron: Latenzmessungen, P99-Statistiken, Beispielbilder für Audit – aber niemals im Entscheidungs-Pfad blockierend.

Triggering und Timing: Wo die ms verschwinden – und wie Sie sie zurückholen

  • Hardware-Trigger statt Software-Trigger: Software-Trigger via Netzwerk bringt Jitter im Bereich von 2–10 ms (Stack, Scheduling). Hardware-Trigger reduziert die Varianz deutlich, oft <0,5 ms Jitter bei geeigneter Hardware.

  • Kurze Belichtungszeiten sind Rechenzeit: Eine scharfe, gut belichtete Aufnahme reduziert den Bedarf an Motion-Compensation und Filterung. Investition in Beleuchtung zahlt direkt in Latenz ein.

  • PTP wenn die Mechanik es verlangt: Wenn Entscheidung und mechanische Aktoren (Ausblasdüse, Weiche) millimetergenau abgestimmt werden müssen, synchronisieren Sie Uhren (Kamera, Edge, SPS). So lässt sich die physische Position eines Teils aus einem Timestamp zuverlässig ableiten.

  • Vorwärmen und deterministische Betriebsmodi: Keine Inferenz aus dem „Kaltstart“. Engine vorwärmen, GPU/SoC in festen Performance-States betreiben (kein Auto-Boost). Bei Jetson: nvpmodel/jetson_clocks; bei x86/dGPU: Persistence Mode, Locked Clocks.

Pipeline-Design: „Newest frame wins“ statt Warteschlangen-Romantik
In einer getakteten Anlage ist die „richtigste“ Entscheidung zum falschen Zeitpunkt wertlos. Entsprechend:

  • Backpressure regeln: Der Bildpfad darf nie stauen. Sobald die Pipeline belegt ist, verwerfen Sie ältere Frames und verarbeiten stets den aktuellsten (sofern der Takt das zulässt). Bei hart getaktetem Trigger (ein Teil = ein Bild) muss die Engine garantieren, jeden Trigger innerhalb des Zeitfensters zu verarbeiten; ansonsten: synchronen Trigger auf die Vision-Ready-Flag der Edge-Box ziehen.

  • Doppel- oder Ringpuffer: Zwei bis drei Puffer reichen, wenn jede Stufe konstant-laufzeitorientiert ist. Große Queues sind nur Latenzspeicher.

  • Feste Bildformate: Vermeiden Sie dynamische Auflösungswechsel oder Farbraum-Konvertierungen zur Laufzeit. Ein Format, eine Pipeline.

  • Kein Python im Hot-Path: C++ oder Rust für Capture, Preprocess, Inferenz und IO. Python eignet sich für Orchestrierung und Monitoring, nicht für die 10-ms-Schleife.