Einheitliche industrielle Bedienoberflächen: Skalierbare Softwarearchitektur mit Angular und .NET

Industrielle Maschinen und Produktionsanlagen besitzen häufig Bedienoberflächen, die zu unterschiedlichen Zeitpunkten, mit verschiedenen Technologien und nach individuellen Vorgaben entstanden sind. Jede einzelne Oberfläche erfüllt möglicherweise ihren Zweck. In der Gesamtheit entsteht jedoch eine fragmentierte Softwarelandschaft: Bedienabläufe unterscheiden sich, Komponenten werden mehrfach entwickelt und Änderungen müssen an verschiedenen Stellen umgesetzt werden.

Die nachhaltige Lösung ist mehr als ein neues Layout. Gefragt ist eine gemeinsame HMI-Plattform (Human-Machine Interface), die eine konsistente Bedienung mit den Besonderheiten unterschiedlicher Maschinen verbindet. Eine solche Plattform benötigt ein durchdachtes Zusammenspiel von Frontend-Architektur, Domänenmodell, Backend, Steuerungsadaptern, Sicherheitskonzept und Entwicklungsprozessen.

Wenn jede Maschine ihre eigene Oberfläche mitbringt

In gewachsenen Anlagenlandschaften sind unterschiedliche Benutzeroberflächen zunächst nachvollziehbar. Maschinen haben andere Funktionen, Hersteller verwenden eigene Steuerungen und Projekte wurden unabhängig voneinander realisiert. Langfristig führt diese Vielfalt jedoch zu spürbaren Nachteilen.

Bediener müssen sich auf wechselnde Navigationsstrukturen, Bezeichnungen und Interaktionsmuster einstellen. Schulungen werden aufwendiger, und uneinheitliche Alarmdarstellungen oder Bestätigungsdialoge können Fehlbedienungen begünstigen. Für Entwicklung und Instandhaltung entstehen parallele Codebasen, unterschiedliche Abhängigkeiten und mehrfach implementierte Funktionen.

Besonders kritisch wird die Situation, wenn eine neue Anforderung alle Anlagen betrifft: beispielsweise zusätzliche Diagnoseinformationen, eine neue Benutzerrolle oder eine verbesserte Darstellung von Messwerten. Ohne gemeinsame Plattform wird aus einer fachlichen Änderung schnell eine Reihe voneinander unabhängiger Softwareprojekte.

Das Ziel lautet deshalb nicht, jede Maschine identisch zu machen. Vielmehr sollen gleiche Aufgaben nach denselben Grundsätzen bedienbar sein, während die fachlich notwendigen Unterschiede erhalten bleiben.

Ein gemeinsames Bedienkonzept, flexible Maschinenfunktionen

Die Grundlage bildet ein verbindliches Bedien- und Interaktionskonzept. Navigation, Statusfarben, Fehlermeldungen, Dialoge, Zustandsübergänge und grundlegende Bedienelemente folgen einheitlichen Regeln. Fachliche Funktionen lassen sich je nach Maschine ergänzen oder ausblenden.

Eine zentrale Rolle übernimmt dabei ein Designsystem. Es umfasst nicht nur Farben und Typografie, sondern auch wiederverwendbare Interaktionsmuster: Wie wird eine Warnung von einem Fehler unterschieden? Wann benötigt eine Aktion eine Bestätigung? Wie werden deaktivierte Funktionen erklärt? Wie bleibt die Oberfläche unter Touch-Bedienung und mit Handschuhen nutzbar? Und wie wird ein nicht mehr aktueller Maschinenzustand sichtbar gemacht?

Aus diesem Regelwerk entsteht eine gemeinsame Angular-Komponentenbibliothek. Sie enthält beispielsweise Statusanzeigen, Alarmübersichten, Trenddiagramme, Rezepteditoren, Parameterfelder, Benutzer- und Rollenanzeigen sowie standardisierte Dialoge. Die Komponenten werden unabhängig von einem einzelnen Maschinentyp entwickelt, dokumentiert und getestet.

Architektonisch ist dabei zwischen drei Ebenen zu unterscheiden: visuelle Basiskomponenten ohne Fachlogik, fachliche HMI-Komponenten mit klaren Schnittstellen und maschinenspezifische Feature-Module. Diese Trennung verhindert, dass eine vermeintlich universelle Komponente nach und nach zahlreiche Sonderfälle und Steuerungsdetails aufnimmt.

Die Referenzarchitektur: Verantwortlichkeiten klar trennen

