Since the introduction of SPICE by the University of California, Berkeley in 1973 and the consequent proliferation of SPICE-like commercial software, one can safely say that there have been millions of simulation sessions in hundreds of thousands of companies, universities, research labs, semiconductor companies and power-supply design houses. These simulations have contributed immensely to the state of our electronics-dependent civilization.
The SPICE simulations have allowed the design engineer to design, verify and run his or her designs without physical silicon devices, inductors or capacitors. They have also allowed the engineer to almost fully (depending on how good the models are) debug a design without building the prototype and without blowing up a single device. Furthermore, these simulations have proven invaluable in helping innovators to fully investigate new topologies and power-delivery architectures and, hence, forever alter the face of the often-maligned power supply.
In my work over the years, I had to resort to other kinds of simulators that are physics-based to help me to better understand issues like skin effect and proximity effects in complex semiconductor packages. This work led me to a more in-depth understanding of the problem under investigation, how to quantize it and ultimately how to improve package performance in newer and better ones.
Since power delivery extends its reach to driving all sorts of motors such as brushless dc (BLDC), actuators for meters and locks, all these motors have to be in a closed control loop to perform the functions for which they were intended.
Let us take the example of a complete motor drive circuit with control logic, feedback loop and power components that interact directly with the motor that delivers torque to the load through some sort of a gearbox. You can attempt to simulate such a system using SPICE-like software that will require the writing of pages upon pages of equations — and hope you have them all right without any mistakes in the equation formulation or any errors in variable names.
When all of this has been done, you solve the entire system for a fixed parameter set. If you were to change any parameter, you would have to repeat the simulation with the new parameter set.
Currently, some software packages can do this job, but by the time you have formulated your system, it looks nowhere close to the simple few blocks you started out with in the beginning. These very sophisticated software tools require great experience, knowledge and patience to do the job.
What is needed right now is a multi-domain simulator where you can enter physical components like motors, gearboxes, couplers, and their control circuit on one simple block diagram. Within this same diagram, you should be able to enter the parameters of the system and have the software solve the entire set of differential algebraic equations. Finally, the simulator should present the results in a format that would allow you to examine the system in view of all the parameters involved and that would preferably be in a symbolic notation.
The power of symbolic notation cannot be underestimated since it packages complete systems, when mathematically possible, in a finite number of equations that can be explored on their own in view of the system at hand. Or these equations can be assembled together to form a subsystem block in a larger and more complicated system with the knowledge that your new subsystem behaves exactly as you have designed it.
This type of software would be a great addition to the toolbox of any power engineer privileged enough to be a member of a team in charge of the design of complicated systems that cross the boundaries of electrical, electronic, and mechanical or hydraulic domains.