12 ms bis zum Stopp: Eine Architektur für deterministische visuelle Inline-Inspektion ohne Cloud

Das Problem
In der Qualitätskontrolle an der Linie zählt nicht der F1-Score auf PowerPoint, sondern ob die Anlage innerhalb weniger Millisekunden eine Fehlentscheidung vermeidet oder den Materialfluss rechtzeitig stoppt. Wer visuelle Inspektion in eine SPS-Logik einkoppelt, kennt die Realität: harte Latenzbudgets, Taktzeiten unter 100 ms, deterministische Reaktionspfade, Safety-Handshakes – und Null Toleranz für „Netzwerkwetter“ oder API-Rate-Limits. Dieses Stück beschreibt, wie wir visuelle Inspektion on-premise so bauen, dass sie deterministisch, auditierbar und souverän läuft: vom Kameratrigger bis zum sicheren SPS-Signal, ohne US-Cloud-Abhängigkeit und ohne „Best Effort“-Latenzen.

Warum das Thema nicht trivial ist

  • KI-Modelle sind das kleinste Problem. 80% der Ausfälle passieren in Triggering, Pufferung, Scheduling, Feldbus-Anbindung und Fehlerszenarien.

  • Latenz ist nichts ohne Determinismus. 8 ms Durchschnitt helfen nicht, wenn 1% der Zyklen 60 ms braucht.

  • Governance ist Pflicht. Jede Entscheidung muss nachvollziehbar, wiederholbar und auditierbar sein – ohne Daten das Werk zu verlassen.

1) Latenzbudget und deterministische Pfade
Bevor man über Modelle spricht, definiert man ein Latenzbudget als verbindlichen Vertrag. Ein Beispiel für ein 12–20 ms Gesamtlatenz-Ziel (Trigger bis SPS-Ausgang):

  • Kamera-Exposure und Readout: 1–4 ms (global shutter, exakter Trigger).
  • Übertragung zum Rechner: 0,2–2 ms (abhängig von Interface und Auflösung).
  • Vorverarbeitung: 1–3 ms (Crop, Normalize, Farbkorrekturen auf GPU).
  • Inferenz: 3–8 ms (kompaktes CNN, feste Inputgröße, INT8-quantisiert).
  • Entscheidungslogik + Safety-Handshakes: 0,5–2 ms.
  • SPS-Zyklus und Aktorreaktion: abhängig von Zykluszeit und Feldbus; deshalb Signalpfad möglichst parallel/synchron und „push“-basiert.

Regeln:

  • Prozentile statt Durchschnitt. 99,9%-Latenz muss im Budget bleiben.

  • Keine variable Auflösungen oder dynamische Tensor-Shapes im Produktionspfad. Variabilität erzeugt Jitter.

  • Alle Pfade, die das Budget verletzen könnten, führen deterministisch in einen sicheren Zustand (z. B. NIO/Fehlersignal statt Stille).

2) Sensorik und Zeit-Synchronisation: Trigger schlägt Polling

  • Hardware-Trigger vor Software-Timer. Kameras werden über Hardware (z. B. Lichtschranke/Encoder) getriggert. Software-Trigger erzeugt Jitter.

  • Global Shutter vor Rolling Shutter in bewegten Linien. Sonst kompensieren Sie Bewegungsartefakte mit künstlicher Komplexität.

  • Zeitbasis harmonisieren. Kamera, SPS und Rechner über einen gemeinsamen Zeitstempelmechanismus synchronisieren (z. B. PTP im Maschinenetz). Ohne konsistente Zeit ist Debugging von Grenzfällen praktisch unmöglich.

  • Beleuchtung ist Teil der Datenqualität. Konstantstromtreiber, Entkopplung von Maschinenversorgung, Strobe-Signale fest im Triggergraph verankern, um Beleuchtungsjitter zu vermeiden.

