Integration in bestehende Linien: Brownfield ohne Stillstand

  • Sidecar-Prinzip: Die KI-Station wird parallel zur bestehenden Prüflogik montiert. Anfangs nur „sniffen“ (mitlauschen) und Schatten-Entscheidungen treffen, ohne Aktoren anzusteuern.

  • Gradual Cutover: Nach P99-Latenz- und Qualitätsnachweis wird das Ergebnis-Bit auf die echte Aktorik geschaltet. Ein Bypass-Schütz erlaubt Rückfall auf alte Logik binnen Sekunden.

  • HIL-Tests: Hardware-in-the-Loop mit echter SPS und realen Triggern. Keine Laborprüfung ohne Feldbus/IO im Loop – zu viel Latenz verschiebt sich erst im echten Takt ans Licht.

  • Dokumentierte Taktfenster: Auf Linienebene festhalten, wie viele ms von Trigger bis Aktorik real zur Verfügung stehen. In diese Zahl muss Ihre P99-Latenz plus Sicherheitsaufschlag passen.

Beispiele aus der Praxis

  • Visuelle Schweißnahtprüfung in der Automotive-Zulieferung: 25-ms-Taktfenster, starke Reflexionen. Lösung: Polarisationsfilter, 0,5-ms-Strobe, INT8-Detektor mit 6–8 ms Inferenz, diskrete IO-Handshake. Ergebnis: P99=18 ms, Auswurf mit 5 mm Reserve bei 1,2 m/s.

  • Textilfertigung, Fadenzug-Anomalien: Kontinuierlicher Bahnprozess, kein harter Einzel-Trigger. Lösung: Rolling-Buffer mit „newest frame wins“, Schwellenwert-Tracking für Ereigniserkennung, Edge-Only. Ergebnis wird mit 2-Bit-Status per Feldbus zyklisch an SPS gemeldet; bei Ereignis setzt Vision synchrones Latch-Bit. P99 stabil bei 22 ms, keine Cloud-Abhängigkeit.

  • Leiterplattenbestückung, Bauteil-Fehlerlage: Zwei Kameras, 35-ms-Gesamtfenster. Lösung: Zwei parallele Engines, Ping-Pong-Handshake an SPS, dedizierte CPU-Kerne je Kamera, GPU in festen Clocks. Timeout-Fallback auf einfache Template-Match-Regel. Keine Taktverluste bei Peak-Last.

Testen, messen, nachweisen

  • Messen Sie End-to-End: Vom Trigger-Flankenwechsel bis zum Ergebnis-Bit an der SPS. Nicht nur Inferenzzeit.

  • P95/P99 statt Mittelwerte: Produktionsrealität ist nicht Durchschnitt.

  • Jitter-Budgets pro Stage: Jede Pipeline-Stufe bekommt ein Budget und ein Alarm, wenn sie überzieht.

  • Reproduzierbarkeit: Engine-Builds und Preprocessing als reproduzierbare Artefakte mit Versions-Hash. Ohne das ist Root-Cause-Analyse im Feld Glücksspiel.

  • Chaos-Tests im Kleinen: CPU-Last künstlich erhöhen, Netzwerk-Jitter simulieren, Kamera-Reset injizieren. Beobachten, wie schnell das System in den nominalen Zustand zurückkehrt.

Meinung: Cloud-first ist im Taktbetrieb eine Bankrotterklärung
Wenn Ihre Entscheidung in 30 ms stehen muss, hat die Cloud im Entscheidungsweg nichts verloren. Punkt. Ebenso wenig gehören „bewegliche Teile“ wie dynamische Batching-Strategien, Garbage-Collecting-Laufzeiten oder generische Message-Busse zwischen Kamera und SPS. Die Architektur muss die physische Realität der Linie respektieren: determinierte Takte, harte Fenster, sichere Fallbacks. Wer das ignoriert, baut Demo-Software – keine Produktionssysteme.

