• Netzwerkjitter, Kodierung/Decodierung und WAN‑Verfügbarkeit sind unvereinbar mit Inline‑30‑ms‑Budgets.
  • Datensouveränität: Rohbilder bleiben in der Anlage. Nur strikt benötigte Metriken verlassen die Zelle – On‑Prem, nicht Internet.
  • Cloud kann sinnvoll sein für Offline‑Analytics, Flotten‑Vergleiche, Trainingspipelines. Nicht im Hot‑Path der Entscheidung.

Modell- und Implementierungsdetails, die im Feld den Unterschied machen

Quantisierung und Genauigkeit

  • INT8 bringt oft den Sprung unter 15 ms. Voraussetzung ist saubere Kalibrierung mit produktionsnahen Daten.
  • Trade‑off: leichte Genauigkeitseinbußen akzeptieren, wenn dadurch P99 stabil wird – das spart Fehlwürfe durch Deadline‑Misses.
  • Batch‑Size 1 für Inline‑Entscheidung; Micro‑Batching lohnt selten, außer wenn SPS‑Takt > 100 ms und Frames gebündelt werden dürfen.

Vorverarbeitung

  • Variierende Beleuchtung adressieren wir in der Pipeline nicht mit Auto‑Exposure, sondern mit fixen Belichtungsprofilen pro Produktvariante plus GPU‑Normalisierung.
  • Geometrie‑Drift (Kamera/Mechanik) wird bei Produktwechsel über eine schnelle Homographie‑Rekalibrierung korrigiert; dafür gibt es in der HMI einen gesperrten Service‑Screen.

Postprocessing

  • NMS/Thresholds strikt auf GPU halten; nur das Endergebnis wandert zur CPU.
  • Overlay fürs HMI wird asynchron aus einer Downscale‑Kopie erzeugt und läuft niemals im selben Thread wie der SPS‑Pfad.

Speicherpfad

  • Unbedingt vermeiden: OpenCV‑CPU‑Operatoren im Hot‑Path, insbesondere cvtColor/resize auf Host‑Seite.
  • Zero‑Copy mit DMABUF/EGLImage/VAAPI je nach Plattform; Formatkonvertierung GPU‑seitig.

Scheduler und OS‑Tuning

  • IRQ‑Balance statisch setzen; NIC‑Interrupts an isolierte Kerne binden.
  • CPU‑Governor auf performance; Turbo‑Sprünge vermeiden, wenn sie Jitter erzeugen.
  • mlockall, RLIMIT_MEMLOCK anpassen; OOM‑Killer per cgroup verhindern, dass kritische Prozesse gekillt werden.

HMI-Integration (C++/Qt)

  • HMI und Pipeline strikt trennen: HMI liest Telemetrie/Ergebnisse über Shared‑Memory oder IPC‑Queue in Read‑Only‑Manier.
  • Keine Bildanzeige im Produktionspfad; das HMI bekommt decoupled, gedrosselte Frames (z. B. 5 fps), um Jitter zu vermeiden.
  • Service‑Modus für Kalibrierung: Schaltet Pipeline in determinierte Single‑Step‑Abarbeitung mit Mess‑Overlay – niemals im Produktionsmodus aktiv.

Testbarkeit und Validierung in der Linie

  • Hardware‑in‑the‑Loop: Produktträger simulieren (Trigger, Encodersignale), um Timing an Grenzen zu testen.
  • Latenz‑Budgettests: 24‑h‑Runs mit 100% Auslastung; P99 und P99.9 aufzeichnen; definierte Grenzwerte, bei deren Verletzung automatisch auf Degradation geschaltet wird.
  • Reproduzierbarkeit: Firmware/OS‑Image, Treiberversionen, Modell‑Hash, Kalibrierungs‑Hash – alles gehört in die Ergebnis-Telemetrie.

Update- und Souveränitätsstrategie (air‑gapped)

  • GitOps‑Flow On‑Prem:
  • Lokale Registry‑Spiegel für Container und Modelle.
  • Modelle signieren; Hash‑Verifikation vor Aktivierung.
  • Rollout als A/B‑Slot: Slot B wird parallel “shadow‑infer” betrieben, Ergebnisse nur geloggt, bis Freigabe erfolgt.
  • Kein US‑Cloud‑Zwang:
  • Build‑Kette und Artefaktverwaltung On‑Prem in EU‑Infrastruktur.
  • Telemetrie verbleibt lokal; Export nur von aggregierten Metriken nach Freigabe.
  • Audit/Freigabe:
  • Jede Modellaktivierung mit Ticket/Change‑ID, Operator‑Sign‑Off und automatischer Regression‑Summary.
  • Lebenszyklus pro Produktvariante; kein “one‑size‑fits‑all”-Modell ohne Kalibrierung.

