SPS-sichere KI: Architektur für ML-Inferenz an der Linie ohne Taktzeitverlust und ohne Cloud-Abhängigkeit

Das Problem
Die meisten KI-Pilotprojekte in der Produktion scheitern nicht am Modell, sondern an der Integration: Eine SPS verlangt deterministische Reaktionszeiten und ein klares Fehlerverhalten, während ein ML-Modell probabilistische Entscheidungen mit variabler Latenz liefert. Wer „mal eben“ ein Python-Skript neben die Linie stellt, riskiert Taktzeitrisse, falsch-positive Ausschleusungen und Audit-Probleme. Und: In vielen Werken sind Cloud-Verbindungen aus Datenschutz- und Souveränitätsgründen keine Option. Dieser Artikel beschreibt eine praxiserprobte Architektur, mit der ML-Inferenz an der Linie in bestehende SPS-Umgebungen integriert wird – on-premise, deterministisch und revisionssicher.

Kernanforderungen aus der Praxis
Bevor eine Architekturskizze Sinn ergibt, müssen die zwingenden Rahmenbedingungen klar sein. Typisch begegnen uns:

  • Harte Latenzbudgets: End-to-End (Trigger bis Aktor) im Bereich 10–100 ms je nach Prozess.
  • Determinismus: Worst-Case-Latenz ist wichtiger als der Mittelwert.
  • Fail-safe-Verhalten: Bei Fehlern muss das System in einen sicheren, definierten Zustand übergehen (z. B. Ausschleusung, Stopp, manuelle Prüfung).
  • Versionierbarkeit und Auditierbarkeit: Jede Entscheidung muss auf Modellversion, Datenrevision und Konfiguration rückführbar sein.
  • Offline-Betrieb: Keine Abhängigkeit von externen Cloud-Diensten; Netzwerkisolierung ist häufig gegeben.
  • Einfache SPS-Integration: Klare, primitive Signale statt komplexer KI-„Magie“ auf der SPS.

Architekturüberblick: ML als deterministisch eingehauster Sensor
Die zentrale Idee: Behandeln Sie ML wie einen Sensor mit bekannter Charakteristik und klar definierten vertraglichen Schnittstellen (Timing, Daten, Fehlerbilder). Die Intelligenz läuft auf einem Edge-IPC, die SPS behält die Prozesshoheit.

Komponenten und Verantwortlichkeiten:

  • SPS/PLC (Safety bleibt bei der SPS):
  • Taktgeber, Trigger, Aktorik
  • Einlesen einfacher Qualitäts- oder Anomalie-Flags
  • Umsetzung der Sicherheitslogik (z. B. „Zwei-Kanal-Freigabe“, Safe Torque Off)
  • Edge-IPC für ML-Inferenz:
  • Kamera-/Sensor-Anbindung und Vorverarbeitung
  • Inferenz-Pipeline (beschleunigt, quantisiert, deterministisch begrenzt)
  • Entscheidungslogik (Thresholds, Hysterese, Ensembling)
  • Watchdog/Heartbeat und deterministische Fallbacks
  • Kommunikationsschicht:
  • OPC UA PubSub oder Client/Server für strukturierte Daten
  • Alternativ: PROFINET/IO für binäre, echtzeitnahe Qualitätsbits
  • MQTT intern für Eventing in IT-Systeme (MES/QMS), aber nicht für die SPS-Echtzeit
  • Zeitbasis:
  • Einheitliche Zeitsynchronisation (z. B. PTP) zwischen Kamera, Edge-IPC und SPS, damit Triggers und Entscheidungen eindeutig zugeordnet werden können.
  • Datenhaltung und Governance:
  • Lokales Artefakt-Repository (Modelle, Konfigurationen) mit Signierung
  • Audit-Logs pro Entscheidung (Timestamp, Modellhash, Konfidenz, Input-Metadaten)
  • Ringpuffer für Rohdaten-Snippets zur späteren Ursachenanalyse

Datenfluss und Timing: Vom Trigger zur Aktion
Ein typischer Zyklus in der visuellen Inspektion:

1) Trigger von der SPS:

  • Digitale Flanke oder OPC-UA-Event mit Werkstück-ID und Geometrievariante.

  • Gleichzeitig Start des Taktzeit-Budgets, z. B. 50 ms.

