2014-01-0305
Published 04/01/2014
Copyright © 2014 SAE International
doi:10.4271/2014-01-0305
saepcelec.saejournals.org
Application of Auto-Coding for Rapid and Efficient
Motor Control Development
James Walters, Cahya Harianto, Edward Kelly, and Tanto Sugiarto
Delphi Automotive
ABSTRACT
In hybrid and electric vehicles, the control of the electric motor is a critical component of vehicle functions such as motoring,
generating, engine-starting and braking. The efficient and accurate control of motor torque is performed by the motor
controller. It is a complex system incorporating sensor sampling, data processing, controls, diagnostics, and 3-phase Pulse
Width Modulation (PWM) generation which are executed in sub-100 uSec periods. Due to the fast execution rates, care must
be taken in the software coding phase to ensure the algorithms will not exceed the target processor's throughput capability.
Production motor control development often still follows the path of customer requirements, component requirements,
simulation, hand-code, and verification test due to the concern for processor throughput. In the case of vehicle system
controls, typically executed no faster than 5-10 mSec periods, auto-coding tools are used for algorithm development as well
as testing. The advantages of auto-coding to greatly speed the development process by linking the tools for simulation,
code generation and testing early in the development process as well as to more easily investigate performance issues late
in the process are well known. It is not uncommon, however, to lose coding efficiency with this approach. While the loss of
efficiency may be tolerable for slow periods, it is not acceptable at faster periods used in motor controls as it will preclude
the algorithms from executing or drive unnecessarily expensive solutions.
This paper will present an auto-coding process applied to motor controls, including full implementation on a production
permanent magnet motor drive. Best practices for implementing requirements into models that generate efficient code will be
highlighted. An overview of the issues associated with model-based documentation will also be covered. The use of test
vectors at the component, model and hardware-in-the-loop (HIL) level will be presented to show the benefits derived from
using a formalized process and the natural linkage to a SPICE® compliant process. A timing study performed during
dynamometer testing detailing the differences between the original hand-code and the model-based code will be presented.
CITATION: Walters, J., Harianto, C., Kelly, E., and Sugiarto, T., "Application of Auto-Coding for Rapid and Efficient Motor
Control Development," SAE Int. J. Passeng. Cars – Electron. Electr. Syst. 7(2):2014, doi:10.4271/2014-01-0305.
INTRODUCTION
A general product development cycle contains several basic
steps including: the formation of customer requirements,
analysis of requirements to form the high level system design,
development of software and hardware requirements, software
and hardware design and ultimately verification testing at both
the component and system level [1]. Automotive manufacturers
often require their suppliers to follow a software development
process such as the Automotive Software Process Improvement
and Capability Determination (SPICE®) process [2]. The
Automotive SPICE® process, shown in Figure 1, summarizes
these steps.
Figure 1. Automotive SPICE® Process
Walters et al / SAE Int. J. Passeng. Cars – Electron. Electr. Syst. / Volume 7, Issue 2 (August 2014)
In these steps, there are numerous simulations performed to
verify the system goals will be met by the design. From the
capturing of requirements to the creation of software, it is
desired to directly use the simulations that have been performed
so as not to repeat the effort and potentially introduce errors. In
addition, it is desired that the simulation model accurately
reflects the implementation as it will greatly aid in any
subsequent problem resolution.
The Automotive SPICE® Process recognizes that engineering
development will need to incorporate the contributions from a
variety of engineers including systems, function developers,
software, and test engineers. What is needed is a tool and
methodology that can directly support the translation of the
system and component designs, often simulated early in the
process, efficiently and accurately into an implementation that
can be verified and released quickly. Auto-coding is a tool that
facilitates development by translating simulations, performed in
the System Design step, into the final software implementation
[3]. It has also been used in the last decade to implement many
functions in the vehicle [4] - [6].
evaluated not only for accuracy to requirements, but also for
efficient code generation. The benefits of this approach are
substantial as the simulation tools can now be used to verify
compliance to system requirements and thus allow porting
concepts from simulation directly onto hardware. There are also
other inherent benefits as the already tested concepts are now
easily transferable between different projects and production
hardware can now be utilized as a development platform.
Motor Control Background
In a hybrid vehicle, the motor controller is responsible for the
efficient and accurate production of torque. This torque may be
used to perform a variety of tasks including motoring, generating,
speed regulation, and/or dc voltage regulation, depending upon
the application. An overview of an electric machine drive system
is shown in Figure 2. The input to the system is a command that
is typically obtained from a Hybrid Control Module (HCM) via
communication lines and the outputs are 3-phase voltages
applied to the machine. Typical components of the motor drive
system include: the battery, motor controller, sensors for current,
temperature and position, inverter and motor.
Although auto-coding offers considerable advantages for
development, many of the implemented designs have been for
relatively slow loop control tasks (5-10 mSec or greater period).
Ironically, complicated time-critical components which are
mostly likely to be simulated are not as commonly auto-coded,
thus losing a potential resource saving opportunity. This is due
to the concerns that the auto-coding process may have
additional overhead in algorithm execution causing throughput
issues in the application.
It should be noted that there are Rapid Controls Prototyping
(RCP) tools that allow for quick transitions from a model-based
/ simulation environment to concept testing [7]. RCP does
eliminate the need for the manual hand-coding step when
transitioning from the simulation model to the implementation,
which requires additional effort and is prone to errors; however,
this process involves extra hardware. The RCP approach,
which can be extremely useful for concept testing, is inherently
different though since the goal is concept development and
evaluation rather than efficient code generation in a production
environment.
This paper focuses on the development of an Automotive
SPICE® compliant process using auto-coding techniques for the
torque control of a permanent magnet synchronous machine
(PMSM). By appropriately defining a process and associated
design environment, it will be shown how to directly go from
simulation to implementation for a complicated system involving
many contributors and to naturally perform both system and
software tests in an automated fashion. The process to actually
implement a design in this fashion is non-trivial and necessitates
a requirements focused approach with the implementation being
Figure 2. PMSM Drive System
As shown in Figure 3, the main components in the inverter are
the 3-phase bridge which receives 6 gate signals from the
motor controller and the DC bulk capacitor. The three legs of
the inverter are connected to the electric machine. For many
applications in hybrid and electric vehicles, the PMSM has
emerged as the preferred motor technology, though induction
motors are commonly used as well [8, 9].
Figure 3. 3-Phase Bridge
Walters et al / SAE Int. J. Passeng. Cars – Electron. Electr. Syst. / Volume 7, Issue 2 (August 2014)
Figure 4. Torque Control Overview
From a vehicle driveline perspective, torque response is needed
within a 30-50 mSec range in order to satisfy performance
requirements for cranking, torque assist, generating, and
braking. In order to create torque that is impervious to voltage or
speed disturbances, it is necessary to control currents in the
machine at a much faster rate, however. Vector control
techniques are commonly employed to perform this task [10]. For
a variety of reasons including motor time constants, the
maximum fundamental frequency in the machine (1000-1400 Hz)
and limiting DC capacitor voltage ripple, it is necessary to run
current control loop rates of approximately 100 uSec. The
sampling of the inputs, current and position, calculation of current
commands, control of current, and the associated transformation
pairs for vector control as well as the center-based PWM
generation must all be performed at this rate of 100 uSec.
The regulation process can be described in Figure 4. Therein,
the commands to / from the controller are denoted with the
starred quantities (e.g., Te* / ωr* denote the commanded torque
/ speed).
In addition to the motor control functions, the protection of the
inverter has to be considered. The diagnostic protection needs
to respond quickly to critical fault conditions (e.g., shorted
devices, loss of current control, etc.) and will require
functionality in the 100 uSec loop. Finally, sufficient throughput
must be available to ensure that slower loops (1, 5 and 10
mSec) have adequate time to execute.
As can be observed, the torque control of an electric machine
is inherently a challenging process. Not only does the control
process require fast data sampling, the execution of the current
control to generate the torque on the machine requires fast and
precise timing. Although auto-coding the PMSM control
algorithm can provide great benefits (e.g., faster and more
efficient development process and quick transitions from
simulation to final product implementation), care must be taken
in this approach so that the resulting code is efficient and does
not consume excessive throughput on the microprocessor.
AUTO-CODING TOOL SELECTION
Conceptually, a simulation model represents the programming
language and an auto-coder is effectively the compiler. The
goal is to select a toolset that enables the transfer of the
‘coding’ responsibility from the software engineer to the actual
function developers. This step is fundamentally important as
the function developers possess the domain knowledge that
allows for a direct implementation to the requirements.
Furthermore, it is also important that the toolset satisfies the
initial goal of performing the pertinent simulations used to
design the system. It is also necessary for the toolset to quickly
and accurately generate code that executes efficiently. Finally,
it is desired, as part of the SPICE® process that the toolset
allows for seamless verification testing of the implementation.
Testing should be performed at each stage, from software
integration test continuing through the complete system test. It
is desired that test vectors, known inputs with expected
outputs, are used to verify each major block as well as the
overall motor control strategy shown in Figure 4.
While there are a variety of options, the MATLAB® toolset was
chosen for this work. First, the system and motor control teams
are already familiar with this tool from their design simulation
work. Next, the toolset can be used from one end of the
development process to the other as the model can be
conceived, simulated, auto-coded and verified all within this
environment.
AUTO-CODING PROCESS FOR PMSM
CONTROL
Per the SPICE® process, product development starts from the
point of the high level requirements being captured continuing
to system requirements analysis which should contain a high
level simulation phase intended to define the system. In
SPICE®, there are also many steps involved with the selection
of tools and methods that should occur, which fall outside of
the intent of this paper. Focusing instead on the development
of requirements, reviews are held to ensure that the proposed
system design will meet the overall requirements and to
establish traceability.
Walters et al / SAE Int. J. Passeng. Cars – Electron. Electr. Syst. / Volume 7, Issue 2 (August 2014)
Figure 5. High Level Motor Control Architecture
In the specific example of the motor control component, there will
be requirements for control modes such as torque, speed, DC
voltage and fault reactions, performance requirements related to
torque response rate, torque accuracy, torque, voltage, and
current ripple, as well as requirements for overall efficiency. In
order to design a solution to meet these requirements, numerous
control level simulations will be performed to derive software
requirements.
Implementation
The simulations used to form the requirements are now the
basis for the implementation created by the motor control
function developers. An output of the design phase should be
an architecture that captures the functionality shown in Figure
4 and converts it into specific modules. The architecture should
clearly define each module’s inputs and outputs, when it is
executed, and its requirements. Figure 5 provides a high level
overview of the motor control architecture with the major
modules shown. For each module, there will be models
developed to meet the associated requirements.
Once the component architecture has been defined, the focus
now shifts to creating a code-efficient model that meets each
module's requirements and is easy to understand and share
among a team. Simulation tools offer a wide array of options
for implementing algorithms. High-level models, state diagrams
or even near C-code implementations can be formed with each
offering advantages. In order to maintain ‘read-ability’ among
the team as well as to foster a common approach, a style guide
was created. The guide includes not only the recommended
approach for model development but also the standard that will
be used in peer reviews. Furthermore, the guide also includes
example implementations to ensure that the developed models
will generate efficient code. It is a living document meant to
show the best practices of implementation.
In order to highlight the impact of model implementation and
the need for a consistent guide, a few examples will be
presented. In the first example, a portion of the Space Vector
Modulation (SVM) from module 2.8 in Figure 5 is shown. In this
module, an on-time related to the voltage to be applied to the
motor is calculated based upon inputs from the current
regulator's voltage commands and the motor's angle. The
important aspect is that a selector switch is being used to
choose among different cases. Figure 6a shows a common
high level model approach for the implementation where
redundant blocks are avoided to minimize ‘clutter’. The
associated C-code is shown in Figure 6b. In the highlighted
code, it can be seen that all calculations are being performed
regardless of whether they are needed thus minimizing the
benefit of the selector switch.
Figure 6a. Inefficient Model
Walters et al / SAE Int. J. Passeng. Cars – Electron. Electr. Syst. / Volume 7, Issue 2 (August 2014)
The next example is related to the use of embedded functions.
Embedded functions are often convenient when performing
many complicated mathematical operations. In this example,
an index for an array is calculated using single precision math.
After the index is determined, it is necessary to convert it to an
unsigned 32-bit integer to find the value in the associated
array. When used in an embedded function, the basic
typecasting command uint32(.) was discovered to generate
additional lines of code as shown in Figure 8. As can be seen,
there is additional rounding logic being performed as opposed
to the basic truncation that is expected.
Figure 6b. Inefficient Code
A superior solution can be formed by recognizing how the
auto-coding tool compiles. The model can be reformed as is
shown in Figure 7a. The result of more efficient C-code
generated from the model is shown in Figure 7b. The code
shows that the intent of the selector switch is now being
followed with only the needed calculation being performed on
each loop. Though the model is now slightly more ‘cluttered’
due to the redundancy, the resulting code performs identically
and will execute more quickly. As can be seen, code that
functions exactly the same can execute differently.
Figure 8. Inefficient Typecasting in Embedded MATLAB® and the
Resulting Generated C-Code
By implementing the typecasting via a custom C-code function
SingleToInteger32(.) that can be called from inside embedded
MATLAB®, the limit and rounding checks can be eliminated as
shown in Figure 9. Also therein, the custom C-code function
has been implemented as a #define for maximum efficiency to
avoid the overhead associated with a function call. Thus the
resulting generated C-code is just the typecasting as was
intended in the original embedded MATLAB® code.
Figure 7a. Efficient Model
Figure 9. Efficient Typecasting in Embedded MATLAB®, Resulting
Generated C-Code and Implementation
A final example of improving code efficiency is in the area of
math functions. Performing calculations using custom functions
can often be more computationally efficient than using the
readily available MATLAB® commands or Simulink functions.
Assuming that memory is available, using a lookup table to
perform trigonometric calculations such as sine or cosine is
much more efficient than using MATLAB®'s sin(.) or cos(.)
function. These functions use an algorithm to determine the
result. While using lookup tables to replace math functions is
not new, the savings can be overlooked by function developers
who are not intimately familiar with software implementation
issues.
Figure 7b. Efficient Code
Walters et al / SAE Int. J. Passeng. Cars – Electron. Electr. Syst. / Volume 7, Issue 2 (August 2014)
In addition to how the model is implemented, the auto-coding
toolset should have features that can assist the development
process and optimize the generated code. As a basic rule, the
toolset should be setup to check the model for errors and
issues by setting diagnostics warnings to quickly identify
problems. Furthermore, the coder should have settings that
can be used to impact the generated code. Optimization for
RAM, ROM or execution efficiency can be selected. As the
primary concern for this work was code execution efficiency, a
higher priority was placed on this objective. It is worth noting
that for these specific models and tool version that the
generated code was relatively insensitive to the objectives that
were set.
Although the examples shown are intentionally basic, they
highlight how by maintaining a recommended implementation
guideline in conjunction with peer reviews from the software
engineers, the toolset can be used to best effect. The basic
step of reviewing the generated code will uncover numerous
areas where improvements can be made to the execution
efficiency. Over time the auto-coding tools have significantly
improved the quality/efficiency of the generated code, but there
is still a need to maintain a knowledge base of best practices
for efficient code. As new modules are created and as new
releases of a tool become available, the best way to implement
concepts will evolve.
Relative to the SPICE® process, the normal peer review to
ensure that requirements are met is also a natural place to
review the implementation for efficiency. The software
engineers are now responsible to carefully track and document
preferred approaches. Their role has also transitioned from the
code implementation to ensuring the auto-coding environment
is set up properly, defining best practices for implementation,
ensuring efficient code implementation, providing expertise in
peer reviews and assisting in the debug of implementation
issues. The motor control engineer has now transitioned from
writing a requirements document and verifying successful
implementation through test to more directly owning the
implementation. While this role does require additional
responsibility to ensure that the selected modeling tool is used
correctly, it minimizes potential misunderstandings of motor
control and software engineers as well as leverages the
existing simulation expertise.
As the model now becomes the implementation, it is important
that each model is easily understandable and consistent with the
models defined in the other modules of Figure 5. It is also
imperative that the overall scope of the full motor control is
clearly visible and easy to understand. With complicated
systems, it is easy to lose visibility of the overall implementation.
As often the highest view of the model will only show function
calls to the various modules, it is necessary to still create a
document that provides additional details on how the
implementation is intended to work.
The architecture, shown in Figure 5, helps to clearly define the
modules and how they relate. Each module will also have an
implementation model associated with it. It was found that
rather than attempting to provide documentation in the model
that an additional document was needed to provide overall
system context as well as module specific implementation
information. This document provides the high level overview of
how the implementation works which may not be easy to
understand from the requirements, architecture or from the
simulation models. It also can be formed in a consistent
fashion for different models to ensure the needed information is
readily accessible and serves as a user's guide on how to
calibrate the associated model. Care, of course, must be taken
to ensure consistency with the implementation, but the overall
benefit of allowing an easy to understand implementation was
found to be worth the additional effort.
Verification
Per SPICE®, it is also necessary to show that the model fully
meets the requirements. This is achieved by creating sets of
test vectors which manipulate the model inputs in the
simulation environment to ensure that the desired outputs
occur per the requirements. Testing of inputs for unexpected
cases should also be performed. As the tool is automated, a
report can be generated at the end of each model modification
to ensure the requirements are still met. Furthermore, the
toolset also offers coverage checks to verify that all appropriate
paths were tested. In addition to this step, a review is held with
the system / software team to verify the requirements were met
and the code efficiently generated. This last step is an
important addition to ensure the implementation is acceptable
and can be naturally added to the normal SPICE® reviews.
While this verification testing was performed in the simulation
environment, it is often necessary to repeat the test on the
production hardware to verify that the final compiled version
executes correctly. The same test vector can often be used in
this phase though additional tools may be required.
Figure 10 shows an example test vector used to verify the
performance of the Torque Mode module (1.3) of Figure 5. This
module is responsible for dynamically determining the proper
d- and q-axis currents commands to the machine to achieve
the commanded torque accounting for speed, temperature,
magnetic saturation and battery voltage constraints. For the
purpose of this example, the motor speed, temperature and
battery voltage are treated as constant inputs to the model,
although they are not shown as part of the input test vector. In
this test vector, the torque commands are being sent from a
variety of inputs including instrumentation to ensure that only
the correct command source is being followed and that the
proper current commands are being calculated for the
simulated voltage, speed and temperature conditions. The
torque command source is determined by ‘Cmd Source’ where
0 denotes Ignore Input, 1 denotes CAN Input and 2 denotes
Instrumentation Input. Note that the torque commands are also
issued during times when they were to be ignored to ensure
proper performance.
Walters et al / SAE Int. J. Passeng. Cars – Electron. Electr. Syst. / Volume 7, Issue 2 (August 2014)
After each module shown in Figure 5 has been tested with its
associated test vector and reports generated, the complete
motor controller can be tested in simulation. Appropriate
models for the electric machine, inverter, and sensors are
required but they should be readily available from earlier
design work. Using a test vector derived from the Torque Mode
test vector of Figure 10, the response of the full control system
was tested. Based on the accuracy of the model, the torque
control and current regulation can be evaluated against
performance targets to determine if the requirements have
been met. Herein, the first 10 Sec of the commanded input test
vector is applied to the full motor control model in simulation as
shown in Figure 12.
Figure 10. Input Test Vector Commands
The results, shown in Figure 11, indicate that the desired
current commands are correctly calculated consistent with the
expected output. This module has numerous calculations being
performed to dynamically modify the current commands based
upon constraints. In this case, high level models/simulations
are used to develop the Desired output and the actual
implementation model for the module is used to form the
Measured output. These signals are used to verify that the
overall requirements were met.
Figure 12. Input Test Vector to the Complete Motor Control
The results of applying this input are shown in Figure 13. It can
be confirmed that the Measured output values are still
consistent with the Desired values from the requirements. For
cases where exact results may not be easy to predict, such as
when using a motor model, it is important to verify that the
overall performance of the test vector meets expectation rather
than each exact time step meeting a specific numeric result.
Figure 13. Expected Output Current Commands from the Complete
Motor Control (Desired and Measured)
Figure 11. Expected Output Current Commands (Desired and
Measured)
Walters et al / SAE Int. J. Passeng. Cars – Electron. Electr. Syst. / Volume 7, Issue 2 (August 2014)
DYNAMOMETER TESTING
The concepts developed in this paper were applied to an
existing project using an Allison® H3000 Transmission Hybrid
System intended for the medium duty commercial truck market.
In this system, a permanent magnet motor is integrated into a
transmission using a sandwich configuration. An overview of
the system is shown in Figure 15. For this project, Delphi® was
responsible for the motor controls, inverter, DC/DC converter
and energy storage system.
Figure 13. (cont.) Expected Output Current Commands from the
Complete Motor Control (Desired and Measured)
The complete simulation model also offers the capability to
verify the intermediate signals for the various modules. These
signals should be included in the test vector to ensure that the
various modules are functioning as intended. In Figure 14a, the
resulting A-phase upper device on-time that will create the
PWM signal applied to the A-phase of the inverter is shown.
This signal is magnified in the Figure 14b.
Figure 15. Allison® Transmission H3000 Hybrid Drive
The system was tested on a dynamometer in order to evaluate
the performance of the production hand-code versus the
model-generated code. The dynamometer setup including the
motor, Allison Transmission inverter, and dynamometer is
shown in Figure 16.
Figure 14a. A-Phase PWM Signal
Figure 16. Dynamometer Test Setup with Allison® Transmission
Inverter
The following table summarizes the performance in torque
control mode of the hand-coded and model-generated code. In
this case, a defined operating point was used so that the two
code sets could be directly compared. The execution times for
key modules of Figure 5 as well as the total time for the 100
uSec task are shown in Table 1. The excess time that is not
consumed by the 100 uSec task is required to allow slower
loops to have sufficient time to execute.
Figure 14b. A-Phase PWM Signal - Magnified
Walters et al / SAE Int. J. Passeng. Cars – Electron. Electr. Syst. / Volume 7, Issue 2 (August 2014)
Table 1. Throughput Comparison between Model-Generated Code and
Hand-Code
From Table 1, it can be observed that the overall modelgenerated code is within 1.5 uSec of the hand-code which
represents a 2.4% penalty. It should also be noted that the
hand-code used as a baseline comparison has been
developed over many projects and has been optimized by the
software team. In general, there is a small but measurable
increase in the required time for the model-generated code.
The benefits of directly using simulation models through the
development process, allowing the domain experts to control
the implementation, and more easily automating the verification
testing are well worth the small penalty.
While the final results are comparable, it did not occur without
the concerted focus of the team. Particularly, the review
process and the new motor control and software team roles
helped to identify and correct numerous instances of model
implementations that led to sub-optimal code. While there was
an initial investment to determine how to best use the autocoding toolset, each subsequent development activity is
expected to be less effort intensive.
SUMMARY/CONCLUSIONS
As the control of the electric machine is one of the more
challenging tasks in a hybrid or electric vehicle due to its fast
execution rates and complex requirements, numerous
simulations are used in the development cycle to appropriately
design the algorithms. Historically, the implementation of the
algorithms into software followed a simulation, requirements
development, hand-coding, and verification process due to
concerns with code throughput. This process is inherently
inefficient and has the potential to introduce errors as the
simulations used to form the requirements are not directly used
in the forming of the software as well as the software
implementation is not directly created by the motor control
engineer.
Auto-coding from simulation models is a natural tool that can be
used to address the process issues though care must be taken
to ensure that an easily understandable and modifiable model
that executes efficiently is developed. By allowing the domain
experts to implement the models a potential source for errors
can be removed. In addition, by transitioning the software
engineers' responsibility to establishing the simulation/modeling
environment, defining the modeling standards for efficient code,
providing input in peer reviews and resolving detailed
implementation issues, complicated control tasks can be coded
with efficiency approaching optimized hand code.
As an Automotive SPICE® development process is already the
norm, when the various reviews should occur for developing
requirements, defining implementations and documenting
verification is already defined. The addition of steps in the
existing reviews to ensure models compliance to requirements
as well as proper model formation is simple and found to be
extremely useful for ensuring that efficient code is generated.
The verification of the model using automated test vectors also
naturally supports a SPICE® process and serves to allow quick
verification that subsequent changes did not impact satisfying
requirements.
The process defined in this paper was applied to an existing
project as the algorithms were ported to the new simulation
environment. The maintaining of the best practices in a style
guide was found not only to improve code efficiency but also to
ensure that models had a common feel which greatly aids
readability, debugging and troubleshooting. Ultimately, the
performance and throughput results were shown to be
sufficiently close to hand-code to justify use on future projects.
REFERENCES
1. Automotive SIG, “Automotive SPICE Process Assessment Model”,
The Procurement Forum, Aug. 21, 2005.
2. Grießer, M., Schreiner, F., and Stölzl, S., “Applying Functional
Safety Management and SPICE for Automotive Functions,” SAE
Technical Paper 2008-01-0109, 2008, doi:10.4271/2008-01-0109.
3. Ueda, K., Uematsu Y., and Baloh, M., “Converting Legacy
Embedded Control Software to Executable Specifications”,
MathWorks' International Automotive Conference, 2006. Retrieved
from: http://www.emmeskay.com/presentation-files/publications/06Ueda-Toyota.pdf
4. Yang, J., Krishnan, S., Bauman, J., and Beydoun, A.,
“Implementation of Auto-Code Generation in Legacy Code for Body
Control Software Applications,” SAE Technical Paper 2008-010749, 2008, doi:10.4271/2008-01-0749.
5. Yan, K. and Trush, C., “Transmission Control Design Approach
Using Simulation, Rapid Prototyping, and Auto Code Generation,”
SAE Technical Paper 2008-01-0536, 2008, doi:10.4271/2008-010536.
6. Hsu, M., El-Jaroudi, M., and Bender, E., “Accelerated Life Cycle
Development for Electronic Throttle Control Software using ModelBased/Auto-Code Technology,” SAE Technical Paper 2004-010276, 2004, doi:10.4271/2004-01-0276.
7. Patil, K. and Muli M., “Model-Based Development of Motor Drive
Controller for Hybrid Electric Vehicles”, E-Drive: The Magazine
of Electric Motor & Drive Technology, Jun. 26, 2013. Retrieved
from: http://www.e-driveonline.com/main/articles/model-baseddevelopment-of-motor-drive-controller-for-hybrid-electricvehicles/
8. Su, G.J., McKeever, J., and Samons, K., “Design of a PM
Brushless Motor Drive for Hybrid Electrical Vehicle Application”,
PCIM 2000, Oct. 1 - 5, 2000, pp. 1-6.
9. Fu, T.J., Xie, W.F., “Torque Control of Induction Motors for Hybrid
Electric Vehicles”, American Control Conference 2006, Jun. 14 16, 2006, pp. 5911-5916.
Walters et al / SAE Int. J. Passeng. Cars – Electron. Electr. Syst. / Volume 7, Issue 2 (August 2014)
10.Krause, P.C., Wasynczuk, O., Sudhoff, S.D (2002). Analysis of
Electric Machinery and Drive Systems. Piscataway, NJ: IEEE
Press.
11. Brogan, W. L. (1991). Modern Control Theory - 3rd Edition. Upper
Saddle River, NJ: Prentice-Hall, Inc.
12.Press, W. H., Vetterling, W. T., Teukolsky, S.A., and Flannery, B. P.
(2002). Numerical Recipes in C: The Art of Scientific Computing
- 2nd Edition. New York, NY: Press Syndicate of the University of
Cambridge.
CONTACT INFORMATION
James Walters
Jim.Walters@delphi.com
Cahya Harianto
Cahya.Harianto@delphi.com
Edward J. Kelly
Edward.J.Kelly@delphi.com
Tanto Sugiarto
Tanto.Sugiarto@delphi.com
DEFINITIONS/ABBREVIATIONS
CAN - Controller Area network
ECM - Engine Control Module
HCM - Hybrid Control Module
HIL - Hardware in the Loop
PMSM - Permanent Magnet Synchronous Machine
PWM - Pulse Width Modulation
RCP - Rapid Controls Prototyping
SPICE - Software Process Improvement and Capability
Determination
SVM - Space Vector Modulation
All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by any means, electronic, mechanical,
photocopying, recording, or otherwise, without the prior written permission of SAE International.
Positions and opinions advanced in this paper are those of the author(s) and not necessarily those of SAE International. The author is solely responsible for the content of the
paper.