KI-Modelle in bestehende SPS-Steuerungen einbinden: Latenzgarantien, Handshakes und Fallback-Architekturen aus der Praxis

Das Problem
In der Fertigung trifft eine probabilistische KI-Entscheidung auf eine deterministische SPS-Logik mit Millisekunden-Budgets. Wer hier „einfach mal eine Kamera mit KI“ an die Linie hängt und einen OPC-UA-Tag „OK/NOK“ schreibt, fährt die Linie früher oder später in die Wand: verfehlte Taktzeit, sporadische Hänger, fehlende Nachvollziehbarkeit. Dieser Artikel beschreibt, wie man KI—insbesondere visuelle Inspektion—sauber an bestehende SPS-Umgebungen anbindet: mit harten Latenzbudgets, deterministischem Handshake, Safety-Fallbacks und on-premise Governance.

1) Anforderungen zuerst: Zeit- und Qualitätsbudgets definieren
Bevor eine Zeile Code entsteht, steht das End-to-End-Budget. Typische Schritte bei einer visuelle Prüfstation pro Teil:

  • Trigger bis Belichtung: 1–3 ms (HW-Trigger von der SPS an Kamera/Controller)
  • Belichtung und Sensor-Readout: 1–5 ms (abhängig von Licht, Bewegung, Rolling/Global Shutter)
  • Bildtransfer (GigE Vision/USB3/CameraLink): 3–10 ms (Netzwerkpfad, Paketverluste, Jumbo Frames)
  • Preprocessing (Crop, Normalize, Undistort): 1–4 ms (GPU/CPU, pipelined)
  • Inferenz: 10–30 ms (abhängig von Modell, Auflösung, TensorRT/ONNX Runtime)
  • Postprocessing (z.B. NMS, Geometrie-Checks): 1–5 ms
  • Übergabe an SPS (Profinet/Shared Memory/DIO): 1–3 ms
  • SPS-Logik und Aktor: 3–10 ms

Ziel-Takt: z.B. 120 Teile/min = 500 ms Zyklus. Unser KI-Pfad darf davon 30–80 ms belegen, mit p99-Latenz in diesem Fenster. Der Rest gehört Mechanik und SPS. Kritisch ist nicht der Mittelwert, sondern die Verteilung: p99 und ggf. p99.9. Jede Architekturentscheidung wird daran gemessen.

2) Architektur-Pattern: KI als „zeitgebundener Sensor“, nicht als Regler
In der SPS-Welt sind deterministische Zustände und Fristen entscheidend. Deshalb behandeln wir KI wie einen Sensor mit Verfallszeit (TTL), nicht wie ein steuerndes Gehirn.

Kernprinzipien:

  • Deadline-basiert: Jede KI-Antwort trägt eine Deadline (z.B. Timestamp + TTL=80 ms). Alles, was nach Ablauf eintrifft, wird von der SPS verworfen.

  • Qualitätsflag: Konfidenz und Qualitätsbits (z.B. Beleuchtungs-Sättigung, Bewegungsunschärfe) begleiten die Entscheidung.

  • Versionstransparenz: Jede Entscheidung ist mit Modell-Fingerprint (z.B. SHA-256 des ONNX/TensorRT-Artefakts) und Konfig-ID versehen. Ohne diese Metadaten ist die Entscheidung in der Produktion wertlos.

  • Shadow-first: Bevor ein Modell in den Entscheidungsweg wandert, läuft es in Shadow-Mode gegen das Live-Bild, protokolliert Entscheidungen, beeinflusst aber nichts.

3) Edge-Setup: Wo läuft die KI?
Für Fertigungslinien ist Cloud-Inferenz praktisch immer falsch: Latenzjitter, Verfügbarkeitsrisiko, Datensouveränität. In der Praxis nutzen wir:

  • Edge-IPC mit GPU: Industrie-PC mit NVIDIA GPU (RTX/IGX/Jetson) oder starker CPU+VNNI. Containerisiert (Docker/Podman), Onnx/TensorRT. Kein Internetzugang in der Produktionszelle.
  • Kameraanbindung: GigE Vision mit HW-Trigger und IEEE 1588 PTP-Zeitsync; alternativ CoaXPress/USB3 mit Trigger. Action Commands sind nur sekundär; Trigger kommt aus der SPS.
  • Netzwerktopologie: Kamera und Edge auf dediziertem VLAN/Segment. Kein Routing über Fabrik-Backbone. Jumbo Frames nur, wenn konstant und durchgängig unterstützt—sonst lieber kleinere MTUs, um Pufferjitter zu vermeiden.
  • OS- und Treiber-Tuning: CPU-Pinning, IRQ-Affinität der NIC, C-States drosseln, konstante GPU-Power-Profile. Ziel ist p99-Latenzglättung, nicht maximale Durchschnittsleistung.

