How can it take multiple CPU cores, a bank of hardware accelerators, and a 10G Ethernet interface to control an electric motor? For designers who have run a motor with a $1 microcontroller (MCU), the question may sound absurd. Yet the answer is both an intriguing case study in control systems design and an indication of the direction in which architecture for real-time systems is moving.
Permit us to introduce the diminutive central character in our drama, the permanent-magnet synchronous motor, henceforth known by his stage name, PMSM. PMSMs come in a wide range of sizes and shapes, and many intended applications, from opening and closing massive doors to articulating robotic surgical tools. Across this space they are gaining popularity because of their inherent reliability, low cost, and—to our point here—their accuracy and efficiency when properly controlled. In effect, as the application becomes more demanding, PMSMs allow you to transfer complexity from the electromechanical design into software.
PMSMs are mechanically and electrically very simple (Figure 1).The rotor is, as the name suggests, a permanent magnet. There are (normally) three stator windings, evenly spaced 120 degrees apart around the motor case. The only real secret sauce, if you will, is that the windings aren’t uniform: the density of turns is sinusoidally distributed around the stator, so that the windings actually overlap each other a bit at the edges. By applying sinusoidal currents in appropriate phases to the windings, you create a rotating magnetic field at right angles to the rotor field, thereby applying torque very efficiently to the rotor.
Controlling the PMSM is not rocket science. A simple MCU can use a look-up table and interpolation to generate the necessary time-varying sinusoids for the driver circuits, which in turn provide current to the windings. If you do the arithmetic correctly, the windings will generate a rotating magnetic field inside the motor, and the rotor will obediently follow it. There are a few details about starting up from a dead stop, but otherwise–mission accomplished, right? Not quite.
Problems, as always with open-loop control, lurk in the details. Starting the motor, especially under load, can be rough and wildly inefficient. The open-loop controller will never respond optimally to changes in load torque or speed commands, and can do nothing to suppress vibrations. For all the usual reasons, a feedback control system would work better.
The problem is figuring out what to control. Obviously we want to control the rotor angle—or in some applications, the rotational velocity. We have to do that by controlling the three winding currents that generate that rotating magnetic field. The best way to do this, the industry has decided, is a multi-step process called—rather grandly—field-oriented control (FOC) (Figure 2).
First, we capture samples of the rotor position from a shaft encoder, and samples of currents from two of the three windings. We don’t need all three, thanks to some mildly clever math. These samples tell us the instantaneous position and lagging velocity both of the rotor and of the stator’s rotating magnetic field. Our job is to control the speed or position of the rotor by controlling the current amplitude in the stator windings, while keeping the rotating magnetic field 90 degrees ahead of the rotor’s magnetic field.
We make this job easier with two simple transforms. The Clarke transform maps the current samples from the two stator windings—which are 120 degrees apart, remember—into a pair of orthogonal vectors. The direction of the vectors is fixed relative to the stator, and of course their vector sum is the rotating magnetic field vector. The Clarke transform only requires multiplying the current values by constants and adding up products—simple multiply-accumulate operations.
Then the second transform, the Park, maps these two orthogonal vectors into the rotating frame of reference of the rotor. One vector aligns with the rotor magnet’s field, and the other—the quadrature vector—is at right angles to it. The Park transform is a little more challenging. It uses instantaneous shaft position to compute sin(θ) and cos(θ) coefficients before doing the vector multiplication to transform the vectors to the rotor’s frame of reference.
Now we have signals we can control. We’d like to keep the vector that is aligned with the rotor—and represents the stator flux that is not applying torque to the rotor—at 0. We use the quadrature component—the stator flux actually applying torque—to control the rotor position and velocity.
For example, the controller might take a desired-position input, compare it to the actual shaft angle in a conventional discrete-time proportional-integral (PI) control circuit, and generate an error-signal output to the FOC block. The FOC block would then turn this error signal into a quadrature torque signal to turn the rotor. Then the block would apply the inverse Park transform to map that torque back into the fixed frame of reference of the stator, and then the inverse Clarke transforms to map the torque signal into currents to apply to the three windings. Thus a change in the desired-position or desired-velocity inputs stimulates signals to the stator windings that rotate the stator magnetic field and bring the rotor to the desired angle.
Altogether, the computing load is not that great: perhaps two trigonometric evaluations, ten multiplications, and seven additions per sample interval in the FOC block, plus a few more operations to implement the PI controller. All of the arithmetic can be done in fixed-point with a little care. With today’s typical 16 kHz sample and pulse-width modulation rates, we are not stressing the integer performance of a modern 32 bit MCU. But wait, there’s more.
Let’s start with that shaft encoder. The FOC algorithm must have accurate shaft-angle feedback. Traditionally this data would come from a shaft encoder—an electro-optical-mechanical device attached to the motor shaft. But an encoder adds expense, size, weight, and a number of new failure modes to each motor in the system. And it requires an industry-standard interface on the controller.
In fact there is, in principle, enough information in just the stator-winding voltages and currents to determine the rotor position. Doing so allows sensorless operation—at least to the extent that you can eliminate the shaft encoder and replace it with one more current sensor and three voltage sensors, all of whose signals will have to find their way through precision analog-to-digital conversion. And that allows you to transfer a lot of mechanical complexity into the software.
Here is the idea. The voltage across the terminals of a winding has two major components: the IR drop due to the winding series resistance, and the back EMF from the winding inductance. But that back-EMF itself has two sources: the self-inductance of the winding, plus the flux linkage due to the magnetic field lines from the rotor passing through the winding. If you could isolate that last part of the voltage change, you could in principle calculate the rotor angle. Actually doing that involves a bit of computation, including the Park transform, evaluation of an integral, and an inverse trigonometric function at each sample interval.
Unfortunately, except in laboratory situations, you are unlikely to have accurate data for motor characteristics such as winding resistance and inductance. Not only do these figures vary from motor to motor, but they are sensitive to other variables such as temperature and aging.
Consequently, developers have proposed various alternatives for extracting the rotor angle from what is in effect a state variable matrix equation. These ideas include phase-locked loops that lock onto the voltage ripple caused by the rotor, state estimators that calculate the rotor position and compare their answer against previous data, and the ultimate estimator, the Kalman filter. These approaches at least double the computational load compared to direct calculation, requiring at least 30 arithmetic operations per cycle.
One of the promises of FOC is the ability to control vibration and its attendant noise. Such measures can improve energy efficiency and mechanical reliability, and perhaps reduce the need for mechanical overdesign. In consumer markets, they can turn a washing machine selling for $600 into a premium model selling for $800.
Once again, the principle is simple. If vibration is the result of marginal instability in the control loop, you can change the gain on the PI controller and move closer to critical damping. If the shakes are the result of mechanical resonances in the motor mount, driveshaft, or load, you can in principle eliminate them by blocking energy at the exciting frequencies from the torque signal. Conveniently, the FOC approach gives you direct access to the torque signal before it gets turned into three time-varying sinusoids, so this is just a matter of dropping in notch filters to block the energy at the resonance frequencies.
Either action—messing with the loop gain or filtering the error signal–may adversely impact the system’s dynamic speed and position error. But in many applications, transient errors in shaft speed are much less important that smooth, silent operation.
Vibration control requires three major processing blocks: a fast Fourier transform (FFT) to extract frequency spectra from the shaft-position or winding-current data, a detect-and-respond block to identify spectral maxima and decide what to do about them, and one or more programmable notch filters to remove offending frequencies from the torque signal (Figure 3).
Each of these blocks should be appropriate to the application. In some systems where the resonances will be fixed or slowly-changing, the FFT might be a startup or background task. In systems where resonances can move around quickly, the FFTs need to run continuously. The response block will be very application dependent, as the decisions about adjusting PI loop gain, adding a filter, and choosing filter parameters will depend a lot on the nature of the whole electro-mechanical system. So it is not possible to estimate the computing load required for vibration control without rather detailed knowledge of the system.
By this time we’ve run the job up to many dozen, and perhaps a few hundred, arithmetic instructions per 16 kHz cycle—and then there are the FFT calculations. We are getting to the point where the task has grown beyond a simple interrupt service routing on an inexpensive MCU. But more is to come.
The most obvious addition is more motors. Many control tasks are inherently multi-axis: the tool position on a milling machine, for example, or a fully-articulated robot hand. Both integration level and the need to share real-time data across axes suggest the advantage of having one multi-channel controller. But since there is very little redundant computation between axes, having more channels just multiplies the work load.
Then there is the sample rate. Rates today are starting to increase from the historic standard of 16 kHz in search of reduced RMS position or velocity error, with some moving to 100 kHz. Naturally, increasing the sample interval reduces the time available to complete the real-time computations that have to fit within a sample interval.
An external change in factory-floor organization is also putting pressure on controller architecture: subsystems are being networked. A major turning point comes with the addition of an industrial network interface to the design. Increasingly, system designers want to issue commands, check status, and read logged data over the network. The network interface adds not only necessary physical-layer and media-access hardware, but also a protocol stack that executes asynchronously to the sample-synchronized activity of the control loop. Now we have not just a simple interrupt-triggered real-time task, but two tasks with deadlines, one real-time and one network-facing. It would be difficult to escape the need for a RTOS at this point.
Along with network access comes vulnerability. The probability of attack on a network-connected control system, whether it is directly exposed to the Internet or not, is sadly related to the extent of potential damage hacking could cause. There is no safety in anonymity. Accordingly, even subsystems at the seemingly insignificant level of motor controllers must in the future be defended. That means they must authenticate messages and encrypt and decrypt data locally. And that generally means a crypto accelerator.
So our original question is just about answered. We have watched our PMSM controller grow, as we moved more and more features into the software, from an easy task for an inexpensive MCU to a heavy computing load requiring hardware acceleration for some tasks. We have noted the need for FFTs, infinite impulse response (IIR) filters, a network interface, and the attendant security functions. Increasingly, asymmetric multiprocessing looks like the best way of providing enough computing power and keeping adequate isolation between real-time and background tasks.
The computing environment has expanded from an interrupt-driven bare-metal code set to a multicontext workload with many hard real-time tasks and some communications-related background tasks, some of which may themselves have hard deadlines in industrial networks. Such rich mixes almost demand an RTOS. We have seen the need for security demand a root of trust in the kernel. Whether implemented in an FPGA or in cell-based technology, our little motor controller has become a respectable heterogeneous-multicore SoC.