Von der Simulation zu Megawatt-Realität: Power-Hardware-in-the-Loop bei EGSTON – Unser Recap von „EGSTON Power Technology Overview“ (Dragan Djukic, EGSTON Power Electronics GmbH)

Kontext: Warum Power-Hardware-in-the-Loop (PHIL) die Entwicklung in der Leistungselektronik beschleunigt

In der Session „EGSTON Power Technology Overview“ zeigte Dragan Djukic (Senior Engineer, EGSTON Power Electronics GmbH), wie sich die Entwicklung großer Leistungselektroniksysteme mit Power-Hardware-in-the-Loop (PHIL) radikal beschleunigen lässt. Der Ausgangspunkt ist bekannt: Klassische Entwicklungszyklen in der Leistungselektronik führen von der Idee über das Simulationsmodell zur Validierung – und enden meist bei ersten Prototypen im Labor. PHIL erweitert diesen Ablauf entscheidend, indem es Simulation und reale Leistung nahtlos verschränkt.

Djukic beschreibt PHIL als „Brücke“ zwischen Modell und physischer Welt: Die Spannungen und Ströme aus der Simulation werden durch breitbandige Leistungs-Verstärker in reale Größenordnung übertragen – bis hinauf in den Megawattbereich. Das Ergebnis: Geräte unter Test (Device Under Test, DUT) interagieren frühzeitig mit einem kompletten, realitätsnahen Systemverhalten, lange bevor die erste Hardware-Serie gebaut ist. Jeder eingesparte Prototypen-Loop spart Zeit und Kosten – gerade bei Leistungen bis 1 MW.

Für uns als DevJobs.at-Redaktion ist vor allem die Interdisziplinarität bemerkenswert: PHIL ist kein reines Software- oder Hardware-Thema. Wie Djukic betont, verschränkt die Lösung Mechanik, Leistungselektronik, Embedded-Programmierung, FPGA/VHDL, Echtzeit-SW-Stacks und nutzernahe Tooling-Schichten.

Der „klassische“ Flow – und was PHIL konkret ergänzt

Djukic zeichnet zunächst den gängigen Ablauf für ein Gerät wie einen Wechselrichter nach:

1. Idee bzw. Topologie
2. Simulationsmodell und Validierung
3. Beschleunigte Simulation mittels Echtzeit-Simulator
4. Prototypenbau und Labortest

Genau zwischen 3 und 4 setzt PHIL an: Statt direkt in teure Hardware zu investieren, verbinden die Ingenieurinnen und Ingenieure die validierte Simulation mit einem leistungsstarken Verstärker, der die simulierten Signale als echte Spannungen/Ströme auf den Prüfling gibt. So interagiert das DUT mit einem realen Netz-, PV- oder Batterieszenario – ohne den Aufwand, diese Quellen physisch aufzubauen.

Der Mehrwert ist zweifach:

• Frühere, realitätsnahe Validierung der Regelung, Schutzlogik und Systemdynamik.
• Kürzere Iterationszyklen, da Konzeptfehler und Parametergrenzen vor dem physischen Prototyp auffallen.

Use Cases: Ein Verstärker, mehrere Rollen – PV, Batterie oder Netz

Besonders eingängig ist Djukics Beispiel, wie ein einziger, hochbandbreitiger Leistungs-Verstärker unterschiedliche Quellen oder Senken emuliert:

• Photovoltaik-Panel (PV)
• Batterie
• Netz (AC)

Die Aussage ist klar: Ein und dieselbe Hardware kann per Konfiguration als DC- oder AC-Quelle/Senke agieren. In der Praxis spart das enorme Rüstzeiten und ermöglicht umfassende Testabdeckung auf einer Plattform. Djukic weist darauf hin, dass viele Systeme am Markt entweder nur DC oder nur AC abdecken oder beim Energiefluss eingeschränkt sind. Die hier skizzierte PHIL-Lösung zielt auf Vielseitigkeit.

Für AC-seitige DUTs (z. B. Wechselrichter oder Windturbinen-Komponenten) wie auch für DC-seitige (z. B. PV- oder Batterie-Emulation) ist die schnelle Umkonfiguration der Schlüssel. Das spart umfangreiche Verkabelung, vermeidet Firmware-Großeingriffe und macht das Testfeld zu einer Software-gesteuerten, wiederverwendbaren Ressource.

Architektur eines PHIL-Teststands: PC, Echtzeit-Engine, Verstärker

Djukic skizziert eine typische Architektur in drei Blöcken:

• Control-PC (links)
• Echtzeit-Verarbeitung (Mitte)
• Leistungs-Verstärker (rechts)

Das DUT hängt an den Ausgängen des Verstärkers. Der Sprecher verweist auf die „Computer System Unit“ als Namen einer Verstärkerplattform. Der Ablauf ist bewusst flexibel gehalten: Um ein neues DUT zu testen, wird das alte abgesteckt, das neue angeschlossen, die gewünschte Konfiguration gewählt – und „in wenigen Minuten“ läuft ein völlig anderer Testfall.

