AI for Power Electronics: From Physics to Useful Models

Start with the engineering decision, not the algorithm

A request such as “use machine learning for this converter” is not yet a specification. The team still needs to know what answer is required, when the answer is used, which inputs exist at that moment and what happens when evidence is weak.

Write a short decision contract first. Name the target, units, operating conditions, acceptable error or classification cost, human reviewer and the cases that must request another simulation or measurement. Only then decide whether a rule, equation, lookup table or learned model is appropriate.

• Decision: the next engineering action the result may support.
• Inputs: values genuinely available before that decision.
• Reference: the simplest calculation or existing process worth beating.
• Acceptance: an error or outcome tied to the intended use, not a generic score.
• Refusal: conditions that trigger warn, abstain or escalate.

Keep a physical baseline beside the model

A baseline gives the model a job to earn. For conduction loss, P = I²R may already be the correct answer. For an LLC screen, a documented analytical approximation may remove clearly unsuitable candidates before a slower method runs. For diagnosis, a traceable fault tree may be safer than a classifier when evidence is sparse.

The baseline does not have to be perfect. It has to be credible, reproducible and evaluated on the same cases as the candidate model. Report where the model improves on it and where it does not. If the learned system cannot beat the baseline in the decision-relevant region, keep the baseline.

Choose a use case with a testable output

Useful applications tend to have an observable target and a repeated cost. A surrogate can approximate a slow calculation inside a defined design space. A classifier can route simulation records for review. A diagnostic aid can rank hypotheses or propose the next safe test. An optimiser can search candidates while explicit constraints remain authoritative.

These tasks are different. Regression estimates a quantity; classification chooses among defined labels; anomaly detection flags unfamiliar behaviour; optimisation proposes candidates. Do not collapse them into one promise that “AI designs the converter”. Each requires different data, checks and failure semantics.

• Surrogate estimation: compare residuals across operating regions and designs.
• Design screening: preserve the rule result separately from solver execution state.
• Fault triage: keep measurements, hypotheses and authorised tests traceable.
• Optimisation: recheck proposed candidates with the governing engineering method.

Make every dataset row explain where it came from

Power-electronics data may come from equations, circuit simulation, finite-element models, bench measurements or service records. Those sources are not interchangeable. Record topology, component or design identity, operating point, units, method version, convergence state and label definition alongside the values used for training.

A large table can still contain little independent information. Thousands of waveform windows from the same design are related. Randomly scattering those rows across training and validation can make a model appear transferable when it is recognising the same design context. Group records by the physical unit that must remain unseen in real use.

Validate the claim you intend to make

Training performance answers whether the model fitted the examples it saw. A separate validation set supports development choices. A reserved set can support one final comparison after the method, features and thresholds are frozen. None of these automatically demonstrates performance on hardware or on a different converter family.

Report more than a single average. Inspect maximum error, error by operating region, residual shape and the cases with the highest decision cost. For classification, show the confusion matrix and define which mistakes matter most. For grouped data, publish the group assignment so another engineer can see what was actually held out.

• Split by design, device, campaign or another independent engineering unit.
• Freeze preprocessing inside the training path to prevent leakage.
• Compare baseline and candidate on exactly the same untouched cases.
• Retain failed executions and missing evidence instead of silently deleting them.

Small example: learn what a prediction is without replacing I²R

Begin with currents and a fixed resistance. Generate conduction-loss examples from P = I²R, train a small regression tree and ask for a current between training points. The tree returns a piecewise-constant estimate while the equation returns the physical reference.

The visible steps are useful: they show that a model learns from examples and from its representation, not from the meaning of current, resistance or loss. Remove a band of currents and the weakly covered region becomes an explicit test. Add only a few carefully chosen examples and compare again on the same validation currents.

Treat unfamiliar inputs as a separate engineering outcome

A model usually returns a number even when the request lies outside its useful domain. The interface must therefore check whether the topology, ranges, materials, operating conditions and feature combinations are represented by the validated population.

Use explicit outcomes such as use, warn, abstain and escalate. A warning can request a higher-fidelity simulation. Abstention can block a prediction when required inputs are absent. Escalation can preserve the case for human review. These behaviours should be tested with examples, not left as policy text alone.

Publish the evidence package, not only the score

A reusable result includes the problem definition, data card, frozen configuration, code or notebook, baseline, split manifest, metrics by region, failure record and a short statement of what the experiment does not prove. Hashes and versioned artifacts make later comparisons interpretable.

For public engineering work, identify whether the evidence is an educational example, a simulation result, a measured result or a hardware-validated decision. That distinction protects both the reader and the usefulness of the work: the next person knows what can be reproduced and what still requires evidence.

Choose the next practical step

Start with the short browser exercise if you have never trained a model. Then inspect the LLC case to see how a result, a method failure and a final decision remain separate.