Zero-Copy-Bildverarbeitung am Edge: 30‑ms‑Inline‑Inspektion ohne Jitter – Architektur, die in der Produktion wirklich läuft

Wer in der Fertigung Inline-Inspektion mit KI betreiben will, scheitert selten am Modell und fast immer an der Daten- und Latenz-Architektur. Das echte Problem: deterministische Latenz unter Taktzeit, kein Jitter, kein Backlog – und das dauerhaft, nicht nur im PoC. Dieser Artikel beschreibt eine Zero‑Copy-Edge-Architektur für visuelle Qualitätskontrolle, die 30‑ms‑Budgets zuverlässig einhält, ohne Cloud, ohne CPU-Kopierorgien und ohne exotische Hardware.

Problemrahmen und Zielwerte

  • Kontext: Inline-Inspektion direkt im SPS-Takt (z. B. 20–80 ms Takt).
  • Ziel: deterministische End‑zu‑End‑Latenz der Bildverarbeitung (Sensor → Entscheidung → SPS‑Signal) < 30 ms, P99 statt nur “Durchschnitt”.
  • Restriktionen: On‑prem, datensouverän (keine Bilddaten in die Cloud), Air‑Gapped-Option, beherrschte Updates ohne Stillstand, Auditierbarkeit.
  • Typische Stolpersteine: unnötige Speicher-Kopien (CPU↔GPU), ungebundene Queues (heimlicher Bufferbloat), Python im Hot‑Path, nicht deterministische Scheduler, Timing-Drift zwischen Kamera und SPS.

Kernprinzipien der Architektur

  • Zero‑Copy durchgängig: Ein Frame wird genau einmal per DMA übernommen und bleibt bis zur Inferenz auf dem Gerät (GPU/NPU), ohne zurück zur CPU zu springen.
  • Vorallokation und Fixed‑Size: Keine Heap‑Allokationen zur Laufzeit, fester Ring‑Puffer, feste Tensor‑Shapes und Pre‑/Post‑Processing-Operatoren ohne dynamische Neuzuweisungen.
  • Kein Python im Hot‑Path: Produktionspfad strikt in C/C++ oder Rust. Python ok für Prototyping, aber nicht in der Linie.
  • Zeitbasierte Integrität: PTP‑Synchronisation (z. B. IEEE‑1588) der Zeitbasen von Kamera, Edge‑Host und SPS für reproduzierbare Messfenster.
  • Harte Backpressure und deterministisches Dropping: Wenn der Takt schneller ist als die Inferenz, werden Frames definiert und nachvollziehbar verworfen – kein verstecktes Aufstauen.
  • Explizites Handshake zur SPS: Ready/Busy/OK/NOK als Signalisierung, optional Frame‑IDs für Nachvollziehbarkeit.
  • Messbarkeit: Latenzhistogramme P50/P90/P99 mit GPIO‑Zeitstempeln, nicht nur Log‑Timestamps. Entscheidungen ohne Metriken sind unhaltbar.

Referenzarchitektur: Komponenten und Datenfluss

Hardware/OS-Ebene

  • Kamera: Industrial GigE‑Vision oder MIPI‑CSI/CoaXPress. Konfiguration: deterministisches Triggering (extern oder via PPS), feste Belichtungszeit.
  • Edge-Host:
  • Variante A: x86 + dGPU (z. B. CUDA-fähig) für hohe Performance.
  • Variante B: Embedded SoC (z. B. mit integrierter GPU/NPU) für kompaktere Bauform.
  • Netzwerk/Bus: NIC mit DMA‑fähigem Treiber, aktiviertem PTP für Sync.
  • OS/Kernel: Low‑Latency- oder RT‑Kernel optional; CPU‑Frequenzskalierung fixiert; IRQ‑Affinitäten und CPU‑Isolation für deterministische Scheduling-Bedingungen.

Datenpfad (Zero‑Copy Pipeline)

  • Capture:
  • V4L2/GigE-Treiber mit DMA in vorallokierte Buffers (DMABUF/EGLImage o. ä.).
  • Kein userspace‑memcpy. mmap der Buffer lediglich für Metadaten, nicht für Pixel.
  • Pre‑Processing (GPU):
  • Farbkonvertierung, Crop, Resize, Normalisierung: GPU‑Kernels, die direkt auf DMABUF/Surface arbeiten.
  • Linsenverzerrungskorrektur und Homographie optional direkt in GPU.
  • Inferenz:
  • Engine in FP16/INT8 (fest kalibriert), statische Tensordimensionen, TensorRT/ONNX Runtime mit GPU Execution Provider – ohne Host‑Rücksprung.
  • Modelldateien vorab geladen, warm‑up durchlaufen, Streams persistent.
  • Post‑Processing (GPU):
  • NMS, Schwellenwerte, Morphologie: GPU‑seitig, Ergebnisaggregation so spät wie möglich.
  • CPU‑Transfer nur für minimalen Ergebnisdatensatz (z. B. Klassen, Scores, Bounding Boxes).
  • Entscheidung/Actuation:
  • Ergebnis in deterministischem Format an SPS: digitaler IO (schnell aber simpel) oder Feldbus‑Mapping.
  • Optional: Publish minimaler Telemetrie (kein Bild) in On‑Prem‑Eventbus zur Nachvollziehbarkeit.

