Closed-Loop Control of Virtual FPGA-Coded Permanent Magnet
Synchronous Motor Drives using a Rapidly Prototyped Controller
Christian Dufour Vincent Lapointe
Opal-RT Technologies, 1751 Richardson, suite 2525, Montréal, Québec, Canada
www.opal-rt.com
{christian.dufour, simon.abourida, jean.belanger, vincent.lapointe}@opal-rt.com
Abstract- Presented in this paper are the results of closed-loop
control experiments using a virtual permanent magnet
synchronous motor (PMSM) drive implemented on a field-
programmable gate array (FPGA) card connected to an external
controller. The FPGA-based PMSM motor drive is implemented
on an eDRIVEsim simulator, based on the RT-LAB platform. The
eDRIVEsim simulator implements 2 types of motor drive models,
Park (d-q) and Finite Element Analysis (FEA), on an FPGA card
of the simulator.
The FPGA-based motor model is designed with Xilinx System
Generator (XSG) blockset with no HDL hand coding. Both motor
models compute motor currents using a phase-domain algorithm
solver that can take into account the instantaneous variation of
inductance and non-sinusoidal induced voltage. The FEA-type
model uses inductance and Back-EMF profiles computed with
JMAG-RT. The d-q model uses sinusoidal induced Back-EMF
voltage and phase inductance values computed from Ld and Lq
using the well-known Park transformation. A 3-phase IGBT
inverter implemented in the FPGA chip drives the PMSM
machine.
The PWM controller is designed using Rapid Control
Prototyping (RCP) methodology based on Simulink. It is
implemented on an separate RT-LAB system using standard
Opal-RT FPGA-based I/O cards for Analog Input capture and
PWM generation.
The paper presents results from the closed-loop control of the
PMSM drive in both current control and speed control modes and
discusses the advantages of using such a virtual test bench for
motor drives.
I. INTRODUCTION
A critical aspect in the deployment of motor drives lies in
the early detection of defects in the design process. The later in
the process that a problem is found, the greater the cost to fix
it. Rapid prototyping of motor controllers is one methodology
that enables the control engineer to quickly deploy control
algorithms and find eventual problems. This is typically
performed using a small real-time simulator called a Rapid
Control Prototyping system (RCP) connected in closed-loop
with a physical prototype of the drive to be controlled. Modern
RCPs take advantage of a graphical programming language
(such as Simulink) with automatic code generation support.
Later in the design process, when this code has been converted
and fitted into a production controller (using mass-production
low-cost devices), the same engineer can verify it against the
same physical motor drive, often a prototype or a pre-
production unit.
978-1-4244-1742-1/08/$25.00 
c 2008 IEEE
Jean Bélanger Simon Abourida
This methodology implies that the real motor drive is
available at the RCP stage of the design process. Furthermore,
this set-up requires a 2nd drive (such as a DC motor drive) to be
connected to the motor drive under test to emulate the
mechanical load. This is a complex setup, however it has been
proven to be very effective in detecting problems earlier in the
design process.
In cases where a physical drive is not available, or where
only costly prototypes are available, an HIL-simulated motor
drive can be used during the RCP development stage. In such
cases, the dynamometer, real IGBT converter and motor are
replaced by a real-time virtual motor drive model. This
approach has a number of advantages. For example, the
simulated motor drive can be tested with borderline conditions
that would otherwise damage a real motor. In addition, setup of
the controlled-speed test bench is simplified since the virtual
shaft speed is set by a single model signal, as opposed to a
using real bench, where a 2nd drive would need to be used to
control the shaft speed.
Other advantages of using a virtual motor drive system
include the ability to easily study the impact of motor drive
parameter variations on the controller itself.
Of course, the fidelity of the motor drive model is an
important aspect of this process. Classical models, like the
PMSM single-frame d-q model [1], are often adequate but lack
some aspects of real motor drives, such as saturation and
inductance variations caused by stator slots. FEA-based models
handle this limitation well [2][6]. The simulator latency also
adds a delay in the control loop, which may change its
response.
Finally, most motor drives include high-bandwidth on-board
protection that cannot be simulated on conventional RCP
systems. For example, a real motor drive may include DC-link
current motoring for short-circuit detection. If this condition is
detected, IGBT pulses are disabled. Despite a sampling time
below 10 microseconds, a high-performance classical CPU-
based HIL simulation [4] is still too slow to simulate these
effects. FPGA-based HIL simulation offers a solution to this
challenge.
This paper presents examples of closed-loop control tests
using an FPGA-based HIL motor drive controlled by an RCP
system. The controller (RCP) and motor drive (HIL) are
1077
 .