Was in der Praxis am häufigsten schiefgeht

  • Heimliche Kopien: Ein einziges “download to host” in einer Bibliothek vernichtet die Latenzgarantien.
  • Unbegrenzte Queues: “Für Sicherheit” erhöhte Puffer verwandeln Jitter in unkontrollierbare Latenzen.
  • Python im Hot‑Path: GC‑Pauses, GIL‑Contention – nicht vereinbar mit SPS‑Determinismus.
  • HMI‑Kopplung: Kamera‑Feed im HMI‑Thread rendern und wundern, warum die Linie steht.
  • Fehlende Backpressure: Pipeline versucht schneller zu laufen als die Mechanik; am Ende sind die Zuordnungen Frame↔Werkstück falsch.

Praxisbeispiel: Visuelle Baugruppen-Verifikation in 25‑ms‑Takt

  • Aufgabe: Prüfen, ob alle Schrauben gesetzt und korrekt angezogen sind; 1 Kamera, 12 ROIs.
  • Umsetzung:
  • Trigger über SPS bei Stillstand des Werkstückträgers; Belichtung fix 1.5 ms.
  • GPU‑Pre‑Processing: ROI‑Crop per Homographie, dann 12 parallele Inferenzläufe auf einem kleinen Backbone (INT8).
  • Post‑Processing: Score‑Aggregation pro ROI; minimaler Vektor zur SPS (12 Booleans + global OK/NOK + Frame‑ID).
  • Ergebnis aus der Praxis:
  • Stabile P99 um 18–22 ms, Degradation auf 6 ROIs bei sporadischen Lastspitzen < 0.1% der Zyklen, mit sauberem Logging für Root‑Cause.
  • Keine Cloud‑Abhängigkeit; Bildspeicherung nur im Ringpuffer 10 s zu Diagnosezwecken mit automatischer Löschung.

Sicherheits- und Compliance-Aspekte

  • Netzwerk‑Isolation: Produktionszelle in eigenem VLAN, nur Whitelist‑Routen zu On‑Prem‑Registern/Monitoring.
  • Signierte Artefakte: Modell‑ und Pipeline‑Konfigurationen kryptographisch signiert; Laufzeit validiert Signatur vor Load.
  • Zugriffstrennung: Service‑Zugriff über gesicherte Konsole, keine Remote‑Shell in der Linie. HMI‑Rollen strikt getrennt.
  • Datenhaltung: Keine Rohbilder außerhalb der Zelle; wenn Speicherung nötig, dann verschlüsselt, und mit automatischer Retention.

Operative Observability

  • Laufzeitmetriken:
  • Latenz‑Histogramme je Stufe (Capture, Pre, Infer, Post, IO).
  • Drop‑Rates, Degradation‑Ereignisse, Missed Deadlines.
  • GPU‑Utilization und Thermal Headroom (Thermal‑Throttling frühzeitig erkennen).
  • Ereignisprotokolle:
  • Versionen (Modell/Config/Driver), Kalibrierungs‑IDs, SPS‑Handshake‑Events.
  • Reproduzierbare Reports bei Abweichungen (nützlich für Qualitätssicherung und Audits).
  • Agenten und Governance:
  • Auch ohne LLMs gilt: Inferenzpfade brauchen Nachvollziehbarkeit. Eine dedizierte On‑Prem‑Observability‑Schicht hilft, Rollouts sicher zu steuern und Ursachen zu finden. Wenn Sie hierfür Plattform‑Bausteine suchen: (→ alpitype.de/leistungen/)

Meinung: Edge‑KI ohne deterministische Architektur ist Produktionsrisiko

Wer Inline‑Inspektion primär als “Modellproblem” behandelt, wird in der Linie scheitern. Die richtigen Modelle sind notwendig, aber nicht hinreichend. Entscheidend sind Zero‑Copy‑Datenpfade, harte Backpressure, deterministische Scheduler und ein Update‑/Governance‑Prozess, der ohne Internet und ohne Produktionsstopp funktioniert. Cloud hat in 30‑ms‑Hot‑Paths nichts verloren. Python hat dort nichts verloren. Und “wir erhöhen mal den Buffer” ist keine Lösung, sondern eine spätere Störung.

Checkliste für Ihren nächsten Produktions‑Rollout