2) Bildaufnahme und Vorverarbeitung:

  • Kamera-Trigger synchron zur Fördertechnik; Belichtungszeit im niedrigen ms-Bereich.

  • Zero-Copy-Transfer in GPU/Accelerator falls verfügbar.

  • Standardisierung (Crop, Normalize, Farbkonstanz, eventuelle Entzerrung).

3) Inferenz:

  • Laufzeitoptimiertes Modell (z. B. quantisiert auf INT8, kompiliert für Ziel-HW).

  • Single-sample Inferenz statt Micro-Batching, um Latenzspitzen zu vermeiden.

  • Latenzfenster und Abbruchkriterien (z. B. 8 ms Budget, harte Timeouts).

4) Entscheidungslogik:

  • Score -> boolesches Urteil via konfigurierbarem Threshold, Hysterese oder Kostenmatrix.

  • Optionale Heuristik-Checks (z. B. Area- oder Shape-Constraints), die deterministisch sind.

5) Rückmeldung an die SPS:

  • Quality_OK (BOOL), Confidence (REAL), Model_Version (STRING kurz) werden atomar bereitgestellt.

  • Handshake-Protokoll: SPS fordert Ergebnis für Trigger-N an, IPC bestätigt mit N und Status. Kein Ergebnis -> Default-to-Safe.

6) Aktorik:

  • SPS steuert Ausschleuser/Stopper basierend auf Quality_OK.

  • Safety-Funktionen bleiben vollständig in der SPS/Safety-PLC.

Timing-Tipps aus der Praxis:

  • Budgetieren Sie jede Stufe konservativ. Rechnen Sie Puffer für Garbage Collection, OS-Jitter und IO-Latenzen ein.
  • Eliminieren Sie nicht-deterministische Pfade: Kein On-the-fly-Download von Assets, kein wechselndes Pre-/Postprocessing.
  • Warmlauf-Phase: Laden und „primen“ Sie das Modell; die ersten 10–50 Inferenzläufe sind häufig langsamer.

Kommunikationsmuster, die funktionieren
Die Kommunikationsschnittstelle zur SPS ist der kritischste Teil, nicht das Modell.

  • Minimalistische Signale: Führen Sie die Entscheidung auf wenige Signale zurück:
  • Quality_OK (BOOL)
  • Confidence (REAL)
  • Result_ID (UINT)
  • Model_Version_Short (STRING, z. B. Git-Hash gekürzt)
  • Handshake:
  • SPS setzt Request_ID = N, IPC schreibt Result_ID = N, Status = OK/FAIL, Quality_OK, Confidence.
  • SPS quittiert und friert den Datensatz bis zum nächsten Request ein.
  • Heartbeat:
  • IPC toggelt ein Heartbeat-Bit in festem Takt (z. B. 10 Hz). Ausfall -> SPS auf sicheren Pfad.
  • Zeitfenster:
  • Definieren Sie hart: Wenn innerhalb X ms kein Ergebnis, dann Default-to-Safe (z. B. Ausschleusung).

Determinismus erzwingen: Inferenz „einhegen“
ML ist probabilistisch. Der Produktionsprozess darf es nicht sein. Maßnahmen:

  • Ressourcen-Pinning:
  • Dedizierte CPU-Kerne/NUMA-Zone für Inferenz; Prioritäten und Affinities setzen.
  • Fixed Paths:
  • Vor- und Nachverarbeitung in C++ oder anderweitig ohne JIT/Interpreter-Overhead; keine dynamischen Graphänderungen.
  • Pre-Allocation:
  • Puffer, Tensoren und DMA-Routen statisch anlegen; Ringpuffer für Frames.
  • Grenzwerte und Timeouts:
  • Maximal erlaubte Inferenzzeit; bei Überschreitung verwerfen und sicher handeln.
  • Model Cards und Konfig-Sperre:
  • Modell- und Konfigurationsparameter sind schreibgeschützt zur Laufzeit; Änderungen nur über einen freigegebenen Rollout-Prozess.

Qualitätssicherung und Observability vor Produktionsstart
Bevor das System in die aktive Steuerkette eingreift: