7) Latenzmanagement auf dem Edge: P99 schlägt Durchschnitt

  • Pipelining: Frames durchlaufen Stufen (Capture, Preproc, Inferenz, Postproc) in einer Producer-Consumer-Pipeline mit bounded queues. Die Queue-Tiefe ist kritisch: zu tief = p99-Katastrophe. Lieber droppen als Schlange wachsen lassen.

  • Deadline-first Scheduling: Frames mit kürzerer Restzeit zuerst bearbeiten (Earliest Deadline First). Verhindert, dass ältere Frames jüngere überholen.

  • Warm-up: Modelle warmhalten, keine Power-Gating-Spitzen. Jede Kaltschicht startet in Shadow-Mode, bis p95 Latenz stabil ist.

  • Tail-Latenzmetriken: Messen und alarmieren auf p99 von Inferenz, Preproc und Übergabe getrennt. Nur so finden Sie Ausreißerquellen (z.B. sporadische NIC-IRQ-Stürme).

8) Modellierung: Genauigkeit vs. Taktzeit bewusst handeln

  • Binäre OK/NOK-Klassifikation schlägt vollumfängliches Segmentieren, wenn das Business-Ziel nur Ausschuss-Entscheidungen braucht. Postprocessing schrumpft.

  • Objekt-Detektion: NMS ist tail-latency-gefährlich. Alternativen: Center-based Decoder, Soft-NMS mit fixem Iterationsbudget oder kleine „head“-Netze mit linearem Decoder.

  • Quantisierung: INT8 mit Kalibrierung liefert oft 2–4x Speedup bei wenig Genauigkeitsverlust. Akzeptanzkritisch: wiederkehrende Latcheffekte vermeiden, also Kalibrierset repräsentativ halten.

  • Mehrere kleine Modelle > ein großes: Splitten nach Fehlerklassen, wenn es die Datenlage zulässt. Parallelisierung auf der GPU reduziert p99.

9) Übergabe-Logik in der SPS: Zustandsautomat statt „if score > 0.8 then NOK“
Statt nackter Schwellwerte nutzen wir in der SPS:

  • Hysterese: Zwei Grenzwerte für Rising/Falling, um Flip-Flop bei 0.79/0.81 zu verhindern.

  • Debounce-Zähler: Ein NOK wird erst nach k aufeinanderfolgenden NOKs scharf (abhängig von Prozess).

  • Mindestqualität: quality_flags müssen OK sein, sonst UNKNOWN. UNKNOWN wird behandelt wie definierter Fallback.

  • Sequenzprüfung: if seq != last_seq + 1 then Goto Fallback Pfad + Diagnosezähler hoch.

So entsteht deterministisches Verhalten, obwohl die Quelle probabilistisch ist.

10) Governance on-prem: Modelle wie Firmware behandeln
Wir sind kein Fan davon, Modelle wie flüchtige Assets zu behandeln. Für Produktionsumgebungen gilt:

  • Signierte Artefakte: Modelle (ONNX/TensorRT) und Preprocessing-Konfigs werden signiert. Der Edge lädt nur whitelisted Artefakte mit bekannter Fingerprint.
  • Reproduzierbare Builds: Container-Images sind deterministisch (fixierte Base, CUDA/TensorRT-Versionen gepinnt). Kein „pip install“ in der Linie.
  • Akzeptanztests vor Rollout:
  • Funktion: Fester Validierungsdatensatz mit deterministischer Metrik (z.B. F1@per-class).
  • Latenz: Benchmark auf Zielhardware unter Produktionslast (p50/p95/p99).
  • Robustheit: Jitter-Injektion in Capture/Netzwerk.
  • Rückroll-Test: Sofortiges Downgrade ohne Taktunterbrechung.
  • Shadow- und Blau/Grün-Deployment: Neues Modell läuft erst shadowed; bei Freigabe schaltet die SPS den „approved_model“ um (z.B. per Steuerwort), während das alte Modell weiter bereitsteht.
  • Observability: Zeitreihen zu Latenz, Dropped Frames, Sequence-Gaps, Score-Drift. Logs sind on-prem, DSGVO-konform. Keine Telemetrie außer Haus.

