Prototype, Verify, and Implement Dynamic FPGA

DesignCon 2012

An Improved Co-Simulation Approach to Rapidly Prototype, Verify, and Implement Dynamic FPGA-based Embedded Control Systems

Muris Mujagic, National Instruments [email protected] Oleg Stepanov, National Instruments [email protected] Brian MacCleery, National Instruments [email protected]

Abstract This paper presents a new co-simulation methodology for the rapid prototyping, design, and verification of digital controllers for switching power electronics circuits based on field programmable gate array (FPGA) logic devices. A case study of a closed-loop DC motor drive design, comprising of a digital controller and analog power drive circuitry, is used to illustrate the new co-simulation methodology. Using an NI Multisim SPICE simulation plug-in for the LabVIEW graphical programming environment, the complete system was verified and optimized using transient simulation prior to being implemented in hardware. All FPGA processing elements were designed and simulated in the co-simulation environment before synthesis to digital hardware, including the analog power stage modeled with SPICE. The system simulation results were compared to the experimental measurements. It was found that the measured motor speed and the DC motor armature current closely matched the simulated results, supporting the method of co-simulation as a valuable, insightful and productivity enhancing initial step prior to system implementation using physical hardware.

Author(s) Biographies Muris Mujagic received his B.A.Sc. degree in computer engineering from the University of Waterloo, Waterloo, ON, Canada, in 2005. He then completed his M.A.Sc. degree in electrical (biomedical) engineering at the University of Toronto, Toronto, ON, Canada, in 2007. At present, he works at National Instruments Toronto, as a member of the Simulation and Modeling group. His primary responsibilities include enhancing and maintaining the Multisim SPICE simulation engine. Oleg Stepanov received his B.A.Sc. degree in Electrical Engineering from the University of Toronto. In 2006, he joined National Instruments Toronto as a member of the Simulation and Modeling group. His research interests are in the areas of analog circuit and electromechanical system simulation. Brian MacCleery received his bachelors and masters degrees in electrical engineering from Virginia Tech where he completed his graduate research in electromechanical modeling and simulation and led multidisciplinary student teams in the development of novel magnetic levitation and propulsion designs for energy efficient rapid transit. Brian is the Principal Product Manager for clean energy technology at National Instruments. His mission is to facilitate the design, prototyping and deployment of advanced embedded systems technologies to make clean energy less expensive and more abundant than fossil fuels.

1. Introduction Dynamic systems are often represented by linear, time-invariant state-space or transfer function models in the Laplace domain. But in practice dynamic system are much more complex; the physical process that is being controlled is often non-linear and exhibits vastly different behavior among various regions of operation. A particularly relevant example is a switched-mode power conversion system. Such a system does not operate close to a single bias point around which a linear model may easily be built. Furthermore, it contains a number of elements that exhibit complex non-linear behavior including the power transistors and magnetic components such as the transformer. Therefore, a non-linear multi-domain simulation helps to more accurately analyze the behavior of such a complex system. What‟s more, as designs grow in complexity and engineering capital requirements, a deep analysis and full scale simulation of the design prior to building the first prototype is changing from a prudent practice to a necessity. New design tools are needed that enable all of the software development, testing and validation effort made during the simulation stage to be moved seamlessly into the physical prototype and through to commercial deployment. Thereby, a single code-base can be designed, simulated, optimized and validated in a seamless iterative development process [1]. This is in contrast to a process in which the code developed for simulation purposes is different from that used for embedded system deployment; resulting in a problematic disconnect in the design validation process that often leads to development inefficiencies and costly or dangerous mistakes. If the embedded system code does not match the code used during the simulation stage, design validation efforts based on simulation have significantly reduced value. In this paper, a case study of the design of a brushed DC Motor drive is used to illustrate a novel multi-domain co-simulation method. NI Multisim, a SPICE-based circuit design and simulation tool, was used to model and analyze the power stage. NI LabVIEW FPGA and the LabVIEW Control Design and Simulation Module were used to design a digital controller. Then, the entire system was simulated and optimized using the multi-domain co-simulation. In co-simulation, the two respective simulators perform non-linear time-domain analysis concurrently, exchanging data at the end of each time-step and negotiating future time-steps, resulting in a tightly integrated and accurate simulation. This enables both solvers to execute in a continuous-time fashion and enforce accuracy requirements that ensure valid simulation results, even in the case of coupled differential equation relationships that span between both solvers. Although it is possible to include both independent and coupled plant dynamics on both sides, the simpler and more common use case is shown in Figure 1. In this case, Multisim simulates the power stage circuitry and LabVIEW executes the FPGA-based control system algorithms. In this configuration, the native strengths of each respective environment are leveraged.

