Hybrid Electric Vehicle Demo for Simulink 7 Tour World (R2008a)
The system design of the hybrid electric vehicle
Before discussing HEV concepts, lets run the model and look at a GUI that shows us vehicle speed and milage based on a driver profile.
The first step in designing an HEV is creating an executable specification from the system requirements.
We can see the various components that we discussed laid out in Simulink 7 in a similar architecture to the diagram on the slide.
The synchronous generator and drive model is an interesting example of multi-domain modeling.
In addition to modeling the dynamics, we have modeled the mode logic using Stateflow.
Looking at the stateflow chart, we can see how Stateflow switches between the various modes automatically based on the brake or driver input while the vehicle response changes on the GUI.
At this point in a design cycle, the systems engineer can hand of the model to the various component specialists for further elaboration and detailed design.
This model shows us a more detailed implementation of a synchronous machine, which includes detailed power electronics, and detailed synchronous machine dynamics, including high-frequency switching.
The model also includes the original high-level Simscape component which will be used for validation by direct comaprison of the responses of the two components.
Simulink control Design, an add on for Simulink 7 was used to perform the control design, directly on the SimPowerSystems model using classical and modern linear control techniques.
Because all the design teams share a single environment, it is easy to do work in parallel and share models at various stages of elaboration.
This model has been modified to convert floating point to fixed point.
Navigate to the Speed Controller subsystem in the Fixed-Point Tool
Create plot that compares floating and fixed point
Notice how we were able to quickly override the data in the model to switch between data types without actually modifying individual block settings in the Simulink model.
So now that we have established that our conversion is not very accurate, lets use the fixed point autoscaling tool to improve our results
Navigate to the Speed Controller subsystem.
Now change Store results as: to ‘active’ and Data type override: to ‘local settings’, then run the model and view the comparison plot.
If you zoom in several times on the top plot, you can see the dotted nad solid lines are very close, ie the conversion was successful.
Now that we have converted the speed controller subsystem into fixed-point, we are ready to generate code. Processor-in-the-loop testing verifies the behavior of the object code running on the instruction set simulator or target processor.
2. Configure the 3rd party IDE based on your choice of target processors:
Freescale MPC5554, NEC V850:
Infineon C166, TriCore:
- Open the Target Preferences: Start -> Links and Targets -> Embedded IDE Link TS -> Target Preferences
- Select the C166 or TriCore configuration.
- Replace the ENTER_TASKING_PATH tokens with the path to your TASKING® installation.
3. Click on one of the blue blocks in the model to configured Simulink to connect to MULTI or TASKING with one of the following configurations:
For the MPC5554 and V850 instruction set simulators:
- You will see the Target Preferences block asking if you want to reset the option. Select No.
- Next, you will see the Embedded IDE Link MU Configuration dialog box appear for you to confirm the settings. Confirm the settings and then click OK.
For the TriCore and C166 instruction set simulators and hardware:
- Open the Target Preferences: Start -> Links and Targets -> Embedded IDE Link TS -> Select Preconfigured Target Preference Settings
- Select C166 -> c166_sim for the C166 ISS
- Select C166 -> xc164cm_hw_u_can for the XC164CM USB stick hardware
- Select TriCore -> tricore_sim for the TriCore ISS
4. Open the Model Explorer and confirm that the correct Model Configuration (C166, MPC5554, TriCore, V850) is selected.
5. Right-click on the Fixed Point Speed Controller subsystem and generate the PIL block. TASKING or MULTI is started and the PIL block is generated in a new model "untitled". The program is also downloaded into the simulator within TASKING or MULTI.
6. Now that the PIL block has been generated, we'll delete the original subsystem and plug the PIL block in to compare with the simulation.
7. And now we can run the PIL cosimulation. You should see the PIL cosimulation results being very close to the simulation results.
Once you stop the cosimulation, if you are running on an instruction set simulator on TASKING, you can see the coverage, profiling, and cumulative profiling reports by clicking on the links in the MATLAB Prompt.
One of the tradeoffs with model fidelity is simulation performance.
Fast forward to the end of the design cycle, we now have a complete system level model with controllers that have been prepared for fixed point code generation.
Let us briefly look at the components in the model.