connected through I/O only, in the same manner as a real
controller and a real drive. The motor drive model will be
either a classical d-q model or a complete FEA-type model.
II. ADVANTAGES AND CHALLENGES
OF AN FPGA-BASED MOTOR DRIVE SIMULATOR
Hardware-In-the-Loop simulation of motor drives is a
proven test method that is used extensively in the industry and
is typically conducted using CPU-based real-time
simulators[3][7][8]. However, the use of an FPGA processor as
the computational engine for a motor drive model still presents
several advantages over classical CPU-based implementation.
• Very low input-output latency: In some applications, the
delay between an IGBT gate action and the reversal of
the current slope can cause the tested controller to
behave incorrectly. This is notably the case when the
motor current is sampled synchronously with the IGBT
gating. The presented models have a computation time
of 300 nanoseconds in addition to an Analog Output rate
of 1 microsecond resulting in a total latency of 1.3
microseconds. Faster D/A converters are also available.
• Capacity to include on-board drive protections: Many
motor drive boards include fast protection circuits which
are not driven by the controller, due to their fast nature.
For example, some IGBT driver boards monitor the DC-
link current or stator neutral point voltage, shutting
down IGBT pulses if abnormal conditions are detected.
Other boards insert minimal dead-time independently of
the controller. A complete test scenario for a controller
should include its response to these autonomous drive
board protection circuits. The presented models have
been used to implement such features.
• Block diagram based coding of the FPGA: The
proposed model is made with Xilinx System Generator
(XSG) and therefore requires no HDL (Hardware
Description Language) programming skills, since the
FPGA code is automatically generated from a Simulink
block diagram. This enables the engineer to quickly
modify the motor drive model at will, without any
dependency on an FPGA specialist.
• Smart bandwidth-related task repartition: The
eDRIVEsim simulator enables users to implement
multi-rate and multi-task complex models using FPGA
cards and Intel/AMD compatible computers. Resource
allocation is made by the user depending on the
computation power and bandwidth required by
individual subsystems. Separate FPGA and CPU
processing allows subsystems to be optimally
distributed between respectively fast and slower
processors, and/or to naturally accommodate the various
bandwidth requirements of a complex system (e.g., a
mechanical-electric coupled model). RT-LAB allows
this task repartition from within its structure(Fig. 1)
1078 2008 13th International Power Electronics and Motion Control Conference (EPE-PEMC 2008)
FPGA-coding of the motor drive simulator has posed many
challenges in comparison to CPU-based implementation of the
same models [4]. The two main causes of these challenges are
1) fixed-point calculations are used for the model and 2) FPGA
firmware is not as flexible as regular software. This results in
the following model design considerations:
• Per-Unit scaling: The usage of fixed-point calculation is
enforced by the usage of the XSG blockset. This
requires a careful design of the model. In order for the
model to be adaptable to various motor drive parameters
and ratings, all FPGA calculations are made on a Per-
Unit basis.
• Parameter modifications: The capability for conducting
on-line parameter modifications is problematic because
of the firmware nature of FPGA processors. In contrast
to CPU-based real-time models that allow the
modification of all model variables, FPGA-based
models have no such built-in features. The presented
FPGA-based motor drives are designed so that
important motor drive parameter modifications do not
require the re-generation of an FPGA bitstream.
Finally, it is worth mentioning that an FPGA implementation
does not automatically produce more accurate results by the
virtue of the use of a small time step (10 nanoseconds). This is
because of the fixed-point calculation used to compute the
machine drive equations. Of course, the user can tailor the
fixed-point format to meet high precision requirements by
using larger number formats and FPGA resources. However,
because these resources are limited, there will be some tradeoff
to be made between precision and FPGA resource usage.
In the case of HIL applications, there is always an interface
with real-world signals through Analog I/O channels. Since
these channels have limited resolution (typically 12 to 16 bits,
neglecting electrical noise), calculating at a precision higher
than that of the communicated signals (i.e. the Analog I/O
quantities) makes no sense. As a result, the trade-off problem is
greatly simplified.
Back-EMF
(FPGA)
DIO
Xilinx System Generator
Simulink Subsystems Simulink Model
Simulink
pre-analysis
Inductance
Rate= 10 ns
JMAG-RT
Subsystems AIO
(CPU)
Rate=10-100μs
RTW RT-LAB Xilinx/ ISE Code Generation
Host PC
SignalWire link
DIO
Distributed
Ethernet
link Real-Time Model
AIO
Single/dual multi-core CPU PC FPGA card with embedded IO
Fig. 1 Workflow structure of the RT-LAB real-time simulator from
the model specification to the multi-task real-time execution
 .

