SPS-Integration: Handshake, der unter Taktbedingungen hält
Verwenden Sie eine Handshake-Logik, die deterministische Reaktionszeiten erzwingt und ein sicheres Fallback definiert. Ein bewährtes Muster über diskrete IO:

  • Signale SPS->Vision: Inspect_Request, Part_ID optional (kodiert), Reset/Abort.

  • Signale Vision->SPS: Vision_Busy, Result_Valid, Result_Good, Error_Code optional (kodiert).

  • Ablauf:

1) SPS setzt Inspect_Request, wenn Teil in Position ist (oder direkt über Hardware-Trigger an Kamera; Inspect_Request dient der Synchronisation).
2) Vision setzt Vision_Busy innerhalb <1 ms, startet Aufnahme/Inferenz.
3) Vision setzt Result_Valid mit Result_Good=0/1, sobald Ergebnis vorliegt.
4) SPS liest Result_Valid und Result_Good innerhalb des gepufferten Taktfensters, führt Aktorik aus.
5) SPS setzt Inspect_Request zurück, Vision setzt Vision_Busy und Result_Valid zurück.

  • Timeout: Kommt kein Result_Valid innerhalb z. B. 35 ms, nimmt SPS „Bad“ an und agiert fail-safe. Die Vision protokolliert den Timeout als Event.

  • Re-Entrancy verhindern: Solange Vision_Busy=1, darf SPS kein neues Inspect_Request setzen (oder es wird verworfen). Alternativ: Zwei-Kanal-Betrieb mit Ping-Pong-Instanzen für sehr kurze Takte.

Feldbus oder diskrete IO?

  • Diskrete IO (24V): Minimale Latenz, sehr deterministisch, simpel zu debuggen. Begrenzte Signalbreite – ausreichend für Good/Bad/Busy/Valid plus begrenzte Fehlercodes.

  • Feldbus (z. B. PROFINET, EtherCAT): Gut, wenn Ergebnis mehr Bits benötigt (Klassen, Fehlerursachen) oder wenn mehrere Kameras/Stationen konsolidiert werden. Achten Sie auf isochronen Betrieb und praktische Taktzyklen. Platzieren Sie die Vision nicht hinter einer „Office“-Switch-Kaskade.

  • OPC UA: Ideal für Diagnose, Kennzahlen, Batch-IDs, nicht für 10–30-ms-Entscheidungspfade im Standard-Client/Server-Modus. Für harte Echtzeit wird’s schnell komplex.

Rechenplattform: Jetson vs. x86/dGPU – was zählt für deterministische Latenz?

  • Jetson (Orin, Xavier): Kompakt, energieeffizient, gute Toolchains (TensorRT), stabile Latenzen bei Engine=Batch1 und fixierten Clocks. Vorteilhaft, wenn Platz/Leistungsklasse begrenzt und 1–2 Kameras versorgt werden.

  • x86 + dGPU (RTX/Industrial): Höhere Peak-Leistung, bessere Spielräume bei mehreren Streams/Kameras, aber mehr Tuning-Aufwand für deterministische Latenzen (PCIe, NUMA, Interrupt-Affinität).

  • CPU-only (AVX/AMX/OpenVINO): Für einfache Modelle oder sehr kurze Pfade ausreichend, bestechend deterministisch, weil weniger Shared-Resource-Contention als bei GPUs. Lohnt bei gut optimierten kleineren Netzen (MobileNet/ResNet-18) und 1-Kamera-Szenarien.

Praxisnahe Latenz-Budgets (Richtwerte aus Projekterfahrung)

  • Kamera/Belichtung: 0,2–2 ms

  • Sensor-zu-Host Transfer (GigE, Zero-Copy): 1–4 ms

  • Preprocessing (GPU): 0,5–2 ms

  • Inferenz (INT8 quantisierte ResNet-18/Detektor): 3–10 ms je nach Hardware

  • Postprocessing: 0,2–1 ms

  • IO-Signal an SPS: <1 ms bei diskreter IO, 1–3 ms bei Feldbus (konfigurationsabhängig)

  • Gesamt: 6–20 ms typisch, 30–40 ms mit großzügigen Puffern/Komplexität. Entscheidend ist die Varianz: P99 muss unter Ihrer Taktgrenze liegen.