Figure 1: Typical LabVIEW-Multisim co-simulation use case. In the illustrated scenario the control code resides in LabVIEW, while the plant and sensor are modeled by Multisim.

With this new methodology a complete system, comprising of an analog stage and an embedded FPGA controller, can be co-simulated in order to validate system connectivity, gain insights into its operation, perform system optimization, and efficiently bridge the gap between system design and the first physical prototype. The paper is organized as follows. In Section 2 the high level requirements of the brushless DC motor drive system are outlined. Prior to performing a full system co-simulation, the individual parts of the system were designed and analyzed in isolation. The design and validation of the analog power stage is presented in Section 3, and the digital controller design is presented in Section 4. Once the constituent parts were designed, the complete system was analyzed and optimized using co-simulation, as described in Section 5. After completing the system optimization and validation, the control code was efficiently implemented on a physical prototype as presented in Section 6. To demonstrate the value of system co-simulation, the simulation and experimental results are compared in Section 7. Concluding remarks are discussed in Section 8.

2. Brushed DC Motor Drive Requirements The case study that is presented in this paper is the design and prototype of a digital speed controller for a brushed DC motor. The application requirements for the design were:      

Spin an inertial load ( ) periodically at 1200 RPM for 3 seconds and at -1200 RPM for 3 seconds. The required speed profile is illustrated in Figure 2. Speed overshoot must not exceed 1400RPM. Motor must reach the final speed in under a second. Use 20 kHz for the PWM switching frequency. Reuse available brushed DC motor with quadrature encoder (see Appendix A) Run the motor using a 12 V supply.

Figure 2: Speed profile requirements for the brushed DC motor controller.

3. Analog Power Stage Design and Analysis Having established the system requirements, the analog power stage for the brushed DC motor system was designed. In order to satisfy the bi-directional current flow requirement (motor must spin in both directions) the power stage was designed around the common H-bridge topology. A feasibility analysis was conducted in Multisim to determine whether the available power supply is capable of accelerating the loaded DC motor to the required speed within the required amount of time. This analysis also revealed worst case current conditions that would be experienced by the switching elements, allowing for the preliminary selection of power switching parts. The selected parts were subjected to a thermal stress analysis to validate their suitability. Following these tests, a plant model of the power stage was designed for system cosimulation.

3.1. Feasibility Analysis and Switch Selection Simulation was used to determine whether the available power supply was capable of accelerating the loaded DC motor to the required speed within the required amount of time. By applying the maximum DC supply voltage (12 V) directly across the terminals of the DC motor, the theoretical minimum time that it would take the motor to reverse directions from -1200RPM to 1200RPM was measured. The circuit of Figure 3 was used to perform this test. The description of the brushed DC motor model and its parameters can be found in Appendix A. The resulting speed and current profiles are shown in Figure 4.

Figure 3: Circuit used to measure the theoretical speed and current response of the brushed DC motor.

Figure 4: Theoretical speed and current response observed when driving the brushed DC motor from an initial speed of -1200 RPM to 1200 RPM. Due to the back-emf generated by the motor at the initial speed of -1200, the motor experiences a large inrush current of approximately 18 A when driven hard in the opposite direction.

According to simulations, the motor is capable of reversing from -1200 RPM to +1200 RPM in 0.51 s. However, applying 12 V across an armature with an approximate resistance of 1 Ω and a back-emf of approximately -6 V (resulting from the initial speed of 1200 RPM) causes an in-rush current of over 18 A, which is above that available from the power supply. To reduce the peak current demanded from the power supply the voltage to the armature could be applied more gradually. Using simulation it was determined that by applying the 12 V supply with a slew rate limit of 34 V/s, the peak in-rush current can reduced to 13.5 A. With slew rate limiting it takes 0.7 s instead of 0.51 s to reach the desired speed of 1200 RPM, which still satisfies the 1 second design requirement.

