Challenge

Design of an Electric Vehicle using Simulink

  • Final Project: Design of an Electric Vehicle

I. OBJECTIVES

  1. To create a MATLAB/Simulink model of an electric car that uses a battery and a DC motor using suitable blocks from the Powertrain blockset of Simulink. The report for the model shall be prepared including the following:

    a. Model parameters

    b. System-level configurations

    c. Results

    d. Conclusion

II. BRIEF INTRODUCTION

  • The powertrain of a Battery Electric Vehicle (BEV) consists of an electric drive system with a battery serving as an energy buffer. Often there is only one electric machine (DC Motor), connected to the wheel shaft via a gearbox and a differential. However, some applications may utilize several electric machines, e.g., hub wheel motors. The energy is stored chemically in a battery, which is electrically connected to the machine via a DC/AC power electronic converter accompanied by a control system. The control system controls the frequency and magnitude of the three-phase voltage applied to the electric machine, which depends on the driver’s present request, which is communicated via the acceleration and/or brake pedal.

  • In the case of vehicle applications, it is usually desirable to keep the physical volume of the electric machine down. This can be done by designing it for higher speed levels. A reasonable compromise is a maximum speed between 12 000 to 16 000 rpm since it serves as a good compromise between volume and performance. Still, during normal on-road driving the speed range of a vehicle may vary between zero to about 130 km/h or even higher at times. This means that the wheels will spin up to around 1200 rpm or higher. Therefore, a reduction gear ratio toward the wheels is inherently needed. Additionally, to give the left and right traction wheels a chance to spin at slightly different speeds during turning, there is also a need for a differential to be connected between the wheels. Sometimes the differential also includes a final gear ratio. A typical BEV drive system is depicted in Figure 1.

    Fig.1. Typical schematic of an EV

