MODELING TECHNIQUE OVERVIEW

FIGURE 1

The model in figure 1 represents the proposed motor model and it's interface with the overall HEV simulation.  Currently the simulation is to run "forward facing", where the driver model requests a specific speed and torque in response to a driving schedule.  The requested torque will already include compensation for traction, grade, and inertia/ mass effects.  The torque is fed into the drive system and any inline component unable to meet the desired torque reduces the request and iterates the routine.  If the torque request reaching the motor is a negative value then the motor acts as a regenerator (example: for recovering braking energy).  In regenerative case, the maximum current ratings and efficiencies are different than for "motoring" operation.  The code must compensate for this and will further work as a generator only device.

The HEV code will incorporate a customizable vehicle control model (deciding when to use the battery or a combustion engine, etc.).  For maximum flexibility, the motor algorithm must be as "dumb" as possible.  For example the driver model might request a torque and speed to accelerate the vehicle.  The vehicle controller model might be configured either to blindly accelerate or might work to follow the most efficient path to the desired speed.  Also regarding the level of the motor model, any velocity change in the motor from a torque is dependent on externalities such as the vehicle mass and driveline inertia.  This means speed is a function of the overall vehicle model and is an input to the motor model.

The mechanical torque output in the model (figure 1) starts with a DC electrical input from the power bus that transports battery and generator power to the controller.   Physically the bus is simply a conduction path.  The bus voltage is subject to a drop depending on the amount of current drawn by the motor and controller.  The drop depends on bus I²R losses and power sources (example: internal losses in the battery).  The motor controller must decide how to efficiently allocate current, voltage, and frequencies to obtain the requested torque.  Available bus voltage and current affects this process.  For example, in a separately excited DC motor, the motor controller must decide how much voltage to apportion the stator winding versus the armature.  The maximum available voltage will drop as more current is drawn and if the simulation time-step is too large, a loop would properly simulate this.  The true vehicle would have a controller and motor that are preset to operate efficiently.  Most high-end controllers also maintain winding temperatures to prevent overheating of the motor by limiting output proportional temperature overage.  The controller model simulates this by monitoring the maximum temperature in the 2d thermal model.

The current will run through the winding resistances that change according to the temperature model.  The I²R losses of the windings will then be fed back into the thermal model.  The hysterisis and eddy current losses will also be fed into the thermal model.  The developed torque from the electrical model is reduced by the mechanical model losses.  These include bearing friction and windage losses.  The formulas regarding the loss depends on air temperature read from the thermal model.  The result is a net torque output that is passed back to the HEV software.  The inertia of the motor itself is included in total driveline inertia.

FIGURE 2
The thermal model in figure 1 uses axis-symmetry to reduce the three dimensional model to a flat-plat problem for WinTherm to solve (shown at the left in figure 2).  Since the thermal solver is an iterative process this is much faster than attempting to solve a three dimensional model for each HEV time step.  Each motor from the database catalog will segment the flat plate into the different components of that type of motor.  For example an induction motor would have regions for the frame, end windings, teeth/embedded windings, back iron, the shaft, cooling passages, the air gap, etc. (See figure 2.)  Each region would have a proper thermal conductivity and for regions such as cooling passages, the temperature would depend on an external heat exchanger model.  Heat fluxes would be applied to the appropriate. 

The two-dimensional model frame will map to a three dimensional CFD duct-flow code as shown in figure 2.  There will be some provision on the motor model setup to simulate fins on the geometry.  Solving flow and conduction in/around actual fin elements is a waste of resources as they simply contribute surface area for the CFD convection calculation.  The purpose of the duct model is to evaluate the heat exchange at the surface of the motor.  Cooling vents and fans would be modeled as boundary conditions in CFD cells near the motor.  Some motors use liquid cooling and a heat exchanger.  The motor model would use the heat exchanger model to predict cooling passage heat flux and map appropriate temperatures on the 2d thermal model.  Also included in the duct will be the motor controller.  The losses in the controller are less than the motor, but quite significant.  The controller cooling is accomplished with fins or liquid.  It will be modeled as a geometric entity with a single node heat source in the duct flow code.  A series connection in liquid cooling between the controller and motor might be required depending on the configuration being simulated.

FIGURE 3
The losses for the motor and controller must be evaluated at each time step.  This means that losses must be reduced to equations that distribute heat loads accordingly.  Motor manufacturer literature is typically in the form of a single efficiency map for the motor/controller combination.  The simulation will have a separate geometry for the controller, which means that the heat loss must be divided between motor and controller.  The efficiency the controller closely shadows that of the motor.    There is more loss in the motor, but a percentage of the loss can be assumed as the controller loss along with the controller's standby power requirement.  This allows the appropriate division as shown in figure 3.

The motor efficiency map is fitted to the loss equations.  The reason for this is that obtained manufacturer data will not be sufficiently detailed to describe changes in motor performance due to such things as temperature.  The equations used will vary depending on the type of motor (induction, synchronous, etc.)  Once the coefficients are determined, then these can be stored in a file to describe the motor without storing the discreet points.  The controller efficiency could potentially be curve fitted in a similar matter.

SAMPLE MOTOR SCREENS