Using VHDL-AMS to model complex heterogeneous systems, part 1

Motion-control-system development poses many challenges for conventional simulation tools. These systems are extremely complex, and they also traverse technology (domain) boundaries as well as analog/digital boundaries. In addition, computers or DSPs control most of these systems in real time, requiring modeling capabilities that encompass both Z-domain transfer functions and software algorithms.

Conventional simulation tools cannot adequately deal with these diverse modeling requirements. High-level "math-based" tools can often accommodate control-block, algorithmic, and Z-domain modeling needs but fall short in physics-based models, for which conservation laws are intrinsically enforced at the model ports. Low-level tools, such as Spice, can deal with physics-based models but fall short in new-model development and struggle with software-algorithm, Z-domain, and mixed-signal/ mixed-technology-modeling needs.

To bridge this "high-level/low-level" modeling gap, the EDA industry has developed HDLs (hardware-description languages) that can seamlessly fulfill these diverse needs. You can use one such HDL, the IEEE standard VHDL-AMS modeling language, to successfully model a motion-control system.

You can find the type of system shown in Figure 1 in many applications, including aerospace, industrial control, and electric/hybrid-electric vehicles. A DSP commands and controls the system, using a field-oriented technique. The output of the DSP drives into a CRPWM (current-regulated pulse-width-modulated) motor driver, which controls a three-phase induction motor. The system aims to control the induction motor in a manner similar to a dc motor, which generates torque as a linear function of commanded current.

A short primer on FOC (field-oriented control) for an induction motor can introduce to readers who are unfamiliar with the type of system in the figure some fundamental concepts. (For more information on this subject, see Reference 1). Figure 2 illustrates a simplified induction-motor-equivalent circuit. The stator current, i_qds, flows through the series input resistance and inductance. The parallel resistance and inductance branches represent the two orthogonal component phasors, i_ds and i_qs, which control rotor flux and torque.

The direct, or d-axis, current component flows through the parallel inductor, and the quadrature, or q-axis, current component flows through the parallel resistor. The d-axis component produces rotor flux; the q-axis component produces torque. The q and d subscripts in Figure 2 identify the quadrature- and direct-axes components; the s subscripts imply that these values are stator currents.

To field-orient the induction motor, you control the torque-producing stator current, i_qs, independently of the flux-producing stator current, i_ds. To understand the mathematical feasibility of this task, you must work with the torque equation for an induction motor:

EQUATION 1

where the superscript "e" implies that you assume all variables to be in a synchronously rotating reference frame. To do so, you normalize all of the electrical, magnetic, and mechanical waveforms associated with the motor with respect to a rotating reference frame (of frequency ω_e). This method allows you to work mathematically with nonrotating waveforms. Using this shift in perspective enables engineers to investigate motor behavior by driving the motor with a dc representation of sine waves rather than actual sine waves.

Equation 1 shows that the difference between two flux-current products produces the induction-motor torque. Applying a field-oriented control technique, you can force λ^e_qr to zero, and you simplify the torque equation from Equation 1 as follows:

EQUATION 2

Equation 2 shows that, if you hold flux λ^e_dr constant, torque is directly proportional to the q-axis current, i^e_qs. Therefore, the system can control the induction motor like a dc motor.

The challenge of implementing the FOC is in correctly producing the controlling sine wave. The designer must precisely match the frequency of the sine wave to the motor's rotating flux vector and set its phase such that the rotor flux is entirely in the d-axis. You can accomplish this task by directly or indirectly obtaining the slip angle, which is the difference between the rotating flux vector angle and the actual rotor angle. You then use this information along with the rotor frequency to generate the commanding sinusoid.

Engineers express torque production in an induction motor with rotor-voltage equations:

EQUATION 3

EQUATION 4

and rotor-flux-linkage terms:

EQUATION 5

EQUATION 6

The above equations, along with Equation 1, are sufficient to describe the behavior of the induction motor with three inputs: q-axis stator current, i^e_qs; d-axis stator current, i^e_ds (which engineers use to indirectly command flux, λ^e_dr); and slip frequency, ω_slip.

Listing 1 shows the behavioral VHDL-AMS description of the motor equations. You can divide VHDL-AMS models into "entities" and "architectures." Entities define the model's interaction with the outside world, via ports (pins), and they allow designers to pass external parameters into the model using the "generic" statement. Architectures define the behavior of the model. Designers describe the actual functions of the model in the architecture portion of the model.

To model the motor equations, you declare all motor parameters (R_r, L_r, and others) as generic constants (generics) in the model entity, because these values remain constant during simulation. Because these parameter values are generics, you can specify them directly from a schematic-capture program or testbench without modifying the model itself.

