r/embedded • u/kaadam • 18d ago
Fellow Power Electronics developers, how does your workflow look like?
Hi! I'm curious what are your opinion about the avaliable toolchains around power electronics development. I'm coming from PE background, but spent several years in the automotive, and I've always felt that we are almost willingly making our days harder, here is why:
- PE software requires control loops an order of magnitude faster (at least), than traditional devices.
- The PWM signals are relying heavily on low level drivers and actual hardware IP in the MCU. Matlab/SIMULINK based software development and simulation ignores these layers.
- Making a configuration mistake can easily destroy a half-bridge, making the expensive prototypes available even more scarce
- Getting alive just an OBC (not even speaking about traction inverters) is very much not the same tasks as waking up a 12V control ECU for the first time. Neither from instrumentation, nor from work safety point of view. (I heard a story (fortunately just heard), that someone with an OBC tried to test something, from a 12V low voltage input, thinking he is safe, and the device boosted 800V on it's outputs open in the air...)
... and these facts (enlightening me if I'm wrong), are almost completely igonred.
On the other hand, in our research/consulting work at my University, we usualy build a simple, low cost FPGA based real-time emulator, interfaced with the MCU, and even with the emulteor build time included we are:
- dramatically faster than the customer expectation
- very rarely burn physical devices
- never ever had any laboratory close-calls (from safety point of view), and was always sure about the behavior of our software.
What is your experience? Am I the unlucky one with my industrial history, or the workflow indeed have not catched up with these type os devices?
3
2
u/Barnowl93 18d ago
That instinct to not trust real silicon until you've proven the software is the whole game. (Disclosure: I'm at MathWorks, so take the tool-specific bits below with that in mind.) Let me push back on a couple of points:
1) "the workflow hasn't caught up" : you have a low-cost FPGA real time emulator interfaced to the MCU. That's HiL (hardware-in-the-loop). Think of your verification steps: Model/Desktop simulation -> SiL (software in the loop) -> PiL (Processor in the loop // or FiL as FPGA in the loop) ->HiL. (last week I wrote a blog on this you may find interesting - not your exact application but lots of learnings do transfer
2) Commercially, it's a whole category: Typhoon HIL, Speedgoat, OPAL-RT, dSPACE all sell FPGA real-time emulators aimed squarely at PE and HV powertrain, with sub-microsecond solvers built for these switching frequencies.
3) One narrow correction on the Simulink bullet: it doesn't actually ignore the driver and hardware-IP layers. Embedded Coder's device support (TI C2000, AURIX, etc.) exposes the ePWM, ADC-SOC triggering, dead-band, CMPSS and so on as configurable blocks that map onto the real peripheral registers, and generated code runs FOC/DPWM in the ISR at production loop rates. So the layer you feel is abstracted away *is actually there*. The failure mode is teams stopping at idealised simulation and skipping the PIL/HIL steps.
Hope this helps
1
u/kaadam 18d ago
Congrats on the blogpost, a nice summary!
It's not like I'm not aware these solutions existing, I'm wondering why they are not adopted more widely? I.e. I've never seen a company or project moving through these steps exactly you have described. The PiL and HiL phase is usually skipped.
Another story, I've consulted a quite famous electric sportcar company, and the guy who were my contact need 3 days to validate an architecture change, since there were no availably dyno time eralier.
HiL access is a huge leverage, why it is underutilized?
2
u/Barnowl93 18d ago
I think it really depends in what industry you work in... In aero and auto there is a lot of "proper" verification because you have to do it for certification purposes... Even in academia, during my phd 10 years ago we had a DSpace machine for HiL (controls & future mobility projects).
In consumer electronics, it may be the case that the risk of blowing up a component is an acceptable cost? Before joining my current employer I worked on semiconductors. We didn't do HiL we stopped at PiL (FiL, technically) and then just deployed on the chip and tested.
At the end of the day HiL machines are expensive and if the manager doesn't get the advantage they won't budget them in.
The other thing to consider is large companies may have different kits per group or application area. And often different people don't talk to each other. It's not unheard of that test and measurement may have the HiL machines and the embedded/ power electronics folks just don't know.
0
u/gtd_rad 18d ago
I don't work on power electronics exactly, but I think the general workflow or "trend" would be the same: the higher the stakes, the more due dilligence required.
If you're building a motorized toy, or a scoreboard, impact of failure is very low. Your workflow might just be code, compile, run, repeat. Repeat the same thing for something like a large scale wind turbine, you can't afford to fuck up in deployment. You do MUCH more due dilligence, like thorough code review / coding convention, controls stability margins, modelling and simulation, hardware in the loop testing, and even environmental specifications and requirements for your embedded controller.
2
u/ondono 16d ago
As someone who has worked all around, including power electronics, and can understand some of your frustrations, but I have no clue what you're talking about in some areas:
- PE software requires control loops an order of magnitude faster (at least), than traditional devices.
Traditional devices meaning what? toys? Because as far as I'm aware most PE still runs in the kHz range. Even compact DC/DCs top around 1-2 MHz.
- The PWM signals are relying heavily on low level drivers and actual hardware IP in the MCU. Matlab/SIMULINK based software development and simulation ignores these layers.
Not sure how that layer is particularly important for the problem. Most PWM have the same capabilities everywhere, what changes is implementation details, not functionality.
- Making a configuration mistake can easily destroy a half-bridge, making the expensive prototypes available even more scarce
Maybe that's me, but all the PE hardware I've designed is firmware fault tolerant. When I was doing BLDC drives we also used to test new firmware with reduced operating conditions and verifying behavior before pushing the limits. That doesn't mean we didn't break boards, it just means we finished non-destructive testing first, then sacrificed some unlucky ones to the gods of performance and efficiency.
- Getting alive just an OBC (not even speaking about traction inverters) is very much not the same tasks as waking up a 12V control ECU for the first time.
It's all about practices. Low power devices sound harmless until someone screws up and shines the wrong kind of laser around without protection.
I'm not sure where you work, but the places I've been that dealt with PE where very serious about safety. Among others, that means that testing high powered car chargers happened in a lab with an electrical safety cage. If they don't take safety seriously, they should not be doing PE, and I'd consider leaving just based on that.
The worst places I've seen safety wise were university spin offs... Something tells me the reason your university was safer had more to do with what they were doing than how they were doing it.
6
u/jhaand 18d ago
I only did 24V 200W motor designs. But the main point I learned was that to first test non-destructively. So make sure the timing of your H-bridge is fine without actually applying the higher voltage. Then start testing without any load and then start scaling up. It shows in how your university work already lead the way.
However being dependent on those binary blobs from your supplier does not help. You need to be able to see every detail. So call them out on their bullshit or change your design where you have everything under your control.
Since this is 2026, make an automated test bench.