reference model without the use of an externally connected

III. RT-LAB EDRIVESIM SIMULATOR MODELS controller.
The various eDRIVEsim models used to make the HIL
simulation of the PMSM motor drive are described here. L(θ)=T(θ)*Ldq0*T-1(θ)
IGBT inverter
A. General PMSM machine equations Inductance
θrotor
PMSM
The general PMSM equation in the phase domain is: N
dψ abc FPGA
[ L]−1 ³ (Vabc − − RI abc )dt = I abc (1) S
dt (Op5130)
where vbackEMF θrotor
[L] is the inductance matrix, iabc BackEMF=f(θ,ω)
6 (sinusoidal)
Iabc is the stator current inside the windings,
Digital Input (10 ns) Analog Output Digital Out
ψ is the magnet flux linked into the stator windings, I/Os (IGBT gates) (Iabc, resolver) (quad encoder)
R is the stator resistance and
Vabc is the voltage across the stator windings.
Controller under test
Both d-q and JMAG-type models’ currents are solved using
Fig. 2 D-Q-based PMSM drive implemented on the FPGA
equation (1). The only difference is that [L] and ψ are
sinusoidal in the d-q model, while [L] and ψ are FEA-
D. Finite-Element-Analysis-Based PMSM model [2]
computed in the JMAG case. Also, most operations are made
using 18 bit number with the notable exception of the flux In the FEA-based PMSM model, the electric equations of the
integrators, which have 48 bits because of the 20 nanosecond PMSM and its IGBT inverter are still computed on the FPGA
integration step used. computational engine using the same phase-domain solver as
the d-q model. Notably, this includes the 1-D nominal speed
B. Inverter model Back-EMF table, derived from JMAG-RT, developed by the
The inverter model includes controlled switches with Japanese Research Institute. The main computational
forward voltage drop, conduction losses and anti-parallel difference with the previously described d-q model is that the
diodes. These diodes turn on only during dead time with a 2-D inductance inverse matrixes L-1(θ,Iabc) as well as the
logic that depends on the load current (ex: if the current flows electrical torque are now computed on the CPU and
into the load, then the lower diode turns on). Since the signal transmitted on the FPGA where interpolation methods are used
resolution of the IGBT gate is 10 nanoseconds on the FPGA to up-sample the inductance at 10 nanosecond rate. This
itself, no interpolation mechanism is used like in the CPU scheme is depicted in Fig. 4
implementation of HIL motor drive[4]. The model does not
account for switching losses[5].
The proposed inverter model can also work in fully rectifying
mode with no IGBT pulses. Depending on the motor speed and
the DC-link voltage, the drive can work in the mode where the
motor Back-EMF voltage makes the inverter act as a diode
rectifier. This is an improvement on the inverter model
proposed in [1].

