Developing DC-DC Converter Control in Simulink - MATLAB & Simulink
Video Player is loading.
Current Time 0:00
Duration 52:42
Loaded: 0.31%
Stream Type LIVE
Remaining Time 52:42
 
1x
  • descriptions off, selected
  • en (Main), selected
    Video length is 52:42

    Developing DC-DC Converter Control in Simulink

    Overview

    In this webinar, we will use a SEPIC circuit topology to show how to model and simulate a DC-DC converter that powers a strip of LEDs. Using Simulink® and Simscape Electrical™, MathWorks engineers will show how to develop, simulate, and implement a controller that maintains desired output voltage in the presence of input voltage variations and load changes to achieve fast and stable response. The control algorithms will be used to generate embedded code optimized for implementing on a Texas Instruments™ C2000™ microcontroller. The demonstration will conclude with hardware-in-the-loop (HIL) testing of the microcontroller using a Speedgoat real-time target machine.

    Highlights

    • Modeling and simulating passive circuit elements, power semiconductors, and varying power sources and loads
    • Simulating the converter in continuous and discontinuous conduction modes
    • Determining power losses and efficiency of the converter
    • Tuning the controller to meet rise time, overshoot, and settling time
    • Generating C code from the controller model for implementation on a Texas Instruments™ C2000™ microcontroller
    • HIL testing using a Simscape Electrical model deployed to as FPGA implemented in a Speedgoat real-time target machine

    About the Presenter

    Vasco Lenzi is a senior application engineer at MathWorks Switzerland. He specializes in design automation with emphasis on multidomain modelling, control design, verification, and deployment. He collaborates with industrial automation and machineries, automotive, and medical companies. Prior to joining MathWorks in 2016, Vasco worked as a development engineer on the modelling and simulation of engines at Liebherr Machines Bulle. Vasco also worked as a control software developer for electric supercars at EVTEC. He holds a B.S. in mechanical engineering and an M.S. in energy sciences from ETH Zurich.

    Recorded: 20 Jul 2021

    Hi, everybody. My name is Vasco Lenzí, and I'm an application engineer with MathWorks. Thank you for registering for this seminar, Developing DC-DC Convertor Control with Simulink. So you can forget all about this presentation, but there are 3 things that I want you to take away. One, you're going to see how we provide graphical programming across our solution, which is very intuitive and powerful.

    This combination allow multidisciplinary teams to work together and to facilitate the design and the verification of complex systems. All of this, of course, with the goal to catch designer errors early and cut down development costs while increasing delivered quality. This is for me the essence of model-based design. And we're going to see today an example with a power electronics application.

    Our project today is to model, simulate, develop, and design software for a SEPIC converter, a Single-Ended-Primary-Inductor Converter. You can see here a development board from Texas Instrument with a (TI) C2000 control card, which powers strips of LEDs. Now you may wonder, basically, what you're going to tell us is just to power some light on and off all the time. This doesn't seem like a very complex application.

    While I agree that this may be a simplified version of what happens in reality, even something as simple as powering light on and off is getting more complex as we speak. Let me present to you ZKW Lichtsysteme, a German company, which developed a system for a headlight. An LED headlamp projection technology, which combined with motors, allows them to selectively shut off certain LEDs and focus the [? zoom ?] of the LEDs in different directions in order to avoid cars getting blinded by your bright LED light.

    So even something that was very simple, powering on and off the light of your car, is getting really complex and involves now motors, and machine learning, to detect a car that [? are ?] coming, and complex control logic to make sure everything works correctly. This is a very nice story. There is a 2 page by Speedgoat, our partner for Real-Time system, that I suggest you to read if you're interested in this topic.

    Today we are going to go through 5 different stages of model-based design. First, we model the converter, calculate the most efficient operating region. Then, we determine power losses and the thermal behavior of the converter in order to size cooling system appropriately. We are going to design control algorithm based on time/frequency domain specification. And we are going to see how we can do this with switched linear system, an optimal solver setting.

    We will design very simple supervisory logic and implement unit testing in order to make sure that everything works as it should. Finally, we are going to implement our design on an embedded platform, such as one of Texas Instrument that we showcased earlier. But let me give you the last point first now as a demonstration. You see, on the top left corner, there is the artwork.

    On the right, I clicked on the button, Deploy to Hardware. When I click that, I'm using the hardware support package, which provides the driver and all the connectivity I need to automatically package the design I developed in Simulink as an application for Texas Instrument platform. This will automatically be uploaded after generating code. And then, thanks to external [? mode, ?] I will be able to see how my system behaves.

    Right now, I'm stimulating my system with random pulses, on and off, for my light. And you can see on the bottom left corner, I'm regulating the current with 60 million per. On the right, I'm trying to keep my voltage of my converter to 18 volt, because I know this is the region where my convertor operates most efficiently. What is really nice is, as you can see, the control system is not performing too badly.

    It's not easy for [? them ?] to react every time I power, on and off, my LEDs, but is actually quite stable. In all the value I used for my PI controller, but for the current and the voltage, are derived from a tuning technique in simulation. I didn't change them once deployed to the hardware. And still they are behaving very well.

    Our first task is going to be to model the converter and calculate the most efficient operating region. The converter is split up in 3 parts. There is the power supply, the converter itself, and the load. We can see here. Now this has been represented in Simulink using 3 different subsystem and some connection between them. But before jumping into the model, let me quickly go over some way that we can represent a physical system with our solution.

    A lot of you may be familiar in using Simulink equation to write them and solve the [? ODEs ?] directly using the block diagram in Simulink. Some of you may already know Simscape, which is our platform for physical network and connecting components together. And the system-level equation is generated automatically by combining together all these different components in one go.

    Lastly, if you have measurement of your system, you can always import them and derive a data-driven model, usually called as well, black-box model. And the nice thing about having all these 3 possibilities and more is that you can combine them. You're not forced to stay in one kind of solution mode. You can have a part of your model as an identified model, some of it as a physical network, and some of it as equation in Simulink.

    Let's take a look at our SEPIC model. As we saw in the slide, we have a view of our system. The convertor should work with a frequency of 100 kilohertz, so medium high. The LEDs on the other end are going to work at 20 kilohertz, the power supply is 12 volt. The operating region of the LEDs, by specification of Texas Instruments, are between 17, more or less, and 20.5 volt.

    So if I open up my SEPIC converter, I'm going to notice that I have 4 different system, three of them [? grey ?] out. I'm using what is called Variant Subsystem. Here I have my controlled converter, which is a perfectly ideal converter, which is just represented with some kind of time constant. And always keep the voltage at the right level, at the output. So this can be incredibly useful for system-level simulation because it's very fast.

    On the other hand, I have other variant of my implementation. I have a steady state convertor. I have an average SEPIC. And I have my SEPIC circuit, which I am going to focus right now. If I look inside, I see that I have all the typical component, such as inductance and capacitor. And I linked actually the datasheet, which is present online, directly to my model. So that it's easier for me to find again the right documentation.

    Just a quick [? excuses ?] on the differences between inductances in the foundation library. If I open up, I see I have only 2 parameters, more or less, and the source code so that I can go and see which kind of equation are implemented under the hood. So this allow me to start from this component, change it if I want, and have my own version of the inductance. I always define any kind of equation using the Simscape language.

    On the other end, I'm using the [? datasheets ?] provided by Simscape Electrical, the dedicated toolbox for electrical and power system. In this case, you can see I have tolerance. I could even apply a random tolerance for my system if I want to perform some kind of Monte Carlo analysis based on the tolerance changing.

    I can set operating limits in my inductance. I can set fault. So I can break down my inductances when I want, how I want. And all of these allow me to increase the level of fidelity of my simulation and do more. But as you can see, this time you don't have access to the source code.

    Let's go back to my SEPIC subsystem and look at this small rectangle here. These are test harnesses. Let's open up one of them. In this test harness, I'm doing a step between 0% and 61% of my circuit, and I'm measuring the output by comparing with some measurement that I've taken on my oscilloscope. So I'm simulating for 700 millisecond.

    The swtiched linear system, so I am simulating all the switches at 100 kilohertz. And you can see that the simulation time is quite fast. This is happening because I'm using [? Odin, ?] which is a software, can be forced to [? access ?] a certain point. In combination with a special PWM block that you can retrieve as well in using your models from these files that you're going to get access to after the seminar. The entire project would be available to you.

    So in this case, in this PWM, you are generating our carrier wave. And we are simulating at a certain frequency, this kind of input in order to force timestep to take the appropriate step at the right point, my carrier wave. If we look then at the simulation result with the timestep present, for instance the diode current, we can see that we are actually taking timestep only when needed by the simulation and no more.

    So we're really simulating entire 100 kilohertz, which is why we're doing that in a very efficient way. We are only switching when it's necessary. There is one time in the middle, which is the point of my [? support ?] of my carrier wave. And the current is modeled as a switched linear system. This is great. It allow me to simulate quite fast. And I can then compare how my model is compared to the reality.

    We can see that I have captured most of the element quite accurately, rising time, the settling time, voltage, and then the slowing-down time when I shut off my PWM. Very well, but this is not going to be my modeling of choice because I want to investigate efficiency. In order to investigate efficiency, I would like to work with actual physical devices, optical MOSFET physical devices models.

    If I go in it, I see that this time I'm using the Simscape Electrical PVM because it's connected to our actual end-channel MOSFET. This can be parametrized by a parameter that you can find in datasheet. And with the right click you can access at multiple options. You can either change the block choice, so if you don't want a threshold-based model or you want to add a thermal port to it. You could do it by accessing or right clicking on this menu. Or you could use it to generate basic characteristics.

    This case is going to do under the hood automatically instrument these MOSFET to this parameter. And generate automatically a typical plot that we can find on a data sheet here for my MOSFET. If I open up the actual data sheet and scroll down to search for the plot, I can then just graphically compare it and see if it matches yes or no.

    We can see that we are doing quite a good job. Here is the eight voltage line, which is settling down around a bit more than 10 ampere after around two or three voltages. We can see here that we have very similar behavior by our MOSFET. You could actually use certain tools from the file exchange to import directly this kind of plot into Simulink and then use them to better parameterize your model as well.

    Let's go back to our model and look at the second test harness. First, I need to close the one I used to simulate and compare it to my measurement. And afterwards, I would like to open up the one called the efficiency test. In this case, I'm simulating a closed loop model. I want my model to reach a certain voltage, that's why I have a very simple PID block here.

    And they change the value of the resistor to get a specific current going in so that I can create a grid of specific voltage from 12 to 30 volt and a specific grid of current from 0 to 2 ampere. And in creating, I create more or less hundreds of operating point that I would like to test. And I instrument my model to stop the simulation if I reach the appropriate voltage.

    Afterwards, when I simulate it, and I can simulate in parallel using the parallel Computing Toolbox to gain even more time, I could use functions such as get efficiency to it to define which components are going to be to load and feed them the simulation result. So I can get the efficiency of my converter at any operating point based on the load.

    I can do the same for the power dissipated. And I actually prepared this as a script and saved my result. If I run this, I will lower already my result showing you the kind of map that you can actually create.

    Here, we have my converter operating region the one defined by Texas Instrument. We can see that it actually working around very high efficiency, with the point up to 92 maybe 93%. And we can see how the converter behaves in the rest of the operating region. So these are the kind of things that you can instrument your model using this a function such as get efficiency, to analyze your circuit and see if where and how you should operate your converter. If you are not happy, you can change your parameters such as inductance capacitor you let it run again hopefully, in parallel because it will speed up a lot this kind of investigation and recreate automatically these kind of maps.

    Let's go back to our presentation. What we saw now is a Simscape. It's a platform to model a physical system and in particular, we saw Simscape electrical inaction which is the toolbox in addition to Simscape to modern electric grid and power system. Simscape offers Simscape language in order for you to start from the basic blocks and make your own block so that to capture exactly the kind of behavior you want to represent.

    Very brief excuses on what's new in Simscape Electrical. You have two block now, and more are coming such as the Stepper motor and the battery, which have been pre-parameterized using value from the industry. We can see the batteries. You can put the battery in your system and automatically pick up some of the cell available on the market pre-parameterized at different temperature levels. So this is going to really speed up the development of your electrified system if you're looking into batteries.

    We have added even more possibility to generate fault not only at the component level. But you can do fault during dynamic load to delta connected, y-connected, and so on. So we are really investing a lot in be able to break your model, make it foldable whenever you want and however you want.

    We can use a very similar methodology to determine the power losses and determine behavior of the converter. You may have noticed when I ran my script, the second plot popped up. In this plot, I'm showing the average power losses of the MOSFET in that over the different operating region I simulated with my parallel simulation and the average power losses of my diet.

    You can see that the MOSFET is losing a big motor with almost 16 watt by high voltage and high current. The diet is a bit more difficult. We can see that actually, the power losses are very much dependent on the current and not so much of the voltage.

    We can reuse these tables in software free in a specific model built up for thermal stimulation. You can see here I feed my voltage and current as a desired operating region. I'm recalculating the power losses using a lookup table and then feeding them in a physical letter which replicates my passive cooling system. And my heat flow, watt generated by the MOSFET.

    I have some thermal masses due to the mass of the junction. I have a connection to the case, as well as some thermal mass, which has a connection to the head sink. My passive head sink then has her convection with the ambient temperature. There is no active cooling. This is simply a passive system based on the ambient temperature.

    I can quickly change to my operating region like around 18 volt and one pair. And then I can simulate for up to an entire day. You can see 2600 second for 24 hours I can run.

    The simulation will be instantaneous. It's a very simple model, but this can be incredibly powerful technique for the engineers, which are creating or assessing or sizing the cooling system for your power converter. We can see here that our expected operating region we actually are going to be around 318 voltages for the MOSFET and 218 kelvin of temperature for the MOSFET. 228 Calvin for the diode, which is acceptable it's more or less 47 degrees.

    So of course, it's the entire day with a lot of current. But it doesn't heat up too much. So we may be fine with a passive cooling system. I used a new probe block to get the temperature. You can use it for any kind of physical system. You double click, you pick a block and then you gotta get access to the other variables that are inserted in this block.

    So this is a very convenient technique that allows you to build up a network and avoiding to instrument everything with sensor. This has been introduced in release 2028. Now of course, if the passive cooling is not enough, your colleagues, which are working on the cooling system may need to search for a fan to start blowing air actively on the headsink. Maybe you need some heat exchanger as well.

    So we provide a lot of these blocks and allow that your team to work truly on the entire engineering aspect. Not only on the power electronics, but on the cooling, sizing the cooling and the cooling control. So this is what we think when we say that we provide truly a multi-domain simulation environment for a multidisciplinary team to work on.

    So as a recap, we saw you can use the function get power loss summary to create your table of power losses from MOSFET and diet. You can create a very fast implementation of your cooling system using simply the power losses at different operating point. We have an example for switching power supply thermal if you want to take a look at it.

    And we actually have a new function as well to high fidelity of your switching devices. We add the most of it and we parameterized the MOSFET based on the data-sheet. But more and more, you can import existing models you may have in SPICE directly to Simscape using the function subcircuit2ssc. This will from a net-list, automatically create a circuit component based on the SPICE meta-list.

    We pushed this that right now, we introduced SPICE models for our switches such as the SPICE-imported MOSFET. And we provide some selection off the shelf for certain types of MOSFET, such as the one from infinium. This is repeatable work for you as well. So we provided the conversion assistance. And of course then you can validate these conversion by generating the characteristics and comparing with LTspice.

    So we now get to the fun part. My background is control engineering and I'm always happy when I can do some control design. What I would like to do is design our control algorithm and tune it based on time and frequency requirement. So this will be for the voltage part. For the LEDs, it will be very similar. But we would like now to do it for the voltage control of our SEPIC.

    And we are going to use a different approach to what you usually see in our videos. This time, we're going to use as a plant model, a switched linear model, which cannot be linearized. And we will need to create a transfer function equivalent model and then tune it based on our requirement. Let's see this in action.

    So I prepared here second model to talk about this. We have here our Simscape model. And actually, since I'm using subsystem reference, which you can recognize is one of the two corners being cut. The top left and the bottom right, I'm referring to an external file called SEPIC_Circuit. This is a very powerful technique that allows me to reuse complex system using different files.

    This can be very useful when you're working in larger team and somebody needs to develop a specific version of a sub-component. Doesn't want to use a library, doesn't want to work within a huge large single file for version control reason. So you can actually break down your physical model using a subsystem reference.

    Let's take a look at this in our documentation. It's a very interesting technique for when your system starting to get really big and you want to split it out in multiple files. Now, here, I have my controller. It's not only the PI, there is some switches as well depending on if I enable the closed loop or not, the ability to output only zero maybe for safety reasons shut off everything, and a saturation as well.

    Here, I'm using one of our off the shelf PI block, which have the ability to tune a plant. Let's see first our result without any tuning. So I just used value from my gut instinct, from my past experience. I'm using the other technique with the specific PWM block that we have. And we can see that we can simulate 100 milliseconds at 100 kilohertz. Quite fast, actually. This is usable for controlled design purposes.

    We can see that our system reacts and then there is a huge overshoot. We go up to 33 volts and this is not good. We would like to have a much more smooth approach, no overshoot at all. And let's get this tuned.

    So as you may know, if you have Simulink control design, you can actually click the tune button and it will be trying to linearize the plan, everything that is after the block. And in this case, it's going to fail. It's going to fail because we are using a switch linear system with our ideal MOSFET and piece-wise linear diet. But still, they create something that cannot be linearized since that is on and off, on and off, on and off. You cannot fix on a specific operating point to get a new plant model.

    So what you're going to do? Well, we're going to do what we suggesting. We can use the plant menu to create, or select a new plan and we're going to click on identify new plan. In this case, we're going to use that we fully integrate system identification toolbox within the system tuner app. So we need just to provide it from IO data. And in this case, I can have it from my experiment, or I could simply simulate them.

    Let's change the view to a single one just to see my system identification view. And here, I can generate my step function that I want my system to simulate. I do the step at 10 milliseconds and I stop the simulation at 100 millisecond. And I will step up to around 61% of duty cycle.

    Here, right now, this is my test vector. And I'm going to automatically split the system to an open loop step test to 61% of duty cycle. I'm going to read the error. And now, while I start, I will explain they're going to need to simulate 3 times 1 with the 0 open loop. One zero. So in order to get the right offset to take away so that they can calculate actually, the plant response.

    So now, this is going to take some second. But still, thanks to the fact that we are simulating using this approach, and the solver is forced to take a step at the right moment. This is actually not going to take a lot of time.

    This, as I said, combines effectively to two logs in one app. System identification toolbox and the Simulink control design. We're going to see when the system is done. We're are going to have to open the response to this open loop test as an output signal. Yes. It seems ready.

    Now, it needs to simulate for the last time. And then it's going to be able to recalculate the output of our plant just by the error and with appropriate input. And now, we have it. We can see the output, we can apply and use this input output response to our system identification. We can close this simulator data and go back to the plant identification.

    We can see a very nice interactive way to create a transfer function based on our input/output. Here now, I see that they have some kind of delay here. So I may want to add a delay with one pole structure, then I can click out the estimate.

    It's going to use the algorithm in the system identification tool box to provide me with a good approximation, but I can see that is not as good. This is true because the system is slightly more complex to be able to approximate with a one pole transfer function. So let's put two poles.

    Click again on Auto Estimate. There, we can see that we can reach a very good approximation this epic, well-known system. It can be approximated with a triple pole with some delays.

    We have now, very good match for our input/output. And again, this works with any kind of converter design. So if you have your custom design, you don't need to spend time driving average system equation in order to do Control design and be able to linearize your system. You can use any design as you have it, implement this kind of fast of linear simulation, use system identification technique and get back your transfer function.

    We can take a look at our transfer function. So we apply this as our new plant. And then we can go back to our reference tracking and see that this time, it's going to work. We can see that we are using this ID proc identified system. Double-click on it, we can see how the transfer function looks like.

    And this can actually be used to retrieve any kind of transfer function approximation as I said, when it kind of converted topology. So we would like to be way more robust. We don't want any kind of overshoot. And we are happy maybe to be a bit slower. We don't need a lot of speed. We are happy if we can reach there 40 millisecond, but without overshoot.

    So right now, we can update the block. And then we can see how the system behaves. Close it. This will have the new value in it. We can simulate and see our system is behaving right now.

    You can see that actually, it's way better. It's behaving like we expect. And this is what I did and these were actually the result that you saw live in my video of the demonstration. I was simply using the same value I calculated using this technique. It's a very powerful technique.

    So what are we seeing? We tuned based on a system identification technique integrated in the PID tuner app. Works at any topology, any kind of a converter. Just requires this kind of switch-linear simulation.

    And even better, we now have for a lot of converter, actually direct the average switch option. So if you don't want to use this energy efficient technique, or if you're ever working with the traditional DC-DC converter we provide for you, a lot of blocks from 620 which are average off the shelf, which can then be linearized and used in your controlled design without problems.

    We're right now at the point where we would like to design some supervisory logic incrementally testing, without getting really confident about our design. Let's get back to the tool. I prepared here a model which representing my operating mode and error logic.

    So designing power converter software is not only about PI tuning, but just one part of it. There is an entire spectrum of software construct that you need to implement to get a very stable system-- such as state machine, supervisory logic. You need to deal with errors and what happened when errors reported to your system. And a very powerful tools to do that it's called State Flow, for state machine modeling and development.

    Here, I prepared such a thing as an example. This sub-chart is called operating mode management. And we can simulate and see in action live. So at the beginning, we would like to have our system output nothing at all. And then we have two parallel chart, which are taking care of the operating mode. We saw them highlighted briefly.

    So you may want to work with open loop. You may want to work with a current voltage open loop, but current closed loop. Or vise versa closed loop for the voltage, open loop current. Everything is closed loop, or in some kind of automatic operation, which at first you are open loop. And then you're waiting for the voltage to settle. And when you're acting with the error of the voltage, you actually go into closed loop mode.

    So this is something that may be very common technique to model state machine to power converter. Again, we have our checking faults sub-system, which runs parallely to the other one. So always check if our system is OK, or not.

    In order to test this state machine, I've created again, a unique test using Simulink test. I used one of the provided logic and I'm not going to spend a lot of time on this because this is a topic mostly for Simulink test interest. But I break my loop using a unit delay and I can do that because this is a discrete system, not a continuous one.

    As I said before, for discrete system, it's OK to use that unit delay to break the loop. And I have a test sequence which allows me to write fairly complex test sequences to stimulate my chart. So for instance, I can have my input change. And then I can react to this change with some kind of verify or other statement that I'm going to validate my design.

    We can see it here. So we have our input, our output. I can specify transition and I can add description of what I would like to do during this time step. And then I can always use this verify statement to see OK, I would like to go in this desired operating mode. And after one second, I will verify that the two outputs are actually behaving as the requirement that they are for this operating mode.

    So if I simulate here now, I will see that there are some slowing down. And if I look at my diagnostic, I will see that I am really some kind of warning in it. And one of them will be that there was this slow down because that certification failed at around 4.2 seconds. And again, at 5.3, and 6.4, 7.5.

    I have all these verification failed because of this step. So I could click here and go verify why this tape actually failed. It failed to verify that the zero output enabled should be false. But in reality, it was probably still true.

    And if I look at my data inspector, I can retrieve directly the result of this verify statement here. And I have, for instance this one and I see that when I try to do it fast, that's all fine. But in this case, some of them were actually wrong.

    And here, we can see that 4.2, I have this zero output enabled. Should be false, but it was actually wrong that means that my zero enabled stayed true instead, of being false. I can automatically generate a report from my data inspector that document these kind of processes.

    So let's go within my operating logic. And I see that actually yes, my checking fault is always true. And it's never going to false. And this happens because I don't have an actual something that tells me to have a system, which is OK. So I add now the transition. When I should go to OK? Well, I should go to OK when my flag fold exist is zero so there is no fault.

    So here, I'm writing this node-- flag fault exists should be zero. Then I have in a system, which enabled my-- OK. Which disabled my output, and this enables the 0, only 0, as an output. So I would like to have something else, not zero.

    And here again, I should put a condition that if the flag is back on, we could actually be like this because it's a Boolean. So I don't need to put any kind of transition. If it's true, is going to be on this fault. So I can repeat my test right now and see what happens this time.

    I can actually open up my step here, and I can see how it's doing everything at a different step of my test. Very convenient. Very similar to Stateflow itself. And now, I have no diagnostic.

    If I look at my data inspector, I see that all my results, everything were either untested, or passed. But I don't have any faith anymore. A lot of green and I'm happy about that.

    So let's go back to our presentation. What we saw is third way to model graphically, called Stateflow. You can use this to model state machine. And it's very powerful and in the company and complement well Simulink and Simscape as a three main platform for graphical modeling within the Simulink world we can say.

    Discovered as well that we provide Simulink test that allows you to create this kind of unit testing. You see here something I didn't show, the test Manager. All these harnesses that you provide to different subsystem can reuse the model level, or can be put together in a sort of test in order to be done automatically with automatic reporting.

    You run the test, you get your result, document it, and you provide an example that say, look, I did my job as an engineer. Here is the report that proves that I tested as much as I could. You can add coverage measurement and start really getting these verification and validation workflow going.

    Now, it's the moment to talk a bit about implementation and how to implement electronic controls on an embedded platform. I go back to the Simulink. And I will show you this model that I called application software.

    In this model, I created my software architecture so to speak, which I was using model reference. I'm calling other models that implement certain algorithms. For instance, some limits to my current supervisory logic that we saw partially in the operating mode management in Stateflow. The closed loop control voltage and the closed loop already controllers.

    You can see different colors here. The colors are associated with the specific timing, step, so that we can already at a glance, see which subsystem and different model are working at which rate and how they interact with one another. I can then go to the app step, open up the embedded coder app.

    And if I don't know exactly how to start or which one is going to be my hardware platform, I can quickly start the quick-start from the embedded coder. It's going to analyze the system. You can specify which kind of code you want to generate this C, AUTOSAR, C++, C++ AUTOSAR. How many instances. So you want to use while it's going to be some reuse.

    It's going to analyze the model, see how many sample rates are in our system if there are any continuous states that can implement that. And in the end, it's going to ask me if I want this to be a multitasking rate monotonic system. Or if I have a single tasking with the fastest execution time where they want to prioritize execution, or RAM.

    And in the end, it's going to suggest me some new value for my parameter on the code generation. You can see it here already, we have 22 parameters. In reality, there are hundreds of them that you can parameterize in order to get exactly the code that you wish. And for the embedded coder, that is very much suggested to take one of our training.

    Now, one new things that we implemented is the ability to look at coded model by side by side with the code interface. Here, I can select my code interface. And then the code will pop up here on the side and allow me bidirectional traceability between the model and the code. If I go back to my closed loop control system and if I instance pick the switch, the code here we automatically go to the C code generated for this sub-system.

    And I will see the switch actually, how this is going to be implemented. This one is implemented, where I can find the single part of my code name will may be more interested. It's a great way to learn how the embedded generation works and to quickly see how my parameter configuration is going to affect the generated code.

    If I'm working with the development board such as the one that I have in for Texas Instruments 3000, I could actually go to the Add on tab, search for the type of hardware. For instance, here, I could search for C2000 and download specific hardware support package for embedded coder.

    There are for C2000, but there are for a lot of other platforms such as SDMI, and arm processor, raspberry, whatever you like. So really, there is a lot of hardware supported. And this give you driver blocks together with ability to generate the executable inflation directly from my embedded hardware.

    So thanks to automatical generation, we can deploy to any processor with best-in-class performance. Models can be generate structural text for PLC, or industrial computer can generate HDI code for FPGA. And they generate CUDA code for PPUs and embedded GPUs. Can as well generate C code, or C++ for embedded processor, or computer processors such as Intel, or AMD.

    This technology not only allows you to connect to hardware by flashing specific ports, such as the one from TI regardless of your package. But MATLAB and Simulink overall, they work very well with hardware together. You can directly connect oscilloscope, you can connect data acquisition devices. And you can connect your Simulink model with digital networks such as the one from OPC and CAN.

    You have dedicated toolbox for a lot of these hardware. So hardware what important to you, please take a look at all the different hardware that we support, make your life easier in your lab. Another thing is that when you start generating code, your project is getting into production. And then you will need professional capability to manage your file and your model.

    For this, you have a Simulink project, which allows you to connect the other five together in a single entity. With checks, such a Simulink project upgrade that will help you keeping always up to date with the latest release. Simulink project is a feature from basic MATLAB. Doesn't need any other toolbox.

    And again, within Simulink project, you can integrate virtual control and then you can easily access Simulink graphical model comparison emerge. This is being included with Simulink. Doesn't require an extra toolbox since 2017b. Before that, you would need to Simulink report generator. But we decided to take a step back and put it into the similar product by itself.

    So if you still don't have 17b, this could be a good reason. You don't need any additional toolbox, you can simply use Simulink project and get started with your analysis of your different version of your system.

    When we got to verification, we provide a lot of different things that you can do with automatic co-generation. One of this is software-in-the-loop, where they generate of your algorithm in your embedded in the closed loop simulation. So you can test if the generated code is functionally equivalent to the model. You could do processor-in-the-loop, or FPGA-in-the-Loop in which the algorithm is going to be flashed on supported boards.

    And then through connection, the processor will work on time step, will feed back the result to the simulation. And will do this non-real-time functional verification and will do performance profiling as well. So that you can actually accurately assess how performance is accurate and how many resources you have available.

    Third, is hardware-in-the-loop, where you have your algorithm working on your processor. And your plant model generating code from Simscape Electrical. It's still possible to generate code from Simscape as well, and put it on a real time machine. For instance, the one from Speedgoat. We actually asked my partner from its peak, Carlos Villegas and he provided me with this few slide in the example of hardware-in-the-loop for this SEPIC example.

    So Speedgoat is a associate company by MathWorks in Switzerland that provide real-time solution for hardware-in-the-loop and rapid prototyping. And here, we can see what they did with this model that they provided them. They used the Simscape to HDL technology to linearize the SEPIC different operating point. And then be able to flash it on the FPGA.

    So there is a work so that we offer that allows you to go from a Simscape model to HDL code. And then this HDL running on the FPGA allows us to test our algorithms still as 100 kilohertz PWM singal, which is very fast.

    So we need to have a very high resolution capture at 200 megahertz. And then to have the model running at least at 2 megahertz on our FPGA, something that they could achieve. And we can see here an example that they share with me in which they deploy first a model to the embedded targets, such as TI. And then I deployed the bitstream on the Speedgoat machine.

    Finally, you can see on the right there, oscilloscope, which is recording the different voltages. They are now going to increase the voltage. And we can see that the voltage reference is 18 voltage. And the voltage output is going to change to 18 voltage. And you can see the different voltages of the capacitor, or at the PWM signal. All captured, working at 100 kilohertz in hardware-in-the-loop.

    So that's another very interesting work in which you can reuse some of the model that you did, translate them to HDL, and provide so closed loop capabilities for high frequency switching system. You can see here now in the data inspector, how the system behaved. Almost exactly like I had in my simulation.

    This closed our session. Again, let me showcase what we work through these today. We modeled the SEPIC based on the hardware model from Texas Instrument. We programmed and tuned control logic and supervisory logic. We then generated C code and used the other support packages to bring it onto this hardware. Like we can see right now. This case, we could control the LED current to 60 million pair using parameters that we derived thanks to our control design tuning capabilities combined with system identification, so that we could use a high fidelity model with switched linear component in order to get the optimal parameter for my control design.

    An example of a customer using this workflow. ABB, very well known for the power conversion community. And what Dr. Robert Turner from New Zealand said is that simulation and co-generation enabled us to turn changes around quickly and eliminate human error encoding, and their developer productivity is easily increased tenfold. It is a strong statement by one of the leading power electronic company in the world.

    Let me conclude by repeating the three key takeaways. We have graphic programming, Stateflow Simulink across our solution, which are very intuitive and powerful. State-of-the-art technology, such as software and control design technique facilitated design and verification of this complex system. Developed by your team, which is by nature multidisciplinary. This will allow you to find design error early and cut down development costs while increasing quality.

    I would like to do a shout out to our power electronics control community on MATLAB center. You have their models, answer, how to videos, and the ability to interact with other power electronics experts, from MathWorks and from the industry. Thank you very much for your participation. And stay safe. Till the next time.

    View more related videos