• Shadow Mode:
  • Das ML-System rechnet parallel, ohne die SPS-Entscheidung zu beeinflussen. Ergebnisse werden mit operatorischer Realität abgeglichen.
  • Golden Set:
  • Ein kuratierter Datensatz mit repräsentativen Gut-/Schlechtteilen unter echten Linienbedingungen. Zielmetriken werden vorab festgelegt.
  • Drift-Monitoring:
  • Online-Verteilung einfacher, robuster Features (Helligkeit, Kantenkontrast, Lage der ROI) zur Erkennung von Beleuchtungs- oder Kamera-Drift.
  • Traceability:
  • Jeder Entscheidungslog-Eintrag enthält: Timestamp, Trigger-ID, Modellhash, Konfidenz, Preprocessing-Config-Hash und optional einen Verweis auf das Bildsnippet im Ringpuffer.

Fail-safe-Strategien, die Ausfälle zu Ereignissen statt Katastrophen machen

  • Default-to-Safe:

  • Kein Ergebnis oder unerwarteter Zustand -> konservative Aktion (meist Ausschleusung/Stop).

  • Degradierte Modi:

  • Fällt die GPU aus, kann ein leichteres CPU-Modell ein grobes Screening übernehmen, das notfalls mehr ausschleust, aber die Linie nicht stoppt.

  • Watchdogs:

  • IPC überwacht KI-Prozess, SPS überwacht IPC via Heartbeat. Trennung von Beobachter und Beobachtetem.

  • A/B-Rollout ohne Downtime:

  • Zweites Modell inaktiv laden, warmhalten, Shadow vergleichen, dann atomarer Umschaltpunkt außerhalb der Taktspitze.

  • Persistenz und Reboot:

  • State möglichst im Prozesstakt stateless halten. Nach Reboot deterministisch in <1 s aufnahmebereit.

Integration in MES/QMS ohne Cloud

  • Ereignisse:

  • Prüfergebnis mit Werkstück-ID, Konfidenz und Modellversion an das interne MES/QMS via MQTT oder REST, nicht SPS.

  • Bildspeicherung:

  • Nicht jedes Bild langfristig speichern. Regeln: nur Ausnahmefälle, Stichproben, und strenge Retention/Anonymisierung.

  • Rückmeldeschleifen:

  • Bedieneroberflächen zur schnellen Re-Labeling-Feedbackschleife, aber mit Freigabe-Prozess; kein Online-Lernen an der Linie.

Sicherheitsarchitektur: KI darf niemals Safety ersetzen

  • Keine sicherheitsrelevanten Aktoren werden von KI direkt angesteuert. KI liefert nur „Empfehlungen“ als Nicht-Safety-Signale.

  • Safety-PLC setzt Sicherheitsfunktionen unverändert um (z. B. Zweihandauslösung, Lichtschranken).

  • Zweikanal-Logik für kritische Aktionen: KI-Bit + externes deterministisches Kriterium erforderlich.

  • Getrennte Netze: OT-Netz für SPS, isoliert von IT/Edge, mit definierten Gateways/DMZ.

Wartung, Updates und MLOps on-prem

  • Reproduzierbarkeit:

  • Modelle sind aus fest versionierten Daten und Code deterministisch baubar. Artefakte signieren.

  • Kalibrierung:

  • Nach jeder mechanischen Änderung (Kamera, Beleuchtung) Kalibrier- und Golden-Set-Tests verpflichtend.

  • Updatefenster:

  • Klare Wartungsfenster; Feature-Flags für sanfte Aktivierung neuer Schwellen und Heuristiken.

  • Governance:

  • Vier-Augen-Prinzip für Produktiv-Freigaben. Trennung von Entwicklung, Validierung und Betrieb.

  • Observability:

  • Latenzhistogramme, Throughput, Drop-Rates, Score-Drift und Fehlerzählungen lokal visualisieren. Keine Telemetrie nach außen.

Konkrete Szenarien aus Projekten

