Buck Converter Thermal Model
This example models the thermal dynamics of MOSFETs in a synchronous buck converter. It matches the structure of the Buck Converter with Thermal Dynamics model. Omitting the electrical switching dynamics allows the simulation to take much larger time steps, dramatically reducing the amount of time it takes for the simulation to calculate steady-state temperatures for the MOSFETS.
The average losses during switching cycles are needed to determine the heat that the MOSFETs produce. This is obtained by running the detailed BuckConverter.mdl model which postprocesses the logged data and saves the losses to workspace variables P_MOSFET1 and P_MOSFET2. The simplified thermal model can then be run, and the final temperatures of the MOSFETs are saved to workspace variables T_junction1, T_case1, T_heatsink1, T_junction2, T_case2 and T_heatsink2. Re-running the detailed model using these temperatures as the starting conditions yields a more accurate result for the behavior of the system since the device characteristics depend on temperature.
Model
Simulation Results from Simscape Logging
The plot below shows the temperature of the MOSFETS over time. Running the simulation for a long period of time enables the steady-state temperatures to be determined. The final temperatures of this simulation can be used as the starting conditions for a detailed electrical simulation where the device characteristics depend on temperature.
Results from Real-Time Simulation
This example has been tested on these platforms:
Speedgoat™ Performance real-time target machine with an Intel® 3.5 GHz i7 multi-core CPU and 4 GB RAM.
dSPACE® SCALEXIO LabBox with Intel® Core XEON E3-1275v3 at 3.5GHz and 4 GB RAM.
You can run this model in real time with a step size of 30 microseconds by using the Simscape local solver. For small sample rates, a task overrun might occur during the initial task execution due to a cold cache. To avoid this overrun, if the selected platform supports these options, relax the start-up behavior by specifying a limited number of task overruns or increasing the sample time of periodic tasks during the start-up phase of the real-time application.
