6) Feldbus, IO und Handshake-Realität

  • Digital-IO vs Feldbus: Für sehr knappe Budgets ist ein dediziertes Digital-IO-Paar (Req/Ack/Valid/Result-Bits) oft robuster. Für integrierte Diagnosen/Traceability im Leitsystem bietet Feldbus (Profinet, EtherCAT) Vorteile, aber beachten Sie den SPS-Zyklus.

  • Lese-/Schreibdisziplin: Ergebnisbits werden doppelt geschrieben (Shadow + Active), Valid schaltet per Write-Barrier. Auf SPS-Seite erst lesen, wenn Valid=1, dann Quittung setzen, erst dann löscht Vision wieder. So vermeiden Sie Gleitbedingungen.

  • Debounce/Timeout in der SPS: Ein eigener SFC/FB, der „Inspect_Req“ setzt, auf „Valid/Timeout“ wartet, Ergebnis übernimmt und deterministisch weiter schaltet. Kein „Nebenbei“-Polling im Zykluscode.

7) Qualität vs Latenz: Die echten Trade-offs

  • Auflösung vs Kontrast: Höhere Auflösung erhöht Inferenz- und Preprocessing-Zeit. Oft bringt bessere Beleuchtung/Optik mehr als Megapixel.

  • Modellarchitektur: Schmale, latency-optimierte Netze (MobileNet-, Efficient*-Klassen, praxistauglich abgespeckt) statt schwerer Backbones. Quantisierung spart Latenz, kann aber Grenzfälle kosten – deshalb mit produktspezifischen Edge-Cases evaluieren.

  • Postprocessing: Aufwendig ist oft NMS/Geometrie. Einfache, deterministische Regeln nach dem Netz können die Entscheidung stabiler und schneller machen als hochkomplexe Postprozesse.

8) Fehlerszenarien konsequent behandeln

  • Zu spätes Ergebnis: „Timeout“-Pfad aktiv, SPS schaltet definierte Reaktion (Ausschleusen/Stop). Kein „Best Effort“ in die Steuerkette durchschmuggeln.

  • Frame-Drops/CRC: Kamera-/Grabber-Statistiken weisen darauf hin. Wenn Drop-Quote steigt: Hardware checken, aber im Betrieb entscheidet sofort der Timeout-Pfad.

  • Modell-Unsicherheit: Wenn das Netz unsicher ist (Score-Band), definierter „Unsicher“-Zweig mit konservativer Entscheidung.

  • Health-Monitoring: Heartbeat vom Vision-System, Watchdog auf SPS-Seite. Wenn Heartbeat ausfällt: sichere Default-Strategie.

9) Validierung: Messen, nicht schätzen

  • Messaufbau: Zwei GPIO/DO-Linien an Oszilloskop/Logikanalysator. Linie A: „Inspect_Req“ (SPS). Linie B: „Inspect_Valid“ (Vision). Optional dritte Linie: „Belichtung aktiv“ oder „Inference start“. So messen Sie reale End-to-End-Latenz und Jitter hardwarenah.

  • Statistik: Histogramm, Perzentile, keine Mittelwerte schönt. Akzeptanzkriterium ist die Einhaltung des definierten 99,9%-Budgets plus Sicherheitsmarge.

  • Worst-Case-Tests: Beleuchtung degradieren, thermisch vorheizen, konkurrierende IO-Lasten simulieren. Erst wenn dann stabil: freigeben.

10) Edge vs Cloud: Keine Glaubensfrage, sondern Physik und Souveränität

  • Inferenz muss an die Linie, Punkt. Latenz, Verfügbarkeit, Unabhängigkeit vom WAN – alles spricht dafür. Die Cloud hat in diesem Setup zwei Aufgaben: Modelldesign/Training und Flotten-Telemetrie außerhalb des Echtzeitpfads.

  • Datenhoheit: Bilddaten aus Fertigungslinien enthalten in Europa oft IP-relevante Details. On-Prem-Training und -Speicherung vermeiden unnötige rechtliche Komplexität und reduzieren Angriffsflächen.