III. CASE STUDY

  • Simulink Model - Electric Vehicle Model (with DC Motor)

    Fig.2. Simulink Model for our EV
  1. Model Parameters:-

    For this project, we have considered the vehicle model parameters of the TATA Nexon EV Max.

    Vehicle Specifications:

    `"Kerb Weight"` `=` `"1400 Kg"`
    `"Payload"` `=` `"100 Kg"`
    `"Coefficient of Rolling Resistance," μ_( r r)` `=` `"0.015"`
    `"Frontal Area"` `=` `"2.9" m^2`
    `"Coefficient of Drag," C_(D)` `=` `"0.18"`
    `"Acceleration Time (0 to 100 kmph)"` `=` `"9 sec"`
    `"Hill Climb Angle"` `=` `"0"^circ`
    `"Transmission Gear Ratio"` `=` `"9.1:1"`

    Vehicle Performance Calculations:
    We use our excel calculator for the propulsion power requirement calculations.

    Fig.3. Excel Calculator
    From the above calculations, it is clear that the maximum propulsion power required is 141.5 kW. If we calculate the Torque value based on this, we will get 1019.38 Nm.

    DC Motor Calculations:
    Since we know the input torque of the motor used in the Nexon EV Max, 250 Nm, we can calculate the highest output torque at the transmission;
    `"Output Torque" = "Input Torque"xx"Gear Ratio"xx"Transmission Efficiency" = 250xx9.1xx0.95`
    `:. "Output Torque" = 2161.25 Nm`
    Hence, the motor is more than capable of handling these torque conditions.
    Based on the given specifications of the motor by Tata Motors, we can calculate the full load speed;
    `"Motor Speed " = ("Power"xx60) / (2pixx "Torque") = (105000 xx60)/(2pixx250) = 4010 RPM`

    Tire Calculations:
    From the specifications, the Nexon EV Max uses tires with the code - R 16 215 / 60 LRR.
    Therefore, with an aspect of 60% and a width of 215 mm, the rim diameter of the wheel should be 16 inches or 0.4m.
    Also, Tire Height = Tire width x Aspect = 215 x 0.6 = 129mm.
    So the final rolling radius is evaluated to be 0.332m. We will assume the Load Index to be 99 (1709 lb).
  2. System-Level Configurations:-

    [A] Drive Cycle Source:

    The Drive Cycle Source block generates a standard or user-specified longitudinal drive cycle. The block output is the specified vehicle longitudinal speed, which you can use to:

    • Predict the engine torque and fuel consumption that a vehicle requires to achieve desired speed and acceleration for a given gear shift reference.

    • Produce realistic velocity and shift references for closed-loop acceleration and braking commands for vehicle control and plant models.

    • Study, tune, and optimize vehicle control, system performance, and system robustness over multiple drive cycles.

    For our study, we have chosen two drive cycles as follows;

    I. WLTP Class 2 (1477 seconds)

    Fig.4. WLTP Class 2 Drive cycle

    II. EUDC (400 seconds)

    Fig.5. WOT Drive cycle
    These drive cycles can be switched whenever necessary. For this purpose, a Multiport Switch block is used which changes the input of the drive cycles.

    [B] Longitudinal Driver Block:
    The Longitudinal Driver block implements a longitudinal speed-tracking controller. Based on reference and feedback velocities, the block generates normalized acceleration and braking commands that can vary from 0 through 1. You can use the block to model the dynamic response of a driver or to generate the commands necessary to track a longitudinal drive cycle.

    Fig.6. Longitudinal Driver Block

    I. VelRef - Reference Vehicle velocity that is directly connected with the Drive cycle output.
    II. VelFdbk - Longitudinal vehicle velocity in the vehicle-fixed frame, or, feedback velocity from the vehicle.
    III. Grade — Road grade angle (constant input in our case)
    IV. AccelCmd — Commanded vehicle acceleration
    V. DecelCmd — Commanded vehicle deceleration

    [C] Control Subsystem:

    Fig.7. Control Subsystem

    - Controlled Voltage Source Blocks
    The Controlled Voltage Source block converts a Simulink input signal into an equivalent voltage source. The generated voltage is driven by the input signal of the block. We use two of these blocks to provide output signals as directed by the output from the Longitudinal Driver block for Acceleration and Deceleration commands respectively.

    - Controlled PWM Voltage Block
    The Controlled PWM Voltage block represents a pulse-width modulated (PWM) voltage source.
    Electrical input ports — The block calculates the duty cycle based on the reference voltage across its ref+ and ref- ports. This modeling variant is the default.
    PS input — Specify the duty cycle value directly by using an input physical signal port.

    For the Electrical input ports variant of the block, the demanded duty cycle is

    `(V_(ref) - V_(min))/(V_(max) - V_(min)) *100 %`

    where:

    • Vref is the reference voltage across the ref+ and ref- ports.

    • Vmin is the minimum reference voltage.

    • Vmax is the maximum reference voltage.

    The value of the Output voltage amplitude parameter determines the amplitude of the output voltage.

    At zero, the pulse is initialized as high, unless the Pulse delay time parameter is greater than zero, or the demanded duty cycle is zero.

    For a 100% duty cycle, the input voltage is set to 0.01V for accurate mapping of the output signals from the driver block.

    Fig.8. Controlled PWM Block Configuration

    - H-Bridge Block
    The H-Bridge block represents an H-bridge motor driver. The block can be driven by the Controlled PWM Voltage block in PWM or Averaged mode. In PWM mode, the motor is powered if the PWM port voltage is above the Enable threshold voltage. In Averaged mode, the PWM port voltage divided by the PWM signal amplitude parameter defines the ratio of the on-time to the PWM period. Using this ratio and assumptions about the load, the block applies an average voltage to the load that achieves the correct average load current. The Simulation mode parameter value must be the same for the Controlled PWM Voltage and H-Bridge blocks.

    If the REV port voltage is greater than the Reverse threshold voltage, then the output voltage polarity is reversed. If the BRK port voltage is greater than the Braking threshold voltage, then the output terminals are short-circuited via one bridge arm in series with the parallel combination of a second bridge arm and a freewheeling diode. Voltages at ports PWM, REV, and BRK are defined relative to the REF port.
    + — Positive Load Connection port
    - — Negative load connection port
    PWM — Pulse-width modulated signal (associated with the pulse-width modulated signal. The voltage is defined relative to the REF port)
    REF — Reference (associated with the floating zero volt reference)
    REV — REV (associated with the voltage that controls when to reverse the polarity of the H-Bridge block output. The voltage is defined relative to the REF port)
    BRK — BRK (associated with the voltage that controls when to short circuit the H-Bridge block output. The voltage is defined relative to the REF port)

    The output signals from the Driver block are mapped in mV. This means that the change in acceleration or deceleration is measured at smaller magnitudes of voltage. Hence, the input threshold voltages for the H-Bridge shall be set to 0.01 V for accurate control of the DC motor.
    Fig.9. H-Bridge Block Configuration

    - Current Sensor Block

    The block represents an ideal current sensor, that is, a device that converts current measured in any electrical branch into a physical signal proportional to the current.

    Connections + and - are conserving electrical ports through which the sensor is inserted into the circuit. The connection 'I' is a physical signal port that outputs the current value.
    The output signal from this block will be used to measure the SoC of the battery.


    [D]
    DC Motor Block:


    This block represents the electrical and torque characteristics of a DC motor.

    The block assumes that no electromagnetic energy is lost, and hence the back-emf and torque constants have the same numerical value when in SI units. Motor parameters can either be specified directly or derived from the no-load speed and stall torque. If no information is available on armature inductance, this parameter can be set to some small non-zero value.
    + — Positive terminal
    - — Negative terminal
    C — Motor case
    R — Motor rotor
    We can configure this block with the values we had previously calculated in the parameters. According to the parameters, the Rated Speed is given as 4010 RPM, Rated Load is set to 105 kW, and the DC supply voltage is kept as 320V.

    Fig.10. DC Motor Block Configuration

    [E] Vehicle Subsystem:

    Fig.11. Vehicle Subsystem

    - Simple Gear Block
    The Simple Gear block represents a gearbox that constrains the connected driveline axes of the base gear, B, and the follower gear, F, to corotate with a fixed ratio that you specify. You choose whether the follower axis rotates in the same or opposite direction as the base axis. If they rotate in the same direction, the angular velocity of the follower, ωF, and the angular velocity of the base, ωB, have the same sign. If they rotate in opposite directions, ωF and ωB have opposite signs.
    B — Base (Rotational mechanical conserving port associated with the base, or input, shaft)
    F — Follower (Rotational mechanical conserving port associated with the follower, or output, shaft)
    As per the model parameters, the value for the gear ratio is set to 9.1:1.

    - Tire (Magic Formula) Blocks

    The Tire (Magic Formula) block models a tire with longitudinal behavior given by the Magic Formula [1], an empirical equation based on four fitting coefficients. The block can model tire dynamics under constant or variable pavement conditions.

    The longitudinal direction of the tire is the same as its direction of motion as it rolls on the pavement. This block is a structural component based on the Tire-Road Interaction (Magic Formula) block.

    To increase the fidelity of the tire model, you can specify properties such as tire compliance, inertia, and rolling resistance. However, these properties increase the complexity of the tire model and can slow down the simulation. Consider ignoring tire compliance and inertia if simulating the model in real-time or if preparing the model for hardware-in-the-loop (HIL) simulation.
    For our model, we utilize 4 of these blocks to simulate the wheels of the car. Each block is configured with the exact same values as mentioned in the parameters section. Also, the front and rear tires are connected in pairs respectively. The gear is connected with the front axle for power delivery.

    Fig.12. Tire Block Configuration

    - Vehicle Body Block

    The Vehicle Body block represents a two-axle vehicle body in longitudinal motion. The vehicle can have the same or a different number of wheels on each axle. For example, two wheels on the front axle and one wheel on the rear axle. The vehicle wheels are assumed identical in size. The vehicle can also have a center of gravity (CG) that is at or below the plane of travel.

    The block accounts for body mass, aerodynamic drag, road incline, and weight distribution between axles due to acceleration and road profile. Optionally include pitch and suspension dynamics. The vehicle does not move vertically relative to the ground.
    In the block, we input all the necessary values as mentioned in the parameters section. The Tire blocks are connected with the respective ports.

    W — Headwind speed, m/s (Physical signal input port for headwind speed)
    beta — Road incline angle, rad (Physical signal input port for road incline angle)
    V — Longitudinal velocity, m/s (Physical signal output port for vehicle longitudinal velocity)
    NF — Front axle normal force, N (Physical signal output port for normal force on the front axle. Wheel forces are considered positive if acting downwards)
    NR — Rear-axle normal force, N (Physical signal output port for normal force on the rear axle. Wheel forces are considered positive if acting downwards)
    H — Horizontal motion (Conserving port associated with the horizontal motion of the vehicle body. All tires are connected to this port)

    Fig.13. Vehicle Body Block Configuration

    [F] Battery Subsystem:

    Fig.14. Battery Subsystem

    - Controlled Current Source Block:

    The Controlled Current Source block represents an ideal current source that is powerful enough to maintain the specified current through it regardless of the voltage across the source.

    The output current is I = Is, where Is is the numerical value presented at the physical signal port.

    The positive direction of the current flow is indicated by the arrow.
    The current signal from the control system determines how this current source behaves with how much flow of current.

    - Battery Block:
    The Battery block represents a simple battery model. the voltage is a function of charge and has the following relationship:

    `V = V_o ((SOC)/(1-beta(1- SOC)))`
    As per the given data for the battery pack of Nexon EV Max, the capacity for it is 40.5 kWh operating at 320V. This means that the Ampere-hour rating is 126.56 AHr. These values are added to the block.

    Fig.15. Battery Block Configuration

    [G] SoC Estimation Subsystem:

    Fig.16. SoC Estimation Subsystem

    The above subsystem is the SOS estimate block where the rate transition, gain, and discrete-time integrator is connected in series after that this series is added with a constant block. This arrangement gives us the SOC and is known as the Coulumb Counting Method. Despite having its downsides, this method is apt for our study of the SoC.

  3. Results:-

    In this project, we have evaluated three results which go as follows for the respective drive cycles:

    I. WLTP Class 2 (1477 seconds)

    A. Actual Speed vs. Drive Cycle

    Fig.17. Plot for Actual Speed vs. Drive Cycle

    From the above plot, it is evident that with the given model parameters and configuration, our model can handle the drive cycle conditions in this case. Though the model cannot mimic the drive cycle perfectly, it does a good job of mimicking it. We can observe that model traces the plot efficiently during acceleration and constant speeds. There are slight inconsistencies during the deceleration phases due to the regenerative braking effect.

    B. State of Charge (Battery)

    Fig.18. Plot for the SoC of Battery

    From the above plot, we can study the battery behavior for the given conditions. In general, with this drive cycle, the battery is depleted by approximately 10%. We can see that during deceleration phases, the battery is being charged due to regenerative braking. Since we haven't tuned the regenerative braking, the program uses default settings to charge the battery.

    C. Distance traveled by the Vehicle

    Fig.19. Plot for the SoC of Battery

    Our vehicle model traversed a distance of 14.68 KM with the WLTP Class 2 drive cycle.

    II. EUDC (400 seconds)

    A. Actual Speed vs. Drive Cycle

    Fig.20. Plot for Actual Speed vs. Drive Cycle

    From the above plot, it is evident that with the given model parameters and configuration, our model can handle the drive cycle conditions in this case. The model fails to trace the drive cycle at higher speeds, presumably due to low motor speed or high gearing. Other than that, the model works as speculated.

    B. State of Charge (Battery)

    Fig.21. Plot for the SoC of Battery

    From the above plot, we can study the battery behavior for the given conditions. In general, with this drive cycle, the battery is depleted by approximately 3.7%. We can see that during deceleration phases, the battery is being charged due to regenerative braking. In this case, the simulation time is less making the distance traveled small which results in lower battery consumption.

    C. Distance traveled by the Vehicle

    Fig.22. Plot for the SoC of Battery

    Our vehicle model traversed a distance of 6.95 KM with the EUDC drive cycle.

  4. Conclusion:-

    The following points are drawn as conclusions from this project:
    1. An Electric Vehicle powertrain was designed and the required parameters were documented.
    2. From the simulation results, it is clear that if we can't exactly get the real-time results, we can still serve the purpose by considering the assumptions.
    3. Satisfactory results were acquired from the model and were documented.

IV. REFERENCES

  1. Tata Motors Website - Tata Nexon EV MAX - Moves You To The Max (tatamotors.com)
  2. MathWorks Help - Simulink Documentation - MathWorks India
  3. Chalmer's University Student Thesis - EmmaGrunditz_PhDthesis_lowrez.pdf (chalmers.se)
Your portfolio, next

Ship work like this
in your own course.

Talk to a career counsellor

Free 20-minute call. We'll map the right course to where you want to work.

By submitting you agree to our Terms and Privacy Policy.

Talk to a career counsellor

Free 20-minute call. We'll map the right course to where you want to work.

By submitting you agree to our Terms and Privacy Policy.