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.