Quantisierung und Stabilität: INT8 ist kein Selbstzweck

  • INT8-Quantisierung spart Latenz und Energie, kann aber bei schlecht kalibrierten Datensätzen zu Varianz und Fehlklassifikationen führen.

  • Kalibrierung mit repräsentativen Produktionsdaten (inkl. Randfälle, Beleuchtungsvarianten) ist Pflicht. Keine Labordaten-only-Kalibrierung.

  • Messen Sie nicht nur Mittelwerte, sondern die P95/P99-Latenzen vor und nach der Quantisierung. Eine 20% schnellere, aber „zappelige“ Engine ist im Taktbetrieb nutzlos.

  • Fixierte Preprocessing-Pfade (gleiche Normalisierung, gleiche Farbprofile) zwischen Training und Inferenz sind notwendig, sonst driftet das Ergebnis – und damit Ihr Latenzbudget durch zusätzliche Fehlerbehandlung.

Betriebssystem und Scheduling: Wie Sie Jitter im Griff behalten

  • Realtime-Kernel/Settings: PREEMPT_RT, CPU-Isolation (isolcpus/nohz_full/rcu_nocbs), IRQ-Affinitäten. Weisen Sie Kamera-IRQ und Vision-Threads fixen Kernen zu.

  • SCHED_FIFO/SCHED_RR für Hot-Path-Threads. Hüten Sie sich vor Priority-Inversion – sperren Sie nicht auf shared mutexen im Hot-Path.

  • Power-Management: Deaktivieren Sie CPU-C-States tiefen Schlafs für die „Hot“-Kerne. Fixieren Sie GPU/SoC-Frequenzen.

  • Speicher: HugePages/Locked Memory für Inferenz-Puffer, um Page-Faults zu vermeiden.

  • Logging: Asynchron, ringgepuffert, verlusttolerant. Kein Sync-File-Logging im Hot-Path.

Fallback-Strategien: Wenn etwas schiefgeht, entscheidet das System trotzdem richtig

  • Zeitbasierter Fallback: Keine Antwort der Vision bis Tdeadline? SPS nimmt „Bad“ an. Das senkt Ausschuss-Kosten gegenüber Produktionsstopp.

  • Degradierter Modus: Wenn KI-Engine nicht geladen werden kann, fällt das System auf einfache Regeln zurück (z. B. Konturerkennung) – mit dokumentiert schlechterer, aber deterministischer Qualität. Automatisch meldet das System „Degraded Mode“ an die SPS/Leitwarte.

  • Watchdogs: Prozess- und Hardware-Watchdogs, die bei Hängern neu starten, ohne die Linie anzuhalten.

  • A/B-Deployment: Zwei Engines parallel (nur eine liefert Ergebnis), Umschalten nur außerhalb des Taktfensters. A/B dient der sicheren Einführung neuer Modelle ohne Latenzüberraschungen.

Datenhaltung und Souveränität: On-Prem ist kein Dogma, sondern eine Systemanforderung

  • Keine Cloud im Entscheidungs-Pfad. Selbst „Edge-to-Cloud-Roundtrip“ von 20–30 ms unter Idealbedingungen ist in der Fabrik unbeherrschbar. Außerdem: Datenschutz, Verfügbarkeit, Abhängigkeiten.

  • On-Prem-Training/Feinjustierung: Daten bleiben im Werk oder im Rechenzentrum des Unternehmens. Modell-Updates werden signiert und über kontrollierte Kanäle verteilt (Air-Gap-fähig).

  • Auditierbarkeit: Speichern Sie stichprobenartige Frames mit Ergebnis, Latenz und Seriennummer, aber nicht jede Aufnahme. Sampling-Strategie so wählen, dass Speicherbedarf planbar ist.

  • Observability: Latenzhistogramme, Drop-Zähler, Timeout-Raten, Engine-Versionierung – alles lokal first, export optional. Governance und Nachvollziehbarkeit sind nicht „Nettigkeiten“, sondern Ihre Versicherung im Auditszenario. (→ alpitype.de/leistungen/)