Inline-Bildverarbeitung unter 120 ms: Edge-Architektur, SPS-Handshakes und Fail-Safe-Design

Problem
Viele Pilotprojekte für visuelle Inline-Inspektion scheitern nicht am Modell, sondern an der Produktionstauglichkeit: Der Takt ist hart (80–200 ms), die SPS erwartet deterministische Signale, Netzwerkjitter frisst Reserven, und im Fehlerfall darf die Anlage nicht stehen. Cloud-Inferenz ist unter diesen Randbedingungen de facto ausgeschlossen. Dieser Artikel beschreibt eine praxiserprobte Edge-Architektur, die unter 120 ms stabil arbeitet, mit SPS/Roboter steuerungssicher spricht und im Fehlerfall kontrolliert ausweichen kann.

Warum deterministisch statt „schnell im Mittel“
In Produktionsumgebungen zählen P95/P99-Latenzen, nicht der Mittelwert. Ein einziges P99-Ausreißerpaket, das den Handshake mit der SPS verfehlt, kann Material verschieben, Ausschuss erzeugen oder, schlimmer, zu einem Not-Aus führen. Entsprechend wird das Budget top-down geplant und gegen worst-case gemessen.

Ein typisches Latenzbudget (Beispielwerte für Inline-Inspektion bei 1 Gbps Kamera, Einzelschuss):

  • Belichtung und Readout: 4–15 ms (abhängig von Sensor/ROI/Strobe)

  • Bildtransfer und DMA in Host/GPU: 3–8 ms

  • Präprozessierung (Demosaic, Normalize, ROI): 2–6 ms

  • Inferenz: 12–35 ms (Modell, Auflösung, Quantisierung)

  • Postprozessierung (NMS, Geometrie, Klassifikationslogik): 2–6 ms

  • SPS-Handshakes (Bit-Setzen, Entprellen, Acknowledge): 1–4 ms

  • Sicherheitsreserve für Jitter: 10–20 ms

Summe: 34–94 ms vor Reserve; mit Reserve bleibt man unter 120 ms stabil, wenn die Architektur stimmt.

Sensorik und Timing: Hardware entscheidet die Software

  • Triggering: Keine „Free-Run“-Kamera mit Software-Timestamp. Der Trigger kommt aus der SPS oder aus dem Encoder (bei Förderband). Der Strobe wird hardwareseitig zum Sensor getimed, nicht aus der Software generiert. Belichtungsstart muss deterministisch sein.

  • Zeit-Synchronisation: PTP (IEEE 1588) mit Hardware-Timestamping auf NICs und Switches. Kameras mit PTP-Support oder deterministische Triggerleitungen. Prozessorzeit und Kamerazeit gehören in dieselbe Domäne, sonst stimmt das Root-Cause-Analyse-Log nie exakt.

  • Optik und Beleuchtung: Konstante, überdimensionierte Beleuchtung (Strobe), um die Belichtungszeit zu minimieren und Bewegungsunschärfe zu vermeiden; ROI statt Full-Frame lesen, wenn nur Teilbereiche relevant sind.

Frame-Akquise ohne Kopierorgien

  • Schnittstellen: CSI/SLVS-EC bietet die geringsten Latenzen auf Embedded-SoCs. Bei industriellen Distanzen: CoaXPress (CXP) mit Framegrabbern, die GPUDirect oder mindestens Zero-Copy in User-Space erlauben. USB3 ist eine Notlösung, wenn deterministische Latenz zählt; es funktioniert, aber Jitter ist höher.

  • Zero-Copy: GStreamer-Pipeline so bauen, dass Frames als DMABUF durchgereicht werden (nvarguscamerasrc/nvvideoconvert/nvstreammux auf Orin; v4l2 + CUDA-Interop auf x86). Ziel: Von Sensorpuffer direkt in GPU-Speicher (oder zumindest gepinnter Hostspeicher).

  • Threads und Prioritäten: Capture-Thread als SCHED_FIFO, eigene CPU-Core-Isolation (isolcpus), IRQ-Affinität der NIC auf dedizierte Cores, C-States drosseln. Der Hot-Path gehört in C++ (oder Rust), nicht in Python mit GIL.