1) Visuelle End-of-Line-Inspektion, 120 Teile/min

  • Herausforderung:

  • 500 ms Taktzeit, davon maximal 40 ms für Bildaufnahme + Inferenz + Entscheidung, 60 ms für Aktorik.

  • Lösung:

  • PTP-Synchronisation von Kamera, IPC und SPS; belichtungsstabile Beleuchtung.

  • Quantisiertes Detektionsmodell, fest zugewiesene CPU/GPU-Ressourcen, Pre-Allocation sämtlicher Puffer.

  • Handshake über PROFINET/IO für Quality_OK und über OPC UA für Diagnose-/Versionstexte.

  • Fail-safe:

  • Fällt das Ergebnis aus, markiert SPS das Teil für manuelle Prüfung; Linie läuft weiter.

  • Ergebnis:

  • Stabiler Betrieb ohne Taktzeitrisse; Audit-Log pro Teil für Reklamationsmanagement.

2) Anomalieerkennung an Wälzlagern, 20 kHz Schwingungssensorik

  • Herausforderung:

  • Hohe Datenrate, Rolling-Window-Analyse, Latenzbudget 200 ms für Frühwarnung, keine Cloud.

  • Lösung:

  • Edge-Feature-Extraktion (Spektren, Ordnungsanalyse) in C++ mit Echtzeitpriorität.

  • Leichtes Autoencoder-Modell für Rekonstruktionsfehler, Hysterese zur Alarmglättung.

  • SPS erhält nur „Warnung_Stufe1/2“; detaillierte Telemetrie geht an das interne Instandhaltungssystem.

  • Governance:

  • Kein automatisches Eingreifen in Drehzahl; nur Empfehlung. Safety bleibt unberührt.

3) Textilfertigung: Fadenspannungsanomalien

  • Herausforderung:

  • Stochastische Störungen, wechselnde Garnsorten; Bediener müssen nachvollziehen, warum ausgeschleust wird.

  • Lösung:

  • Feature-Dashboard direkt in der Linie: Visualisierung einfacher, erklärbarer Metriken (z. B. Varianz, Peaks).

  • Konfidenz-Score wird als Prozentbereich angezeigt; Bediener kann Stichprobe markieren, die ins Golden Set wandert.

  • Ergebnis:

  • Höhere Akzeptanz, weniger „Black-Box“-Widerstand, klarer Freigabe-Prozess für Modellupdates.

Warum Cloud hier nichts zu suchen hat

  • Latenz und Determinismus: WAN macht deterministische Garantien praktisch unmöglich.

  • Souveränität und Audit: Produktions- und Bilddaten sollen das Werk nicht verlassen.

  • Verfügbarkeit: Wartungsfenster und Netzwerkisolation sind Planungsrealitäten, keine Ausnahmen.

  • Fazit: On-prem ist Default. Cloud hat ihren Platz in übergeordneten Analysen – aber nicht in der Echtzeit-Entscheidungskette an der SPS.

Was häufig schiefgeht – und wie Sie es vermeiden

  • „Wir hängen das Modell direkt in die SPS“:

  • Selbst wenn es technisch möglich scheint, leidet Wartbarkeit und Performance. Besser: Edge-IPC mit klarer, schmaler Schnittstelle.

  • Keine harte Deadline im Inferenzpfad:

  • Führt zu Taktzeitspitzen. Abhilfe: Timeouts, deterministische Pre-/Postprocessing-Pfade, Ressourcen-Pinning.

  • Keine Shadow-Phase:

  • Live-Risiko ohne empirische Passung. Abhilfe: Wochenweise Parallelbetrieb und quantitativer Vergleich.

  • Zu viele Daten in MES/QMS:

  • Datenhalden ohne Zweck. Abhilfe: Ereignisgetriebene Speicherung, Retentionsregeln, Stichproben.

  • Änderungen ohne Governance:

  • „Nur schnell Threshold anpassen“ endet in Audit-Fiasko. Abhilfe: Change-Requests, Versionierung, Signierung.

Ein Wort zu LLMs an der Linie
LLMs sind nützlich für Bedienerassistenz, Störungsdiagnosen und das Navigieren in Wartungshandbüchern. Die gleichen Prinzipien gelten:

  • On-prem RAG auf freigegebenen Dokumenten.

  • Keine Agenten mit direkter Aktuatorsteuerung.

  • Klare Observability: Prompt, Kontext, Tool-Aufrufe, Antwort – alles revisionssicher geloggt.

  • Governance: Freigegebene Werkzeuge, Whitelists, Zeit- und Rechtemodelle.

Für Observability und Governance lohnt es sich, eine Plattform zu nutzen, die diese Aspekte standardisiert, statt sie jedes Mal neu zu bauen (→ alpitype.de/leistungen/).