• Realtime-Kernel/Settings: CPU-Isolation (Isolcpus), IRQ-Affinity für Kamera/GPU, Realtime-Prioritäten für Capture/Preproc/Inference-Threads. Frequenzskalierung fixieren, C-States konservativ.
  • GPU-Scheduling deterministischer machen: Persistenzmodus aktivieren, exklusiver Compute-Mode wenn möglich, dedizierter GPU für Inspektion statt Sharing mit HMI/Rendering.
  • Container ja, aber richtig: Rootless-Container, schlanke Basen, deterministische Ressourcengrenzen. Orchestrierung auf Edge nicht mit Cluster-Fetisch übertreiben. Systemd + Podman/K3s nur, wenn man ihre Latenz- und Update-Implikationen beherrscht.
  • Rolling Updates ohne Blindflug: Blau/Grün-Slotting der Pipeline mit synchronem Input-Mirroring. Ein Slot produziert, der andere verarbeitet identische Frames offline und verifiziert Latenz + Übereinstimmung. Erst bei grüner Metrik geht der Switch live.

8) Datenhaltung, Nachvollziehbarkeit und Souveränität
On-Prem bedeutet nicht „kein Logging“. Im Gegenteil.

  • Minimaler Entscheidungsdatensatz je Frame:
  • Zeitstempel (synchronisierte Zeitbasis)
  • Kameraparameter (Exposure, Gain, Triggerquelle)
  • Modellversion und Hash des Inferenzgraphs
  • Vorverarbeitungskonfiguration
  • Scores/Klassifikation + OOD/Unsicherheitsindikator
  • Latenzen pro Stage (Capture/Preproc/Infer/Handshake)
  • Referenz auf Bilddaten im Ringspeicher/Archiv
  • Speicherung: Kurzfristig im lokalen NVMe-Ringspeicher, langfristig selektiv (z. B. nur Grenzfälle, Ausschuss, Konzept-Drift-Kandidaten) auf on-prem Objekt- oder Dateispeicher. Kein Cloud-Transfer nötig.
  • DSGVO und Werkvertrags-Realität: Produktionsdaten enthalten oft Werk- bzw. Produktgeheimnisse. Wir bauen die Governance- und Observability-Ebene grundsätzlich on-prem (→ alpitype.de/leistungen/). Zugriffskontrolle, Retention-Policies und Auditpfade sind technisch durchgesetzt, nicht nur in einem SharePoint-Dokument.

9) Modellpflege im Takt der Produktion, nicht im Takt der Hypes

  • Drift-Erkennung: Metriken wie Feature-Statistiken, Class-Mix, OOD-Quote über die Zeit tracken. Keine Blind-Updates – erst Daten, dann Hypothese, dann AB-Validierung im Schatten-Slot.

  • Testdatensätze sind lebendig: Jeder Grenzfall landet automatisiert im kuratierten „Hard Set“. Ohne das degeneriert Qualität bei Prozessänderungen.

  • Trainingsumgebung spiegelt Produktion: Gleiche Preproc-Kette, gleiche Quantisierung, gleiche Inputgröße. Unterschiede zwischen Training und Produktion sind die häufigste Quelle für „unerklärliche“ Performance-Einbrüche.

  • Dokumentation als Code: Konfigurationen versioniert, reproduzierbare Builds, deterministische Artifacts (Hashes). Ein Audit fragt nicht nach „ungefähr so“, sondern nach konkreten Commit-IDs.

10) Praxisbezug: Zwei Muster aus Fertigung und Textil
A) Visuelle Schraubensitzkontrolle an einer Montagestrecke

  • Problem: 40 ms Takt, Kamera über Lichtschranke getriggert, Stop bei fehlender Schraube. Anfangs traten sporadische 80 ms-„Spikes“ auf.

  • Ursache: OS skalierte CPU-Frequenz; zusätzlich kollidierten NIC-Interrupts mit GPU-Kernel-Laufzeiten.

  • Lösung: Frequenzskalierung fixiert, IRQ-Affinity auf dedizierte Kerne, GPUDirect-ähnliche Pipeline (Upload einmal, Preproc+Infer ohne Host-Roundtrip), Double-Buffer und harte Watchdogs. Die 99,9%-Latenz fiel unter 15 ms, keine Spikes mehr. Entscheidungs- und Latenzmetriken on-prem persistiert.

  • Governance: Jede Stop-Entscheidung verknüpft mit Frame, Modell-Hash, Parametern. Retrospektive Analysen erklärten falsche Negativen – ein Beleuchtungsregler driftete.

