Blue/Green-Deployment von ML-Modellen an der Linie: SPS-sichere Umschaltung, Schattenmodus und Latenzbudget

Das konkrete Problem
Sie haben eine visuelle Qualitätskontrolle im Takt der Linie. Ein neues Modell verspricht weniger Pseudofehler. Aber: Wie schalten Sie ohne Stillstand, ohne Ausschuss und ohne “Hoffentlich passt’s”? Wie stellen Sie sicher, dass Latenz, Reproduzierbarkeit und Rückrollbarkeit messbar sind – in einer On-Prem-Umgebung ohne Cloud-Anbindung und unter den Zwängen von SPS/PLC-Logik?

Was folgt, ist eine Architektur aus der Praxis, mit der wir Modelle produktionssicher ausrollen: Blue/Green mit Schattenmodus, deterministische Umschaltung an der SPS-Grenze, strengem Latenzbudget und auditierbaren Artefakten – vollständig on-prem, DSGVO-konform und ohne US-Cloud-Abhängigkeit.

1) Anforderungen aus der Linie – nicht aus dem Notebook

  • Takt und Latenz: Entscheidungen müssen innerhalb eines festen Budgets vorliegen (z. B. 40–120 ms je nach Mechanik), sonst greift eine definierte Default-Strategie.

  • Determinismus: Keine “Best-effort”-Netzwerkaufrufe, kein unvorhersagbares Scheduling. Vorhersehbare Antwortzeiten sind wichtiger als maximale mittlere Performance.

  • Sicherheitsgrenzen: Die SPS bleibt Herr des Prozesses. ML liefert Empfehlungen/Prüfentscheidungen, aber keine sicherheitsgerichteten Funktionen. Fällt ML aus, muss der Prozess in einen sicheren, bekannten Zustand wechseln.

  • Souveränität: Daten, Modelle, Telemetrie, Logs – alles on-prem. Air-gapped oder kontrolliert angebunden. Artefakte signiert, versioniert und rückführbar.

  • Rückrollbarkeit: Rollback auf das “alte” Modell in Sekunden. Umschaltung muss über SPS/HMI kontrollierbar und nachvollziehbar sein.

  • Nachweisbarkeit: Jede Entscheidung muss mit Modellversion, Datenstempel, Bild-ID, Schwellenwerten dokumentiert sein – für interne QS und Audit.

2) Referenzarchitektur am Edge
Physische Komponenten

  • Edge-Node: x86_64-Industrie-PC mit RTX-/A-Series-GPU (alternativ: iGPU/OpenVINO), NVMe, redundante NICs. Optional zweiter Node als Hot-Standby.

  • Kameras/Sensorik: GigE Vision/USB3 Vision mit deterministischer Triggerung. Beleuchtung synchronisiert.

  • SPS/PLC: z. B. Siemens S7/TIA, Beckhoff TwinCAT, B&R; Schnittstellen: digitale IO, Profinet/ADS, OPC UA je nach Kritikalität.

Software-Stack (on-prem)

  • OS: Linux (mit stabiler LTS; optional PREEMPT_RT, wenn Systemjitter kritisch ist).

  • Orchestrierung: K3s für leichtgewichtige Container-Orchestrierung oder Docker Compose, wenn Einfachheit Priorität hat.

  • Artefakte: On-Prem-Registry (z. B. Harbor), signierte Container-Images, lokales Model-Registry (Dateibasiert + Checksums).

  • Inferenzdienste: Zwei identische Services (Blue = aktuell produktiv, Green = Kandidat) mit getrennten Runtime-Instanzen und dedizierten Ressourcen.

  • Frame-Bus: Zero-Copy-Pipeline via GStreamer/V4L2, Shared Memory Ringbuffer (Single Producer, Multi Consumer) für parallele Inferenz.

  • Decision-Gate: Ein separater Dienst, der Ergebnisse (Score, Klassen, Bounding Boxes, Latenz) beider Modelle entgegennimmt, mit Regeln bewertet und den “offiziellen” Entscheid an die SPS ausgibt.

  • Telemetrie: On-Prem-TSDB/Log (z. B. InfluxDB/Loki/Timescale-Äquivalent) + Export von Metriken, Model/Build-Infos. Audit-Store mit unveränderbaren Logs (WORM-Prinzip).

  • Governance: Gleiche Prinzipien wie in LLM-Agenten-Governance (Audit Trails, Policy Gates, Freigabestufen); falls LLM-Agenten im Betrieb (z. B. Assistenz für Störungsdiagnose) eingesetzt werden, werden diese über Alpi-M observiert und gesteuert. Für CV-Modelle analoger Governance-Prozess.