4) Kommunikation zur SPS: Handshake statt „Best-Effort-Tag“
Die meisten Ausfälle stammen nicht aus dem Modell, sondern aus wackeliger Übergabe. Drei bewährte Pfade:

  • Profinet IO-Device Stack auf dem Edge: Für sub-10-ms Handshakes. Der Edge agiert als IO-Device, die SPS als Controller. Wir mappen minimale, starre Strukturen (OK/NOK, Seq, Quality, Valid-Bit).
  • Digital IO (kurzfristig/pragmatisch): Strobe-ähnliche Signale plus wenige Bits für Zustand. Robust, aber wenig Metadaten. Geeignet für Pilotierungen.
  • OPC UA (ergänzend): Für Diagnose, Langsamdaten, Batch-IDs, Modell-Metadaten. Nicht für Echtzeitentscheidungen. Sessions lang leben lassen (Handshake-Overhead vermeiden), Security on, aber ohne interaktives Prompting pro Teil.

Ausfallsicherheit: Der Edge sendet als „Publisher“ strikt monoton ansteigende Sequence-IDs. Die SPS prüft Sequence-Gaps. Eine Acknowledge-Schleife („Ack“ zurück) erhöht die Sicherheit, ist aber nicht immer nötig, wenn der Edge sowieso „Fire-and-forget“ innerhalb der Taktfenster betreibt und die SPS per Deadlines validiert.

Empfohlenes Nachrichtenlayout (kompakt):

  • seq: uint32 (monoton)

  • t_capture_ns: uint64 (PTP)

  • decision: enum {OK, NOK, UNKNOWN}

  • score: float32 (0..1)

  • quality_flags: bitmask (z.B. glare, blur, low_light)

  • deadline_ns: uint64 (t_capture + TTL)

  • model_fingerprint: 128-bit (gekürzt)

  • calib_id: uint16

  • bbox_count + top-k Defekte (optional, nur für Diagnose)

  • crc16: uint16

Die SPS prüft:

  • deadline_ns > now: sonst verwerfen

  • seq == last_seq + 1: sonst Gap-Handling

  • quality_flags == 0 oder tolerierbar

  • score >= thresholds[hysterese_state]

  • model_fingerprint == approved_model

5) Safety: KI bleibt außerhalb des Sicherheitskreises
Wesentliche Regeln, die wir in Projekten nie brechen:

  • Keine KI im Safety-Kreis: Sicherheitsreaktionen (Not-Aus, Schutztüren, 2-Hand) sind unabhängig. KI kann nur Empfehlungen oder Nicht-Sicherheitsentscheidungen liefern.

  • Zwei-Kanal-Strategien bei risikoarmen, aber teuren Fehlklassifikationen: Ein deterministisches Heuristik-/Regelset (Kanal A) plus KI (Kanal B). Entscheidung nach 2oo2 (beide zustimmen) oder 1oo2 mit Eskalation bei Widerspruch—vom Risikoprofil abhängig.

  • Fallback definiert: UNKNOWN oder überschrittene Deadline führt zu vordefiniertem, sicheren Anlagenzustand (z.B. Umleitung in manuelle Nachprüfung, Stoppen eines Segmentförderers, aber kein harter Anlagenstillstand).

6) Lighting, Trigger und Bilddisziplin: 50% der „KI-Probleme“ sind Optik
Wir sehen in Linien, dass „die KI“ angeblich versagt—tatsächlich ist es die Bildqualität:

  • Stroboskopisches Licht, getriggert von der SPS, mit fester Pulse-Width koordiniert zur Belichtungszeit. So frieren Sie Bewegung ein bei kurzen Belichtungen.

  • Polarisationsfilter oder dome lighting, um Glanzstellen zu eliminieren. Qualität_flag glare wird zur SPS mitgegeben und ggf. als NOK gewertet.

  • Region-of-Interest (ROI) bereits in der Kamera oder im Preprocessing, um Datenpfad zu entlasten und Latenz zu sparen.

  • Periodische Selbstkalibrierung: Checkerboard-Shots außerhalb der Taktung, um Intrinsics/Extrinsics zu prüfen. Calib-ID wandert mit zur SPS.