• Triage-Header: Links die kritischste Anlage/Flotte mit Alarmzustand, mittig Systemgesundheit (Backlog, Latenz, Dropped Messages), rechts Nutzerkontext (Rolle, Sperren, Schicht). Eine Blickachse, keine Spielwiese.
  • Ereignis-Queue mit Dedup und Korrelation: Statt „Alarmflut“ sehen Bediener korrelierte Root-Cause-Cluster. Ein Alarm darf sich nicht 200-fach materialisieren, wenn es eine Ursache gibt.
  • Trend + Sparklines: Für jede Kernmetrik ein 2–5-Minuten-Fenster plus Sparklines auf Asset-Karten. Decimation/Downsampling serverseitig, damit die GPU für das Wesentliche frei bleibt.
  • Raumbezug: Karten/Layouts mit logischen Zonen. Layer an/aus per Hotkeys, nicht über verschachtelte Menüs.
  • Asset-Detail: Einheitliches Template: Status, letzte N Ereignisse, aktuelle Steuerungen, KI-Empfehlungen, relevante Historie. Keine Überraschungen pro Asset-Typ.
  • Zeitsteuerung: Freeze/Live-Toggle und Scrubber mit deterministischem Verhalten. „Freeze“ friert Datenzustrom in der UI, nicht im System. Beim Rückkehr zu Live wird Lücke explizit markiert.

Leistungsseitig: Rate-Limits und Priorisierung gehören ins UI-Konzept. Beispiel: Max. 10 Updates/s für nicht-kritische Charts, Alarmbanner priorisiert. Wenn Frames droppen, zeig es. Keine Illusion von Aktualität.

5) Sicherheitskritische Interaktionen: Fehler verzeihen, aber nicht verharmlosen

  • Do-Confirm vs. Confirm: Gefährliche Aktionen sollten im Do-Confirm-Muster stattfinden: Erste Eingabe löst Aktion aus, zweite Chance zum Abbrechen in kurzem Fenster mit klarer Rückgängig-Möglichkeit, sofern reversibel. Für irreversible Aktionen: Zwei-Kanal-Bestätigung (z. B. Hardware-Taste + Software-Prompt, oder Doppelbestätigung durch zwei Rollen).
  • Sperrzustände explizit: Wartung, Test, Schattenmodus, Automatik – jeder Zustand hat klare visuelle Sprache und beschränkt Interaktionen. Nichts ist tückischer als „Ich dachte, ich sei im Testmodus“.
  • Degradationsmodi: Wenn KI oder Sensorik ausfällt, wechselt das UI automatisch auf manuelle Checklisten und Rohsignale. Der Operator bekommt Handlungsanweisungen, keine Fehlermeldungswüste.
  • Keine toten Enden: Jeder Fehlerdialog enthält nächstbeste Schritte, nicht nur Codes. Und: Fehler werden protokolliert und im Systemgesundheitsbereich sichtbar, nicht nur im Log.

6) Accessibility für raue Umgebungen

  • Zielgrößen: Interaktive Flächen >= 12–14 mm bei Touch, Abstand 2–4 mm. Handschuh- und Fettfilm-tolerant. Kritische Buttons mit zusätzlicher räumlicher Trennung.
  • Kontrast und Licht: Hoher Kontrast, minimale Abhängigkeit von reinen Farbunterschieden. Sonnenlicht-taugliche Paletten und Test auf matten/hellen Displays. Dunkelmodus nur dort, wo die Umgebung es erfordert – sonst eher Hellmodus mit gedeckten Akzentfarben.
  • Redundante Kodierung: Farbe + Icon + Text. Rot-Grün-Schwächen sind Realität, Alarmfarben brauchen Formunterstützung (Balken, Muster).
  • Haptik/Akustik: Taktile Bestätigung auf unterstützten Geräten, Audiohinweise mit klarer Priorisierung – und Stummschaltung pro Nutzerkontext. In lauter Umgebung nicht auf Ton verlassen.
  • Tastaturnavigation/Hardware: Volle Tastaturnutzung, Hotkeys dokumentiert, Fokusmanagement. Optional Hardware-Encoder/Knöpfe für kritische Regelkreise.
  • Internationalisierung vor Ort: Längen von Texten kalkulieren, Ziffernformate, Einheiten. Keine kryptischen Abkürzungen.

