Who We Are
Hyperdrives is a deep-tech engineering company founded in 2021 in Munich. We build highly power-dense electric drive systems around hollow-conductor-cooled motors, in a package up to 50 percent smaller than today’s series motors, and we supply turnkey drive systems to project customers while working with OEMs and Tier-1 suppliers towards industrialisation. Our software team is small, our roadmap is not, and every hour on the power test bench counts.
With Typhoon HIL, we validate our inverter software every day at our desks, long before we get time on the test bench.
Where We Started
Anyone who writes software for motor inverters will know this one. A new build is ready, and before you can even ask whether it works, you are asking when you can get on the test bench. For a long time, bench availability pretty much decided how our week went. And the bench is not only scarce, but it is also the most expensive place to find a software bug. A wrong sign in a current reference, a mishandled CAN message during a torque step, or a protection threshold that trips too late could cost us a prototype inverter or motor sample. Once something has gone wrong under power, working out whether the cause was in the software or in the hardware takes days, not hours.
Even once we had the bench, setting up the power stage, motor, protections, and measurement equipment could easily take half the morning before the first test started. With two motor variants, and calibration, tuning, and debugging all needing the same bench hours, it was clear we needed a different approach.
Bringing the Motor to Our Desk
So we moved the motor to our desks, in simulation at least. Our inverter control board is now connected to Typhoon’s HIL506 through low-voltage signals, and the HIL simulates what the bench used to provide—the motor, the power stage, and the DC-link—in real time. We built the motor models in Typhoon Schematic Editor, added a HIL SCADA panel, and automated our tests using the TyphoonTest IDE and the Typhoon HIL Python API. The motor models are non-linear, including saturation, and were parameterised from earlier measurements on our test bench. That way, the controller sees the same motor on the HIL that it later meets on the bench.
Within the first week, the control board was running against the simulated motor much like it would against the real one. What started as an experiment has since become a normal part of how we work, and today every new software build goes to the HIL first, well before it sees a test bench.
The test bench stopped being the place where we start. It became the place where we confirm.
Two Motors, Our Own CAN, and Tests on Every Build
One of the first things we noticed was how easy it is to switch between our Gen3 and Ultra motor generations. Both models use the same interface, so changing motors just means loading a different model. It takes a few minutes and no rewiring.
CAN was flexible too. For automated tests, the Typhoon model handles the communication. When we want to look at things ourselves, we connect our own CAN tools and inverter GUI and let the HIL simulate only the motor. Either way, we can recheck our messages and their timing every time the software changes.
Our state machine regression now runs automatically and gives us a report at the end, and we plan to add the other test areas next. Faults that are hard to provoke on a real bench, such as overcurrent, overtemperature, or Safe Torque Off, can be triggered in the model whenever we need them, and they behave the same way every time without ever putting a prototype at risk. For more exploratory work, we use the intuitive SCADA panel.
AI has changed how we write the tests, too. We start from the specification and a short prompt for the test area, and the AI breaks it down into a test plan and detailed test cases. It is especially good at the edge cases that are easy to miss by hand: the last value inside a limit and the first one outside it, both directions of rotation, invalid state requests, and a CAN message that stops arriving. Where the specification does not give a value, the AI marks it as open instead of guessing, so an engineer closes the gap rather than finding an invented number later. From the reviewed test case, the AI then drafts the TyphoonTest script in Python, which runs on the HIL from the TyphoonTest IDE through the Typhoon HIL API and adds its results to the same report as the rest of our regression. An engineer reviews and approves every step along the way.
Opening the Box, Without Opening the Box
Debugging turned out to be one of the biggest improvements. On the test bench, our control board sits inside the inverter housing, behind the bench protections, so connecting a debugger (such as the Lauterbach in the picture) meant opening covers and working around the safety setup.
On the HIL, the board sits open on the desk. We connect the Lauterbach cable, run the software against the simulated motor, and read registers and variables live while the test is running. Deep debugging is now something we can do whenever we need it, not something we have to plan for.
Arriving at the Test Bench Ready
Calibration used to take up a lot of our bench time. Today we do the lambda bandwidth tuning of our current controller and set up the motor parameters for both motors on the HIL, so every new software release arrives at the bench already tuned. We set the target bandwidth, check the response on the simulated motor, and configure the parameters. We built and checked our whole calibration parameter structure the same way.
So when we do get to the bench, most of the groundwork is already done, and we can spend that time confirming the results on the real motor instead of starting from scratch. And when something does need attention on the bench, we can largely rule out the control software as the cause and concentrate on what the bench is really there for: the thermal behaviour, the NVH effects and the mechanics.
What Changed For Us
The biggest change for us is where the work happens. Testing, debugging, tuning, and calibration have largely moved from the bench to the desk, and our software team no longer has to wait for hardware to make progress. Software issues now surface at the desk, with every signal visible, and are fixed in hours instead of days.
What’s Next
AI-drafted test cases are already part of our everyday workflow. The next step is an agentic development flow. We have built an MCP server for the Typhoon HIL application and tested it with basic calls. The full end-to-end workflow is still in progress, but the groundwork is there, and we are looking forward to taking it further.
Being able to switch motors in minutes, debug on an open board and tune before going to the bench has really changed how our team works.
Benjamin Hengstler
Co-founder and Chief Software Officer
Hyperdrives
The time we used to spend setting up the test bench now goes into improving our software.
Uthara Keerthan Ramamoorthy
Embedded Software Developer
Hyperdrives
If you know your motor well enough to build it, you know it well enough to model it. From that point on, the controller cannot tell the difference, and that is the moment you can test everything.
Andrea Loi
Technical Sales Lead e-Mobility DACH
Typhoon HIL