Rechenplattform: x86+RTX oder Orin – die nüchterne Abwägung

  • x86 + RTX (PCIe-Framegrabber): Maximale Performance, breite Bibliotheken (TensorRT, cuDNN, OpenVINO optional). Vorteilhaft bei hohen Auflösungen und mehreren Kameras (>4).

  • Jetson Orin (NX/AGX): Kleiner Footprint, gute CSI-Integration, niedriger Latenzpfad mit NVMM und NVDLA. Ideal für 1–3 Kameras, wenn die Modelle quantisiert sind.

  • Industrietauglichkeit: Temperaturbereich, Vibrationsfestigkeit, M12/L-coded für Power over Ethernet, ESD-Schutz. Ein Technikraum-PC mit Desktop-RTX mag in der Pilotlinie funktionieren – im Feld scheitert er am Staubfilter.

Modellarchitektur und Quantisierung: Latenz ist ein Feature

  • Backbones: Leichte Architekturen (YOLOv6/8n-s, EfficientDet-D0/1, MobileNetV3-Head) mit gezielter ROI-Crop-Strategie schlagen oft „große“ Modelle im End-to-End-Latenz/KPI-Verhältnis. Für segmentationslastige Aufgaben: BiSeNet/DDRNet-Varianten statt schwerer DeepLab.

  • Quantisierung: INT8 mit guter Kalibrierung (repräsentative Batchs aus realer Produktion, inklusive Varianz in Beleuchtung/Material). Mix-Precision (INT8 Kernpfad, FP16 für empfindliche Layer) hält Qualität hoch. Ohne repräsentative Kalibrierdaten ist INT8 im Feld ein Risiko.

  • Post-Processing: NMS und Geometrieoperationen in GPU (TensorRT Plugins/CUDA-Kernel). CPU-basiertes NMS ist ein Latenzgrab.

  • Decision Rule: Nicht „Softmax > 0.5“. Die Schwelle leitet sich aus einer Fehlkostenmatrix ab (False Reject kostet Takt, False Accept kostet Ausschuss/Nacharbeit). Dynamische Schwellen je Produktvariante oder Produktionsfenster sind oft sinnvoll.

SPS-Integration: Profinet zuerst, OPC UA später

  • Protokollwahl: Für harte Echtzeit ist Profinet/EtherNet/IP als IO-Device die robuste Wahl. OPC UA Client/Server mit Polling ist für <20 ms deterministisch kaum tragfähig; OPC UA PubSub über TSN kann es sein, setzt aber durchgängig TSN-fähige Infrastruktur voraus.

  • Handshake-Zustände (bewährt als minimaler, robuster Satz):

  • Request: SPS setzt „PartReady“ + VariantID + Position/Encoder-Latch.

  • Busy: Vision setzt „Busy“, sobald Trigger akzeptiert und Bild akquiriert wird.

  • Result: Vision setzt „OK“ oder „NOK“ + optional Region/Code, sowie „ConfLow“ bei Grauzone.

  • Ack: SPS quittiert, dann Vision löscht Result/Busy.

  • Latching und Entprellen: Bits werden erst gelöscht, wenn die Gegenseite quittiert. Keine flackernden Zustände; jeder Übergang ist ein Ereignis mit eindeutiger Semantik.

  • Brownout- und Backpressure-Strategie: Wenn die Inferenzqueue > 1 anwächst, setzt Vision „NotReady“. SPS reduziert Takt oder überspringt Station. Niemals mehrere Requests ohne klaren Abschluss zulassen.

Safety und Fail-Safe: Trennen, was getrennt gehört

  • Safety-Funktionalität liegt in der Safety-SPS (PL e/ SIL je nach Anlage), nicht im Vision-System. Vision liefert Qualitätsentscheidung, keine sicherheitsrelevanten Stopps. Der einzige sicherheitsrelevante Pfad aus Vision ist der Health-/Watchdog-Status: Fällt der aus, reagiert die SPS mit einem definierten, sicheren Zustand (z. B. Auswurf auf „unsicher“).

  • Watchdog: Hardware-Watchdog im Edge-Rechner und Software-Watchdog in der Vision-App. Wenn der Inferenzzyklus eine Zeit T_max überschreitet, wird automatisch „ResultUnknown“ gesetzt und der Request geblockt, bis eine definierte Recovery-Sequenz durchlaufen ist.

  • Grauzone/Unsicherheit: Ein „ConfLow“-Signal zwingt nicht zum Anlagenstopp. Typische Praxis: Auswurf in manuelle Kontrolle oder Zweitstation mit langsamer, hochgenauer Prüfung (z. B. stationäre Mikrometer/Laserscanner).