C. D-Q-Based PMSM model [1]

Fig. 2 describes the two-axis (d-q) PMSM and IGBT inverter
models that were designed in XSG and executed with RT-
LAB. With this model, all calculations are made in the FPGA
itself: the model uses FPGA-stored inverse inductance and
nominal-speed Back-EMF tables. During the calculations, the
real Back-EMF is found by multiplication of the nominal value
by the actual speed. The gate signals of the IGBT inverter can Fig. 3 Lq inductance profile computed by the JMAG model
(with sqrt(3/2) factor)
come from external I/O, from a controller model running on
one CPU of the simulator, or from an internal PWM source. The Lq profile of the motor used in this paper is shown in
This internal PWM generation feature is useful for the model Fig. 3. Storing the inverse of the inductance matrix table on the
self-verification and to validate the model against some FPGA itself is difficult and is under investigation. It is also
normal to compute the electrical torque on the CPU because

2008 13th International Power Electronics and Motion Control Conference (EPE-PEMC 2008) 1079
 .

the device speed is usually computed from many different
torque sources like, for example, mechanical torque produced
by the engine in hybrid propulsion cars[3][8].
As for the d-q model, the storage of the nominal speed Back-
EMF profile of the JMAG model on the FPGA enables the
computation of real Back-EMF voltages by multiplication of
the fixed table stored value by the actual speed.
Inductance and torque
CPU data pre-computed from
(Intel/AMD)
JMAG software
executed in real-time on one CPU of the simulator. This
dynamic model can then be interfaced with the motor drive on
the FPGA chip.
F. DC Source and AC fed System
In the presented model, the DC-link voltage comes from one
CPU of the RT-LAB simulator. If desired, a more complex
feeding circuit can be implemented, for example a 6-pulse
diode rectifier or a grid equivalent circuit, still computed on the
CPU and interfaced with the FPGA model. This can be done
using standard Simulink, with or without specialized blocksets,
PMSM
such as SimPowerSystems and ARTEMIS from Opal-RT
Technologies.

iabc L-1 (θ,iabc) θrotor IV. MOTOR CONTROLLER DESCRIPTION

IGBT inverter Inductance The motor controller is a classical vector controller using the
PMSM Park d-q transform to control motor currents and torque. An
N outer speed control loop completes the controller. This enables
the torque control of the motor by acting on the Iq current
FPGA S
(Op5130)
component. For this experiment, no flux weakening is applied
vbackEMF θrotor and the Id current command is therefore set to zero. PWM
iabc BackEMF=f(θ,ω)
generation can be made in either sinus or space-vector
6 (JMAG pre-computed) modulation with user variable carrier frequency and dead-time.
Digital Input (10 ns) Analog Output Digital Out In our tests, the PWM frequency is 5 kHz and dead-time is 5
I/Os (Iabc, resolver)
(IGBT gates) (quad encoder) microseconds. All models are made with Simulink. The sample
time of the controller is 50 microseconds.
Controller under test The controller is interfaced to the virtual motor drive
through a proper set of I/Os. In this case, the controller is
Fig. 4 Real-time simulation of FEA-based PMSM drive on an FPGA
equipped with the standard RT-LAB I/O configuration: 16
Analog Inputs, 16 Analog Outputs, 16 Digital Inputs and 16
E. Mechanical Model
Digital Outputs. The I/O card is based on FPGA and has a 10
The mechanical model is computed on the main processors nanosecond resolution for the PWM generation. The controller
of the real-time simulator at 65 microseconds and can be linked model and interface to the HIL motor drive is shown in more
to complex models implemented with Simulink or compatible detail in Fig. 5.
tools. For example, a complete car dynamic model can be
implemented using the CARSIM software package and
I/O eDRIVEsim motor drive
RT-LAB Rapidly Prototyped Controller
interface (FPGA-type)
DC link
Digital Ouputs