All of the ports in the model are analog. By declaring them of type "terminal," you can enforce energy-conservation laws at each port. Terminals involve "through" and "across" aspects. For electrical terminals, the through aspect represents current, and the across aspect represents voltage.

You declare analog valued objects in the architecture as type "quantity." You can associate quantities with terminals, or they can represent other analog objects. Simultaneous equations always include one or more quantity.

All objects you declare in the model associate with a particular "type," such as current, flux, or angular_velocity. These types help to minimize the risk of interfacing incompatible objects. They also allow engineers to view simulation waveforms with proper units—an important consideration for mixed-technology systems.

As shown between the "begin" and "end architecture" keywords (VHDL-AMS keywords appear in bold in the listing), you can implement the motor equations given in Equation 1 and equations 3 through 6 almost verbatim in the model. This one-to-one correspondence between model implementation and device equations is one of the benefits of HDLs.

The minus sign preceding the right-hand side of the torque equation is present to force "positive" torque to flow out of, rather than into, port mot_out. Without the negative sign, positive torque will flow from mot_out to mechanical ground and pull torque from the load. Also, the torque equation includes torque loss due to shaft inertia. (For additional information regarding the VHDL-AMS modeling language, see Reference 2.)

Figure 3 illustrates a simplified version of the system in Figure 1. This configuration does not require the CRPWM and waveform-transformation blocks, because the motor model is synchronous and ideally current-regulated.

In addition to the velocity-profile command, ω_CMD, you input a constant value of i^e_ds, because you want the flux factor to remain constant in Equation 2. With this configuration, you can concentrate exclusively on the effects of the slip-calculator accuracy.

The test circuit of Figure 3 allows you to determine whether the overall design and implementation approach is sound. The system drives the velocity profile command (ω_CMD) into a velocity-control loop. It subtracts the actual rotor velocity from this command, resulting in an error signal that represents i^e_qs. The value of i^e_qs controls the motor torque. The motor frequency command, ω_e, is the sum of the rotor frequency and the calculated slip frequency.

One of the key error dependencies of this FOC-implementation strategy lies in the slip-frequency calculation. Specifically, the accurate knowledge of the rotor's time constant is necessary to determine the system field orientation. This situation poses a practical problem: This time constant changes with temperature, which makes it difficult to determine optimum coefficients for the slip calculator. The following equation shows the slip calculator implemented in Figure 3:

EQUATION 7

The slip value depends on R_r and L_r. To verify that the overall system is behaving as expected, you can run a simulation with an ideal calculated value for slip frequency. You use the slip-gain (k) values of 1, then 2, then 0.5 to see how the changes affect performance. If the system is operating properly, you can expect to see the best performance with k=1 and degraded performance as you increase or decrease k.

You can measure system performance by observing λ^e_qr as a function of slip gain. You can observe this factor directly in the motor, in which its value goes to zero if the motor is field-oriented. The ability to make such observations is a benefit of using a simulation tool as a design and analysis aid in system development. This quantity is easy to observe in the motor model but difficult to measure in a real motor. The ability to directly observe the effects of the FOC approach and implementation is a primary reason to use a motor modeled using d-q-axis components.

Figure 4 shows the resulting simulation waveforms. The upper waveform shows the commanded velocity profile. This profile aims to exercise the motor as it might be during typical operation. In this case, the maximum rotor velocity is 377 rad/sec (60 Hz). The lower three superimposed waveforms show λ^e_qr at the various slip-gain values. All three waveforms show nonzero values for λ^e_qr at start-up. This situation is not surprising, as the testbench is changing the commanded flux value (via i^e_ds) from 0 to 4A. Once value settles, however, you see near-perfect field-orientation for k=1, where λ^e_qr settles to zero, as expected (indicated by the solid waveform). On the other hand, with slip-gain values k=2 or k=0.5 (indicated by the dashed waveforms), you see much λ^e_qr activity, which results in nonlinear motor torque production.

As a final test, you simulate the system to see how well it can follow a typical velocity command profile with a slip-gain value of 1. Figure 5 shows the results of system operation by comparing the commanded velocity profile (ω_CMD in Figure 3) with the actual rotor behavior, measured as ω_r.

Part two of this article, which resides in the Web-exclusives area of our Web site, shows how you can digitally reimplement the DSP controller and use VHDL-AMS to test the software algorithms in the overall system. 

All simulations in this article used the SystemVision analysis platform. If you would like to simulate your own VHDL-AMS designs, you can download a free educational copy of SystemVision, as well as VHDL-AMS and application-based tutorials, at www.mentor.com/system/.