• Feld/Edge:
  • Gateways sprechen OPC UA/MQTT, normalisieren Topics/Namespaces.
  • Lokales Zeit-Alignment (z. B. via PTP-ähnlicher Synchronisation) und Puffer bei Netzflaps.
  • Streaming/Processing:
  • Event-Bus für Hot-Path (z. B. MQTT-Broker oder ein log-basiertes System). Dedizierte Stream-Prozessoren für Alarme, Korrelation, Anomalien.
  • Timeseries-DB für Warm-Path-KPIs, Objektspeicher/Relationale DB für Cold-Path.
  • Modelle/Inference:
  • CV/ML-Modelle als Dienste mit klaren SLAs, Health-Probes, Canary-Deployments im Schattenmodus.
  • LLM-Gateway on-prem, Tool-Adapter zu DMS/CMMS/ERP, RAG mit dokumentierter Quelle.
  • Observability: Metriken (Rate/Latency/Error), Traces über Tool-Chains, strukturiertes Logging.
  • UI/Frontend:
  • Web-App mit Offline-Cache, getrennte Ansichten für Leitstand und Mobil.
  • WebSockets für Hot-Path, Request/Response für Warm/Cold. Virtualisierte Listen, Canvas/WebGL sparsam.
  • Feature-Flags und Remote-Konfig on-prem, nicht über öffentliche Dienste.
  • Sicherheit/Netz:
  • mTLS End-zu-Ende, Zero-Trust-Ansatz zwischen Zonen. Trennung OT/IT, begrenzte, auditierte Brücken.
  • Lokales SSO (z. B. Keycloak-ähnliche Systeme), Hardware-Token/Badge-Support.
  • Governance:
  • Agenten-Observability und -Policies (z. B. mit Alpi-M), Freigabeworkflows, Audit-Export.
  • UX-Metriken: Time-to-Action, Fehlannahmerate, Alarm-Shelf-Time, „Shadow-vs-Operator“-Divergenzen.

8) Beispiel aus der Praxis (anonymisiert)

Auf einer Fertigungslinie mit visueller Endkontrolle wurden Bildklassifikation und ein textbasierter Assistent für Störungsbehebung eingeführt.

  • Problem: Operatoren ertranken in Alarmen der Prüfstation, Downtime durch Fehlalarme, Fachwissen verteilt in PDFs und Köpfen.
  • Architektur: Kamerastreams am Edge inferiert, Ereignisse via MQTT, Hot-Path UI mit Aktionsliste. RAG-Assistent on-prem, Quellen aus Handbüchern und Störungsdatenbank. Agenten-Observability zur Nachvollziehbarkeit.
  • UX:
  • Schattenmodus 6 Wochen: KI markierte Defekte, aber ohne Eingriff. UI zeigte „Hätte aussortiert“ inkl. Gründe und Bilder. Abweichungen wurden gelabelt.
  • Danach Empfehlungsmodus mit Two-Step-Genehmigung. Playbooks eingebettet, schnell scannbar.
  • Alarm-Gruppierung: Statt 40 Einzelalarmen pro Stunde fünf Cluster-Einträge mit Ursache und vorgeschlagener Maßnahme.
  • Ergebnis: Stabilere Bedienlast, schnellere Ursachenfindung, höhere Akzeptanz, da jeder KI-Schritt erklärbar und lokal nachvollziehbar war. Zahlen sparen wir uns – entscheidend war die belastbare, souveräne Umsetzung.

9) Häufige Anti-Pattern

  • Schwarze Box KI: „System empfiehlt“ ohne Quelle, Unsicherheit oder Alternativen.
  • Farbe als einzige Semantik: Rot/Grün im Sonnenlicht – viel Glück.
  • Alles-echtzeit-Anspruch: Jede Zahl live, keine Priorisierung – führt zu kognitiver Überlast.
  • Mobile=Desktop: Ein UI für Leitstand, Tablet und Handschuh – am Ende scheitern alle.
  • Cloud-Zwang: Prompting oder Telemetrie gehen außer Haus – Betrieb steht beim nächsten WAN-Ausfall.
  • A/B-Tests im Safety-Kontext: Funktionale Varianten im Live-Betrieb ohne Schattenmodus und Freigabe – No-Go.
  • „KI ersetzt Prozesse“: Ohne Playbooks, Interlocks und Audit bleibt nur Show.

