Safety- und Functional-Boundaries

  • KI trifft keine Safety-Funktionen. Not-Halt, Lichtschranken, Safe Torque Off bleiben in Safety-SPS/HW.

  • „AI proposes; PLC disposes“: SPS prüft Plausibilität (z. B. Fensterlogik: nur Entscheidungen innerhalb [t_min, t_max] akzeptieren).

  • Fallbacks:

  • Zeitbasierter Fallback: Wenn decision_ready nicht rechtzeitig kommt ⇒ Defaultentscheidung oder Ausschleusen.

  • OOD/Unsicherheit: Wenn Confidence < Schwellwert ⇒ definierter Safe-Mode (z. B. Ausschleusen + Markierung).

  • KI-Box Down: Heartbeat-Ausfall ⇒ SPS schaltet auf konservative Logik.

Zeit- und Positionszuordnung

  • Kameratrigger erhalten Encoderposition (z. B. via 24V-Inkrementalgeber an SPS; Position via Feldbus zur KI-Box spiegeln).

  • Mapping Kamera-Zeitstempel → Förderband-Position; deterministisches Delay-Kompensationsmodell (Kalibrierung bei Inbetriebnahme).

  • Pufferung von N letzten Entscheidungen mit Position; SPS liest passende Entscheidung exakt am Weichenfenster.

Software-Lifecycle und Update-Strategie

  • Container ja, Orchestrierung nein (in der Zelle):

  • Docker/Podman + nvidia-container-runtime, systemd als Supervisor. Kubernetes erzeugt unnötigen Jitter/Komplexität im Taktkreis.

  • Atomic Updates:

  • A/B-RootFS (RAUC/Mender), signierte Images; Blue/Green pro Zelle, canary an einer Linie, Rollback in <1 min.

  • Versionierung:

  • MLflow/DVC für Modelle/Daten; jede TensorRT-Engine mit eindeutiger ID, Preprocessing-Hash, Kalibrier-Dataset-Referenz.

  • Re-Training on-prem:

  • Edge-Daten werden zeitversetzt in Werk-DMZ gespiegelt; Training auf On-Prem-GPU-Knoten; kein US-Cloud-Zwang.

  • Qualitätssicherung:

  • Golden-Set pro Linie, Acceptance-Kriterien: p99.9-Latenz, FNR/FPR unter Linienziel, OOD-Verhalten dokumentiert.

  • HIL-Tests gegen SPS-Teststand (OBs, Feldbus-Telegramme, IO-Handshakes simuliert).

Beispielzahlen aus der Praxis
Linie: 2 Kameras, 60 FPS je Stream, Teileabstand 450 ms.

  • Kamera → RAM: 5.2 ms p99.9 (GigE Vision, Jumbo Frames, dedizierte NIC)

  • Preproc (resize 1280→640, normalize): 3.4 ms p99.9 (CUDA)

  • Inferenz (YOLOX-s INT8 @ Orin NX): 11.8 ms p99.9

  • Postproc (NMS GPU + ROI-Check CPU): 3.1 ms p99.9

  • Feldbus Write (PROFINET RT, 2 Enums + Timestamp): 1.6 ms p99.9

Gesamt KI-Pfad: 25.1 ms p99.9. Jitter-Hotspots vor Optimierung: Preproc-Kopien (gelöst mit Zero-Copy), Python-NMS (in C++/CUDA verschoben), GC-Pausen (ganz entfernt).

Daten- und Drift-Management

  • Kontinuierliche Metriken:

  • Produktionsmetriken: Latenz p95/p99.9, Drop-Frames, Timeout-Rate, Anteil OOD.

  • Qualitätsmetriken: FP/FN per Schicht (verknüpft mit Ausschleusung/RMA).

  • Drift-Erkennung:

  • Embedding-Statistiken (z. B. Feature-Histogramme der letzten 24h vs. Baseline), Alarm bei Verteilungsshifts.

  • Labeling-Loop:

  • Asynchroner Review-Client für ausgeschleuste Teile; Golden-Set aktualisieren; geplante Re-Trainingsfenster.

  • Governance:

  • Daten verbleiben on-prem (DSGVO, IP); Zugriffe rollenbasiert; Audit-Trail der Modellversionen und Entscheidungen.

Mechanische und optische Grundlagen (die oft übersehen werden)

  • Beleuchtung ist „der halbe Klassifikator“. Stabilisierte, diffuse Beleuchtung mit reproduzierbarer Geometrie verringert Modellkomplexität und Jitter.

  • Vibrationsentkopplung der Kameras; Triggerleitung abgeschirmt, kurze Wege.

  • Regelmäßige Re-Kalibrierung von Belichtung/Weißabgleich als Teil der Wartung; Metrikbasiert (Mean/Std der Raw-Pixel pro Schicht).

