14) Trade-offs und Fallstricke

  • OPC UA als alleiniger Pfad für Echtzeit-OK/NOK: führt oft zu Jitter, wenn Security/Session-Handling schlecht konfiguriert ist. Lösung: Profinet/DIO für die schnellen Bits, OPC UA für Metadaten.

  • „Wir nehmen einfach das präzisere Modell“: Wenn p99 > Budget, stirbt die Linie an Schwanzlatenz. Besser zwei kleinere Modelle, die zusammen robust sind.

  • „Wir lassen Frames nie fallen“: Klingt gut, tötet aber die Taktstabilität. Bounded Queues + Dropping über Deadline sind Pflicht.

  • „KI sagt STOP“: Nein. KI sagt „NOK/UNKNOWN + Qualität“. Die SPS entscheidet, wie STOP/Eskalation aussehen.

15) Meinung: KI in der Linie ist ein Sensor mit Verfallsdatum
Wer KI in die SPS-Welt integriert, ohne Deadlines, Sequenzen, Versionen und Fallbacks zu definieren, baut eine Störquelle, keinen Mehrwert. Wir vertreten eine klare Linie:

  • KI liefert zeitgebundene Beobachtungen.

  • Die SPS bleibt Herr des Verfahrens und des Sicherheitskonzepts.

  • On-premise Governance ist nicht optional. Modelle sind Produktionsartefakte wie Firmware, nicht wie PowerPoint-Folien.

Wenn diese Grundsätze gelten, skalieren visuelle Inspektion, Anomalieerkennung und operatornahe Assistenzsysteme stabil und nachvollziehbar. Wenn nicht, werden Sie Debugger Ihrer eigenen Ausfälle. (→ alpitype.de/leistungen/)

FAQ – Technische Detailfragen

1) Wie stelle ich p99-Latenz sicher und messe sie korrekt?

  • Messen Sie jede Stufe getrennt: Capture, Transfer, Preproc, Inferenz, Postproc, Übergabe. Nutzen Sie monotone, PTP-synchronisierte Timestamps.

  • Loggen Sie pro Frame: t_in, t_out, deadline, dropped? true/false.

  • Alarme auf p95/p99, nicht nur Durchschnitt.

  • Vermeiden Sie globale Queues. Nutzen Sie bounded Queues pro Stufe und geben Sie späte Frames früh auf (Deadline-aware Scheduling).

2) PTP-Zeitsynchronisation in der Praxis: Worauf achten?

  • Eine Quelle (Grandmaster) pro Zelle, stabile Hierarchie. Kamera, Edge-IPC und ggf. SPS als PTP-Clients.

  • Netzwerk-Switches PTP-aware konfigurieren oder PTP über dediziertes Segment führen.

  • Zeitdrift regelmäßig prüfen; Drift >1 ms ist für straffe Budgets kritisch.

3) Profinet IO-Device auf Linux-Edge: Welche Optionen?

  • Kommerzielle Stacks liefern robuste Realisierungen und Zertifizierbarkeit; Open-Source ist oft für Piloten ok, aber für Produktion selten ausreichend.

  • Zykluszeiten unter 4 ms sind machbar, wenn NIC-Treiber und CPU-Isolation stimmen.

  • Minimalistische Telegramme mit fixen Längen halten und Parsing im SPS-Programm simpel halten.

4) Wie rolle ich ein neues Modell ohne Taktunterbrechung aus?

  • Shadow-Mode parallel zum aktiven Modell betreiben.

  • Blau/Grün: Beide Modelle laufen; die SPS akzeptiert nur Freigabe-Fingerprint.

  • Umschaltkriterium: definierte Metriken auf Live-Daten + stabile Latenz über definierte Schichten.

  • Rollback jederzeit über SPS-Steuerwort; Edge hält Vorversion im Speicher.

5) Wie gehe ich mit Modelldrift um, ohne die Linie zu riskieren?

  • Drift-Detektoren auf Score-Verteilung (Population-Shift) und Qualitätsflags.

  • Periodische Stichprobenprüfung: Stichprobe in die Label-Pipeline (on-prem) geben.

  • Keine Autoupdates. Nur signierte, geprüfte Modelle, nach Shadow-Phase, mit Audit-Trail.

Schluss
KI an die SPS zu hängen ist kein „OPC-UA-Tag beschreiben“. Es ist ein Architekturdiskurs über deterministische Übergabe, Latenzbudgets, Safety und Governance. Behandeln Sie KI wie einen Sensor mit Verfallsdatum, nicht wie einen Regler. Dann bleibt die Linie stabil, erklärbar und souverän—ohne Cloud-Abhängigkeiten, ohne Telemetrie-Leaks, und mit der SPS als Chef im Ring. Wenn Sie genau so bauen wollen, reden wir über die konkreten Randbedingungen Ihrer Linie und das passende Integrationsmuster. (→ alpitype.de/leistungen/)