10) Kompakte Checkliste für den Start

  • Klären: Welche Entscheidungen müssen in welcher Zeit getroffen werden? Welche Folgen hat eine Fehlentscheidung?
  • Inventarisieren: Datenquellen, Latenzbudgets, Offline-Szenarien, Rollen und Freigabeketten.
  • Architektur trennen: Hot/Warm/Cold Path. On-Prem first, Cloud optional für Nichtkritisches.
  • UX-Muster festlegen: Drei-Zonen-Layout, Zeitnavigation, Aktionsliste, Sidecar-Erklärungen, Modussichtbarkeit.
  • KI-Governance: Schattenmodus, Freigaben, Observability, Audit, Datenherkunft.
  • Accessibility: Handschuh-tauglich, hoher Kontrast, redundante Kodierung, Mehrsprachigkeit.
  • Messen: Time-to-Action, Alarm-Shelf-Time, Akzeptanzquote von Empfehlungen, Divergenz „Mensch vs. KI“.
  • Üben: Post-Incident-Reviews, Fault-Injection, Bedienertests unter Realbedingungen.

Unsere Haltung

Wir bauen Systeme für Umgebungen, in denen Souveränität nicht verhandelbar ist. Das heißt: KI-Funktionen laufen dort, wo die Entscheidungen fallen. Keine Abhängigkeit von US-Clouds, keine versteckten Datenabflüsse. Statt „mehr KI“ setzen wir auf „bessere Entscheidungen“ – mit klaren Modi, erklärbaren Empfehlungen und robustem Design, das in Handschuhen, Staub und Sonnenlicht funktioniert.

FAQ

  • Wie balanciere ich Erklärbarkeit und Geschwindigkeit?
  • Standardmäßig eine knappe Begründung mit Quelle und Unsicherheit direkt an der Empfehlung, Details im Sidecar. Für wiederkehrende Aufgaben kann die Detailtiefe im Routinebetrieb reduziert werden. Kritisch ist, dass die tiefe Erklärung immer einen Klick entfernt ist.
  • Kann ich LLM-basierte Assistenten sicher in der Leitwarte einsetzen?
  • Ja, wenn sie on-prem laufen, Retrieval ausschließlich aus lokalen, freigegebenen Quellen erfolgt, Tool-Aufrufe und Freigaben gesteuert sind und die gesamte Kette beobachtbar ist. Schattenmodus und rollenbasierte Freigabe sind Pflicht.
  • Wie gehe ich mit Alarmfluten um, ohne echte Probleme zu übersehen?
  • Korrelieren und clustern statt dämpfen: Ereignis-Ketten erkennen, Duplikate zusammenfassen, Eskalation nach Dauer und Kritikalität. UI-seitig klare Ursachenketten anzeigen, nicht nur Listen. Dazu domänenspezifische Regeln und Anomalieerkennung auf dem Stream.
  • Was ist die richtige Metrik für „gute“ UX im industriellen Kontext?
  • Time-to-Action bei kritischen Ereignissen, Fehlannahme- und Fehlablehnungsraten von KI-Empfehlungen, Alarm-Shelf-Time (wie lange bis zur Bearbeitung), Downtime durch Bedienfehler, sowie Divergenz Mensch vs. KI im Schattenmodus.
  • Brauche ich zwingend unterschiedliche UIs für Leitstand und Instandhaltung?
  • In der Praxis ja. Der Kontext, die Eingabegeräte und die Aufgaben unterscheiden sich so stark, dass getrennte Oberflächen mit geteilten Komponenten erfolgreicher sind als ein kompromissbehaftetes Einheitsinterface.

Wenn Sie ein KI-gestütztes Interface planen, starten Sie nicht mit Widgets, sondern mit dem schlimmsten Störfall: Wer entscheidet was, in welcher Zeit, auf welcher Datenbasis, unter welchen Restriktionen? Aus diesen Antworten leitet sich die Architektur ab – und erst dann das Design. Genau dafür bauen wir bei AlpiType Systeme und mit Alpi-M die Beobachtbarkeit und Governance für LLM-Agenten, die in der Industrie gebraucht werden: souverän, on-premise und unter Ihrer Kontrolle.