Eine belastbare HMI-Architektur trennt die Benutzeroberfläche von der fachlichen Ausführung und der konkreten Maschinenkommunikation. Angular und TypeScript bilden die Präsentationsschicht. Ein .NET-/C#-Backend stellt Anwendungsfälle, Zustandsmodelle und einheitliche APIs bereit. Dahinter kapseln Adapter die jeweils verwendeten Steuerungssysteme und Protokolle.

Frontend: Angular als modulare Bedienplattform

Das Angular-Frontend sollte nach fachlichen Features strukturiert werden, nicht nur nach technischen Dateitypen. Module wie Alarme, Diagnose, Rezepte, Betrieb und Wartung besitzen nachvollziehbare Verantwortlichkeiten und explizite Abhängigkeiten. Eine gemeinsame Shell übernimmt Navigation, Layout, Anmeldung, Lokalisierung und übergreifende Statusanzeigen.

Wiederverwendbare Bausteine werden über klar definierte öffentliche APIs bereitgestellt. Angular Services kapseln Infrastrukturzugriffe; zustandsbezogene Logik wird bewusst von darstellenden Komponenten getrennt. Für umfangreichere Anwendungen können Signals, RxJS oder ein dediziertes State-Management-Muster sinnvoll sein. Entscheidend ist weniger die Wahl eines bestimmten Werkzeugs als die Frage, wem welcher Zustand gehört, wie lange er gültig ist und wie Änderungen nachvollziehbar werden.

Strikte TypeScript-Typisierung, einheitliche Linting-Regeln und vertraglich definierte Datenmodelle reduzieren unbeabsichtigte Kopplungen. Ein Monorepo mit getrennten Bibliotheken kann gemeinsame Versionen und Abhängigkeitsregeln vereinfachen; bei unabhängig betriebenen Teams sind auch separat versionierte Pakete möglich. Die passende Struktur folgt den tatsächlichen Release- und Teamgrenzen.

Backend: Fachlogik und Steuerungsintegration in .NET/C#

Das Backend ist nicht lediglich ein Durchleitungsserver. Es übersetzt zwischen Bedienanforderungen und Maschinenfähigkeiten. Hier liegen Anwendungsfälle, Validierungsregeln, Autorisierung, Auditierung, Fehlerbehandlung und die Normalisierung unterschiedlicher Steuerungsdaten.

Ein Ports-and-Adapters-Ansatz (hexagonale Architektur) bietet sich an: Die Fachlogik spricht mit abstrahierten Schnittstellen, während Adapter konkrete Protokolle oder Herstellersysteme implementieren. Dazu gehören beispielsweise OPC UA, definierte HTTP-APIs oder vorhandene proprietäre Schnittstellen. Ein Adapter darf ausgetauscht werden, ohne dass Alarmanzeige, Rezeptverwaltung oder Navigationslogik im Frontend neu programmiert werden müssen.

Hilfreich ist ein fachlich stabiles Domänenmodell, etwa für MachineState, Alarm, Measurement, Recipe, Capability und CommandResult. Solche Modelle müssen die Unterschiede zwischen Maschinen abbilden können, ohne sie vollständig zu nivellieren. Ein Maschinenzustand, den die Steuerung nicht liefert, darf nicht künstlich als verlässlich verfügbar erscheinen.

Verträge statt impliziter Annahmen

Zwischen Frontend und Backend sollten versionierte API-Verträge verwendet werden, beispielsweise über OpenAPI und generierte TypeScript-Clients. Für asynchrone Ereignisse sind ebenfalls explizite Schemas, Versionen und Kompatibilitätsregeln notwendig. Ein gemeinsames Format sollte Zeitstempel, Herkunft, Qualität und Gültigkeit von Werten berücksichtigen.

So entsteht eine überprüfbare Grenze: UI-Komponenten müssen weder Protokolldetails noch interne Steuerungsnamen kennen. Das Backend bleibt seinerseits unabhängig vom konkreten Aussehen einer Bedienmaske.

Echtzeitdaten und Bedienbefehle sind unterschiedliche Aufgaben

Industrielle HMIs müssen Zustände zeitnah visualisieren. Dafür eignen sich ereignisbasierte Kanäle, etwa WebSockets oder SignalR, gegebenenfalls mit gezielter Bündelung und Drosselung hochfrequenter Werte. Nicht jede Maschinenvariable muss in der Browseroberfläche mit derselben Frequenz aktualisiert werden. Wichtig sind konsistente Zustandsbilder, erkennbare Verbindungsunterbrechungen und ein klarer Umgang mit veralteten Daten.