7) Testen unter Realbedingungen und Observability

  • Schattenmodus: KI-Empfehlungen werden angezeigt, aber haben keine Wirkung. Wir messen „Was hätte der Bediener getan?“, Fehlalarme, verpasste Chancen. Erst danach wird kontrolliert aktiviert.
  • Golden Scenarios: Wiederholbare Playbacks realer Sequenzen, um UI-Reaktion und Performance zu verifizieren. Dazu deterministische Mock-Feeds.
  • Chaos-Drills: Simulierte Netzsegmentierung, Latenzspitzen, Sensor-Ausfälle. Erwartung: UI bleibt bedienbar, zeigt Degradation an, bietet Fallback.
  • Telemetrie des UIs: Eingabe-Latenzen, Frame-Drops, Fehlklicks in kritischen Bereichen, Zeit bis Entscheidung. Lokal erfasst, auditierbar, ohne Personen-Tracking-Exzesse.
  • Post-Incident-Review: Replay von UI-Zuständen, Empfehlungen, Aktionen mit Zeitachse. Ohne diese Rekonstruktion lernt das System nie.

8) Typische Trade-offs und wie wir entscheiden

  • Web vs. nativ: Web ist portabel, wartungsarm, gut für Dashboards. Nativ (z. B. Qt/QML) sinnvoll, wenn harte HMI-Integration, Offlinesicherheit und geringe Latenz oberste Priorität sind. Mischformen sind möglich: Web-Front mit nativer Shell und lokalem Cache.
  • Sampling vs. Vollfidelity: Für Trends reichen decimierte Daten; für Forensik braucht es Rohdaten on-demand. UI muss nahtlos zwischen beiden wechseln, ohne das Gefühl „Zwei Welten“ zu erzeugen.
  • Erklärbarkeit vs. kognitive Last: Feature-Attributionen sind oft Rauschen. Besser: Wenige, robuste Begründungsformen (Provenienz, Vergleichsfälle, simple Schwellenverletzungen) und der „Warum?“-Knopf nur, wo er Entscheidungswert hat.
  • Autonomie vs. Kontrolle: In sicherheitskritischen Pfaden bleibt Mensch-in-der-Schleife Standard, außer durch explizite Freigaben. Autonomie steigern wir graduell, sichtbar und reversibel.
  • GPU/CPU-Budget: Inferenz schlägt Kosmetik. Wir priorisieren Reaktionsfähigkeit und Stabilität vor 60-fps-Animationen. Wenn Ressourcen knapp sind, skaliert UI visuell kontrolliert herunter.

9) Drei Muster aus Projekten

  • Visuelle Prüfung in der Fertigung: Statt farbigem Rechteck über „Defekt“ zeigen wir die Differenz zur Master-Geometrie als Heatmap, Einstieg über „Top 3 Abweichungen“ mit Rohbild-Snapshots. Bediener kann in <2 Klicks den Defekttyp aus einem kontrollierten Vokabular wählen. Ergebnis: kürzerer Entscheidungsweg und sauberere Labels für das Retraining.
  • Flottenüberwachung Bahn: Event-Korrelation gruppiert 50+ Telemetrie-Events zu zwei Root-Causes. Triage-Sicht zeigt sofort: „Energieüberlast in Sektor B“ mit betroffenen Zügen. Freeze/Live-Scrubber ermöglicht Rücksprung um 120 s für Abgleich und dann gezielten Eingriff. Keine Alarmflut, dafür klare Arbeitsreihenfolge.
  • Agenten im Wartungsleitstand: Ein LLM-Agent darf nur drei Tools: Wissensabfrage, Ticketvorschlag, Checklisten-Start. Das UI zeigt in einer rechten Seitenleiste jede Tool-Invocation, Policy-Checks und blockierte Versuche. Operator klickt „Übernehmen“ oder „Ändern“, alles wird auditiert. Vertrauen entsteht, weil der Agent nicht „ins Blaue“ agiert.

10) Checkliste: Was wir in HMI/UX-Reviews abprüfen

  • Zeigt das UI Unsicherheit und Datenlücken explizit und knapp?
  • Gibt es einen eindeutigen Primary-Action-Pfad pro kritischer Empfehlung?
  • Funktioniert das UI deterministisch bei Netzproblemen und Lastspitzen?
  • Sind Gefahraktionen reversibel oder zweikanalig bestätigt?
  • Sind Datenquellen, Zeitstempel, Zustände jederzeit sichtbar?
  • Ist die Informationsdichte hoch, ohne Scroll- und Klickwüsten?
  • Sind Accessibility-Anforderungen (Größe, Kontrast, Redundanz) erfüllt?
  • Lässt sich das Geschehen im Nachhinein mit UI-Zuständen rekonstruieren?

Ein Wort zu Souveränität und Governance