3) Datenfluss vom Trigger zur SPS – mit Budget
Beispielhafter Pfad und Budgetierung

  • T0: SPS setzt Trigger (digitale Flanke) → Kamera belichtet (Exposure 1–5 ms).

  • T0+Δ1: Frame in Edge-Node via GigE/USB3 (Transfer 2–10 ms), Zero-Copy in Ringbuffer.

  • T0+Δ2: Preprocessing (Debayer, Normalize, Resize) auf GPU/CPU (3–10 ms).

  • T0+Δ3: Inferenz (TensorRT/OpenVINO/ONNXRuntime mit passenden EPs) (5–30 ms je nach Modell).

  • T0+Δ4: Postprocessing (NMS, Geometrie, Kalibrierung) (1–5 ms).

  • T0+Δ5: Decision-Gate evaluiert Scores/Schwellen, Konsistenz mit Regeln (1–2 ms).

  • T0+Δ6: Ausgabe an SPS (digitale IO <1 ms, Feldbus/OPC UA je nach Stack 1–10 ms).

Das harte Budget wird aus der Mechanik abgeleitet. Kritisch: Worst-Case messen, nicht nur Mittelwert.

4) Blue/Green mit Schattenmodus – sicher umschalten

  • Doppelter Inferenzpfad: Blue (produktiv) bedient die SPS. Green arbeitet parallel im Schattenmodus auf demselben Frame-Stream.

  • Metrik-Sammlung: Für jede Teile-ID speichern wir beide Ergebnisse (Score, Klassifizierung, Laufzeit, Model-ID, Input-Hash, ggf. Crops). Keine Beeinflussung des Live-Entscheids.

  • Gatekeeper-Regeln zur Freigabe: Green wird erst produktiv, wenn:

  • Auf “Golden Batch” (historische repräsentative Daten) definierte KPIs erfüllt/überboten werden (z. B. weniger Pseudofehler bei gleicher Ausfallraten-Obergrenze).

  • Schattenmodus in Live-Produktion über X Teile Stabilität und Latenzgrenzen einhält.

  • Keine Drift-Indikatoren (z. B. Beleuchtungsvariationen) unbeherrscht sind.

  • Umschaltung: Entweder

  • manuell über HMI (freigegeben durch QS-Stufe), oder

  • automatisch durch Gatekeeper, der der SPS ein “Switch Window” anbietet (z. B. zwischen zwei Losen).

Umschalten bedeutet: Decision-Gate routet die SPS-Entscheidungen auf Green; Blue bleibt für sofortiges Rollback geladen.

  • Rollback: Ein SPS- oder HMI-Bit setzt Decision-Gate zurück auf Blue. Max. Umschaltzeit = 1–2 Zyklen, weil beide Modelle bereits warm sind.

Konsequenz: Keine Downtime, kein Blindflug. Die Linie bleibt deterministisch, weil die SPS nie direkt von zwei Modellen konkurrierende Signale erhält.

5) SPS-Integration: Drei stabile Muster

  • Muster A – Asynchron mit Timeout (empfohlen für Non-Critical):

  • SPS triggert Capture, wartet maximal T ms auf “OK/NOK/UNKNOWN”.

  • Kommt nichts oder UNKNOWN, greift Default (z. B. Ausschleusen/Einziehen, je nach Prozess).

  • Umsetzung: Digitale IO für Zeitkritik; OPC UA für Diagnose/Telemetrie.

  • Muster B – Zweistufige Entscheidung:

  • Modell liefert Vorentscheidung + Confidence.

  • SPS verknüpft mit Prozesskriterien (z. B. Sensor X, Messstation Y) und setzt erst dann den Aktor.

  • Vorteil: ML-Unsicherheit wird durch Prozesswissen abgefedert.

  • Muster C – Pufferzelle (für hohe Taktung):

  • Entscheidung erfolgt erst in der nächsten Station; Teile werden zwischengepuffert; mehr Budget für Inferenz, dafür Mechanik-Aufwand.

Was wir in der Praxis nicht empfehlen: Hard-Realtime-Entscheid per OPC UA allein, wenn digitale IO verfügbar ist. OPC UA ist top für Zustände, Konfigurationen, Telemetrie – nicht für 5-ms-Grenzfälle.