Für LLM-basierte Assistenzsysteme (z.B. für Werkerdokumentation, Störungsleitfäden) gelten ähnliche Governance-Prinzipien, ergänzt um Prompt-/Antwort-Logging, Rollback von Tooling-Policies und Zugriffssteuerung. Ohne Observability ist eine Produktionsintegration fahrlässig. (→ alpitype.de/leistungen/)

11) Praxisbeispiele aus Projekten

  • Visuelle Montageprüfung bei 120 Teilen/min
  • Problem: Orientierung und Vollständigkeit kleiner Bauteile, glänzende Oberflächen, stark schwankende Reflektionen.
  • Setup: Zwei synchron getriggerte GigE-Kameras, Stroboskoplicht, Edge-IPC mit RTX-GPU. PTP-Sync für Kamera und SPS.
  • Modell: Zwei kleine Detektoren (Teile-Orientierung, Teile-Vollständigkeit), INT8-quantisiert, zusammen p95 18 ms, p99 27 ms.
  • Handshake: Profinet IO, Telegrammzyklus 1 ms. Nachricht mit seq, deadline, decision, score, quality. TTL 80 ms.
  • SPS-Logik: Hysterese, Debounce=2, UNKNOWN führt zu mechanischer Ausschleusung in manuellen Check, Linie läuft weiter.
  • Ergebnis in Betrieb: Wegfall sporadischer Bandstopps. Hauptursache vor Projekt: Nachlaufende Frames ohne Deadlineprüfung fütterten veraltete Entscheidungen in die SPS.
  • Textilfertigung – Predictive Maintenance an Nadelmaschinen
  • Problem: Vibrationssensorik liefert hochfrequente Daten; Ziel ist frühzeitige Anomalieerkennung ohne Fehlalarme.
  • Setup: Edge-Controller nahe Maschine, Feature-Extraktion (STFT, spektrale Peaks), leichter Anomaliedetektor. Entscheidungen werden per OPC UA an die Linien-SPS publiziert—keine Echtzeit nötig, aber deterministische Aggregationsfenster.
  • Governance: On-prem Feature-/Modell-Registry, signierte Updates. Shadow-Fase über 6 Wochen zur Driftbeobachtung.
  • Bin-Picking mit KI-gesteuerter Greiferwahl
  • Problem: Auswahl des passenden Greifpunkts unter Zeitdruck, Greiferwechsel kostet 300 ms.
  • Setup: 3D-Kamera, Inferenz für Greifpunkt plus Qualitätsvektor. SPS bekommt top-1 und top-2 Greifpunkt mit Deadlines. Fallback-Regel: Wenn top-1 Quality < Schwelle oder Deadline überschritten, nutze top-2; sonst Standard-Greifer.
  • Ergebnis: Greiferwechsel nur noch bei Bedarf; Linie blieb deterministisch dank Deadline/Qualitäts-Handshake.

12) Teststrategie: HIL, deterministische Replays, Fehler provozieren

  • Hardware-in-the-Loop (HIL): SPS-Programm und Edge laufen wie in der Linie, Kamera wird durch deterministische Replays ersetzt. Netzwerktiming wird synthetisch gestört (Paketverluste, Burst-Jitter).

  • Freeze-Time-Replays: Gleiche Capture-Timestamps, identische Reihenfolge, so dass Latenz- und Entscheidungsvergleiche reproduzierbar sind.

  • Negative Tests: Überlange Belichtung, absichtliche Blendung, GPU-Drosselung. Ziel: Fallback greift, Linie bleibt stabil.

  • Audit Trails: Jede produktive NOK-Entscheidung ist später mit Bild, Modell-Fingerprint und Parametern nachvollziehbar.

13) Edge vs. zentrale KI-Services: bewusst trennen

  • Edge-Inferenz: Latenz, deterministische Übergabe, Prozessnähe. Keine Abhängigkeit von WAN/Cloud.

  • Zentrale Services on-prem: Trainingscluster, Label-Server, Feature Stores, Metrikdatenbank. Kommunikation asynchron, batch-orientiert, entkoppelt vom Takt.

  • Kein Mischmasch: Produktionsentscheidung darf nicht auf einen zentralen Service warten. Telemetrie und Training dürfen niemals die Echtzeit einschränken.