Automatic Code Generation and Conclusions | How to Develop DC-DC Converter Control in Simulink, Part 6

Now it's the moment to talk a bit about implementation. Now, to implement power 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 have a-- using model reference, I'm calling other model that implement certain algorithms, for instance, some limits to my current supervisory logic that we saw partially with the operating mode management in Stateflow, the closed loop control voltage, and the closed loop LED 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 Apps tab, open up the Embedded Coder Help, 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, C, C AUTOSAR, C++, C++ AUTOSAR, how many instances, so you want to use one or it's going to be some reuse. Going to analyze the model, see how many sample rates are in our system, if there are any continuous states that's implemented. 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, whether I 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, it is very much suggested to take one of our training.

Now one new things that we implemented, the ability to look at code and 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, for instance, make this switch, the code here will automatically go to the C code generated for this subsystem, and I will see the switch actually how this is going to be implemented, this one is implemented. What I can find the single part of my code that I may be more interested.

It's a great way to learn how the embedded code 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 for Texas Instruments C2000, I could actually go to the Add-Ons 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 STMI, an ARM processor, Raspberry, whatever you like. So really, there is a lot of hardware supported,

and this give you driver blocks together with the ability to generate the executable and flash it directly from my embedded hardware.

So, thanks to automatic code generation, we can deploy to any processor with best in class performance. Models can generate structural text for PLC or industrial computer, can generate HDL code for FPGA, can generate CUDA code for GPUs and embedded GPUs, can as well generate a 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 boards such as the One from TI regardless 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 integrated toolbox for a lot of these hardware. So if hardware is 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 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 files together in a single entity with checks such as 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 and Merge. This is being included with Simulink, doesn't require an extra toolbox since 2017B.

Before that, you would need the Simulink report generator, but we decided to take a step back and put it into the Simulink 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 go to verification, we provide a lot of different things that you can do with automatic code generation. One of these is Software-in-the-Loop, where we generate code of your algorithm and 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 to connection the processor will work runtime step, will feedback the result of 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 Simscale 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 Speedgoat, Carlos Villegas, and he provided me with these few slide and the example of Hardware-in-the-Loop for this SEPIC example.

The Speedgoat is an associate company by MathWorks in Switzerland to provide real-time solution for Hardware-in-the-Loop and rapid prototyping. And here, we can see what they did with this model that I provided them. They used the Simscape to HDL technology to linearize the SEPIC at different operating

point and then be able to flash it on a FPGA. So there is a work flow that we offer that allows you to go from a Simscape model to HDL code.

And then this HDL code running on the FPGA allows us to test our algorithms still as 100 kilohertz PWM signal, which is very fast. So we needed to have a very high resolution capture at 200 megahertz, and then to have the model running at least at two megahertz on our FPGA, something that they could achieve. And we can see here an example that they share with me in which they deployed first a model to the embedded target, such as TI, and then I deployed the bitstream on the speed machine.

Finally, you can see on the right their oscilloscope, which is recording the different voltages. They are now going to increase the voltage. And we can see that the voltage reference is 9 dot-- or 18 voltage, and the voltage output is going to change to 18 voltage, and you can see the different voltages of the common capacitor or at the PVM signal all capture working at 100 kilohertz in Hardware-in-the-Loop.

So that's another very interesting work 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. Can see here now in the inspector how the system behave almost exactly like I had in my simulation.

This close our session. Again, let me showcase what we worked through these today. We modeled the SEPIC based on the hardware model from Texas Instruments. We programmed and tuned control logic and supervisory logic. We then generated C code and used the other support packages to bring it onto these 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, which switched linear component in order to get the optimal parameters for my control design.

An example of our customers using this workflow, ABB, very well known for the power conversion community, and what Dr. Robert Turner from ABB New Zealand said is that simulation and code generation enabled us to turn changes around quickly and eliminate human error in coding and their developer productivity is easily increased tenfold. These are strong statement by one of the leading power electronics company in the world.

Let me conclude by repeating the three key takeaways. We have graphical programming Stateflow Simulink across our solution, which are very intuitive and powerful, state of the art technology such as solver and control design technique, facilitated design 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 my top center. You have their models, answer, how to videos, and the ability to interact with other power electronics expert from MathWorks and from the industry. Thank you very much for your participation, and stay safe till the next time.