Digital Inputs

i*d=0 v*u,v,w
v'dr
ω* +- PI PWM
6
IGBT
v'qr T-1( θr)
i*q gen inverter
+ +- PI
- PI

iq 3 iabc
Analog Outputs

id T(θr)
Analog Inputs

speed PMSM
controller current controller θr
2
resolver angle decoder N

S
ωr 3
Outputs
Digital
Digital
Inputs

Frequency calculation (RT-Events) resolver

quad-encoder

Fig. 5 Motor controller structure and interconnection with the eDRIVEsim PMSM drive

1080 2008 13th International Power Electronics and Motion Control Conference (EPE-PEMC 2008)
 .
V. EXPERIMENTAL RESULTS B. Machine Drive Parameters
In this section, we describe the experiments that where The machine under test is a 4 poles (2 pairs) interior magnet
conducted using the FPGA-based PMSM drive (d-q and machine (IPM) with the parameters described in Table 1. The
JMAG) in closed-loop with a motor controller running on a 2nd 800V DC-link voltage is rather high and allows the motor to
independent simulator as a Rapidly Prototyped Controller. operate at 12000 RPM without flux weakening.
Using the set-up and models previously described, current and TABLE 1. MOTOR PARAMETERS
speed control tests were performed. Quantity Value
A. Real-Time Simulator Hardware set-up Stator resistance 3.3 Ω
As previously mentioned, the controller and the motor drive Park equivalent direct inductance 0.0109 H
are implemented on two independent RT-LAB simulators, as Park equivalent quadrature inductance 0.0310 H
depicted in Fig. 6. The controller is running on an MX Station-
type RT-LAB simulator (middle box) with I/O connections on Magnet flux 0.1584 Wb
the back. The MX Station is a 2.3 GHz Core2 Duo-based PC. Number of pair of poles 2
The MX Station I/Os are based on 2 different Opal-RT FPGA Total number of slots 24
cards: the OP5110 (PCI) implements the digital inputs and
Inertia 1.854*10-4 kg.m2
outputs while the OP5130 implements the analog inputs. It is
possible to use OP5110 for analog input, however, the OP5130 Friction 5.396*10-5 N.m.s
is user reconfigurable enabling it to be programmed with a Applied mechanical torque 1 N.m.
closed-loop Resolver-To-Digital model for future studies. The
DC-link voltage 800 V
Digital I/Os are isolated in both systems and the opto-coupler
circuits are powered by the 12V power supply of the RCP. FPGA sample time 10 ns

The motor drive is running on the eDRIVEsim RT-LAB CPU sample time 65 μs
simulator (bottom box). The eDRIVEsim simulator is a 2.3 Quadrature encoder 1024 pulses/channel
GHz dual quad-core (Intel Core2) PC with an onboard FPGA
card (Opal-RT OP5130). The FPGA card holds the machine C. Controller Parameters
and inverters models for both d-q and JMAG-type models. One The controller parameters used in these tests are enumerated
core of the PC computes the machine electrical torque with the in Table 2. The reference Id value is set to 0 in all tests as no
mechanical equations as well as the inductance values in the flux weakening is made. The Vdq limits are really the entry to
case of the JMAG model. the dq-abc transform that produce the modulation indexes for
A console PC (not shown) completes the simulator set-up all phases and are therefore limited to ±1. All PI controllers
and enables the control and monitoring of the real-time have anti-windup mechanisms.
systems themselves. All of these are connected together by an TABLE 2. CONTROLLER PARAMETERS
Ethernet switch (top box of Fig. 6) Quantity Value
Current controller Ki Kp/Ki gains 22.7 0.0017
Vdq limits (from current controller) ±1 pu
Speed controller Ki Kp/Ki gains 3.5 0.026
(except section E)
Iq limits (from speed controller) ±9.5 A
PWM frequency 5 kHz
Dead time 5 μs
Sample time 50 μs

The rotor angle position, θ, sent by the motor drive analog

