Echtzeit-Monitoring-Plattform für gemischte Erzeugungsportfolios

Ausgangslage

Wer ein gemischtes Portfolio aus Windparks, Solaranlagen, Speichern und Verbrauchern betreibt, hat im 24/7-Betrieb ein wiederkehrendes Problem: Die herstellerspezifischen Werkzeuge zeigen jedes Asset in seiner eigenen Sprache, das interne Operations-Team braucht aber eine einheitliche Sicht — über alle Hersteller, alle Asset-Klassen und alle Standorte hinweg.

Genau dafür wurde diese Monitoring-Plattform als Greenfield-Projekt konzipiert: ein modernes, web-basiertes Echtzeit-Tool für Operations und Support, das die Daten der Datenerfassungs-Schicht herstelleragnostisch visualisiert und steuerbar macht. Parallel zum hauseigenen SCADA-System OneView ist damit eine fokussierte, leitstandfähige Monitoring-Lösung entstanden, die heute in mehreren Produktionsumgebungen rund um die Uhr im Einsatz ist.

Herausforderung

Echtzeit-Monitoring auf produktivem Niveau verlangt mehr als nur Charts und Tabellen:

• Skalierung: Das System muss zehntausende Datenpunkte pro Sekunde verarbeiten und sie nahezu verzögerungsfrei an mehrere gleichzeitig verbundene Nutzer im Leitstand ausliefern.
• Heterogenität: Wind, Solar, BESS, Hybrid und Gridcontroller — jedes mit eigenen Datenprofilen — sollen in einer konsistenten Oberfläche dargestellt werden.
• Sicherheit und Steuerbarkeit: Operatoren müssen nicht nur sehen, sondern auch eingreifen können — Start, Stopp, Reset, Remote-Display, Fahrpläne für Trading und Reserveenergie, manuelle Overrides. Jeder dieser Eingriffe muss berechtigungsgeprüft und nachvollziehbar sein.
• Dual-Use für intern und extern: Operations- und Support-Teams nutzen das Tool zur Überwachung der eigenen Hardware-Basis; externe Kunden nutzen es als Leitstand für ihre eigenen Assets.
• Multi-Umgebung-Betrieb: Das System muss in unterschiedlichen Cloud- und On-Premises-Konfigurationen betreibbar sein — mit denselben Deployment-Prozessen über alle Umgebungen hinweg.

Meine Verantwortung

Das Projekt habe ich von der Architektur über die initiale Implementierung bis zum produktiven Betrieb verantwortet:

• Architektur und Hands-on-Implementierung der ersten produktiven Versionen — Frontend, Backend und Deployment-Pipeline.
• Aufbau des Entwicklungsteams: Recruiting, Onboarding und Etablierung der Arbeitsweise.
• Produktmanagement: Übergang in eine Rolle als Architekt und Produktverantwortlicher mit Verantwortung für Roadmap, Meilensteine und Stakeholder-Kommunikation.
• Produktdiscovery mit internen und externen Stakeholdern: Erhebung von Bedürfnissen und Schmerzpunkten, Übersetzung in umsetzbare Anforderungen entlang der Produktvision. Regelmäßige Status- und Anforderungsmeetings mit Kunden, Abstimmung von Meilensteinen und Zeitplänen.
• Berechtigungskonzept: Definition und Umsetzung des Rollen- und Scope-Modells für Steuereingriffe.

Architekturentscheidungen mit Geschäftswirkung

Fokus auf Echtzeit — keine Reporting-Plattform

Statt zu versuchen, alle Anforderungen einer SCADA- oder Asset-Management-Lösung mitzubedienen, ist die Plattform bewusst auf Echtzeit-Monitoring zugespitzt. Diese Fokussierung war strategisch wichtig: Sie hat das Produkt schlank gehalten, schnelle Release-Zyklen ermöglicht und eine klare Positionierung neben dem hauseigenen SCADA-System OneView geschaffen, das eigenständig weiterentwickelt wird.

Hersteller-Agnostik im Frontend, ermöglicht durch das einheitliche Datenmodell