Based on the operating voltage and the maximum expected armature currents, the Infineon IPP126N10N3 100V, 58A, N-channel MOSFET part was selected as the low-side MOSFET. For the high side switch, the Infineon SPP80P06P 60V, 80A P-channel MOSFET was selected. P-channel transistors were selected for the high-side because of the simplicity of controlling them. The International Rectifier IR2101PBF was selected as the gate driver for all switches.

3.2. Power Transistor Thermal Stress Analysis Using high-fidelity SPICE models of the driver and MOSFETs, worst case switching losses were extracted. Using a combination of piece-wise-linear and behavioral modeling sources, these switching losses, along with expected worst case conduction losses, were fed into a thermal network representing the MOSFET package and heat sink. The junction temperature was monitored to ensure that it did not exceed 125 °C, which was deemed the safe operating limit of the device. See Appendix B for more details.

3.3. Plant Model for Controller Design In order to design and test the controller using co-simulation, a plant model needed to be designed. Figure 10 shows the plant model used for co-simulation. In the interest of simulation performance, focus was placed on elements that would significantly affect the dynamic behavior of the entire system. The gate drivers were not considered because their effect on the system dynamics is minimal. Furthermore, their ability to drive the switches as well as their impact on switching losses had already been investigated.

Figure 5: Plant model in Multisim for co-simulation

The switches S1-S4 were represented using simplified resistive models because the timeconstants associated with the actual switches are much smaller than those associated with the dynamic system at hand. These simplified models function as follows: if the control voltage is 5V or higher, then the drain-source path is a fixed resistance with a value equal to (12.3 mΩ for N-channel and 23 mΩ for P-channel MOSFET), and if the control voltage is 0V or lower, then the drain-source path is a fixed resistance with a value equal to (1 MΩ for the N-channel and P-channel MOSFET). The resistance varies exponentially for control values in between 0V and 5V. The gate control signals U1, U2, L1, and L2 are driven by the controller. M1 is the DC motor represented by the same linear model used in the feasibility test. J1 represents the moment of inertia of the load. U1 is a functional model of the optical encoder that is present in the actual motor. The values of the signals Current, IdealSpeed, and A, B, and I are sent to the controller.

4. Digital Controller Design With the H-bridge topology selected for the analog power stage, the corresponding digital controller was designed in LabVIEW. The controller consists of a quadrature decoder, a PI controller, a PWM generator, and an H-bridge driver (items 1-4 in Figure 8). For this design, the default on-board 40 MHz FPGA clock was chosen because it permitted the generation of a high resolution 20 kHz PWM digital pulse with small duty cycles and dead-times.

4.1. Quadrature Decoder The quadrature decoder calculates the position, velocity, and acceleration based on a quadrature encoder signal (speed sensor data) from the motor. The velocity output is updated on every falling edge of the clock input; however, by using the Clock Divider signal the time interval between velocity updates was increased by N number of clock cycles. While this increases the delay between velocity updates, as more encoder pulses are acquired during the larger time interval, the accuracy of the measured velocity is improved. The velocity is calculated in units of Counts/Interval. Using the conversion derived in equation (1) this raw value was converted to revolution per minute (RPM).

(1)

For the design presented in this paper a of 20000 was chosen. This amounted to an of 30, and a new velocity update every 0.5 ms.

4.2. PI Controller In order to prototype the controller on an FPGA the continuous time model for the controller had to be discretized. To demonstrate the approach for custom fixed-point algorithm development, the already available discrete time PID controller node was not used as part of this brushed DC motor drive case study. The discretization approach presented can be used to move any floating point algorithm to a fixed point representation for execution on an FPGA. To make the PI controller design reusable, the controller was designed to operate at a rate of 40 MHz (the default clock speed for most FPGAs). Any code executing at that rate must compute its outputs within a single clock period of the FPGA. Such a fast controller was not necessary for the brushed DC motor application presented in the paper (especially when the brushed DC motor was loaded by a large inertial disk); however, a high speed controller offers improved disturbance rejection, and can be used to maintain control of very high bandwidth actuators. The continuous time PI controller equation was discretized by using the backward Euler approximation for the integral term, as shown here:

(2)

where, is the controller output; is the proportional portion of the controller output; is the integral portion of the controller output; is the control error (i.e. the difference between the process variable and the desired set point); it the proportional control coefficient; is the integral control coefficient; is the discretized time; and is the sampling interval of the discrete PI controller. Figure 6 shows the implementation of the discrete time, fixed point PI controller.

Taking advantage of the FPGA fixed point math the discrete time PI controller logic was further augmented to include anti-windup. Anti-windup ensures that the integral part of the controller is limited whenever the motor response saturates, thereby ensuring that the controller is ready to resume action as soon as the control error changes. By enabling saturation in the fixed point configuration of the high throughput math functions, the integral term, , and the controller output, were limited to a range of -1024 to 1024. This range was chosen since it is a multiple of 2, and the PWM generator block which is fed by the PI controller expected a value in the range 0 to 2000.

Figure 6: A 40MHz discrete PI controller, implementation according to equation (2). The fixed point math precision was adjusted to implement anti-windup, with the integral term and the output terms limited to a range of [-1024, 1024].

To reduce the propagation delay of the high throughput math functions, and thereby ensure that the discrete time PI controller could execute at the required rate of 40 MHz, these additional fixed point math precision limitations were placed:  

was limited to a range of [0, 63.8750], and could be changed in steps of 0.125, and for a 40 MHz clock,

could be changed from 0 in steps of approximately 2.384.

These fixed point precision limitations did not impact the selection of the proportional and integral coefficients of the PI controller. In Figure 7, the response of the discrete time PI controller is compared to the continuous time PI controller. As seen in the image, when the sampling time of the integral term is (40 MHz FPGA clock), the discrete time controller tracks perfectly the continuous controller output. Figure 7 also illustrates the antiwindup behavior of the PI controllers, with the output limited to 1024.

Figure 7: Comparison of discrete time PI controller to continuous time PI controller. With , and identical.

,

the output of the continuous and discrete time PI controllers is nearly

4.3. PWM Generator and H-bridge driver For the brushed DC motor speed control design the H-bridge was driven using lock antiphase mode. In this driving mode the four switches of the H-bridge are turned on and off in every cycle, with the diagonal switch pairs of the H-bridge driven together. In this design, a PWM duty cycle of 50-100% would spin the motor in the clockwise (positive) direction, while a 0-50% PWM duty cycle would spin the motor in the counter-clockwise (negative) direction. A duty cycle of 50% resulted in no spin since the average voltage across the motor was 0 V (there was no external torque applied to the shaft of the motor). As per requirements, the PWM generator node (node 3 in Figure 8) was configured to generate a 20 kHz digital pulse, with the duty cycle of the PWM regulated by the output of the PI controller (node 2 in Figure 8). The H-bridge driver nodes (nodes 4 and 5 in Figure 8) convert the PWM duty cycle into the drive signals for the H-bridge switches. In order to prevent shoot-through, which can happen when S1 and S2 (or S3 and S4) of Figure 5 are on at the same time, the H-bridge driver node implemented dead-time control. The dead-time is inserted whenever the controller switches current between the diagonal switch pairs of the H-bridge. During the dead-time all switches are off and the armature current flows through the freewheeling diodes. For our design, 2.5 μs of dead-time was required in the worst case. This value was originally determined using high-fidelity SPICE models in simulation, and verified during prototyping.