Lesen und Schreiben dürfen architektonisch nicht gleichbehandelt werden. Telemetrie wird empfangen, normalisiert und angezeigt. Ein Bedienbefehl dagegen benötigt einen kontrollierten Pfad mit Berechtigungsprüfung, fachlicher Validierung, eindeutiger Zuordnung, Ergebnisrückmeldung und gegebenenfalls Protokollierung.

Ein Klick auf „Start“ bedeutet noch nicht, dass die Maschine tatsächlich gestartet ist. Die Oberfläche muss zwischen Befehl angefordert, Befehl angenommen, ausgeführt, abgelehnt und Zeitüberschreitung unterscheiden können, soweit diese Informationen verfügbar sind. Wiederholte Befehle, Verbindungsabbrüche und parallele Bedienhandlungen erfordern explizite Regeln.

Sicherheitsgerichtete Funktionen wie Not-Halt, Schutztüren oder sicherheitsrelevante Verriegelungen gehören weiterhin in die dafür vorgesehene Maschinensteuerung und Sicherheitstechnik. Eine Web-HMI ersetzt keine Sicherheitssteuerung. Auch bei einer optisch einheitlichen Oberfläche müssen Risikobeurteilung und sicherheitstechnische Anforderungen maschinenspezifisch erfüllt werden.

Konfiguration statt duplizierter Anwendungen

Viele Unterschiede lassen sich über deklarative Maschinenprofile abbilden. Ein solches Profil beschreibt beispielsweise verfügbare Fähigkeiten, Navigationspunkte, Einheiten, Parameterbereiche, zulässige Funktionen und die Zuordnung zu passenden Fachmodulen.

Konfiguration ist jedoch kein Freibrief für beliebige Laufzeitlogik. Sie sollte schema-validiert, typisiert, versioniert und testbar sein. Für unterschiedliche Maschinenfähigkeiten sind explizite Capability-Modelle hilfreicher als eine wachsende Sammlung unübersichtlicher boolescher Schalter. Nicht jeder Sonderfall gehört in eine Konfigurationsdatei: Unterscheiden sich fachliche Abläufe grundlegend, ist ein eigenständiges Feature-Modul oft sauberer.

Besondere Aufmerksamkeit verdienen Kompatibilität und Migration: Ein aktualisiertes Maschinenprofil muss zur installierten Backend-Version und zu den vorhandenen Steuerungsfunktionen passen. Fehlende oder inkompatible Funktionen sollten sichtbar und nachvollziehbar behandelt werden, statt stillschweigend zu fehlerhaftem Verhalten zu führen.

Qualität, Sicherheit und Betrieb von Anfang an einplanen

Einheitliche Komponenten senken Wartungskosten nur dann, wenn Änderungen kontrolliert ausgerollt werden. Sinnvoll ist eine mehrstufige Teststrategie aus Unit-Tests für Fachlogik, Komponententests für UI-Verhalten, Contract-Tests für API-Grenzen, Integrationstests für Steuerungsadapter und End-to-End-Tests für kritische Bedienabläufe. Für schwer verfügbare Maschinen sollten Simulatoren beziehungsweise digitale Testadapter reproduzierbare Zustände und Fehlerfälle erzeugen.

Hinzu kommen rollenbasierte Berechtigungen, sichere Authentifizierung, ein nachvollziehbarer Audit-Trail für relevante Bedienhandlungen sowie ein Konzept für Zertifikate, Netzwerksegmentierung, Updatefähigkeit und Ausfallverhalten. Die Anforderungen sind abhängig von Anlagentyp, Risiko und Einsatzumgebung zu konkretisieren. Industrielle Sicherheitskonzepte sollten einschlägige Normen und Vorgaben, etwa aus dem Umfeld der IEC 62443, berücksichtigen.

Im Betrieb sind Observability und Diagnosefähigkeit entscheidend. Strukturierte Logs, technische Metriken, Korrelationskennungen und verständliche Fehlermeldungen erleichtern die Analyse, insbesondere wenn Frontend, Backend und Steuerungsadapter von unterschiedlichen Teams betreut werden. Zuverlässigkeit bedeutet auch, dass die HMI ihren eigenen Kommunikationszustand korrekt darstellt und keine Scheinsicherheit durch eingefrorene Werte vermittelt.

Schrittweise einführen, statt alles gleichzeitig zu ersetzen

Die Modernisierung sollte mit einer Bestandsaufnahme beginnen: Welche Bedienaufgaben wiederholen sich? Welche Technologien und Schnittstellen existieren? Wo liegen Sicherheits- oder Verfügbarkeitsrisiken? Welche Unterschiede sind fachlich notwendig, welche lediglich historisch gewachsen?