Die Plattform setzt auf dem vereinheitlichten Datenmodell der Datenerfassungs-Schicht auf (nach IEC 61400). Das bedeutet: Eine Windanlage von Hersteller A und eine von Hersteller B erscheinen in derselben Oberfläche mit derselben Semantik. Das ist nicht trivial sichtbar im Code, aber massiv wirksam im Produkt: Operations-Teams müssen sich nicht in mehrere Herstellerwelten einarbeiten, und das Onboarding neuer Asset-Typen ist im Frontend kostenarm. Später wurde dieser Ansatz auf die Daten aus Direktvermarktung und Reserveenergiehandel ausgeweitet.

Steuerfähigkeit mit kontrolliertem Berechtigungsmodell

Die Plattform ist nicht nur Anzeige, sondern auch Eingriffswerkzeug: Start/Stop/Reset, Remote-Display, Fahrpläne für Trading und Reserve, manuelle Overrides. Authentifizierung erfolgt über Auth0, Autorisierung über Scopes mit feingranularer Rechtesteuerung. Diese Entscheidung war Voraussetzung dafür, dass die Plattform als Leitstand-Werkzeug eingesetzt werden kann — nicht nur zur Überwachung, sondern auch für aktive Operations-Arbeit.

Cloud-agnostisches Deployment über GitLab

Wie auch in den anderen Produkten der Plattform-Familie folgt das Deployment einer Multi-Cloud-Strategie: Produktionsinstanzen laufen bei OVH, Hetzner, Azure, Google Cloud sowie On-Premises in MicroK8s-Clustern. Über GitLab als zentrale Deployment-Pipeline werden alle Umgebungen mit denselben Prozessen verwaltet. Das macht die Plattform für Kunden mit unterschiedlichen Compliance- oder Souveränitätsanforderungen anschlussfähig und entkoppelt das Produkt von Vendor-Lock-in.

Skalierbares Backend mit Redis und AMQP

Die Backend-Architektur trennt klar zwischen Daten-Streaming (AMQP für Events von der Datenerfassung), heißem Zustand (Redis für aktuelle Werte) und Verbindung zum Frontend (WebSockets für Push). Diese Trennung erlaubt es, viele tausend Datenpunkte pro Sekunde an Dutzende gleichzeitige Nutzer auszuliefern, ohne dass einzelne Komponenten zum Engpass werden.

Ergebnis

• Größte Produktionsumgebung: ca. 7.000 Anlagen und Controller im Echtzeit-Monitoring, davon ein Großteil aktiv steuerbar.
• Update-Frequenzen: Standard 30 s, für ausgewählte Datenpunkte bis hinunter zu 5 s und 1 s.
• Gleichzeitige Nutzer: rund 50 Operatoren parallel verbunden im 24/7-Betrieb.
• Multi-Umgebung-Betrieb: Mehrere produktive Cluster bei OVH, Hetzner, Azure, Google Cloud und On-Premises — alle über dieselbe Deployment-Pipeline.
• Dual-Use erreicht: Internes Tool für Operations und Support und Leitstand-Werkzeug für externe Kunden mit eigenen Operations-Teams.
• Funktionale Reife: Echtzeit-Visualisierung, Steuereingriffe, Fahrpläne und Overrides für Trading und Reserveenergie — alles berechtigungsgeprüft und nachvollziehbar.

Eingesetzte Technologien

• Frontend: React, TypeScript, WebSockets, Material UI
• Backend: Node.js, TypeScript, Redis, AMQP
• Authentifizierung und Autorisierung: Auth0 (Scopes für feingranulare Rechtesteuerung)
• Infrastruktur und Deployment: Kubernetes (Cloud und MicroK8s On-Premises), Terraform, GitLab als zentrale Deployment-Pipeline
• Betriebsumgebungen: OVH, Hetzner, Azure, Google Cloud, On-Premises

Worauf diese Erfahrung übertragbar ist

Diese Case Study zeigt, dass mein Profil nicht auf C++ und industrielle Protokolle beschränkt ist: Ich kann Greenfield-Produkte auf modernem Web-Stack führen — von der Architektur über die initiale Implementierung bis zum Aufbau eines Teams und zur Übernahme der Produktverantwortung. Dabei ist das wiederkehrende Muster sichtbar, das auch die anderen Projekte prägt: bewusste Fokussierung statt Feature-Sprawl, hersteller- und vendor-agnostische Architektur, klare Anschlussfähigkeit an die übrige Produktfamilie — und ein Tech-Stack, der sowohl mit Cloud als auch mit On-Premises zurechtkommt.