Alarmanlagen-Projekt
Blazor-Server-Anwendung mit TwinCAT-ADS-Anbindung
Webbasierte Alarmanlagen-Oberfläche, die Zustände aus einer TwinCAT-SPS über ADS ausliest und containerisiert auf Linux hinter einem Reverse Proxy betrieben wird. Umgesetzt im Team mit drei Entwicklern, Aufgaben über Issues organisiert; mein Schwerpunkt lag auf dem Backend.
Problem
Eine webbasierte Anwendung sollte Zustands- und Alarmdaten aus einer TwinCAT-Umgebung zugänglich machen und in die bestehende Unternehmensinfrastruktur integriert werden. Die eigentliche Schwierigkeit lag weniger in der Oberfläche als an den Rändern: Authentifizierung, SPS-Kommunikation, Containerbetrieb und Reverse-Proxy-Routing waren jeweils eigenständige Teilaufgaben.
Lösung
Das Projekt wurde im Team mit drei Entwicklern umgesetzt: Die anstehenden Arbeiten wurden als Issues erfasst und aufgeteilt, Frontend- und Backend-Aufgaben getrennt verteilt. Mein Schwerpunkt lag überwiegend im Backend. Eine ASP.NET-Core-/Blazor-Server-Anwendung stellt die Weboberfläche bereit: Gebäude- und Etagenpläne mit verorteten Meldern, eine tabellarische Sensorübersicht, Torzustände und ein Ereignisprotokoll. Die SPS-Kommunikation ist bewusst in eine eigene Klassenbibliothek ausgelagert, die Gerätetypen wie Sensoren und Signalgeber auf SPS-Strukturen abbildet und deren Zustand ableitet. Damit ADS auch aus einem Linux-Container funktioniert, betreibt die Anwendung einen eigenen AMS-TCP-Router als Hintergrunddienst, konfiguriert über Umgebungsvariablen. Der Betrieb erfolgt containerisiert; HTTPS wird am Traefik-Reverse-Proxy terminiert, während die Anwendung intern per HTTP erreichbar bleibt.
Mein Beitrag
- Arbeit an der Blazor-Anwendung, ihren Ansichten und den Datenmanagern dahinter.
- Trennung der TwinCAT-Kommunikation in eine eigene Bibliothek mit Gerätemodellen und Zustandslogik.
- Betrieb eines AMS-TCP-Routers als Hintergrunddienst, damit ADS aus dem Linux-Container erreichbar ist.
- Analyse von Start- und Binding-Problemen im ASP.NET-Core-Hosting.
- Anpassung des internen HTTP-Bindings für den Containerbetrieb hinter Traefik.
- Untersuchung von Netzwerk-, DNS-, Routing- und ADS-Verbindungsproblemen.
- Deployment und Betrieb in einer Linux-/Docker-Umgebung.
- Abstimmung von Schnittstellen mit dem Frontend-Teammitglied und Bearbeitung zugewiesener Issues.
Aufbau
- Browser → Reverse Proxy (Traefik, HTTPS-Terminierung)
- Reverse Proxy → Blazor-Server-Anwendung (intern per HTTP)
- Anwendung → eigene TwinCAT-Bibliothek mit Gerätemodellen und Zustandslogik
- TwinCAT-Bibliothek → AMS-TCP-Router als Hintergrunddienst im Container → SPS
- Verzeichnisdienst für Authentifizierung über Konfiguration angebunden
- Container- und Host-Netzwerk so konfiguriert, dass Webzugriff und ADS-Kommunikation gleichzeitig funktionieren
Technische Herausforderungen
- ADS setzt auf dem AMS-Routing auf — in einem Linux-Container ist dieser Router nicht selbstverständlich vorhanden und muss selbst bereitgestellt und erreichbar gemacht werden.
- Unterschied zwischen direktem HTTPS-Binding in der Anwendung und TLS-Terminierung am Reverse Proxy sauber auflösen.
- Zusammenspiel aus Host-Ports, Container-Ports, DNS und Traefik-Routing.
- Sensorzustände robust ableiten: entprellte Werte, Dauerstörungen und nicht genutzte Kanäle müssen unterscheidbar bleiben.
- Authentifizierung in einer Umgebung mit Unternehmensverzeichnis.
- Fehlerbilder sauber trennen: UI, ASP.NET-Hosting, Proxy, Netzwerk oder SPS-Kommunikation.
Ergebnis
Die Anwendung läuft containerisiert hinter dem Reverse Proxy und kommuniziert mit der TwinCAT-Seite. Das Projekt ist mein deutlichstes Beispiel dafür, einen Fehler über mehrere Systemebenen hinweg einzugrenzen, statt an der Oberfläche zu raten.
Medien
Screenshots der internen Oberfläche benötigen eine Freigabe. Ein neutrales Architekturdiagramm ohne interne Domains, IPs oder SPS-Kennungen ist geplant.