EGSTON Power Electronics GmbH
EGSTON Power Technology Overview
Description
Dragan Djukic von EGSTON Power gibt in seinem devjobs.at TechTalk einen Überblick über die im Unternehmen entwickelte Technologie und welche ungeahnten Möglichkeiten sich hier für Developer finden.
By playing the video, you agree to data transfer to YouTube and acknowledge the privacy policy.
Video Summary
In EGSTON Power Technology Overview, Dragan Djukic outlines how EGSTON Power Electronics GmbH delivers turnkey Power Hardware-in-the-Loop and high‑power test systems up to 1 MW by tightly integrating software, hardware, mechanics, and firmware. He explains how PHIL merges real‑time simulation with high‑bandwidth power amplifiers to emulate PV panels, batteries, or the grid (AC and DC), allowing devices under test—such as inverters or wind‑turbine systems—to interact with the model and speeding development before prototypes exist. He also details the architecture (control PC, real‑time processing engine, amplifier) and tooling (GUI plus scriptable API; C++/Qt, gRPC, Python/Robot; embedded Linux or bare‑metal MCUs and FPGA/VHDL) that enable rapid reconfiguration and automated, standardized or ad‑hoc tests with real‑time signal generation and measurement—practices viewers can apply to automate DUT testing and accelerate megawatt‑scale validation.
From Models to Megawatts: Power Hardware‑in‑the‑Loop at EGSTON — Our Recap of “EGSTON Power Technology Overview” (Dragan Djukic, EGSTON Power Electronics GmbH)
Why Power Hardware‑in‑the‑Loop (PHIL) matters for modern power electronics
In the session “EGSTON Power Technology Overview,” Dragan Djukic (Senior Engineer, EGSTON Power Electronics GmbH) walked through how power hardware‑in‑the‑loop (PHIL) shortens development cycles for high‑power electronics. The familiar path—idea, model, simulation/validation, then first prototypes—hits time and cost limits when you scale to hundreds of kilowatts or a megawatt. PHIL extends the process by merging validated simulation with high‑bandwidth power amplifiers so that a device under test (DUT) can interact with realistic voltages and currents well before the first hardware series is built.
As Djukic puts it, PHIL “bridges the gap” between digital models and physical behavior. The simulation’s voltage/current waveforms are translated into real power at the amplifier output—up to the megawatt range. The payoff is earlier insight, fewer prototype iterations, and faster design loops at power levels where each iteration is expensive and slow.
“Power hardware in the loop extends this concept of simulation by means of bridging the gap and merging the simulation environment together with high‑bandwidth power amplifiers … in order to get a fully‑fledged and efficient framework for testing devices even before they are actually produced.”
Equally important, PHIL is not a single‑discipline discipline. Djukic emphasizes the blend: mechanical and power design, embedded and real‑time software, firmware/FPGA, and tooling for user control and automation.
The classical flow—and where PHIL changes the game
The conventional sequence for something like an inverter is:
- Concept/topology
- Simulation model and validation
- Acceleration via real‑time simulation
- Prototype fabrication and lab test
PHIL inserts a new stage between steps 3 and 4. Instead of jumping straight to physical prototypes, the validated real‑time model is coupled with a high‑bandwidth amplifier. The DUT sees realistic source/sink behavior—grid, PV, or battery—without the overhead of physically assembling those sources. That means earlier interaction with dynamics, protection, and control, while a lot of hardware complexity remains virtual.
The value is twofold:
- Early, realistic validation of control loops and protection logic.
- Shorter, cheaper iterations, as limits and flaws surface before the first hardware run.
Versatility by design: one amplifier, many roles
Djukic offers a memorable example: a single amplifier can take the role of a PV panel, a battery, or the grid. In other words, the same hardware can emulate DC and AC scenarios. That level of versatility reduces setup time, minimizes re‑wiring, and broadens test coverage.
He notes that many systems on the market are limited—either DC‑only, AC‑only, or restricted in their energy‑flow direction. The approach described here prioritizes reprogrammability and breadth of use cases.
“By means of emulation, we can emulate both DC and AC use cases with the same amplifier … there are many use cases for an amplifier whose characteristic is to be highly versatile, programmable, and which can be used in many different scenarios simply by means of reprogramming it.”
For AC‑side DUTs (e.g., inverters or wind‑turbine components) and DC‑side DUTs (e.g., PV or battery emulation), being able to switch quickly between roles is the foundation for automation and scale.
The PHIL bench architecture: control PC, real‑time engine, power amplifier
Djukic outlines a three‑block setup:
- Control PC (left)
- Real‑time processing engine (middle)
- Power amplifier (right)
The DUT connects to the amplifier outputs. Djukic references the “Computer System Unit” as the name of one amplifier platform. The key is modular flexibility: swap the DUT, load a new configuration, and “in a couple of minutes” you’re running a different scenario.
“Remove the current device under test, connect the next one … and in a couple of minutes there is a completely different use case scenario.”
For us, that quick turn is not just convenience—it’s the backbone of scalable test automation and continuous verification at high power.
Control and automation: GUI for humans, APIs for pipelines
Every amplifier is paired with a graphical user interface (GUI) and multiple ways to control the system:
- GUI mode: Click‑driven interaction, configuration, start/stop, status feedback.
- Script/API mode: Automation without the GUI, with procedures driven programmatically.
For automation, the team uses scripting frameworks such as Python and Robot. On the integration side, Djukic mentions gRPC and MySQL—signal clues that the platform is distributed and data‑backed.
Technology stack (as mentioned)
- C++ and Qt Creator for GUI/application logic
- gRPC for distributed communication
- MySQL for persistence
- Python and Robot for automated testing
The theme is pragmatic choice rather than dogma: pick the right tools per product and project to achieve an “optimal” solution at this level of complexity.
Real time in layers: embedded, networking, and FPGA
PHIL brings together soft and hard real‑time. Djukic separates concerns clearly:
- Embedded software on SoCs/microcontrollers runs either bare‑metal or on embedded Linux in C/C++. TCP/IP is used so the GUI can communicate status and commands to the embedded layer.
- The hard real‑time path is implemented in FPGA using VHDL. This is where the highest reliability and determinism are required—control loops and bandwidth‑intensive signal generation.
“The hard real‑time features … are implemented in the core FPGA technology by means of using VHDL as hardware description language … with the highest degree of reliability.”
He also underlines the practical constraint: regulators “must do what they must do” in real time. That’s why the split between FPGA and software is a core architectural decision, not a post‑hoc optimization.
Mechanical design and energy density: the hardware reality
Djukic stresses that mechanical design is integral: squeezing high energy density into compact, serviceable enclosures is non‑trivial. Thermal management, safety, accessibility, and maintainability are prerequisites for making PHIL not just powerful but usable on a daily basis.
Data path: generation, small‑signal acquisition, and post‑processing
Beyond generating voltages and currents in real time, the platform supports “small signal acquisition in real‑time.” This enables end‑to‑end workflows: stimulus generation, measurement, post‑processing, and evaluation of standardized tests or ad‑hoc scenarios. In other words, the bench is both source and instrumentation, with data captured and stored for later analysis.
“… signal generation in real‑time, small signal acquisition in real‑time … post‑processing, evaluation of standardized tests or … ad‑hoc test scenarios.”
Continuous improvement and an adaptable stack
Djukic frames both software and firmware as interdisciplinary endeavors with an adaptable technology stack. Lessons learned inform new products; interesting components on the market are considered; the team “continuously” refines their development approach. He references an amplifier family by name—“Compiso”—as an example of the product context where that evolution applies.
Automation and integration are intentionally built‑in, with “continuous integration” and “continuous deployment” mentioned alongside Python/Robot test suites. At high power, that CI/CD discipline is what allows safe, rapid iteration.
What engineers can take away
The talk offers a set of practical principles for anyone building or adopting PHIL:
- Lead with interdisciplinarity: mechanical, power, embedded, FPGA/VHDL, real‑time software, and test automation belong on one team.
- Assign responsibilities by timing constraints: hard real‑time in FPGA; communications and UI in embedded/Linux and the PC layer; TCP/IP as the interface for GUI interaction.
- Support both exploration and scale: a capable GUI for day‑to‑day use, and an API/scripting path for automation and CI/CD.
- Design for versatility: aim to cover DC and AC scenarios on the same amplifier through reprogramming—so you can emulate PV, battery, and grid behavior as needed.
- Make data a first‑class citizen: real‑time acquisition, persistence (e.g., MySQL), and reproducible post‑processing are essential for comparable results.
- Keep the stack flexible: C++, Qt, gRPC, Python, Robot, VHDL—choose per project rather than forcing a one‑size‑fits‑all approach.
From lab convenience to a test factory
Djukic highlights that switching DUTs should not require “massive recabling” or heavy firmware/software updates. Instead, attach the next device, configure, and within minutes run a new scenario. Practically, that means:
- Higher utilization of the PHIL bench across teams
- Faster regressions after firmware changes
- Broader coverage: grid disturbances, PV profiles, battery cycles, and more
Backed by APIs and scripting, that agility evolves a bench into a test factory—one that scales horizontally across DUT variants and vertically across scenario complexity.
Roles and skills: where engineers fit
The environment Djukic describes welcomes multiple skill sets:
- Firmware/embedded (C/C++, bare‑metal, Embedded Linux, TCP/IP)
- FPGA/VHDL for hard real‑time
- Application/GUI (C++, Qt)
- Test automation (Python, Robot)
- Data/backend (gRPC, MySQL)
- Mechanical and power engineering
It’s “never boring,” highly dynamic, with plenty of learning opportunities—and, depending on needs, room for routine tasks if that’s your preference.
Closing thoughts
“EGSTON Power Technology Overview” captures how PHIL becomes practical at scale: high‑bandwidth amplifiers that can play PV, battery, or grid; a modular bench of control PC, real‑time engine, and amplifier; hard real‑time in FPGA, with GUI and APIs on top; and a complete data path from generation to analysis. The development culture is to iterate continually, adapt the stack, and fold lessons back into products like the Compiso amplifier family.
“We are always trying to continuously improve our approach … to developing firmware in an optimal way.”
For engineers, the message is straightforward: if you want to work where simulation meets real power, PHIL is a compelling space—demanding on timing and reliability, yet rich in modern software, automation, and system‑level design. As an editorial team, we found it a clear, grounded view into how high‑power testing up to 1 MW becomes a software‑defined, repeatable process.