Prozess- und Ressourcensteuerung

  • Core‑Pinning:
  • Erfassungs-Thread, GPU‑Dispatcher und IO‑Signalisierung jeweils auf dedizierten Kernen.
  • Affinitäten auch für IRQs der NIC/Kamera sauber getrennt von HMI oder Logging.
  • Speicher:
  • Pre‑Allokation eines Ring‑Buffers (z. B. 3–5 Frames, je nach Takt).
  • mlockall, um Paging zu verhindern; Hugepages, wo sinnvoll für Host↔Device‑Staging (nur Metadaten).
  • Prioritäten:
  • Echtzeit-Prioritäten für Erfassungs- und Signalpfad; HMI, Persistenz und Diagnose als Best‑Effort.
  • Backpressure:
  • Wenn Ring voll: definierte Drop‑Policy (z. B. “drop newest” oder “drop oldest”), abhängig vom Prozess.
  • SPS‑Handshake: “busy” solange der Pipeline‑Slot für das aktuelle Werkstück belegt ist.

Zeit und Synchronisation

  • PTP‑Basis:
  • Kamera‑Timestamps und SPS‑Zyklen auf gemeinsame Zeitbasis ziehen.
  • Entscheidungen referenzieren Frame‑ID und Timestamp; SPS‑Programm ordnet Entscheidung deterministisch dem Werkstück zu.
  • GPIO-Messung:
  • Toggle‑Pins an “Frame‑eingetroffen”, “Infer‑start”, “Infer‑end”, “Signal out”.
  • Externe Oszilloskop‑Messung zur Verifikation der P99‑Latenzen.

Fehlertoleranz und Degradation

  • Graceful Degradation:
  • Zeitbudget überschritten? Wechsel auf vereinfachtes Modell oder ROI‑Downsampling.
  • Optional: heuristische Fallback‑Checks (Kanten/Flächen), wenn KI nicht rechtzeitig liefert.
  • Watchdogs:
  • Heartbeat‑Signale zur SPS; bei Ausfall Umschaltung auf Bypass‑Strategie (mechanischer Sortierer in “safe”).
  • Persistenz:
  • Kurzzeit‑Ringpuffer der letzten N Sekunden an reduzierter Auflösung – nur On‑Prem – für Root‑Cause‑Analysen.

Konkrete Zeitscheiben (Beispielwerte als Orientierung)

  • Capture DMA + Sync: 1–3 ms
  • GPU‑Pre‑Processing (resize/normalize): 1–3 ms
  • Inferenz (INT8, kleines bis mittleres CNN/Transformer‑Backbone): 5–15 ms
  • GPU‑Postprocessing (NMS/Morph): 1–3 ms
  • CPU‑Ergebnisaufbereitung + SPS‑Signal: 0.5–2 ms

Summe: typischerweise 10–25 ms, mit Reserven für Jitter. Entscheidend ist, P99 im Budget zu halten, nicht nur Mittelwerte.

Integrationsmuster zur SPS

  • Digital‑IO:
  • Vorteil: Sehr niedrige Latenz, simpel, robust.
  • Nachteil: Nur binäre Signale; für Traceability Frame‑ID muss separat korreliert werden.
  • Feldbus‑Mapping (z. B. Profinet/Modbus‑Register):
  • Vorteil: Mehr Informationen (OK/NOK, Score, ID) in einem Takt; saubere Zuordnung zu Werkstück.
  • Nachteil: Sorgfältiges Timing‑Design nötig, damit Zyklus sicher eingehalten wird.
  • Handshake‑Zustände:
  • READY (Edge → SPS): System bereit, Frame‑Slot frei.
  • TRIGGER/ACQUIRE (SPS → Edge): Erfassung startet oder wurde getriggert.
  • BUSY (Edge → SPS): Inferenz läuft; keine neuen Frames akzeptieren.
  • RESULT (Edge → SPS): OK/NOK + ID; BUSY fällt.
  • ACK (SPS → Edge): Ergebnis übernommen; Slot freigegeben.

Warum Cloud hier nichts verloren hat