Herstelleragnostische Datenerfassungs-Plattform für Windenergieanlagen

Ausgangslage

Im Markt für erneuerbare Energien betreiben Asset-Owner und Direktvermarkter zunehmend gemischte Portfolios: Windparks unterschiedlicher Hersteller, ergänzt um Solar, Speicher und steuerbare Verbraucher. Jede Anlagengeneration und jeder Hersteller spricht dabei seine eigene Sprache — proprietär, halb-standardisiert oder über Industrieprotokolle. Gleichzeitig wachsen die Anforderungen an Verfügbarkeit, Skalierung, Cloud-Betrieb und nachvollziehbare Datenflüsse stetig.

In diesem Umfeld habe ich über 15 Jahre eine Datenerfassungs-Middleware mitentwickelt, modernisiert und schließlich als Teamleiter verantwortet. Die Software ist heute europaweit und in den USA bei über 30 Kunden im Einsatz und erfasst die Daten von mehr als 8.000 Anlagen und Geräten — darunter Windenergieanlagen aller relevanten europäischen Hersteller sowie deren Anlagensteuerungen.

Herausforderung

Die Software steht im Zentrum eines heterogenen Ecosystems:

• Southbound müssen unterschiedlichste Anlagen und Steuerungen angebunden werden — mit proprietären Herstellerprotokollen ebenso wie mit industriellen Standards (Modbus, OPC XML-DA, OPC UA, IEC 60870-5-101/104, ICCP/TASE.2).
• Northbound erwarten Kunden den Anschluss an ihre eigenen SCADA-Lösungen, Datenbanken, Vermarktungssysteme und Cloud-Plattformen — über AMQP, Azure Event Hub, OPC UA, FTP, HTTP-APIs.
• Operativ muss das System rund um die Uhr verfügbar sein, in unterschiedlichsten Infrastrukturen lauffähig (vom Kunden-Rechenzentrum bis zur Public Cloud) und so wartbar bleiben, dass Hunderte Anlagenanbindungen über Jahre stabil betrieben werden können.

Die Komplexität liegt nicht in einem Einzelproblem, sondern in der Fähigkeit, all diese Achsen gleichzeitig sauber zu beherrschen.

Meine Verantwortung

Über die Jahre habe ich die Software in allen Rollen begleitet, in denen sie sich entwickelt hat: zunächst als Entwickler, dann als Senior mit Architekturverantwortung, schließlich als Teamleiter mit Verantwortung für Aufbau und Weiterentwicklung des Entwicklungsteams. Parallel dazu war ich von Anfang an in die technische Beratung des Vertriebs und der Kunden eingebunden und habe den Third-Level-Support für anspruchsvolle Integrationsfälle übernommen.

Inhaltlich umfasste das unter anderem:

• Implementierung und Reverse Engineering von Herstellerprotokollen für Windenergieanlagen aller relevanten europäischen Hersteller (u.a. Vestas, Enercon, Siemens, Gamesa, Senvion, NEG Micon, Nordex, GE Wind Energy) sowie für Anlagensteuerungen verschiedener Controller-Hersteller (Mita, Bachmann, Phoenix Contact u.a.).
• Aufbau einer modernen Software-Engineering-Kultur im Team: Etablierung von Unit-Tests, nachvollziehbaren Deployment-Prozessen und kontinuierlichem Refactoring.
• Anbindung an Kundensysteme und Integration der Middleware in weitere Produkte des Firmenportfolios.
• Aufbau und Leitung des Entwicklungsteams sowie Projektmanagement.

Architekturentscheidungen mit Geschäftswirkung

Die wichtigsten Hebel waren nicht einzelne Features, sondern strategische Architekturentscheidungen, die das Produkt über Jahre tragfähig gemacht haben.

Einheitliches Datenmodell nach IEC 61400

Statt jeden Hersteller mit seinem eigenen Datenschema bis in die Northbound-Schnittstellen durchzureichen, habe ich die Einführung eines vereinheitlichten Datenmodells nach IEC 61400 verantwortet. Die Wirkung war doppelt: Kunden konnten ihre SCADA-Lösungen und Vermarktungssysteme herstellerunabhängig aufbauen, und das hauseigene Monitoring-System nutzte dieselbe Basis. Der Beratungsaufwand bei Kunden mit gemischten Portfolios sank deutlich, und das Daten-Gateway gewann sichtbar an strategischer Bedeutung im Produktportfolio.

Python-Embedding für kundenspezifische Logiken

Auf meine Initiative hin wurde Python als Erweiterungssprache in die C++-Middleware integriert. Damit ließen sich Custom-Logiken für einzelne Windparks oder Kunden umsetzen, ohne das Kernprodukt anzufassen. Anpassungen konnten anschließend nicht nur durch das Entwicklungsteam, sondern auch durch den Support vorgenommen werden — mit deutlich kürzeren Lieferzeiten und freier Kapazität im Entwicklungsteam für Produktarbeit.

Cloud-native und cloud-agnostisches Deployment

Die Transformation von Bare-Metal-Prozessen über Virtualisierung hin zu Container-basiertem Cloud-Betrieb war eine bewusste strategische Weichenstellung des Unternehmens, die ich mit umgesetzt habe. Heute läuft die Software in Docker-Containern auf Kubernetes — wahlweise bei Hetzner, OVH, Azure, Google Cloud oder On-Premises beim Kunden. Deployments sind dadurch in unter einer Stunde durchführbar, neue Anlagen lassen sich in wenigen Minuten onboarden, und Kunden mit Souveränitäts- oder Compliance-Anforderungen können ohne Vendor-Lock-in bedient werden.

Modernisierung der Northbound-Anbindung

Auf meine Initiative hin wurden Azure Event Hub und RabbitMQ als moderne Messaging-Backbones integriert. Damit war die Middleware anschlussfähig an die Cloud- und Streaming-Architekturen, in die Kunden ihre Datenplattformen verlagert haben.

Ergebnis

• Skalierung: Heute über 8.000 angebundene Anlagen und Geräte bei 30+ Kunden in Europa und den USA.
• Herstelleragnostik: Anbindung praktisch aller relevanten Windenergieanlagen-Hersteller des europäischen Marktes über proprietäre und standardisierte Protokolle.
• Time-to-Market: Kundenanpassungen über Python können durch Entwicklung und Support umgesetzt werden — statt durch Kernprodukt-Releases.
• Operativ: Deployments unter einer Stunde, Onboarding neuer Anlagen in Minuten, semi-automatisierte Prozesse mit klarer Nachvollziehbarkeit.
• Strategisch: Das Daten-Gateway ist von einer technischen Komponente zu einer Plattform geworden, auf der weitere Produkte des Unternehmens aufsetzen.

Eingesetzte Technologien

• Sprachen: C++, Python
• Southbound-Protokolle: Modbus, OPC XML-DA, OPC UA, IEC 60870-5-101/104, ICCP/TASE.2, diverse proprietäre Herstellerprotokolle
• Northbound-Protokolle und -Schnittstellen: AMQP, RabbitMQ, Azure Event Hub, OPC UA, FTP, HTTP-APIs, Datenbankanbindungen
• Standards: IEC 61400 (vereinheitlichtes Datenmodell)
• Infrastruktur: Docker, Kubernetes (Hetzner, OVH, Azure, Google Cloud, On-Premises)
• Engineering-Praktiken: Unit-Testing, Refactoring, nachvollziehbare Deployment-Prozesse

Worauf diese Erfahrung übertragbar ist

Diese Case Study steht stellvertretend für ein Profil, das ich Mandanten anbiete: die Fähigkeit, langlebige industrielle Software in einem heterogenen, regulierten Umfeld nicht nur am Leben zu halten, sondern strategisch weiterzuentwickeln — von der Protokollebene bis zur Cloud-Architektur, und vom Code bis zur Teamführung.