B) Textilfertigung: Bahninspektion bei hoher Geschwindigkeit

  • Problem: 600 m/min, fehlerhafte Webkanten. Voller Stopp ist teuer; Ziel: Markierung statt Stopp, späterer Ausschussentscheid.

  • Architektur: Mehrkamera-Setup, Encoder-synchronisierte Trigger, zonenbasierte Klassifikation. Inline-Entscheidung in <10 ms für Marker-Auslösung; paralleles High-Res-Grab für spätere QS-Analyse.

  • Tradeoff: Konservativer Schwellenwert Live (False Positives akzeptiert → Markierung), strenger Offline-Klassifikator für endgültige Entscheidung. So bleibt der Live-Pfad deterministisch, während die Qualitätssicherung in Ruhe tiefer analysiert.

  • Drift: Neue Garncharge veränderte Textur; OOD-Quote stieg. On-Prem-Governance zeigte den Sprung; Daten flossen ins Retraining; Update via Schatten-Slot verifiziert – ohne Produktionsstillstand.

11) Warum Cloud-first hier scheitert

  • Netzwerklatenz ist nicht das Problem – Jitter und Nichtverfügbarkeit sind es. Integrierte Anlagen dulden keine unkalkulierbaren Pfade. „9x% Availability“ eines entfernten Dienstes ist für eine Linie, die alle 50 ms Entscheidungen trifft, faktisch unbrauchbar.

  • Datenhoheit ist nicht verhandelbar. Produktionsdaten verlassen den Werkszaun nicht, schon aus IP- und Vertragsgründen.

  • Operative Kontrolle: Wenn eine KI-Entscheidung die SPS beeinflusst, muss der Betreiber jeden Aspekt kontrollieren – von der Treiberversion bis zum Modell-Hash. Externe Managed-Services entziehen genau diese Kontrolle.

  • Fazit in einem Satz: Inline-Inspektion ist eine Steuerungsaufgabe mit ML-Komponente, keine Web-App mit ML-API.

12) Testen wie in der Realität, nicht wie im Notebook

  • Reproducible Replays: Produktionsnahe Datensätze mit originalen Timestamps durch die echte Pipeline jagen, nicht durch „Testmocks“, die die Scheduling-Realität verbergen.

  • Lasttests auf Peripherie: NIC, NVMe, PCIe-Bus, GPU unter realistischer Last messen. Viele „ML-Engpässe“ sind eigentlich IO-Probleme.

  • Fault Injection: Erzwungene Frame-Drops, verzögerte SPS-Acks, drosselnde Beleuchtungstreiber. Jeder Fehlerpfad braucht einen definierten Ausgang.

13) Was wir bewusst weglassen

  • Keine generische MLOps-Plattform in der Cloud.

  • Keine dynamischen Modellzoos in der Produktion.

  • Keine „Kamera per WLAN“, kein „wir loggen später“.

Meinung und Schluss
Wenn eine KI-Entscheidung in die Bewegungslogik einer Maschine eingreift, dann ist das ein Steuerungsproblem mit strengem Zeitverhalten – nicht ein „KI-Projekt“. Der Technik-Stack muss deterministisch, auditierbar und vollständig unter Werkskontrolle sein. Cloud kann eine Rolle im nichtzeitkritischen Umfeld spielen (z. B. Offlineschulung, Berichtswesen), aber nicht im Inline-Entscheidungspfad. Wer „Durchschnittslatenz“ optimiert, verliert an den Rändern. Wer Governance aufschiebt, verliert im Audit. Unsere Praxis zeigt: Halten Sie den Pfad kurz, fixieren Sie die Parameter, messen Sie alles, und behandeln Sie ML wie eine Komponente Ihrer Steuerung – dann sind 12–20 ms bis zum sicheren Signal nicht Magie, sondern Ingenieurarbeit. On-premise, souverän, reproduzierbar. (→ alpitype.de/leistungen/)