UI/UX für industrielle KI-Systeme: Sicherheit, Souveränität und Design unter Zeitdruck

In industriellen Systemen entscheidet UX über Sicherheit, nicht über Conversion Rates. Bediener treffen Entscheidungen unter Lärm, Zeitdruck und Ungewissheit. KI bringt zusätzliche Komplexität: Modelle liefern Wahrscheinlichkeiten statt Gewissheiten, Datenkanäle sind nie perfekt, Netzwerke sind oft on-premise und teilweise offline. Die Frage ist nicht, wie „schön“ eine Oberfläche aussieht, sondern wie sie die Wahrscheinlichkeit korrekter Entscheidungen erhöht – auch wenn Sensoren ausfallen, Modelle driften oder die Sonne auf den HMI-Bildschirm knallt.

Dieser Beitrag beschreibt konkrete Muster, Architekturen und Trade-offs für UI/UX in industriellen, KI-gestützten Systemen – mit Fokus auf Datenhoheit, On-Prem-Deployment und sicherheitskritische Abläufe.

Ausgangslage und Systemgrenzen: Die UI als Teil des Regelkreises

Bevor wir über Bedienelemente reden, klären wir den Systemkontext:

  • Wo läuft die UI? Panel-PC am Band, Leitstand, Tablet am Gleis, Ruggedized Laptop im Feld? Jedes Medium bringt Eingabe-, Helligkeits- und Vibrations-Constraints.

  • Welche Netzwerksituation ist realistisch? Air-gapped Netz, sporadische L2/L3-Ausfälle, PTP/NTP-Drift, Edge-Cluster ohne Internetzugang. Die UI muss staleness anzeigen, Befehle bei Unsicherheit sperren und offline-fähig sein.

  • Welche Latenz- und Aktualisierungsbudgets gelten? Legen Sie harte Budgets pro Use Case fest (Beobachten, Erkennen, Eingreifen). Die UI darf nie „jagen“ (ständig springen) und auch bei hoher Eventrate stabil bleiben.

  • Welche Sicherheitsklasse und Verantwortlichkeiten gelten? Trennen Sie Beobachtung von Steuerung. Sichere Aktionen brauchen höhere Reibung als ungefährliche.

  • Wie sieht die Datenhoheit aus? Kein externer Telemetrieabfluss, keine CDN-Abhängigkeiten, Updates kontrolliert und prüfbar. Ihre UI-Architektur muss das von Anfang an berücksichtigen.

Designprinzipien für KI-gestützte Entscheidungssysteme

1) Unsicherheit sichtbar machen – aber handlungsorientiert

  • Modelle liefern Unsicherheiten, nicht Wahrheiten. Zeigen Sie Konfidenz als Qualitäten, nicht als Prozent-Spielerei. Eine Operatorin braucht „hoch/mittel/niedrig“ mit klaren Aktionsvorschlägen, nicht 73,2%.

  • Vermeiden Sie binäre Labels. Zeigen Sie „Keine Entscheidung“ als gültigen Zustand, statt eine Entscheidung zu erzwingen.

  • Zeigen Sie Kontext: Welche Sensoren flossen ein? Welche waren degradet? Wann wurde das Modell zuletzt validiert?

  • Stellen Sie die Kosten beider Fehlerarten dar. Wenn ein „False Negative“ gefährlicher ist als ein „False Positive“, muss die UI das Risikoprofil widerspiegeln (z. B. striktere Schwellen mit zusätzlicher Bestätigung zum Überschreiben).

2) Provenienz und Nachvollziehbarkeit im UI verankern

  • Immer anzeigen: Datenzeitfenster, Datenquelle(n), Sensorge­sundheit, Modellversion, Regelbasisstand. Keine Entscheidungen ohne Versionen.

  • Verlinken, nicht verstecken: Von jedem Alarm zur Rohdatenspur springen können (Zeit synchronisiert), inklusive Health-Events (z. B. Sensor-Kalibrierung, Netzwechsel).

  • Drift- und OOD-Informationen (Out-of-Distribution) auf Artefaktebene einblenden, nicht als globale Lampe. „Diese Empfehlung basiert auf Daten außerhalb des Trainingsbereichs“ ist ein anderes Vertrauenssignal als „System generell gesund“.

