TECHNICAL ARTICLE
|
Join |
Tweet Connect
Model-Based Design Streamlines Embedded
Motor Control System Development
by Dara O’Sullivan, Jens Sorensen, Aengus Murray, Analog Devices, Inc.
This article describes the detailed steps in building a model-based design
(MBD) platform around an ARM®-based embedded motor control processor.
It follows with examples of basic permanent magnet synchronous motor
(PMSM) control algorithms initially deployed and the ease of extending the
functionality to include multiaxis position control for automation systems.
Rather than using complex structures and extensive software codes, designers can use MBD to define models with advanced functional characteristics
using continuous time and discrete time building blocks. These models, used
with simulation tools, can lead to rapid prototyping, software testing, and
hardware-in-the-loop (HIL) simulation.
System and circuit modeling has long been an important aspect of motor
control system design. With the MBD approach, electrical, mechanical, and
system-level models are used to evaluate design concepts before building
and testing physical hardware. The latest simulation tools from MathWorks
can model complete embedded control systems, including the electrical
circuit and mechanical system domains. Meanwhile, embedded coding tools
generate C code from control system models to enable direct deployment of
control algorithms on embedded control platforms.
Simulation enables specification discrepancies and modeling errors to be
found immediately, rather than later in the design cycle. To optimize the
overall code generation process, automatic code generation can be added to
reduce any manual implementation steps and to help further reduce the overall time to market. All in all, the MBD approach allows a designer to expand
from more classical design schemes and move directly from model creation
to simulation, generation, HIL, and testing in a controlled fashion that allows
changes in system settings without a complete redesign of the system.
These tools enable a model-based design process where control algorithms
can be designed and fully tested on a simulation platform before the final
hardware test. The key to building a successful MBD platform is partitioning
the system model and embedded software code. Once the MBD platform
is tested using a known algorithm and system, new algorithms can be
developed and safely tested on the simulation platform at the extreme limits
of system operation.
The experimental setup used in this article is based on an ac fed closed
motor control system, as depicted in Figure 1. This system represents a fully
functional PMSM main input motor drive, with power factor correction, full
control communication signal isolation, and optical encoder feedback. At the
core of the system is the ARM Cortex®-M4 mixed-signal control processor
from Analog Devices, the ADSP-CM408. This is programmed with combined
tools from IAR and MathWorks to achieve complete implementation of the
MBD platform.
A Complete Design Flow
Modeling the AC Motor Drive System
MBD has been a discussion topic for decades, but has only in recent years
evolved into a complete design flow—from model creation to complete
implementation. MBD is a mathematical and visual method of addressing
problems associated with designing complex embedded control systems.
LIVE CIRCUIT
VDC
PFC
EMI
IGBT MODULE
PWM (6)
CDC
G
D
ADP3634
100V TO
250V
VAC
ADP7102
ADP121
MA
SIM TLAB ®
ULIN
WO GUI K
RK
BEN
CH
RS-232
3V3_ISO
ADP1864
ADM3202
ADP1715
ADCMP600
PWM(6)
ENPWM
5V
I2C
PWM
ENC
A
E
C
AD8662
TRIP
ADN4662
AD8515
AD2S1210
FEEDBACK
SELECTION
GPIO
SINC
SRAM
CPU
ADC
FLASH
J-LINK
JTAG
SPRT
QEP
B
Z
S
TRIP
1V8
RES
AD7401 ADuM5000
ADuM2250 ADuM1310 ADuM1310 ADuM1401
CM408
UART
3V3
IDC
AD7417
ENPFC
MOTOR
0.5HP
5V_ISOW
AD8515
AD8515
5V_ISO
POSITION FEEDBACK
OPTIONS
MUX
15V_ISO
INRUSH
CURRENT FEEDBACK
OPTIONS
SHUNT
HE
SENSORS SENSORS
IV , IW
TC
IAC
AD8515
VDC
ADP1047
The target drive system is a PMSM with encoder position feedback connected
to a 3-phase ac power inverter with isolated phase current feedback. The
drive control algorithm is implemented on a mixed-signal application-specific
SPI
(a)
Figure 1. Drive system platform. (a) Block diagram of ac fed closed motor control system, and (b) prototype of the system.
analog.com
(b)
signal processor (ASSP) that includes peripherals to capture motor feedback
signals and control the power inverter.
creates the C code to execute the control algorithm and data structures for
the algorithm input, output, and state variables. The algorithm itself is the
commonly used field oriented control (FOC) with an outer velocity loop and
inner d-axis and q-axis current loops, as depicted in Figure 2.
For modeling purposes, the system has three main components: the power
inverter and motor (plant), the control feedback circuits, and the digital controller. The plant model uses Simulink Simscape components to simulate the
power inverter electrical circuit and the motor electromechanical elements
in the continuous time domain. The feedback circuit models take care of
the gain and data type conversions between the controller and motor
drive models.
The inverter interface and feedback paths are split into sensor signal
conditioning and embedded interface blocks. The current sensor and signal
conditioning models are simple gain elements since their bandwidths extend
beyond the range of interest for control feedback. The position sensor model
is more complex since it provides a high resolution incremental position signal
and a low resolution absolute position signal.
Simulink embedded coder tools create embedded C code that accurately
reflects the algorithm execution on both the simulation platform and on the
embedded control processor. Successful execution of model-based design requires accurate system and circuit models and appropriate partitioning of the
system model and the embedded control software. The simulation solver used
is a fixed step discrete solver because of the mix of discrete and continuous
time functions in the system.
The models for the embedded signal interfaces include type conversion functions since the ADCs, sinc filter, counters, and timer peripherals have 16-bit or
32-bit fixed point output data registers. The gain of each embedded interface
is a function of the peripheral system clock rate, the sample rate, and the
interface peripheral register settings. The model parameters must be matched
to the embedded system configuration to ensure accurate simulation results.
The drive system hardware consists of a power board, control board, and
a PMSM with encoder feedback (as seen in Figure 1b). The power board
includes an input rectifier, a 3-phase inverter module, current and voltage
sensors, digital and analog signal isolation circuits, and encoder signal buffers. The control board includes the motor control ASSP with a 240 MHz ARM
Cortex-M4F core and dedicated motor control peripherals, including PWM
timers, quadrature encoder counters, sinc filters, and embedded analog-todigital converters (ADCs). The hardware includes motor current feedback
options of using isolating current sensors with the embedded ADC or current
shunts with an isolating ADC Σ-∆ converter and the embedded sinc filters.
Software Partitioning and Code Generation
The motor drive system performs multiple functions along with the motor
control algorithm. The embedded software splits into multiple functional modules for platform flexibility and ease of development. The key code functions
are system initialization, communications interface, application tasks, motor
control interface, and motor control algorithm. Figure 3 describes the high
level drive program flow, while Figure 4 describes the code structure.
The main program calls the initialization routines to configure the ASSP
hardware and then places the processor in a continuous wait loop. All other
functions are called by event driven interrupt service routines (ISRs). The
ADC interrupt has the highest priority and the ADC ISR calls the motor control
functions when new sensor data samples are ready. The ADC sampling is
synchronized to the PWM switching and provides the control loop execution timing. The ADC ISR executes every PWM cycle but only calls the motor
control routine (PMSMctrl) when the motor run flag is set. The selection of the
motor current feedback path is made before building the code.
The feedback signal acquisition and control algorithm execution is synchronized to the PWM switching frequency using the processor interrupt
mechanism. The system simulation uses the same time step since the time
constants of interest in the plant are much longer than the PWM switching
period. The power inverter uses an average value model since full switching
signal simulation does not provide useful control information.
The PMSM motor model, which comes from the MathWorks
SimPowerSystems library, is supported by a configuration menu and even
preset model parameters. The user may switch in a custom motor or inverter
model depending on the focus of the design development.
The PWM trip interrupt is asynchronous; it’s only called in response to a
hardware fault, and is the only function to lag the fault since the hardware
PWM trip function automatically shuts off the inverter PWM signals. The
communications port ISR has a lower priority, processes user commands,
and transmits data captured by a debug monitor function. The kernel timer
ISR manages the background application tasks such as motor start and stop
sequencing, debug monitor interface, and other housekeeping tasks.
The motor control (MC) algorithm model is a set of discrete time functions, which execute every time step on both the simulation and embedded
platforms. Typically, the MC algorithm functions are included in a single
subsystem block to simplify the code generation process. The code generator
VELOCITY LOOP
CURRENT LOOPS
FIELD ALIGNMENT
VOLTAGE CONTROL
ia
𝛚*
Iq*
PI
Vq*
PI
𝛚r
FORWARD PARK
V𝛂
1
TORQUE LOOP
+
0
I d*
Vd*
PI
−
cos(𝚹)
−sin(𝚹)
sin(𝚹)
cos(𝚹)
FORWARD
CLARKE
V𝛃
FLUX LOOP
0
− √3
2
− √3
2
− √3
2
+ √3
2
Va*
Vb*
Vc*
3 𝛟 INVERTER
COMMAND
PWM MODULATOR
Va
𝛚r
𝚹abs
d𝚹
𝚹inc
QEP
Ls
SHAFT
SENSOR
ib
Vb
ic
Vc
FIELD
MOTOR
Rs
Rs
Ls
Rs
Ls
(FINE)
A, B
(COARSE)
HU ,HV,HW
dt
sin(𝚹)
ENCODER
ALIGNMENT
cos(𝚹)
GP
IO
𝚹abs
PERIPHERAL
CONTROL
iq
id
REVERSE PARK
cos(𝚹)
sin(𝚹)
−sin(𝚹)
cos(𝚹)
i𝛂
i𝛃
ia
ib
CLARKE
1
0 0
1 −1
0
√3 √3
ib
ia=
−ib −ic
ic
Figure 2. FOC algorithm.
| Model-Based Design Streamlines Embedded Motor Control System Development
2
ADC0
ADC1
ic
CURRENT
AND POSITION
FEEDBACK
𝚹r
MC SETTINGS
PWM
ADC
TIMERS
PORTS
RUN
ADC
Simulink that includes data structures for feedback and output signals. All of
the other drive codes are hand coded.
INITIALIZE
CLOCKS
I/O PINS
PERIPHERALS
INTERRUPTS
ISR
WAIT
UPDATE i, 𝚹, 𝛚 INPUTS
PMSMctrl
OUTPUT AH, BH, CH
STOP
PWM TRIP
ISR
SET FAULT FLAG
COMM
ISR
RECEIVE USER INPUT
TRANSMIT MONITOR DATA
KERNEL
TIMER
APPLICATION TASKS:
START/STOP/SPEED
SIGNAL MONITOR
PFC INTERFACE
SYSTEM FAULT MONITOR
ISR
Figure 3. Description of ISRs.
AUTOGENERATED
C CODE
MOTOR
CONTROL
ALGORITHM
UART
COMMAND
The system model is partitioned into the logical blocks shown in Figure 5
with the associated signal flows. Each of these blocks is further subdivided
as indicated on the right, with an appropriate modeling approach for each
subblock, as listed in Table 1. The user commands block is not included in
this list. User commands are communicated to the core algorithm by means
of global parameter structures within the C code, and once these are defined
in the Simulink algorithm as global tunable parameters, they will be handled
correctly.
ELECTROMECHANICAL
SYSTEM
PWM
CPU
CORE
RAM
PLL
CAN
In order to get the maximum value from the MBD approach, it is important
to understand the modeling detail requirements of the different parts of the
motor control system and to match the critical physical system parameters as
closely as possible with the corresponding model parameters. This involves
partitioning of the modeled system into different areas of detail. As an overall
rule, it is sufficient to model the entire system in a PWM averaged manner.
For example, treating all signals as averaged over the high frequency PWM
switching period, and not including PWM ripple or switching components in
voltage or current signals.
GATE DRIVE
INVERTER
Implementation Details
DRIVER
CIRCUITS
iv, iw
ADC
ETH
SENSORS
AND
INTERFACE
PROCESSOR
PERIPHERALS
QEP
COMM/APP
CORE
ALGORITHM
SYSTEM INIT MC INTERFACE
USER COMMANDS
AC MOTOR
HANDWRITTEN C CODE
𝚹, 𝛚
The embedded code is organized by function rather than according to the
program flow. The system initialization code sets up the processor clocks,
power, and kernel timer in a standard fashion, almost independent of the application function. The communications and application task code is defined
by the user interface and system management requirements and has almost
no dependency on the motor control algorithm.
The motor control (MC) interface function manages the signal data flow
between the motor drive hardware and the control algorithm. The code is
specific to the drive circuit connections and the MC peripheral configurations
needed to provide the appropriate feedback signals for the control algorithm.
The motor control algorithm is the platform independent code generated by
4
2
ENCODER
GATE
DRIVERS
TRIP
MECH SYSTEM
Figure 4. Code partitioning.
MOTOR
INVERTER
1
PROCESSOR
ADC, PWM, QEP,
GPIO, TMR
AUTOCODE/
MODEL
3
I/V SENSORS
SIGNAL
CONDITIONING
USER COMMANDS
Figure 5. System model partitioning.
Table 1. Modeling Considerations
Block
Electromechanical System (1)*
Sensors and Interface (2)
Processor (3)
Driver Circuits (4)
Modeling/Code Generation
Inverter: averaged functional model, very simple
Motor: standard electromechanical DQ model
Mech system: standard stiffness-inertia-friction model, application specific
Function models
Peripherals: function models
Core algorithm: code generation from here
Function models
Critical Parameters
None
Stator inductance, back EMF/torque constant
Load inertia
Gains, offsets
Scale factors, quantization effects
Efficient implementation, fixed-/floating-point boundaries
None
*Numbers in parentheses refer to blocks in Figure 5.
analog.com | 3
Maximum code portability and ease of maintenance is achieved by making
the autocode generation nontarget specific, apart from the basic settings,
such as type sizes, byte ordering, and so forth. MathWorks provides processor
specific code generation modules that directly address processor peripherals
and drivers. While this capability can be attractive in some circumstances, the
downside is that the code becomes less portable and any changes in device
drivers or peripheral configuration (for instance, in a new processor variant)
will require changes to the code. Hence, in the design example presented here,
the code generation is confined to the control algorithm only, with all peripherals having functional models in the Simulink model and being hand coded in
the application project. This approach is emphasized in Figure 6, in which it
can be seen that the code generation from the MathWorks controller model is
linked to the other code and library modules in the main application project.
The Simulink model with partitioned model blocks is illustrated in Figure 7.
As indicated, code is generated from the motor control algorithm part of the
model. The important settings for the code generation are selected in the configuration parameters  hardware implementation window where an overall
device type can be selected, and in the configuration parameters  code
generation  interface window, where the standard math library is selected.
Another factor when it comes to code efficiency is the C language dialect
used. Two very common dialects supported by most code generation tools
and embedded workbenches are C89/C90 and C99. First and foremost, it is
important that the same dialect is used across all tools. For example, if the
embedded workbench is configured to build code according to C99, the automatic code generation tools must build codes according to the C99 standard
also. Failing to do so can result in a significant drop in code performance and
in the worst case, unintended functioning of the code.
SYSTEM MODEL
TEST
SIGNALS
MOTOR/
INVERTER
MODEL
CONTROLLER
MODEL
VERIFY
Another important factor is fixed point vs. floating-point type representation.
Fixed point is supported by both coding dialects, so for this case the choice of
dialect does not matter, as long as the same dialect is used across all tools.
However, if floating-point types are used, the choice of C dialect becomes
much more important.
PC
CODE
GENERATION
C89/C90 does not distinguish between single precision floating point and
double precision floating point. If the code is going to run on a processor
that supports double precision, this may be acceptable, but for a processor
that only supports single precision, such as an ARM Cortex-M4, the distinction makes a big difference. With this in mind, it is crucial to make sure the
autocode generation tool, as well as the embedded workbench, is set up to
use C99 dialect.
MOTOR/
INVERTER
SYSTEM
EMBEDDED CONTROLLER
TARGET
HW
MOTOR DRIVE SYSTEM
(a)
ARM LIBRARY
• M3/M4 SUPPORT
MOTOR CONTROL
• FOC FUNCTIONS
LEGACY CODE
• EXISTING CODE
Simulink provides toolboxes such as Simscape and SimMechanics that
can be used to easily model the electromechanical system once physical
parameters are known. Even if physical parameters are not fully characterized, predefined models of components such as motors can be loaded with
approximately matched specifications to enable initial design of the motor
control algorithm. For the algorithm itself, there are some useful blocks, such
as Park transformations and sine cosine CORDIC approximation blocks that
simplify the development of the motor control algorithm.
DEVICE DRIVERS
• FUNCTIONAL MODEL
C CODE
DEVICE DRIVERS
• SW ENABLEMENT
PACKAGE
SYSTEM RESOURCES
• ALLOCATION
AND SETUP
C CODE
C CODE
APPLICATION CODE
• STATE MACHINES
The autocode interface is defined by an initialization function call, and one
or more time step function calls, which must be called from within the main
application code at the appropriate time steps. In this example, there are two
time step functions—the main control algorithm, which is called at the PWM
rate of 10 kHz, and a speed measurement function, which is called at a 1 kHz
rate. The autogenerated code modules are integrated into the main project as
illustrated in Figure 8.
SCHEDULING
• IRQS/RTOS
EXECUTABLE
(b)
Figure 6. Model code interface.
ADSP-CM40x
B6
VDC
VDC_MEAS
DUTY
+
DCP
–
DCM
DC_LINK
DUTY_ABC
VABC
A
A
B
B
C
C
IABC
A
B
C
VA
VB
RPM
[RPM]
IABC
[IABC]
THETA
[THETA]
VC
DISCRETE,
s = 0.0001s
[ALL_ABC]
PMSM
POWER GUI
POWER INVERTER AND MOTOR (MODEL)
PMSMCTRL
[ABC_ADC]
[DUTY_ABC]
CNT_A
[CNT_A]
[CNT_A]
DUTY_ABC CNT_B
[CNT_B]
[CNT_B]
CNT_C
[CNT_C]
[CNT_C]
ePWM
[RPM]
[THETA_QEP]
[VDC_ADC]
[IABC_ADC]
K–
[VDC_ADC]
VDC_ADC
[PD]
MC ALGORITHM
(SIMULINK)
SLATERPMSM
[THETA_QEP]
MC C CODE
DEVICE DRIVERS
APPLICATION CODE
IABC_SNS IABC
[IABC]
QEP_cnt
QEP_CNT THETA_SNS
VDC_SNS
VDC
[VDC]
VOLTAGE SENSOR
THETA_SNS
THETA
QEP
[THETA]
HALL_ABC
[PD]
CC AND LINK
VDC_SNS
ADC
EMBEDDED
DECODER
[IABC]
IABC_SNS
CURRENT SENSOR
ADSP-CM40x
T
MC APPLICATION
FIRMWARE
IABC_ADC
DEVICE DRIVERS
Figure 7. Modeling and code generation implementation.
| Model-Based Design Streamlines Embedded Motor Control System Development
4
PD
HALL_ABC
PD
HALL
POSITION
SENSOR
SENSORS, INTERFACES,
AND DEVICE DRIVERS
[HALL_ABC]
1800
1440
INITIALIZATION CALL
SPEED (pm)
10kHz FUNCTION CALL
SPEED REFERENCE
MODEL
EXPERIMENTAL
1080
720
1kHz FUNCTION CALL
360
0
0
0.1
0.2
0.3
0.4
0.5
0.6
0.7
0.8
0.9
1
TIME (s)
(a)
1800
Figure 8. Code module organization and algorithm function calls.
As indicated, the code is organized in a modular fashion that makes integration of application specific functions, such as networking and protection,
quite straightforward. High priority tasks, such as the motor control algorithm,
are called from the ISRs of Figure 3. Application level tasks are called as
scheduled tasks from a basic scheduler kernel. The MC interface routines
are included in the motor control and measure code blocks, where the latter
includes all of the current feedback signal handling codes. The ADI monitor
code includes the debug monitor function used for system tests, which captures application and control algorithm signal data while the motor is running.
The data is transmitted over a serial link to a PC for display and analysis.
Q-AXIS CURRENT (A)
1440
1080
720
0
System Test and Debug
Having determined the critical parameters of Table 1 by measurement, calculation, and data sheets, the appropriate controller gains for velocity and current loops can be determined using the Simulink model. This can be achieved
utilizing either standard PID tuning approaches [2] or the tuning tools provided
by MathWorks, such as the PID tuner tool. This process is described in more
detail in Reference 3.
0
0.1
0.2
0.3
0.4
0.5
0.6
0.7
0.8
0.9
1
TIME (s)
(b)
Figure 9. Comparison of (a) speed response and (b) q axis current reference for modeled
and experimental operation.
0.3
The performance of the current loop for both modeled and experimental
operation is shown in Figure 9 and Figure 10. The experimental data is only
sampled every 5 ms in this plot, so there is some aliasing, but the overall
trend is clear enough.
Q-AXIS CURRENT (A)
0.24
The performance of the model-based autogenerated code can be determined
by examining the code execution timeline over a PWM period. This can be
done using I/O pins and a scope, or more easily, using the ITM event feature
in the IAR Embedded Workbench C-SPY Debugger. The sequence of events
within the PWM cycle is illustrated in the timeline of Figure 11.
A PWM synchronization pulse occurs at the start of every new PWM cycle,
and this is connected in hardware to the ADC timer, which controls the
sampling of each ADC channel. In this case, motor currents are sampled
immediately after the PWM sync pulse and direct memory accessed
(DMAed) to memory, after which the algorithm is executed and updated
values for PWM duty cycle are generated. As illustrated in Figure 11, the
execution of the model-based autogenerated code consumes less than 10%
of the PWM cycle, allowing plenty of overhead for additional background
tasks. Historical concerns about the efficiency of autogenerated codes are
no longer a significant factor.
IQ-REF: MODEL
IQ-REF: EXPERIMENTAL
IQ:MODEL
IQ:EXPERIMENTAL
360
IQ-REF: MODEL
IQ-REF: EXPERIMENTAL
0.18
0.12
0.06
0
0
0.1
0.2
0.3
0.4
0.5
0.6
0.7
0.8
0.9
1
TIME (s)
Figure 10. Current loop performance—modeled and experimental results.
HIGH OPT
0×00
0×0A
0×14
4.7𝛍s 8.2𝛍s
ALGORITHM
0×00
0×0
87.2𝛍s
AVAILABLE FOR BACKGROUND TASKS
ADC SAMPLING
PWM SYNC
PWM SYNC
Figure 11. Code execution timeline.
analog.com | 5
In terms of code footprint, the relative size of the algorithm autocode is shown
in Table 2, where it can be seen that the autogenerated code occupies just
over 10 kb of memory, which equates to almost 15% of the total footprint. The
available SRAM on the ADSP-CM408 of 384 kB clearly accommodates this
memory requirement with no difficulty, allowing the program to be run from
SRAM, at the fastest rate possible, with more than enough headroom available for more complex algorithms and additional monitoring or user interface
features.
Table 2. Sizes of Code Modules
Code (Bytes)
Data (Bytes)
Total
Motor control peripherals
(PWM, encoder)
1584
94
2.3%
Measurement peripherals
(ADC, sinc, serial monitoring)
2224
2691
6.7%
PFC controller configuration
and monitoring
3032
2149
7.1%
User interface peripherals
(UART, LCD)
1484
5055
9%
System (kernel, state machine,
startup)
1192
1364
3.5%
14.7%
Modules
Algorithm autocode
5656
5022
Drivers, libraries
21,596
19,737
56.7%
Total
36,768
36,112
72,880 (100%)
New Application Development
implemented correctly, these models can be reused across products. And
because the models are generic they can run on the processors available
today, as well as the ones that will be available tomorrow.
In addition to meeting potential requirements for product variants or control of
multiple axes, developers can sometimes provide different controller modes.
A typical example is an application that offers torque control, velocity control,
and position control modes. Development of a position control algorithm
can be layered on the fundamental building blocks of the current and speed
control algorithms.
In most applications, a position control loop is applied as an outer loop around
the inner velocity and current loops. A basic position controller requires only
a proportional gain term. An integral term is not generally required since any
steady state error in the position loop will result in a nonzero speed reference.
Provided that the inner current and velocity loops are well tuned, these can be
regarded as ideal unity-gain blocks, and the task of tuning the position loop
becomes a straightforward task.
In addition to the outer proportional control loop, it can be important to include
a position reference profiler in order that the load follows defined periods
and rates of acceleration and deceleration. This is important for minimizing
mechanical stress in many systems. In this application example, a constant
acceleration, constant speed, and constant deceleration profile is applied to
the position reference change. This is illustrated in Figure 12, in which the
position reference, profiled position reference, and corresponding ideal velocity profile are indicated. The extent to which the actual velocity follows this
profile is dependent on the dynamic response of the velocity controller.
The premise of the SW discussed in this article has been a system consisting
of two main components. The first is a model-based component that implements control algorithms. Though the model is developed with the embedded
target in mind, the code obtained from the autogeneration tool is essentially
generic. Second, there is a handwritten SW component that ties the generic
algorithm code to the embedded target, handles scheduling, and assigns
processor resources. In terms of reuse of models and scalability, this system
partitioning has several benefits.
In this article development of control for a single motor (single axis) has been
discussed. Now, imagine that the drive specification calls for control of two
motors (dual axis) by the same processor. It goes without saying this is a
radical change of the system but the strength of working with generic models
is becoming evident. The single-axis model already developed did not make
any assumptions regarding processor peripherals—it is a general control
algorithm for a PM motor. To create a model that is capable of controlling
single/dual axes is therefore only a matter of creating a second instance of
the single axis model.
Naturally, the handwritten code requires tailoring to support single/dual axis,
but assuming the processor has the right set of peripherals and the computational resources to control dual axes, the modifications to the handwritten
code are straightforward. Regardless of controlling single or dual axes, the
main tasks of the handwritten code are to assign values to the model’s input,
write the model’s output to processor peripherals, and schedule when the
model is to be executed. Therefore, going from single to dual axes is mostly
a matter of assigning/configuring peripherals and schedule execution of the
algorithm of the added axis. The process is seamless and enabled by the fact
the model is generic.
The benefits of using a model-based design may be limited if only a one
control system is developed. However, in most cases, product development means multiple product variants and for these cases reuse of models
becomes attractive—not only because of reduced development time but
also because of the increased quality that comes from using trusted models.
Over time, an algorithm developer will create a library of models and, if
POSITION REFERENCE
PROFILED POSITION REFERENCE
IDEAL VELOCITY PROFILE
Figure 12. Profiled position reference.
All of this functionality—position loop gain, position profiler, as well as
ancillary functions, such as home positioning and end-stop detection, is
implemented as additional blocks in the model-based part of the code. The
only additional handwritten code change required is configuration of I/O to
accommodate home position and end-stop signals.
Conclusion
Model-based design can be a powerful tool in accelerating embedded development for motor drive manufacturers. If set up and configured in a generic
manner, it can significantly ease the burden of handwritten code development
and maintenance. It can also accelerate time to market, as code development can proceed initially in the absence of hardware, if reasonably accurate
models of the key system components are available.
These features have been shown in the context of a PMSM drive operated
under FOC with extensions to multiple axis and position control. A partitioning
approach to the software modules and the model-based components has
| Model-Based Design Streamlines Embedded Motor Control System Development
6
been detailed that optimizes the value provided by the model-based solution.
The advantages of the model in terms of optimizing the velocity controller
parameters, and the compactness and efficiency of the code generation, have
also been illustrated from the experimental data.
References
http://www.analog.com/en/processors-DSP/cm4xx/products/index.html
Drury, Bill. The Control Techniques Drives and Controls Handbook. IET Power
and Energy Series, 2nd edition, 2009.
O’Sullivan, Dara, Jens Sorensen, Anders Frederiksen. “Model-Based Design
Tools in Closed Loop Motor Control.” PCIM Europe 2014; International
Exhibition and Conference for Power Electronics, Intelligent Motion,
Renewable Energy and Energy Management; Proceedings of, May 2014.
About the Author
Dara O’Sullivan is a system applications engineer for the motor and
power control group at Analog Devices. His area of expertise is power
conversion and control in ac motor control applications. O’Sullivan received his B.E, M.Eng.Sc., and Ph.D. from the University College Cork,
Ireland. He can be reached via email at dara.osullivan@analog.com.
Jens Sorensen is a system applications engineer at Analog Devices,
where he works with motor control solutions for industrial applications. His main interests are control algorithms, power electronics, and
control processors. While currently focusing on industrial applications,
Sorensen developed motor control and power electronics for appliance
and automotive applications earlier in his career. He can be reached via
email at jens.sorensen@gmail.com.
Aengus Murray is the motor and power control applications manager
for the automation, energy, and sensors unit at Analog Devices. He is
responsible for the complete Analog Devices signal chain offering for
industrial motor and power control. Murray holds a bachelor and doctorate degree in electrical engineering from University College Dublin
in Ireland. He has over 30 years of experience in the power electronics
industry and has also worked with International Rectifier, Kollmorgen
Industrial Drives, and Dublin City University. He can be reached via
email at aengus.murray@analog.com.
Online Support Community
Engage with the Analog Devices
technology experts in our online
support community. Ask your
tough design questions, browse
FAQs, or join a conversation.
ez.analog.com
analog.com | 7
Analog Devices, Inc.
Worldwide Headquarters
Analog Devices, Inc.
One Technology Way
P.O. Box 9106
Norwood, MA 02062-9106
U.S.A.
Tel: 781.329.4700
(800.262.5643,
U.S.A. only)
Fax: 781.461.3113
Analog Devices, Inc.
Europe Headquarters
Analog Devices, Inc.
Wilhelm-Wagenfeld-Str. 6
80807 Munich
Germany
Tel: 49.89.76903.0
Fax: 49.89.76903.157
Analog Devices, Inc.
Japan Headquarters
Analog Devices, KK
New Pier Takeshiba
South Tower Building
1-16-1 Kaigan, Minato-ku,
Tokyo, 105-6891
Japan
Tel: 813.5402.8200
Fax: 813.5402.1064
Analog Devices, Inc.
Asia Pacific Headquarters
Analog Devices
5F, Sandhill Plaza
2290 Zuchongzhi Road
Zhangjiang Hi-Tech Park
Pudong New District
Shanghai, China 201203
Tel: 86.21.2320.8000
Fax: 86.21.2320.8222
©2015 Analog Devices, Inc. All rights reserved.
Trademarks and registered trademarks are the
property of their respective owners.
TA13139-0-4/15
analog.com