Anschliessend entsteht ein kleiner, aber belastbarer Plattformkern. Ein Pilot mit repräsentativen Maschinenfunktionen prüft die Architektur unter realistischen Bedingungen. Dabei sollte nicht nur die technische Machbarkeit bewertet werden, sondern auch die Bedienbarkeit mit den tatsächlichen Anwendern.

Erkenntnisse aus dem Pilotbetrieb fliessen in Komponentenbibliothek, API-Verträge, Designsystem und Entwicklungsrichtlinien zurück. Erst danach folgt die schrittweise Überführung weiterer Funktionen und Maschinenvarianten. Für jede Etappe sind Abnahmekriterien, Regressionstests und ein Rückfallkonzept sinnvoll.

Messbarer Fortschritt lässt sich beispielsweise an der Wiederverwendungsquote gemeinsamer Komponenten, dem Aufwand für neue Maschinentypen, der Anzahl UI-spezifischer Sonderimplementierungen, der Testabdeckung kritischer Bedienabläufe und der Zeit zur Behebung von Fehlern ablesen. Ein übergreifendes Architektur- und Komponenten-Governance-Modell verhindert, dass mehrere Teams erneut inkompatible Varianten schaffen.

KI-Agenten als Entwicklungswerkzeug, nicht als Freigabeinstanz

KI-Agenten können diese Arbeit gezielt unterstützen. Sie helfen bei der Analyse vorhandener Oberflächen, beim Erkennen wiederkehrender UI-Muster, beim Entwurf von Komponenten-APIs und bei der Erstellung von Tests, technischen Dokumentationen oder Migrationshilfen. Gerade bei umfangreichen Bestandsprojekten kann die strukturierte Aufbereitung bereits existierender Implementierungen viel Entwicklungsarbeit einsparen.

Entscheidend ist die Einbindung in einen kontrollierten Engineering-Prozess. Ein Agent erhält eine abgegrenzte Aufgabe, definierte Eingaben, Architekturregeln und überprüfbare Akzeptanzkriterien. Seine Ergebnisse werden durch statische Analysen, Build-Pipelines, automatisierte Tests und Code-Reviews abgesichert. Ein zweites Modell, gegebenenfalls von einem anderen Anbieter, kann als unabhängige zusätzliche Prüfinstanz dienen, ersetzt aber weder Tests noch fachliches Review.

Für sensible Quelltexte, Anlageninformationen oder Betriebsgeheimnisse können selbst betriebene Modelle und lokal ausgeführte Werkzeuge sinnvoll sein. Dabei sind Datenflüsse, Zugriffsrechte und Protokollierung ebenso zu prüfen wie beim Einsatz externer Dienste. Die blosse Verwendung eines lokalen Modells garantiert noch keine Vertraulichkeit.

Besonders bei industriellen Bedienoberflächen muss nachvollziehbar bleiben, wer eine Änderung freigegeben hat und welche Auswirkungen sie auf das Maschinenverhalten haben kann. KI-generierter Code ist ein Änderungsvorschlag, keine geprüfte Maschinenfunktion. Die technische, fachliche und sicherheitsbezogene Freigabe verbleibt bei verantwortlichen Menschen.

Fazit: Eine gemeinsame Plattform ist eine Architekturentscheidung

Die Vereinheitlichung industrieller Bedienoberflächen ist kein reines Frontend-Redesign. Ihr wirtschaftlicher Nutzen entsteht durch gemeinsame Komponenten, ein konsistentes Bedienkonzept, vertraglich definierte APIs, klar getrennte Verantwortlichkeiten und eine kontrollierte Integration heterogener Steuerungen.

Angular und TypeScript bieten die Grundlage für modular aufgebaute Benutzeroberflächen, während .NET/C# Fachlogik, Integrationsschnittstellen und einheitliche Datenmodelle kapseln kann. Konfigurierbare Maschinenprofile reduzieren Doppelentwicklungen, ohne notwendige fachliche Unterschiede zu verstecken. Eine schrittweise Migration mit realistischen Tests sorgt dafür, dass die Plattform im Betrieb belastbar bleibt.

KI-Agenten können Analyse, Implementierung und Qualitätssicherung beschleunigen. Den entscheidenden Unterschied machen jedoch Architekturdisziplin, klare Zuständigkeiten und überprüfbare Freigabeprozesse.

Der Mensch entscheidet. Die KI unterstützt.