3) Human-in-the-loop korrekt umsetzen

  • KI schlägt vor, Mensch entscheidet. Besonders bei sicherheitskritischen Aktionen niemals KI automatisch ausführen lassen.

  • Vorschläge müssen Maßnahmen enthalten, keine reinen Diagnosen. „Anomalie in Achse 3“ ist unzureichend. „Empfohlene Aktion: Linie in 30 Sekunden stoppen oder Drehzahl um 20% reduzieren. Gründe: Temperaturanstieg + Vibrationstrend.“

  • Implementieren Sie reversible Schritte und „Shadow Mode“: Neue Modelle laufen erst begleitend und werden im UI explizit als „experimentell“ gekennzeichnet. Akzeptanzquoten, Abweichungen und Korrekturen werden je Maßnahme geloggt.

4) Kriterien- und regelbasierte „Quality Stripes“

  • Jede Empfehlung bekommt eine Quality-Leiste: Datenvollständigkeit, Datenfrische, Sensorvertrauen, Regelkonformität, Modellkalibrierung. Diese Indicators sind konsistent und farb-/form-codiert, nicht nur farbabhängig.

  • Regeln schlagen KI. Wenn eine Sicherheitsregel verletzt wird, wird die Empfehlung geblockt und die Regelbegründung sichtbar.

5) Langzeit-Audit und Governance als UI-Fähigkeit

  • Jeder Klick, jede Ablehnung/Bestätigung ist mit Zeit, Nutzerrolle, Systemzustand, Daten- und Modellversion auditierbar – direkt aus der UI.

  • „Replay“-Fähigkeit: Zeitleistensteuerung, um jede Entscheidungssituation später exakt nachzustellen. Das UI ist nicht nur ein Frontend, sondern ein Fenster in eine reproduzierbare Ereignisspur.

Dashboard-Design für industrielle IoT-Daten

1) Topologie statt „Kachelwüste“

  • Organisieren Sie Informationen entlang der realen Anlage: Standort -> Linie -> Maschine -> Baugruppe -> Sensor. Navigierbar als Baum, Karte oder Graph.

  • Aggregieren Sie Kennzahlen topologiebezogen. „10 Pumpen OK, 1 Warnung, 0 Alarm“ auf Linienebene, mit Drill-down auf die fehlerhafte Baugruppe.

2) Ereignisse und Trends kombinieren

  • Ein zentrales Zeitfenster steuert alle Widgets synchron. Ereignisliste (Alarme, Wartungsaktionen) links, Zeitreihen-Trends rechts. Ein Cursor zeigt in allen Charts denselben Zeitpunkt.

  • Sparklines und Minicharts statt 20 große Graphen. Das UI zeigt per Default die letzten Minuten/Stunden, nicht „alle Zeit“.

3) Alarm-Design gegen Alarmflut

  • Deduplicate und korrelieren Sie Alarme, bevor sie an den Menschen gehen. Gruppieren nach Ursache, nicht nach Sensor.

  • Zustandsmaschine für Alarme: Neu -> Anstehend -> Quittiert -> Gelöst -> Verifiziert. Quittierung benötigt Rolle, Grund und ggf. Ticket-ID.

  • Backoff bei Fluten: Die UI priorisiert kritische Kanäle, drosselt Benachrichtigungen und zeigt eine „Flood active“-Hinweisleiste. In Flutmodus wird die Liste aggregiert („27 ähnliche Alarme unterdrückt“ mit expandierbarer Gruppe).

  • Acknowledge ist kein „Mute“. Eine quittierte Warnung bleibt sichtbar, bis die Bedingung tatsächlich endet oder Maßnahmen gesetzt sind.

4) Rate-Limits und Backpressure bis ins UI

  • Aktualisieren Sie Widgets mit festem Intervall und Priorisierung statt „push everything“. Stabilität schlägt Neuigkeitswert.

  • Zeigen Sie Datenstaleness pro Widget an. „Letztes Update vor 14 s“. Bei Überschreitung eines Grenzwerts steuert die UI in Degradationsmodus (weniger Detail, mehr Robustheitsinfos).

5) Offline- und Fehlerfälle sind erste Klasse

  • Trennen Sie klar: „keine Daten“ vs. „Daten veraltet“ vs. „Sensorfehler“. Unterschiedliche Icons und Texte.

  • Befehle sind im Zweifel gesperrt, mit Begründung („Antriebsstatus unbekannt – Steuerbefehl blockiert“).

  • Skeleton-States statt Flackern bei Ladezeiten. Nie leere Flächen ohne Erklärung.

Sicherheitskritische UI-Muster