outputs as sin(θ) and cos(θ), is read by analog inputs of the
RCP. The sin(θ) and cos(θ) are then properly decoded on the
controller (avoiding basic arctan{sin(θ)/cos(θ)}, because of the
analog noise floor). This type of position encoding is similar to
using a resolver with DC excitation. For its part, the quadrature
Fig. 6 Virtual motor drive closed-loop control hardware set-up
encoder is used to obtain the rotor speed in the controller.

2008 13th International Power Electronics and Motion Control Conference (EPE-PEMC 2008) 1081
 .
D. Current control mode tests
One great advantage of a virtual motor drive test bench over
a real one is ease of the hardware set-up. This becomes even
clearer when one tries to test motor current control loops. In
this case, with a real bench, one really needs two motor drives:
the PMSM drive itself and a second motor drive to control the
shaft speed. With a virtual bench, one simply has to set the
shaft speed state-variable to the desired speed!
the one following the current amplitude. Nevertheless, the
difference between the d-q and JMAG models is quite modest.
It seems that the dead-time is causing a greater impact than the
effects of non-ideal Back-EMF and inductances.
The two figures actually display two acquisition frames
acquired at the Windows console station of the RCP. This
means that there is a time discontinuity in the figures. In Fig. 7
for example, the two frames begins at 4.25 and 4.37 sec. Since
the command is applied asynchronously from the motor drive,
this enables verification of the drive response relative to the
motor rotor angle at the time of the command application. The
results of Fig. 7 and Fig. 8 show that the controller response
does not depend on the motor angle.

E. Speed control mode tests

Following the adjustment of current control parameters,
closed-loop speed control tests are performed. Fig. 9 and Fig.
10 compare the speed response of the motor drive for d-q and

Fig. 7 Current command step (d-q model, 1500 RPM)

Fig. 9 Speed step (d-q model, 1000->3000 RPM)

Fig. 8 Current command step (JMAG model, 1500 RPM)

Fig. 7 and Fig. 8 respectively show the d-q and JMAG

model response of the current control at 1500 RPM,
corresponding to a 50 Hz stator frequency and a commanded Iq
current step from –2 to 6 A. The two responses are strikingly
similar except for increased fluctuations on the Iq command
signal of the JMAG model, most likely caused by the slot-
induced current harmonic content of the JMAG model. This
harmonic content is itself caused by the inductance variations
(due to gap variations for example) of the JMAG model and Fig. 10 Speed step (JMAG model, 1000->3000 RPM)
cannot be modeled in a standard (single frame, non-saturating)
d-q model. In the figures, the Iq component is recognizable as

1082 2008 13th International Power Electronics and Motion Control Conference (EPE-PEMC 2008)
 .
