Application of Auto-Coding for Rapid and Efficient Motor Control Development

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

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]. 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 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. 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

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., T e * / ω 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.

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

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

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.

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 11. Expected Output Current Commands (Desired and Measured) Figure 13. Expected Output Current Commands from the Complete Motor Control (Desired and Measured)

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

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/06- Ueda-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-01- 0749, 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-01- 0536. 6. Hsu, M., El-Jaroudi, M., and Bender, E., Accelerated Life Cycle Development for Electronic Throttle Control Software using Model- Based/Auto-Code Technology, SAE Technical Paper 2004-01- 0276, 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.

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 - 3 rd 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 - 2 nd 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.