3) Datenpfad: Zero-Copy als Grundprinzip
Jede unnötige Kopie ist Latenz und Jitter.

  • Kamera-Interface wählen, das deterministische Bandbreite ermöglicht (z. B. Gigabit/10G mit deterministischer QoS, CoaXPress etc.). Entscheidend ist: keine Contention mit Office-Netzen, eigene VLAN/physische Trennung.
  • Page-locked Memory (Pinned) für Empfangsbuffer verwenden, um DMA-Transfers ohne Paging zu ermöglichen.
  • Double/Triple-Buffering auf allen Stufen: Capture → Preproc → Inferenz. Producer-Consumer mit Lock-Free-Ringbuffer; Backpressure ist explizit, Drops sind dokumentiert.
  • GPU-Pipeline ohne Roundtrips: Upload in GPU-Memory nur einmal, Vorverarbeitung als CUDA-Kernels, Inferenz im selben Stream. Host-GPU-Synchronisation nur an geprüften Barriers.
  • Keine JPEG/PNG im Produktionspfad. Komprimierung ist für Archiv, nicht für Entscheidungswege. Wenn Bandbreite knapp ist, dann sensornahe Pre-Crops.

4) Inferenz-Engine und Modellwahl: feste Formen, fixierte Pfade

  • Feste Eingangsgröße, statische Graphen. Vermeiden Sie dynamische Shape-Inferenz; Compilers (z. B. TensorRT/ONNX-Runtime-EP) danken es mit deterministischer Runtime.

  • Quantisierung auf INT8, kalibriert auf produktionsnahe Datensätze. INT8 reduziert Latenz und Bandbreite im Speicher; entscheidend ist ordentliche Kalibrierung an „schwierigen“ Samples.

  • Batchgröße 1. Latenz schlägt Durchsatz in Inline-Inspektion.

  • Wärmehaushalt im Blick: Thermal Throttling ist der versteckte Latenz-Jitter. Lüfterkurven fixieren, Gehäuse entstauben, Temperatur-Metriken loggen.

  • Algorithmische Guardrails: OOD- und Unsicherheitsindikatoren in die Entscheidungslogik integrieren (z. B. Softmax-Temperatur, Feature-Distanz zu Trainingsverteilung). Unklare Fälle deterministisch in definierten Prozess (Marker, Ausschleuser, QS-Flag) leiten – nicht „raten“.

5) SPS-Integration: harte Grenzen, klare Handshakes
95% der Fehlalarme und Aussetzer, die wir in der Praxis gesehen haben, sind SPS-Schnittstellenprobleme, nicht Modellfehler.

  • Sicheres Ausgangssignal: Für Stop/Fehler niemals TCP-Only. Entweder digitale I/O über Echtzeitkarten oder deterministischer Feldbus mit sicherheitsgerichtetem Kanal, je nach Safety-Konzept der Maschine. Die Steuerung darf nicht von Broker-Liveliness abhängen.
  • Handshake-Muster:
  • Data-Ready (KI → SPS) mit Sequenznummern.
  • Acknowledge (SPS → KI) innerhalb definierter Zykluszeit.
  • Timeout-Logik: Ausbleibende Acks setzen sicheren Default.
  • Zyklusentkopplung: Wenn die SPS mit 2–8 ms Zyklus fährt, entkoppeln wir durch einen minimalen Shaper (z. B. Shadow-Register mit letzter stabiler Entscheidung für N Zyklen), um sporadische Jitter zu glätten, ohne Latenz zu erhöhen.
  • Testbarkeit: Simulationsmodus mit deterministischen Replays von Kameraframes und SPS-Inputmustern. Ohne deterministische Replays sind Grenzfälle in der Linie nicht reproduzierbar.

6) Fehlertoleranz, Watchdogs und sichere Zustände

  • End-to-End-Watchdog: Vom Trigger bis Ausgangssignal wird jede Stufe zeitlich überwacht. Verletzung führt in sicheren Zustand (z. B. Ausschleusung statt Weitertransport).

  • Frame-Drops sind Ereignisse, keine Logs. Jede verworfene Aufnahme wird gezählt, begründet und mit Kontext persistiert (Ringspeicher der letzten N Frames mit Metadaten).

  • Heartbeats mit Signatur: KI-Prozess und SPS tauschen periodische Heartbeats aus; die SPS vertraut ausschließlich validierten Heartbeats. Kein Heartbeat, kein Gutteil.

  • E-Stop-Integration: KI-Pfade dürfen E-Stop-Signale nicht verzögern. E-Stop führt sofort zum definierten Hardwarezustand; Software fährt danach in Diagnosemodus.

7) Betriebssystem, Scheduling und Container
Die beste Pipeline scheitert an einem Systemd-Service mit Default-Prioritäten.