Checkliste zum Mitnehmen

  • Hardware-Trigger der Kamera, Strobe-Licht, kurze Belichtungen.

  • Zero-Copy-Pipeline, GPU-Preprocessing, Batch=1, fixierte Clocks.

  • C++/Rust im Hot-Path, asynchrones Logging, keine Blocker.

  • Diskrete IO oder echtzeitfähiger Feldbus für das Ergebnis; OPC UA für Diagnose.

  • Expliziter SPS-Handshake mit Timeout und Fail-Safe-Default.

  • PTP-Zeitsync, wenn positionale Korrelation erforderlich ist.

  • P99-Latenz messen und unter Taktfenster halten, mit Sicherheitsaufschlag.

  • A/B-Deployment, Watchdogs, degradierter Modus.

  • On-Prem-Governance: signierte Modelle, Observability, Audit-Samples. (→ alpitype.de/leistungen/)

FAQ

Frage: Warum nicht einfach OPC UA für alles, inklusive Entscheidungs-Bit?
Antwort: OPC UA ist hervorragend für Diagnose, Rezepturwechsel und Historie. Für 10–30-ms-Entscheidungen hängt die Latenz und Varianz aber von Stack, Netzwerk und Server-Last ab. Diskrete IO oder ein deterministischer Feldbus reduzieren Variabilität und Fehlerquellen. Nutzen Sie OPC UA flankierend, nicht im Hot-Path.

Frage: Wie bekomme ich GPU-Inferenz deterministisch?
Antwort: Batch=1, Engine vorgewärmt, feste Power/Clock-States, asynchrone CUDA-Streams mit vorallokierten Puffer, keine Speicherallokation im Hot-Path. Pinning von Threads und IRQs auf dedizierte Kerne, PREEMPT_RT oder zumindest sorgfältige CPU-Isolation. Vermeiden Sie konkurrierende GPU-Workloads auf demselben Gerät.

Frage: Jetson oder x86 – was ist robuster im Feld?
Antwort: Beides ist einsetzbar. Jetson punktet mit kompakter Bauform, fixierbaren Clocks und guter Toolchain – ideal für 1–2 Kameras. x86 mit dGPU bietet Reserven für mehrere Streams und komplexere Modelle, verlangt aber ein strengeres Tuning von PCIe/NUMA/IRQ. Entscheidend sind P99-Latenz und Servicebarkeit im Werk, nicht theoretische TOPS.

Frage: Wie teste ich die Latenz ohne die Linie zu stören?
Antwort: Hardware-in-the-Loop. Nutzen Sie eine SPS im Teststand, die reale Triggerfolgen generiert, und messen Sie das Ergebnis-Bit am digitalen Eingang mit einem Logik-Analyzer. In der Linie starten Sie im „Shadow Mode“ (Ergebnis wird nur geloggt), bis P99 und Fehlerraten nachgewiesen sind. Danach Gradual Cutover mit Bypass-Schütz.

Frage: Ist INT8-Quantisierung immer sinnvoll?
Antwort: Sie bringt oft signifikante Latenzgewinne, aber nur mit sauberer Kalibrierung und stabiler Preprocessing-Kette. Prüfen Sie nicht nur Genauigkeit, sondern auch Latenz-Varianz und Fehlerverteilung. In sicherheitskritischen Stationen kann ein langsameres, aber stabileres FP16/FP32-Modell die richtige Wahl sein.

Fazit
Visuelle Inspektion im Millisekundenbereich ist weniger eine Frage des „besten Modells“ als konsequenter Systemarchitektur: deterministische Triggerung, Zero-Copy-Pipelines, fixierte Inferenzpfade, klare SPS-Handshakes und belastbare Fallbacks. Wer diese Prinzipien einhält, erreicht End-to-End-Zeiten, die auch unter Produktionsbedingungen und Störungen tragen – ohne Cloud-Abhängigkeit und ohne Überraschungen im Takt. Alles andere bleibt ein Laborexperiment mit hohem PR-Wert und geringem Produktionsnutzen.