11) MLOps in OT: Air-Gapped, signiert, rollback-fähig

  • Artefakte: Modelle als signierte, versionierte Artefakte (Engine/Weights + Pre-/Post-Config + Kalibrierung). SBOM für das Runtime-Image.

  • Verteilung: Offline-Registry-Mirror in der DMZ, signaturgeprüfte Promotion (Dev → Staging-Linie → Produktion). Kein spontanes „pip install“ hinter der Linie.

  • Blue/Green-Deployment: Zweite Instanz zeitgleich mit Shadow-Traffic füttern, Latenz/Ergebnisdifferenz messen, dann umschalten. Rollback-Knopf muss existieren.

  • Observability: Inferenzlatenz, Droprates, Temperatursensorik, Scoreverteilung loggen. Keine personenbezogenen Daten, aber ausreichende Telemetrie für Drift-Detektion und Wartung. Für generative/agentische Komponenten braucht es zusätzlich Observability & Governance – Prinzip bleibt: Produktion bleibt souverän und auditierbar (→ alpitype.de/leistungen/).

12) Beispiel aus der Praxis: Schraubplatz-Inspektion an einer Montagezelle
Ausgangslage: Eine Zelle montiert 8 Schrauben pro Bauteil. Die SPS taktet die Station; Taktzeit knapp. Aufgabe: Verifizieren, ob alle Schrauben vorhanden, richtig positioniert und ohne Lackeinschluss sind.

Technische Umsetzung:

  • Hardware-Trigger von der SPS, sobald der Schraubkopf an Position ist. Strobe-Beleuchtung schräg, um Kantenkontrast zu maximieren.

  • Kamera über deterministische Schnittstelle, PTP-synchronisiert mit Vision-PC.

  • Vision-Pipeline: Pre-allocierte Puffer, GPU-Preprocessing, quantisierte Detektor-Architektur, Score-basiertes Postprocessing mit engen Schwellwerten.

  • Handshake: Pro Schraube ein „Inspection Ticket“ mit ID (Position 1..8). Ergebnisbits in einem Feldbus-Array, Valid-Bit pro Position.

  • Failover: Timeout führt zur sofortigen Ausschleusung, nicht zur Weiterfahrt.

  • Validierung: Per Oszilloskop Latenz-Distribution gemessen, 99,9%-Perzentil innerhalb Budget, zusätzliche Sicherheitsmarge.

Ergebnis: Nicht die maximalen mAP-Prozentpunkte waren erfolgskritisch, sondern ein knallhartes, deterministisches Handshake- und Zeitbudget-Design. Genau das unterscheidet einen PoC von einer produktiven Lösung.

13) Skalierung: Mehr Kameras, mehr Stationen, gleiche Prinzipien

  • Pipeline-Pro-Station: Pro Station eigener Prozess/Container mit dediziertem CPU/GPU-Anteil. Interferenz reduzieren.

  • Scheduling: Kamera-Trigger so entflechten, dass sie nicht alle dieselbe GPU-Zeit beanspruchen. Entweder zeitlich versetzt triggern oder GPU partitionieren.

  • Netzwerk: Dedizierte VLANs für Bilddaten, QoS/Traffic Shaping. Kein Mischbetrieb mit generischem Office-Traffic.

  • Zentraler Überblick: Telemetrie in ein On-Prem-Observability-System einspeisen, Alarme bei Latenz-/Drop-Anomalien.

14) Häufige Anti-Pattern (bitte vermeiden)

  • „Cloud-Inferenz“ für harte Inline-Entscheidungen. Sie wird immer zum Nadelöhr – physikalisch und betrieblich.

  • Python-Skripte direkt an der Linie ohne Ressourcen- und Scheduler-Kontrolle. Schnell gebaut, später unbeherrschbar.

  • Software-Trigger via Timer ohne Hardware-Handshake. Jitter vorprogrammiert.

  • On-the-fly Modelldownloads/Updates in der Schicht. Risiko ohne Not.

  • Keine definierte Timeout-Strategie. Der schlimmste Zustand ist stilles Wegoptimieren von Fehlern.

Fazit
Echtzeit-Vision in der Produktion ist kein Deep-Learning-Problem, sondern ein Takt- und Determinismusproblem. Wer erfolgreich deployen will, zwingt die KI in den SPS-Takt: Hardware-Trigger, deterministische Puffer, prekompilierte Engines, feste Ressourcen, messbares Handshake. Alles andere – Architekturentscheidungen, Modellwahl, Infrastruktur – folgt diesem Primat. Edge statt Cloud ist hier kein Glaubensbekenntnis, sondern eine Konsequenz aus Physik, Sicherheit und Souveränität. Wer das beherzigt, baut produktionsreife Systeme statt PoCs auf Stelzen.