JMAG models respectively, for a speed command step of 1000
to 3000 RPM. The responses are again very similar. Both
figures show two consecutive acquisition frames. It is
interesting to see that because of the asynchronous speed step
application, the phase current responses differ from one frame
to another mainly because of the initial conditions of the motor
at each application of the speed command steps.
Again, there is not a great difference between d-q and JMAG
model results. Tests on a drive with smaller inertia may reveal
a greater sensibility of the drive to cogging torque.
F. HIL application: Speed Controller tuning using batch test
The controllers used in this experiment are rather simple but
nevertheless have non-linearities like saturations. Because
these effects are hard to account for by regular control theory, a
thorough batch test procedure is often necessary to validate a
controller against the various control scenarios and
contingencies of the motor drive.
PI controller tuning is one good example of batch tests using
a real-time simulator. In this case, a set of speed commands is
applied to the motor drive for various PI control gain values.
Results are analyzed for the best set of PI parameters. Fig. 11
shows that some instability results from a large speed
command step (8000 to 12000 RPM). It was found that
dividing the Kp gain of the speed controller by 3 stabilizes the
response of the motor. One can notice that the current
commands are identical in the first 20 milliseconds but diverge
after. This divergence is most likely caused by a saturation or
anti wind-up action in the speed control: referring to Table 2,
the controller Iq limit is set to ±9.5A.
Fig. 11 Speed control PI tuning results (JMAG model)
2008 13th International Power Electronics and Motion Control Conference (EPE-PEMC 2008)
CONCLUSION
This paper has presented experimental results of a motor
controller connected to a virtual motor drive. The controller
was designed in Simulink and implemented on a RT-LAB RCP
system. The motor drive was also designed in Simulink, and
implemented on an FPGA processor using Xilinx System
Generator blockset. Both PMSM standard d-q and FEA-
computed models were used for the tests.
The control was successfully tested in closed-loop for both
current and speed control modes using the eDRIVEsim real-
time plant simulator. The closed-loop set-up has been simply
and successfully used to tune a controller for stability.
The results show certain corroboration between JMAG and
d-q-type model simulation cases, as their responses are similar.
This does not mean that increased precision of FEA models is
not needed, but rather that the test cases presented were not
chosen to highlight the benefit of high-accuracy finite-element-
based models. Tests with a partially saturated machine and/or
with smaller inertia should demonstrate the usefulness of FEA
models.
By using a virtual motor drive, as the one presented here,
early in the design process, it is expected that algorithm errors
can be pinpointed earlier by the control engineer and thus
produce a more efficient design methodology. Leading power
electronic equipment and hybrid vehicle manufacturers now
successfully use such design methodology.
REFERENCES
[1] C. Dufour, S. Abourida, J. Bélanger,V. Lapointe, “Real-Time Simulation
of Permanent Magnet Motor Drive on FPGA Chip for High-Bandwidth
Controller Tests and Validation”, 32nd Annual Conference of the IEEE
Industrial Electronics Society(IECON-06), Paris, France, November 7-
10, 2006.
[2] C. Dufour, J. Bélanger, S. Abourida, V. Lapointe, “FPGA-Based Real-
Time Simulation of Finite-Element Analysis Permanent Magnet
Synchronous Machine Drives”, Proceedings of the 2007 Power
Electronics Specialists Conference (PESC-07), Orlando, Florida, June
17-21, 2007
[3] C. Dufour, T. Ishikawa, S. Abourida, J. Bélanger, “Modern Hardware-In-
the-Loop Simulation Technology for Fuel Cell Hybrid Electric
Vehicles”, Proceeding of the 2007 IEEE Vehicle Power and Propulsion
Conference (VPPC-07), Arlington, Texas, Sept. 9-12, 2007
[4] M. Harakawa, H. Yamasaki, T. Nagano, S. Abourida, C. Dufour, J.
Bélanger, “Real-Time Simulation of a Complete PMSM Drive at 10 us
Time Step”, Proceedings of the 2005 International Power Electronics
Conference (IPEC 2005) – April 4-8, 2005, Niigata, Japan.
[5] G.G. Parma, V. Dinavahi, “Real-Time Digital Hardware Simulation of
Power Electronics and Drives”,Transactions on Power Delivery, Vol 22,
No. 2, April 2007
[6] O. A. Mohammed, Fellow IEEE, S. Liu, Member IEEE, and Z. Liu,”A
Phase Variable PM Machine Model for Integrated Motor Drive
Systems”, 35th Annual IEEE Power Electronics Specialists Conference,
Aachen, Germany, 2004, pp. 4825-4831
[7] L.-F. Pak,, V. Dinavahi, G. Chang, M. Steurer, P.F. Ribeiro, “Real-Time
Digital Time-Varying Harmonic Modeling and Simulation Techniques”,
IEEE Trans. On Power Delivery Vol.22. No. 2, April 2007.
[8] D. Winkler, C. Gühmann, “Hardware-in-the-Loop simulation of a hybrid
electric vehicle using Modelica/Dymola” Proceedings of the 22nd
International Battery, Hybrid and Fuel Cell Electric Vehicle Symposium
(EVS-22), Yokohama, Japan, Oct 22-26 2006, pp 1054-1063.
1083