5. System Co-simulation With the analog power stage model and digital controller design complete, the entire system was analyzed and optimized using co-simulated. In the co-simulation environment, Multisim and LabVIEW concurrently perform a non-linear time-domain analysis, exchanging data at the end of each time-step. What‟s more, when LabVIEW is configured to use a variable step size solver Multisim and LabVIEW are able to negotiate future time-steps, resulting in a tightly integrated and accurate simulation. The result is that both tools can enforce accuracy requirements that ensure valid simulation results, even in the case of coupled differential equation relationships that span between both solvers. In the case of a brushed DC motor, such coupled dynamics exist if the mechanical load system is modeled in LabVIEW and the electrical system in Multisim. Because the mechanical torque of a motor is proportional to the electrical current, the mechanical and electrical dynamics are inextricably linked. If a sufficiently fine time-step is selected, as is necessary during the initial in-rush current startup behavior of the motor, the simulation performance for the overall simulation will be much slower than necessary. On the other hand, if a larger time-step is chosen, the simulation results may be dangerously inaccurate. To further complicate the matter, the required step size varies throughout the simulation run and depends on the nature of the control action. A higher bandwidth control compensator or fast changes in the set point will necessitate a finer time-step. Not surprisingly, designers must use fixed time-step co-simulation tools with caution; especially in the case that dynamic coupling exists between the two tools. Since no coupled dynamics existed in our case study of the brushed DC motor, using a variable step size solver was not necessary; a fixed step size solver was adequate. The simulation diagram of the complete brushed DC motor drive systems is shown in Figure 8. Node 5 contains the power circuitry plant model designed in the Section 3.3. It is simulated using Multisim. Everything else in the figure represents elements of the control system (nodes numbered 1-4) or elements used to support the simulation, all of which are simulated using LabVIEW. The FPGA nodes in the simulation diagram (velocity decoder, discrete time PI controller, PWM generator, and H-bridge driver) were configured for discrete time execution (indicated by the „D‟ glyph) in the upper right corner of each node. Configuring the discrete time execution rate of these nodes for simulation was necessary in order to simulate the precise timing behavior of the code as it executes on the FPGA.

Figure 8: Closed loop system simulation of the brushed DC motor controller. The LabVIEW Control & Simulation Loop (black) executes the simulation diagram. Nodes 1-4 are part of the digital controller and are (in order): the speed decoder, continuous time PI controller, PWM generator, and H-bridge driver. The plant model, node 5, consists of the MOSFET switches, brushed DC motor, and an optical encoder executing in the Multisim SPICE simulation environment. The one time-step delay added to the optical encoder outputs (A, B, and I) are necessary in order to perform a closed loop simulation. The ‘Sim Tic Count’ variable was used to simulate the FPGA clock whenever the simulation step size was larger than the FPGA clock period ( ).