Aus Redaktionssicht ist dieser Aspekt mehr als ein Komfort-Feature: Er ist die Voraussetzung für skalierbare Testautomatisierung und Continuous Verification in der Leistungselektronik.

Bedienung und Automatisierung: GUI plus API/Scripting

Eine PHIL-Plattform ist nur so gut wie ihre Bedienbarkeit. Djukic betont, dass jeder Verstärker mit einer grafischen Benutzeroberfläche (GUI) und unterschiedlichen Steuerungswegen ausgestattet wird:

• GUI-Modus: Klickbasierte Interaktion, Konfiguration, Start/Stop, Status-Feedback.
• Skript-/API-Modus: Automatisierung ohne GUI – Prozeduren werden via API angesteuert.

Für die Automatisierung kommen Skripte und Frameworks zum Einsatz, namentlich Python und Robot. Die Plattform unterstützt so sowohl explorative Laborarbeit als auch reproduzierbare Testsequenzen. Aus Daten- und Integrationssicht nennt Djukic gRPC und MySQL – ein Hinweis auf verteilte Kommunikation und persistente Ergebnisdaten.

Technologiestack (Auszug)

• C++ und Qt Creator für GUI und Applikationslogik
• gRPC für verteilte Kommunikation
• MySQL als Datenbank
• Python und Robot für Testautomatisierung

Entscheidend: Der Stack ist nicht dogmatisch, sondern projektspezifisch. Djukic verdeutlicht, dass die Auswahl jeweils auf die Problemstellung gemünzt ist, mit Fokus auf Effizienz und Wartbarkeit.

Echtzeit, Embedded und FPGA: Wer macht was?

In PHIL-Systemen treffen Soft- und Hard-Real-Time aufeinander. Die Zuordnung der Aufgabenbereiche ist nicht nur Performance-Frage, sondern auch eine Frage der Verlässlichkeit.

• Embedded-Software auf SoCs/Mikrocontrollern: Hier nutzt das Team „bare metal“ oder Embedded Linux in C/C++. Für die Interaktion mit der GUI wird TCP/IP-Kommunikation etabliert, Statusmeldungen fließen zurück an die grafische Oberfläche.
• Harte Echtzeit im FPGA: Die zeitkritischsten Pfade – Regelkreise mit höchsten Anforderungen an Bandbreite und Determinismus – sind in VHDL implementiert.

Die Regler müssen „tun, was sie tun müssen“, so Djukic – und zwar deterministisch. In Kombination mit hochbandbreitigen Verstärkerstufen entsteht so die Fähigkeit, Spannungen und Ströme präzise und schnell zu generieren – essenziell für die Emulation dynamischer Netzzustände, PV-Profile oder Batteriecharakteristiken.

Mechanik und Energiedichte: Das physische Fundament

PHIL ist nicht nur Code und Logik. Djukic hebt die mechanische Dimension hervor: Die Energie- und Leistungsdichte eines Systems muss in ein kompaktes, wartbares Paket. Damit steigen Anforderungen an Thermik, Layout, Servicefreundlichkeit und Sicherheit. Diese Mechanikkompetenz bildet das physische Fundament, auf dem Software, Firmware und FPGA-Design erst zur Wirkung kommen.

Datenfluss: Signal-Generierung, Small-Signal-Akquisition, Post-Processing

Neben der Signalgenerierung spricht Djukic explizit die „small signal acquisition in real-time“ an – also die Erfassung kleiner Signale in Echtzeit. Diese Daten werden zur weiteren Auswertung, zum Post-Processing und zur Bewertung von Standardtests wie auch Ad-hoc-Szenarien herangezogen. Für Teams bedeutet das: Die Plattform ist nicht nur Stimulusquelle, sondern ebenso Mess- und Analysegerät – mit durchgängiger Toolingkette bis hin zur Ergebnisbewertung.

Kontinuierliche Verbesserung und Technologie-Flexibilität

Djukic beschreibt die Firmware- und Softwareentwicklung als bewusst interdisziplinär, mit einer adaptiven Technologieauswahl. Lehren aus vorhergehenden Projekten fließen ein; neue Komponenten am Markt werden berücksichtigt. Ziel ist, „kontinuierlich den Ansatz zu verbessern“, um die Plattform optimal an Produktanforderungen anzupassen – genannt wird auch die Verstärkerfamilie „Compiso“.

Diese Haltung setzt sich in CI/CD-Praxen fort: Der Sprecher erwähnt „continuous integration“ und „continuous deployment“ im Kontext automatisierter Tests (Python/Robot) und Integrationspipelines. Für große Testfelder ist das die logische Voraussetzung, Veränderungen sicher und schnell in Betrieb zu bringen.

Was wir als Engineering-Kernprinzipien mitnehmen

Aus dem Vortrag lassen sich klare Prinzipien für Teams ableiten, die PHIL aufbauen oder nutzen wollen:

• Interdisziplinarität zuerst: Mechanik, Leistungselektronik, Embedded, FPGA, Echtzeit-SW und Testautomatisierung müssen Hand in Hand arbeiten.
• Rigorose Aufgabentrennung: Harte Echtzeit in den FPGA, Kommunikations- und UI-Logik in Embedded/Linux und PC-Schicht. TCP/IP als klare Schnittstelle für GUI-Interaktion.
• Tooling-Dualität: GUI für Bedienbarkeit, API/Scripting für Automatisierung und Skalierung.
• Plattform-Vielseitigkeit: Eine Verstärkerhardware sollte DC- und AC-Szenarien via Reprogrammierung abdecken können – ideal für PV-, Batterie- und Netz-Emulation.
• Daten-Ende-zu-Ende denken: Echtzeitgenerierung, Echtzeitakquisition, Post-Processing und standardisierte Bewertung bilden einen durchgehenden Pfad.
• Adaptiver Stack statt Dogma: Technologien wie C++, Qt, gRPC, MySQL, Python, Robot, VHDL werden bedarfsorientiert kombiniert.

Ein Blick in die Praxis: Vom Labor-Setup zur automatisierten Testfabrik

Besonders greifbar wird der Nutzen von PHIL, wenn man die Umrüstzeiten und Testfallwechsel betrachtet. Laut Djukic braucht es „keine massive Neuverkabelung, keine massiven Firmware- oder Softwareupdates“, um ein neues DUT zu prüfen. Stattdessen wird das nächste Gerät angeschlossen, konfiguriert, und in Minuten läuft ein anderer Use Case. Für Teams bedeutet das:

• Höhere Auslastung der Testinfrastruktur
• Schnellere Regressionstests nach Firmware-Änderungen
• Breitere Testabdeckung (z. B. Netzstörungen, PV-Profile, Batteriezyklen)

Gepaart mit Skriptfähigkeit (Python/Robot) und verteilten Protokollen (gRPC) entsteht eine Testfabrik, die skaliert – horizontal über DUT-Varianten, vertikal über Szenarien und Parameter.

Rollenbilder: Wo sich Entwicklerinnen und Entwickler einbringen

Djukic zeichnet ein Umfeld, in dem sich verschiedene Profile einbringen können:

• Firmware-/Embedded-Entwicklung (C/C++, bare metal, Embedded Linux, TCP/IP)
• FPGA-/VHDL-Entwicklung für harte Echtzeit
• Applikations-/GUI-Entwicklung (C++, Qt)
• Testautomatisierung (Python, Robot)
• Daten/Backend (gRPC, MySQL)
• Mechanik und Leistungselektronik

Die Quintessenz: PHIL-Entwicklung ist „nie langweilig“, sehr dynamisch, mit viel Lernpotenzial – und je nach Bedarf auch mit Routineanteilen, wenn jemand das bevorzugt. Die Botschaft an Interessierte ist offen formuliert.

Praktische Takeaways für Engineering-Teams

• Starten Sie mit einer sauberen Aufteilung: Was muss deterministisch sein (VHDL/FPGA)? Was darf in Embedded/Linux? Wo sitzt die GUI?
• Investieren Sie in eine starke API-Schicht: Alles, was man klicken kann, sollte man auch skripten können. Das entschärft Engpässe und ermöglicht CI/CD im Testfeld.
• Standardisieren Sie Datenpfade: Echtzeit-Akquisition, Persistenz (z. B. MySQL) und reproduzierbares Post-Processing sind die Basis für vergleichbare Ergebnisse.
• Optimieren Sie auf Umrüstzeit: Konzeptionieren Sie Hardware-Interfaces, sodass DUT-Wechsel ohne „massive Recabling“-Aufwände möglich sind.
• Halten Sie den Stack flexibel: Nutzen Sie etablierte Bausteine (C++, Qt, gRPC, Python, Robot, VHDL), aber wählen Sie pro Projekt die beste Kombination.

Fazit

„EGSTON Power Technology Overview“ zeigt, wie PHIL heute aussieht, wenn man Simulation, Echtzeit und Leistung konsequent verbindet: breitbandige Verstärker, die DC- und AC-Szenarien emulieren; eine modulare Architektur aus PC, Echtzeit-Engine und Verstärker; harte Echtzeit im FPGA, steuerbar über GUI und API; Datenfluss von der Generierung über die Akquisition bis zur Auswertung. Dazu ein adaptiver Technologie-Stack und eine Entwicklungsorganisation, in der Mechanik, Firmware, Software und Testautomation eng verzahnt sind.

Für Entwicklerinnen und Entwickler ist die Botschaft eindeutig: Wer an der Schnittstelle von Simulation und realer Leistungselektronik arbeiten will, findet in PHIL das ideale Spielfeld – mit viel Verantwortung in Echtzeitpfaden, aber auch mit modernem Software-Engineering und Automatisierung. Für uns war es ein seltener, dichter Einblick in die Praxis einer Plattform, die Testen auf bis zu 1 MW zu einem softwaregesteuerten, wiederholbaren Prozess macht.

• 

  

  Gerhard Ecker, CEO von EGSTON Power

  Der CEO von EGSTON Power Gerhard Ecker gibt im Interview Einblicke in das Unternehmen, wie das internationale Team zusammenspielt und was die dort entwickelte Technologie besonders macht.

  Jetzt ansehen