Was wir ablehnen

  • „Edge-to-Cloud-Roundtrip im Takt“: Für Inline-Entscheidungen in unter 100 ms kompromisslos ungeeignet.

  • „Python-only-Produktivpfad“: Schnell gebaut, später teuer – wir trennen Hot Path (C++/CUDA) und Orchestrierung (Python/Go).

  • „KI ersetzt Safety“: Nicht in 2026, nicht in dieser Form. Safety-Funktionen bleiben deterministisch/hardwired.

Praxisbezug: drei typische Szenarien

  • Montage – Schrauberstation:

  • Ziel: Erkennen fehlender Unterlegscheiben in <40 ms. Lösung: 2 Kameras mit ringförmiger Beleuchtung; Jetson Orin; IO-Handshake; p99.9 18 ms. Fallback: Ausschleusen bei Timeout.

  • Textil – Oberflächenfehler:

  • Ziel: Öl-/Zugfäden erkennen bei 2 m/s. Lösung: Zeilenkamera, Encoder-Sync, Segmentierung light, x86+RTX wegen Zeilenrate. Async Kafka für Bildausschnitte; Re-Training on-prem.

  • Lebensmittel – Etikettierung:

  • Ziel: Falschetikett/Schiefstand, 200 ppm. Lösung: Detektion + Heuristik (Geometrie), EtherCAT-UDT an SPS; Safety strikt getrennt; p99.9 22 ms.

Fazit
Deterministische Inline-KI entsteht nicht durch „noch ein stärkeres Modell“, sondern durch eine Architektur, die Jitter eliminiert: Hardware-Triggerung, Zero-Copy, Batch=1, INT8, fest verdrahtete Hot-Paths, klare SPS-Handshakes, Safety-Abgrenzung und ein asynchroner Nebenpfad für Daten. Cloud-first ist hier ein Anti-Pattern. Wer diese Prinzipien ignoriert, baut Latenz-Lotterie – und bezahlt sie mit Taktverlusten und Fehlteilen.

Wenn Sie so ein System bauen oder sanieren wollen: Wir übernehmen Technical Ownership von der Anforderung bis zur Abnahme – inkl. On-Prem-ML-Ops, HIL-Tests mit Ihrer SPS und signierten A/B-Updates (→ alpitype.de/leistungen/).

FAQ
1) Wie erreiche ich deterministische Latenzen auf Linux?

  • PREEMPT_RT-Kernel, CPU-Isolation (isolcpus/nohz_full) für Inferenz-Threads, IRQ-Affinität für NIC/Kamera auf dedizierte Kerne, Hugepages. Keine Speicherallokationen im Hot Path, keine GC-Sprachen dort. I/O über DMA und Zero-Copy (NVMM/GPUDirect), feste Thread-Prioritäten (SCHED_FIFO).

2) Jetson Orin oder x86+RTX für meine Anwendung?

  • Unter 3 Kameras und moderater Auflösung/FPS genügt Orin NX/AGX mit TensorRT INT8. Bei Zeilenkameras hoher Taktung, >4 Streams oder komplexer Segmentierung ist x86+RTX robuster (mehr Speicherbandbreite, bessere NIC/Framegrabber-Optionen). EMV/Thermik und Lebenszyklus beachten.

3) Wie kalibriere ich INT8, ohne Genauigkeit zu verlieren?

  • Repräsentatives Kalibrier-Set aus der Ziel-Linie (verschiedene Schichten, Belichtungen, Chargen). Vorkalibrierung offline, danach Validierung auf p99.9-Latenz UND Qualitätsmetriken (FPR/FNR). Kritische Layer ggf. auf FP16 lassen (Mixed Precision). Keine nachträglichen Preprocessing-Änderungen ohne Rebuild der Engine.

4) PROFINET/EtherCAT oder digitale IO für Entscheidungen?

  • Brauchen Sie maximale Deterministik mit minimalem Payload (z. B. reine Ausschleusung), sind digitale IO-Handshakes unschlagbar. Müssen Sie zusätzlich Timestamp/Confidence übertragen und in der SPS weiterverarbeiten, ist ein kleiner zyklischer UDT über PROFINET/EtherCAT sinnvoll. Große Payloads immer auslagern (MQTT/Kafka).

5) Wie valide ich OOD- und Unsicherheitsfälle in der Produktion?

  • OOD-Scores oder Confidence-Schwellen definieren, dann im HIL-Setup und in einer begrenzten Produktionsphase testen. Metriken: Rate „Unsicher“ pro Schicht, Konsequenz in der Linie (Ausschleusen/Manuell prüfen), Einfluss auf Takt. OOD-Auslöser und Beispiele versionieren; Re-Trainingsfenster und -Kriterien festlegen.