In order to closely replicate the synchronous sequential logic behavior of the digital controller, the simulation diagram was solved using the Runge-Kutta 1 (RK1) fixed step size solver. A fixed step solver has the advantage of accurately representing the actual FPGA execution behavior; however, this comes at the cost of performance, since a step-size must be chosen to match the FPGA clock period ( for a 40 MHz clock). To get around this problem the “Sim Tic Count” variable in Figure 8 was used. With this variable it was possible to simulate the tic count of the 40 MHz FPGA clock even when a step size larger than the actual FPGA period was used. This greatly improved simulation speed; however, it yielded an approximation of the true cycle-by-cycle execution timing behavior of the FPGA code. In this case study, the solver step size was typically chosen as either or , depending on the desired accuracy. Using the smaller step size ( allowed for a higher resolution simulation of the PWM signal (and hence better armature current prediction) at the cost of simulation speed; however, for the purposes of selecting the PI controller coefficients the larger step size ( was adequate.

Throughout the system analysis, to gain insight into the brushed DC motor drive system behavior, various signals inside the embedded FPGA control code and the analog plant model were monitored during co-simulation. Having the ability to probe any signal (e.g. currents/voltages inside a MOSFET/motor, or the dead-time behavior of the control code) allowed for validation of system connectivity and a much deeper understanding of the system behavior. To perform system optimization, the behavior of the brushed DC motor drive system was analyzed in simulation for various expected operating cases. These included:    

Start up (0 RPM to ±1200 RPM), Stopping (±1200 RPM to 0 RPM), Transitioning between 1200 RPM and -1200 RPM (and vice versa), and Transitioning between speeds lower than 1200 RPM.

Through an iterative process, the transient response of the system for these operating cases was analyzed and appropriate values for the proportional and integral coefficients were determined. It was found that selecting , and allowed us to satisfy the brushed DC motor drive requirements outlined in Section 2. These same PI controller coefficients were later used in the physical prototype. The system co-simulation results are presented in Section 7. In addition to optimizing the PI controller coefficient, co-simulation was helpful in determining the type of drive mode to use for the H-bridge. After attempting to use the drive mode implemented as part of the intellectual property (IP) libraries available in LabVIEW, it was determined that this drive mode was inadequate for our needs and had to be redesigned. The problem was further convoluted as the new drive mode (lock-anti phase, see Section 4.3), necessitated a change in the dynamic range of the PI controller, signal level adjustment between the PI controller and the PWM generator, and the ability to specify a dead-time for the controller. All such significant changes to the controller were verified using system co-simulation.

6. System Prototype After performing system co-simulation and attaining a high degree of confidence that the complete brushed DC motor drive system would behave as desired, a physical prototype was developed. The analog power stage was prototyped on a basic proto-board using discrete components, including bypass capacitors on the power rails. To expose the prototype to a mechanical load expected in the final application, a steel disk, whose moment of inertia can be controlled by varying the radius according to equation (3), was machined and fixed to the shaft. (3)

The controller was implemented on the CompactRIO FPGA-based embedded platform, as described in Section 6.1. CompactRIO I/O modules were used to sample the armature current and interface with the velocity encoder and the gate drivers on the proto-board. Note that since the implemented controller strategy did not involve current limiting, the sampled armature current was used for monitoring purposes only. Figure 9 shows the resulting prototype.

Figure 9: Brushed DC motor controller prototype.

6.1. Digital Controller Implementation Figure 10 shows the digital controller as was it is implemented on the Xilinx Spartan-3 2M Gate FPGA inside of the CompactRIO. The controller is configured as a 3-stage pipeline as follows: Stage 1: Stage 2: Stage 3:

Quadrature decoder Discrete time PI controller PWM generator and H-bridge driver

Each stage of the pipeline executes in one clock cycle.

Figure 10: The 40 MHz FPGA implementation of brushed DC motor controller, for the NI CompactRIO-9074. The numbered items are (in order) the speed decoder, discrete time PI controller, PWM generator, and the H-bridge driver.

The FPGA nodes 1-4 in Figure 10 are the same nodes that were used for system co-simulation (see Figure 8) during system design. These FPGA control nodes were configured in exactly the same way for the prototype as they were in simulation. The experimentally measured data is compared to the simulation data in Section 7.

7. Results Figure 11 shows the simulated and measured response of the brushed DC motor system to a step change in the motor speed from 0 RPM to 1200 RPM. Figure 11A is a plot of the motor speed. The stair case effect that can be seen on the speed curve (moves up in steps of 30 RPM) is the result of the quantization introduced by using a velocity decoder. The simulated speed curve tracks very well with the experimentally measured speed response of the motor. Figure 11B shows the simulated and actual armature current through the motor. The current peak, during the period of inrush current resulting from the initial startup behavior of the motor, matched very well between simulation and experiment. Being able to predict this peak current

and how long such large current are sustained is important for preventing damage to expensive parts (such as the motor), and determining whether the available power supply is able to keep up with the current demand.

A

B

C

Figure 11: Simulated and measured response of the Brushed DC motor to a 1200 RPM step command. The controller parameter were , , and dead-time of 2.5 µs. The simulation data was collected using the RK1 solver with a step size of s.

Figure 11C shows the input signal of the PWM generator (the PWM duty cycle command). As with the speed, the quantization introduced by the velocity encoder is responsible for the stair case effect. Both in simulation and experiment the PWM duty cycle command signal settled at approximately 1500. In order to achieve such good agreement, the static friction torque of the motor (a measure of the resistance to angular motion) had to be taken into account.

This was achieved by augmenting the plant model of Figure 5 with a controlled current source on the shaft of the motor. The effect of including the shaft friction in simulation was apparent in the steady state armature current of approximately 0.4 A, which was also observed in the physical prototype. The impact of the shaft friction was also apparent in the open-loop analysis of the controller (these results are not presented here). Overall, excellent agreement was observed between the simulation and experimental results, and with the presented co-simulation method, the embedded system code matched the code used during the simulation/design stage, thereby eliminating potential sources of error and increasing our confidence in the value of simulation as a design tool.

8. Summary This paper presented new co-simulation methodology that enables full system verification of mixed signal designs on a standard PC. A case study of a closed-loop DC motor drive was presented, which demonstrated that the co-simulation methodology can be used for insightful evaluation of a complete mixed signal application prior to creating a physical prototype. Furthermore, this methodology makes it possible to do complete system simulation using the exact same FPGA code which can eventually be used to target the hardware. The result is an improved design approach, reducing prototype iterations, improving digital design and speeding time to implementation. Excellent agreement was observed between the experimental and simulation results in the case of the DC motor drive. In our design the digital controller operated at 40 MHz with very low latency, while the analog drive circuitry was switched at a much slower maximum rate of 20 kHz. Since the analog switching frequency was a few orders of magnitude lower than the digital, modeling FPGA timing in simulation was not necessary. For designs with similar requirements, this new co-simulation methodology allows for rapid verification and implementation of high fidelity prototypes. In addition to the presented motor drive case study, co-simulation can be used for studying other complex dynamic systems with coupled dynamics that cross the domain boundaries between the digital software domain and the physical world, including switchedmode power supplies, grid-tied inverters, and vector control of AC machinery.

Appendix A: DC Motor Model and Parameters The equations that describe the behavior of the brushed DC motor model are [2]:

(A1)

where

and represent the resistance and inductance of the motor armature, respectively; is the motor torque; is the rotor and mechanical load inertia; is the shaft velocity; is the load torque; is the friction torque constant; is the angular position of the shaft; is the motor terminal voltage; is the back electromotive force (emf) constant; is the torque constant; and is the armature current. The brushed DC motor that was used in this study was the Midwest Motion Products D22-376D-24V brushed DC motor. The specs for the motor were supplied in the manufacturer‟s datasheet. The relevant parameters are summarized in Table A.1. The nominal motor parameters of Table A.1 were used in all simulations presented in this paper. The friction torque constant ( ) was not provided by the manufacturer and was not considered in the simulations; however, the static friction torque coefficient which was supplied by the motor manufacturer upon request was taken into account.

Table A.1: Datasheet parameters for the Midwest Motion Prodcuts D22-376D-24V brushed DC motor.

Performance Parameters Rated DC Voltage Rated Continuous Current Rated Speed Back EMF Constant ( ) Torque Constant ( ) DC Armature Resistance (@1.5 A) Armature Inductance Rotor Inertia Static Friction Torque1

1

Value 24 V 4.1 A 4700 RPM 4.5 V/kRPM 0.0431 Nm/A 0.94 Ω 0.85 mH 2.825E-5 Kg∙m² 0.0141231 N/m

The approximate static friction was provided by the Manufacturer upon request.

Tolerance ----± 15% ± 10% ± 10% ± 15% ± 15% -----

Appendix B: Power Switch Thermal Stress Analysis Without extensive design experience, using only a datasheet to determine the suitability of a power transistor for application requirements can be problematic if the switch performance outside a steady, continuous current mode of operation is considered. For instance, if the switch carriers a transient burst of current, a designer may be able to use the dynamic thermal impedance curves (or “Z-theta” curves) to predict the peak junction temperature, but only if the designer knows the case temperature [3]. However, unless a very large heat sink is used, few assumptions about the case temperature should be made. Another complication comes from switching losses, which at high frequencies contribute significantly to the overall losses, raise the junction temperature, and further de-rate the device Fortunately, simulation models and tools can aid with the analysis in a way that considers the coupled dynamic interaction between the electrical and thermal domains. In this case, highfidelity SPICE models of the gate driver and the switches are available. If long simulation times were acceptable, it is possible to analyze the stress on the switches in a transient simulation that models the exact application scenario. However, for faster results a simplified worse application scenario was analyzed. If in the worst case scenario the switches are within operating limits, then it should be expected that the switches will satisfy design requirements during less stressful modes of operation. This was the approach taken. In this approach, the end goal was to calculate the peak junction temperature and to ensure that it was below 125 °C, which would indicate that the device is operating within safe operating limits. Based on the curves from the feasibility tests, a simplifying assumption was made that any one of the switches conducts current only during the 0.7 second transient when the motor is either accelerating or decelerating. This assumption was made because the overall motor load is completely dominated by inertia (when the speed is not changing, the load from the inertia is zero and therefore only enough current will flow to overcome friction and maintain constant speed operation). It was also assumed that during the 0.7 s transient the controller would exercise the switches in a way that produces both switching and conduction losses. To simplify the analysis a theoretical worst case scenario was assumed. First, it was assumed that switching and uninterrupted conduction losses accrue throughout the entire 0.7 s transient. Second, it was assumed that switching losses occur at the maximum expected current of 13.5 A operating point throughout the period. And finally, it was assumed that the MOSFET drain-source resistance was at the design limit value of 125 °C. The analysis procedure is only discussed for the P-channel MOSFET. In order to construct a simplified circuit to calculate the worst case junction temperature, worst case turn-on and turn-off losses first needed to be determined. To accomplish this, the circuit of Figure B.1 was constructed and analyzed. The gate driver, U2, and P-channel

MOSFET, U9, were modeled using high-fidelity SPICE models provided by their respective manufacturers. In addition to modeling electrical behaviour, the P-channel MOSFET models the thermal behavior and self-heating of the device package. For this test, the P-channel MOSFET was assumed to be operating in an environment with an ambient temperature of 25 °C through a heat sink with a thermal resistance of 60 °C/W (a typical value if the device case is mounted to the printed circuit board).

Figure B.1: A high-fidelity circuit designed to analyze the worst case turn-on and turn-off losses of the P-channel MOSFET.

Using very small time-steps to capture the details of the switching events, a transient analysis was run and the turn-on and turn-off switching losses of U9 were recorded for one switching cycle. These are shown in Figure B.2.

Figure B.2: Worst-case expected switching losses.

The electro-thermal circuit of Figure B.3 was then constructed to measure the junction temperature. Thermal network VIds

Vds

Tjunction Rsink 60C/W

0V U2 Icond

Rds 35mΩ

P_cond

P_sw

R-C I = { I(vvids)*v(vds) }

Tambient 25C

I = { v(P_sw)*v(isActive) }

P_sw

isActive

V1

V2 0V1V 0.7 sec 7.4 sec

Figure B.3: Simplified electro-thermal circuit for determining junction temperature

The important elements of the circuit are: 

 



Icond models using a piece-wise-linear current source the armature current which was recorded during the feasibility test. This current is injected into the switch, modeled as a simple Rds resistor, for the 0.7 s transient. No current is injected during the remainder of the 7.4s period when the motor is expected to be at steady speed or accelerating in the opposite direction. This current can be seen in Figure B.4B. P_cond is a controlled current source that calculates and injects the conduction losses into the thermal network. V1 is a piece-wise-linear voltage source that places on node P_sw a voltage signal that represents the turn-on and turn-off power losses recorded using the high-fidelity models (Figure B.1) and is used by current source P_sw. The losses are repeated at the switching frequency of 20 kHz. V2 is a periodic voltage source that places onto node isActive 1V for 0.7 seconds, and 0V for 6.7seconds. This is the same duty cycle and period as the conduction current in source Icond. The voltage is used as a boolean by P_sw to blank out the injected switching losses during the time when no current flows through the switches (i.e when the motor is at steady speed or is accelerating in the opposite direction) This is shown in Figure B.4C.

 

P_sw is a controlled current source that injects the switching losses into the thermal network. U2 contains an RC ladder that represents the thermal network of the switch. It was taken directly from the high-fidelity switch SPICE model. The goal was to run a transient analysis until: 1. The voltage on the node “Tjunction”, which represents the junction temperature, stabilizes. 2. To ensure that its peak value is below 125 °C (represented using Volts).

A transient analysis was conducted over 70 seconds. The junction temperature is shown in Figure B.4A. Because the junction temperature did not exceed 120 °C, the switches were deemed suitable for the application.

Figure B.4: Results of key signals following a 70 s transient analysis.

References 1. Brian MacCleery, Zaher M.Kassas. New Mechatronics Development Techniques for FPGA-Based Control and Simulation of Electromechanical Systems. Peer review paper published at IFAC 2008, the International Federation of Automatic Control World Congress. July 2008. 2. Krause, Paul C., Wasynczuk, Oleg and Sudhoff, Scott D. Analysis of electric Machinery and Drive Systems, Second Edition. Piscataway : Wiley-IEEE Press, 2002. 3. Divins, David. Simulation MOSFET Heating Caused by Inrush Currents. Power Electronics Technology. June 2007.