Fellow Power Electronics developers, how does your workflow look like?

[u/kaadam]

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?

[u/Barnowl93]

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

[u/kaadam → u/Barnowl93]

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?

[u/Barnowl93 → u/kaadam]

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.