Wichtig:

  • Das Zeitbudget wird in der SPS hart modelliert (z. B. TON-Timer). Überschreitung setzt TIMEOUT_FAILSAFE.

  • Edge setzt RES_VALID atomar mit RES_CODE. Kein Zustand, in dem “gültig ohne Code” anliegt.

  • Wiederanlauf klar definiert (z. B. Flanke auf TRIG_IN reseted CAP_ACK/RES_VALID/…).

OPC UA vs direkte Feldbus-Anbindung

  • OPC UA: Gut für Zustände und Diagnosen. Für harte Echtzeit-Budgets ist PubSub über UDP in einem TSN-Netz geeignet, klassische Client/Server kann reichen, wenn Latenzen im Budget bleiben.

  • Direkte Feldbus-Anbindung (z. B. Profinet Device Stack auf dem Edge-IPC): Bietet deterministischere Kopplung, erfordert industrielle Stacks und Tests.

  • Digital-I/O als letzte Ausweichlösung: Strobe/OK/NOK-Bits über IO-Module – simpel, robust, aber limitiert in Diagnose.

Jitter-Messung und Budgetierung
Sie brauchen Messkurven, nicht nur Logs:

  • Zeitstempel auf jeder Stufe: Trigger-In, Frame-In, Preproc-Start, Infer-Start/-Ende, Postproc-Ende, RES_VALID-Out.

  • Kennzahlen: 50./95./99. Perzentil + Maximum. Engineering-Entscheidung basiert auf 99%+Worst-Case, nicht Median.

  • Guard-Band in der SPS: Worst-Case + Sicherheitsaufschlag. Keine “wir schaffen’s schon”-Annahmen.

  • Sichtbarkeit: Lokale Timeseries (z. B. Prometheus/InfluxDB on-prem), Dashboards, Alarmierung bei Drift. Kein US-Cloud-Zwang, keine Internetabhängigkeit.

Fallback-Strategien, die die Linie schützen

  • Unsicherheitsklasse: Das Modell liefert “unsicher”, wenn Konfidenz unter X oder Zeitbudget knapp. Die SPS reagiert konservativ (z. B. Ausschleusen).

  • Degradierter Betrieb: Wenn GPU/Modell ausfällt, ersatzweise regelbasierte Checks (z. B. simpler Blob-/Kanten-Check) aktivieren, um Linie am Laufen zu halten, aber mit Sperrvermerk.

  • Watchdogs: Edge-Prozess-Health-Bit, externe Hardware-Watchdog-Karte für IPC. SPS überwacht Heartbeat.

  • Graceful Degradation von Persistenz: Wenn die Platte voll ist, werden nur Metadaten/Thumbs gespeichert; niemals der Echtzeitpfad blockiert.

Datenhaltung, Souveränität, DSGVO

  • On-Prem-Speicher der Produktionsdaten. Selektive Speicherung: nur Fehlerfälle + Stichproben iO, rotierend, nachvollziehbar. Keine personenbezogenen Daten in der Regel; falls Menschen im Sichtfeld, Maskierung im Echtzeitpfad.

  • Reproduzierbarkeit: Jede Entscheidung mit Hash von Modellartifact, Konfiguration, Preprocessing-Parametern, Software-Build-ID versehen. Ergebnis ist später rekonstruierbar.

  • Update-Kanal air-gapped: Signierte Artefakte, offline-installierbar. Keine stillen Internet-Abhängigkeiten. Governance/Change-Logs zentral in der Fabrik-IT (→ alpitype.de/leistungen/).

Modell-Lifecycle unter Produktionsbedingungen

  • Blue/Green auf dem Edge: Zwei Inferenz-Stacks parallel. Umschaltung nur, wenn Health- und Latenzkriterien erfüllt sind; sofortige Rückschaltung möglich.

  • Canary-Modus: Anteil der Teile wird doppelt bewertet (alt/neu), aber nur alt steuert die SPS. Drift und Latenz unter realer Last sichtbar machen, bevor man scharf schaltet.

  • Dataset-Management on-prem: Kuratierte Fehlerbibliotheken, Versionierung, Label-Qualitätssicherung. Trainings finden offline/on-prem statt; Export nur, wenn Compliance es erlaubt.

  • Keine “Online-Lernversprechen” im Shopfloor: Inline-Modelle lernen nicht “von selbst”. Sie liefern deterministische Ergebnisse und werden periodisch auf Basis kuratierter Daten neu trainiert.

Beleuchtung und Mechanik: Die oft unterschätzten Taktgeber

  • Stabilität der Beleuchtung ist Latenzrelevanz: Flackernde LED-Netzteile erzeugen Varianz im Preprocessing/Belichtungszeit; das schlägt auf Jitter durch.

  • Mechanische Toleranzen: Wenn das Bauteil ±10 mm wandert, ist dynamisches ROI-Finding nötig – mit deterministischem Fenster. ROI-Suche nicht unbounded gestalten.

  • Encoder/Geberintegrität: Positionssignale müssen sauber entprellt und zeitlich referenziert sein, sonst ist der beste Inferenzpfad nutzlos.

Praxisbeispiele aus der Fertigung

  • Visuelle Montageprüfung: Prüfen, ob zwei O-Ringe montiert sind. Architektur: Doppelkamera (oben/seitlich), Hardware-Trigger von der Station, INT8-klassifizierendes Modell + Morphologie-Regelcheck. Ergebnisbit steuert Schrauber-Freigabe. Guard-Band 20% über Worst-Case. Degradierter Betrieb: Regelbasiert nur Ringschatten prüfen.

  • Textil-Defekterkennung am laufenden Band: Hohe Bahn-Geschwindigkeit, Zeilenkamera mit PTP-sync. Segmentierung mit kleiner, quantisierter Architektur. Auswurffenster strikt: 60–80 ms. Jitter wird primär durch DMA/NIC getrieben; Lösung: IRQ-Affinität und feste CPU-Frequenzen. Persistenz nur bei Defektclustern, sonst Thumbnails.

  • Verpackungs-Labelprüfung: OCR plus Layoutvalidierung. Pipeline trennt OCR (GPU) und Regelwerk (CPU). Ergebnisbitkette umfasst neben NOK auch “Unsicher-OCR”, worauf die SPS den Bediener zur manuellen Verifikation auffordert, ohne Stopp.

Teststrategie vor Go-Live

  • Closed-Loop-HIL: SPS/PLC in der Testumgebung mit aufgezeichneten Triggersequenzen, deterministische Replay-Engine. Verifizierung des Handshakes und der Timer.

  • Worst-Case-Szenarien: Kältester Start, thermische Sättigung, concurrent IO-Last, “Störung” im Nebenaggregat. Messen, nicht raten.

  • Fault Injection: Kamera-Timeout, korruptes Frame, GPU-Reset, Dateisystem voll. Erwartetes Verhalten: TIMEOUT_FAILSAFE, Linie bleibt stabil.

  • Acceptance-Gates: Latenz-Perzentile, Fehlklassifikationsrate je Fehlerklasse, Recovery-Zeit nach Reboot. Abbruchkriterien definiert.

Sicherheit und Wartbarkeit

  • Minimaler Angriffsfläche: Keine unnötigen Dienste auf dem Edge. Firewall-Regeln eng. Nur aus Fabriknetz erreichbar.

  • Signierte Artefakte: Inferenz-Engines, Konfigurationen, Modelle – alles signiert. Rollback ist ein erster Bürger, nicht ein Notfall.

  • Logging: Lokal, strukturiert, rotierend, manipulationssicher archiviert. Zugriff nur für berechtigte Rollen. Auditierbar.

Meinung: Cloud-first ist im Inline-Check der falsche Default
Inline-Inspektion ist ein Steuerungsproblem mit einer KI-Komponente – nicht umgekehrt. Wer den Echtzeitpfad mit Netzwerk-Hops, variierenden Ressourcen oder “wir sehen schon die Latenzen in der Cloud” verwässert, zahlt in der Produktion mit Stopps und Misstrauen. Edge-first, deterministische Budgets, explizite SPS-Kopplung und ein konservativer Fallback sind die Grundlagen. Die eigentliche Modellwahl ist wichtig, aber zweitrangig, wenn die Architektur nicht industrietauglich ist. Souveränität heißt hier: Kontrolle über Zeit, Daten und Verhalten, nicht nur über IP-Rechte.

FAQ
1) Brauche ich einen RT-Kernel (PREEMPT_RT), um deterministische Latenzen zu erreichen?

  • Nicht zwingend. Viele Systeme erreichen stabile, enge Latenzbudgets mit einem gut getunten Standard-Linux: CPU-Isolation, feste Frequenzen, IRQ-Affinität, vorallozierte Puffer, minimierte Kontextwechsel. PREEMPT_RT hilft bei Scheduling-Deterministik, ist aber kein Ersatz für IO-/Speicherdisziplin. Entscheiden Sie nach Messung, nicht nach Dogma.