Using Simulink to Develop Grid-Tied Solar Inverter Controls

Hi. Welcome to this webinar. We'll be using Simulink to develop grid-tied inverter controls. My name is Carlos Villegas, and I am the electrification industry manager at Speedgoat. I'll be presenting together with Jonathan LeSage, a senior application engineer at MathWorks.

Before starting, let me walk you through a few logistics. If you have any problems hearing the audio or seeing the presentation, please contact the webinar host by typing in the chat panel. Or if you have questions during the presentation for myself or Jonathan, please type them in the Q&A panel. We'll answer them at the end of the presentation. Thank you.

In our agenda, we'll be defining hardware-in-the-loop testing and then have an overview of the control development process. Then we'll go through the main control design task that aim at capturing power from the solar panels and also protecting the grid. We'll then describe the automatic code generation process, and finally, we'll have a hardware-in-the-loop testing demonstration.

There are three main takeaways from this presentation. First, that you can use Simulink, Simscape Electrical, and Speedgoat hardware for developing controllers for power electronics, and we use models from desktop simulation to real-time testing. Second, that you can generate C and HDL code directly from Simulink and Simscape Electrical, both for production code and electrical plant real-time testing. And third, that you can use hardware-in-the-loop with Speedgoat hardware to thoroughly test control hardware for normal operating conditions and also fault conditions.

In this session, we are going to show how to design a controller for a solar inverter, have that running in an embedded microcontroller, and thoroughly test its operation using virtual plant by means of hardware-in-the-loop testing. For these, we are going to use Simulink and Speedgoat as a common development platform. We are first going to design and optimize a controller using electrical simulation tools. Then we'll generate code automatically for the plant simulation, including green inverter and solar panels. Then we'll also automatically generate C code to the microcontroller.

We now can thoroughly test our grid-tied inverter for normal and fault operating conditions. We'll present a hardware demonstration to illustrate testing, including solar power generation and great synchronization. We'll also show how to include switching dynamics.

Before getting started, let's quickly introduce Speedgoat. It was started by former MathWorks employees in 2006. Speedgoat is a MathWorks associate company, with subsidiaries in the US and Germany and distributors worldwide. Speedgoat provides real-time target computers that are expressly designed to work with Simulink, and therefore with the MathWorks product portfolio. The real time systems are developed by a core team of around 200 people, both in MathWorks and Speedgoat. And this team works closely with the rest of the MathWorks organization.

So what is our goal? Primarily, we want to design a system with power electronics hardware and controllers. This requires designing controllers and designing power electronics hardware, or the plant. These devices will then be connected by a combination of digital and analog signals to achieve the desired design goals. The process of designing systems like this is far from simple, and it's riddled with many challenges. Hardware-in-the-loop testing can greatly improve this design process.

Another key goal is to protect the utility grid. Grid codes help to prevent cascading faults from many small generation facilities. With the influx of renewables, more grid codes have been added around the world for compliance. Simscape Electrical allows for quick testing against different grid codes, including custom codes. These codes apply voltage and frequency considerations, a result in solar facility is having to supply sometimes excess reactive power during grid voltage events. These are scenarios that can be tested in simulation and then converted into software.

And before we start discussing hardware-in-the-loop, let's first define it. Hardware-in-the-loop replaces the power electronics with a virtual simulation. The controller operates as if it was connected to the real system. So why should we consider hardware-in-the-loop testing? Well, you can replace prototypes or production hardware with a real-time system. You can also use it, as it's easier to automate testing and test fault conditions. There are many destructive faults that are much easier to replicate in simulation.

Speaking of faults, it is much safer also to work with virtual systems than with high voltage systems. Preliminary work can be done in the hardware-in-the-loop setup before transitioning to the power level. And perhaps most importantly, it allows you to start designing and testing at an early stage without having to wait for the hardware. This can also help you to catch bugs at an early stage when it is cheaper and easier to fix them.

We will be using model based design. We then start with the requirements of the grid-tied inverter. Then we generate an electrical model, including the power electronics, the grid, relays, inverter, et cetera. We design our controller within this environment. Our goal is to test our controller with our real hardware prototype, in this case, a grid-tied inverter. As a first step, we can generate code to a Speedgoat target computer. Speedgoat target computers are designed to easily tune, test, and deploy controllers from Simulink.

Then we can generate optimized code to a microcontroller. Before connecting our grid-tied inverter to a hardware prototype, we use hardware-in-the-loop loop testing to thoroughly evaluate our control software and our control hardware. Once all tests pass, we can safely connect to the real hardware.

The basic steps that we will be carrying out today are plant modeling, the control design of the maximum power point tracking, the current control, the phase lock loop, et cetera. Then once we have our controller, we'd automatically generate C and HDL code to the TI C2000 microcontroller and Speedgoat hardware. And then we will carry hardware-in-the-loop testing. So now that we have an overview of the required steps, Jonathan, could you show us how to use Simulink to design a controller, not only to optimize the power output but also to protect the grid?

Thank you, Carlos. My name is Jonathan LeSage, and I'm an application engineer with The MathWorks. My job today is to walk us through how we can actually build a representative model of a utility scale solar system in Simulink and then use that model for control design tasks, both on the power electronics side and then also on the power systems side. These types of utility scale systems have layers of control tasks, and we'll talk about that in more detail.

But firstly, we're going to focus on the modeling aspects. And so if we break a utility scale PV system into its main components, what we really have is the array itself, or the panels, the three phase inverter, which is taking that DC output of the panels and converting it into three phase AC wave forms, and then some kind of point of connection to the utility grid. These are the three main components. Now if we were to rebuild this model in Simulink, we'd drag and drop these blocks out of the Simscape Electrical library to construct up all three of these main stages.

Let's hop over to Simulink and take a look at what the simulation could look like. So what I have here on the screen is that same kind of representative model with a few additional functionality and components, mainly for visualization and instrumentation. I'm going to go ahead and hit the Run button and start this simulation. You'll see we have the blocks that represent components like the solar panels, the inverter, also the grid point of connection. But there's other components as well, such as the controls.

Right now, this utility scale solar array is actually islanded. It's not connected to the grid. I'm going to throw the switch, and we can see the reaction as this solar facility connects to the grid. Now I'm going to actually inject a fault, and we can see how these control schemes that we've designed react to faults on this system as well. And so that's the power of simulation. I have a representative system here that lets me test my software before I take it to an embedded system, like the TI C2000.

So with that, let's take a look at how we can do controlled design. One thing that I like to emphasize when I'm talking about power electronic systems that also connect into power systems as well, such as this utility scale solar application, is that there are many different layers of control strategies that have to be implemented. And so really these control strategies will range from the very fast, so focusing on the power electronic side and looking at switch mode control, wave form generation. These are control loops that are going to be operating at incredibly high speeds, and when we're doing things like hardware-in-the-loop testing, will often need to be deployed to FPGA type solutions to do testing. For a lot of grid connected applications and even for power electronics, there are many applications where that level of fidelity isn't necessary, especially if we're looking at voltage or frequency control loops or other control strategies, like maximum power point tracking for the solar array or reactive power support for fault ride through conditions.

These situations, we can use things like average volume models and drastically speed up our simulation speeds. And then finally, simulations could also involve very long time spans for things like energy market participation. So having a single model that can allow you to slide between all of these different fidelity modes really helps validate the control strategies for many different applications. And so one of the things I want to emphasize today is that using Simscape Electrical, we can use full switch mode fidelity or use average value approximations or even go to phase or RMS type of simulation, as well, if we need to go to that level.

All right. So the first control design task that we're going to tackle for this system is the control loop that's actually controlling the DC voltage on the solar panel on this side of the inverter. Really the goal here is we want to construct a feedback loop that measures the PV panel voltage. We have a reference voltage that we want that PV panel to be set at. And then using PID control, we're going to actually come up with the duty cycle, feed that to a PWM generator, and that's actually going to go to our inverter. The reason that we're doing this is, of course, the PV panel itself for some given load is going to have a maximum power point. So once we know what that maximum power point is, the voltage that that occurs at for a given load, we want to make sure that we set the panel to that voltage.

So let's hop over to Simulink and take a look at what this example would look like. So I've got my same utility scale solar facility model here. I've removed a few things just to simplify. Inside the grid inverter, you'll see that essentially the input to this block is the duty cycle. So Uref is our duty cycle input for each of the phases. Now I could have this switched over to switching devices. That means I would be simulating the full switch mode, and that input would be the PWM waves instead of the duty cycle. So again, going back to different levels of transience for different types of simulations, you can switch

between them given what you need to do. Because we're focused on that voltage control that's at a lower rate than, say, the high frequency switching, we can use the average value approximation in this case.

Going over to the inverter controls, we've got these low level controls here that are focused more on the individual access control for direct and quadrature. What we're focused on is that DC loop. So again, just like the schematic that I showed in the slide, we're measuring the DC voltage off the panel. We have a step, or reference in this case, that we want this voltage to be, and PI loop. And so I can run this simulation just like we've done before.

These are the full grid level responses that we're looking at. But really if we're focused just on the PV voltage here, we can see that it tracks OK. There's some overshoot. And so we could potentially want to improve this. And the way that we can do that is double-click on the PID. We can come in here and of course, adjust these gains by hand, if we want. Or we can use tuning methods, so automated tuning methods using MATLAB and Simulink's control design capabilities.

And so by using that tune button, that will open up our PID tuner. It will allow us to start to adjust the response time. So if I wanted to speed this up, we can see the change in response, and you'll notice that as I speed the response up to a certain point, we start to see the hints of instability, right? So we're approaching the stability margin as we push the speed of this controller. And this is of course, a full digital controller. It's got time steps associated with it. And so that's why you see this digitization.

If we like this response, we can update the block and send that back. And then do a full simulation with this again. And so in this case, I'll dial this back a little bit. Get that response. Maybe we can look at the frequency domain as well. Get an idea of what the loop shape is of the system, and have more confidence in the controls that we're designing.

Now that we've designed a controller that can set the reference voltage on the PV panel and thus help us get to the maximum power point, what we want to do is actually modify that controller so that we can actually be grid connected. And so if we were to take a look at the actual schematic that we just built, same exact schematic as before, but now we're going to have an additional input that will either generate a wave form. So if we're islanded with no reference to the grid, we can just generate a wave form, and that's the tracking waveform we have. Or we can actually use something like a phase lock loop to track the frequency and phase of the grid and match that so that we can then connect a breaker to actually synchronize up this utility scale solar system with the grid.

So let's take a look at what that would look like in simulation as well. All right. So I have our same model here. And if I go into our inverter control, you'll see that we've added a little bit more here. We've got the current regulator. We've got basically the PQ priority, and here you'll see there's the DC regulator. There's some additional stuff here for maximum power point tracking. We'll talk about that next.

But really what we have here is a phase lock loop block here that's measuring the voltage of the grid. And then we're going to use that to synchronize up. And so basically we look at the grid voltage and then our current output of our inverter, and we want to drive those two to zero, basically match the voltage curves. And we can use a PID loop to do that. Once we've actually matched, the breaker can be thrown, and then we go back to our standard voltage control that we designed before.

So let's take a look at that in action. I've actually got the plot here of the grid connections. This is our inverter current output. And then down here, the blue wave form that you're going to see is going to be the inverter voltage, and then the yellow is our grid wave form. So you see we're slowly converging, and then at about 0.2 seconds, they're matched enough that we actually close the breaker. And now we're

actually grid connected and producing current. And so that's essentially how a good connection works. And so as long as we have a measurement that allows us to use the phase lock loop to match the frequency and phase, we can synchronize up and then close the breaker. All right.

Now that we've been able to design a control loop that lets us control the PV voltage and also a addition to that loop to allow us to connect to the grid, we're going to focus on maximum power point tracking. This is actually what's going to be providing that voltage reference to the control loops that we've already designed. And really, the goal of maximum power point tracking is to ensure at all the different operating conditions of the panel and the loading conditions on it that is operating and producing the most power.

And so just a brief little description of it. Essentially panels have these nonlinear power output curves with respect to their voltage, and these curves, of course, change location and size given the irradience. So of course, the higher power output is possible for higher irradience, more sun on the panels. But that maximum power point of that is also going to shift, so it's not a constant PV voltage that's going to produce that. And so essentially, we need an algorithm that can seek out and find these maximum power points given any kind of operational conditions, different irradiences or different loads on the solar panels. And that's the goal of maximum power point tracking, to find those at that point. Once we found that, that would be the voltage reference that we provide to the next loop down the line.

And so there's many different ways you can implement this, many different algorithms for maximum power point tracking. For this particular example, we're using a perturb and observe type of routine that actually goes through and seeks out the maximum power point. So you'll see here that's the current maximum power. There was an irradience change, and so now we're lower. And after some time, you'll see that this starts to converge back to the maximum power output. With a state chart like this, you do get a visualization of how this routine is working. And if you're interested, we do have a full webinar to talk in a lot more detail about these methods.

So what we've done so far has been focused primarily on the freestanding, individual solar facility. We haven't really talked about how we need to add an additional layer on top of the controls we've already created to account for grid code requirements, such as fault ride through. Carlos introduced this topic, and essentially we have grid codes that are going to dictate how long we have to remain connected to the utility grid during faults to provide things like reactive power support during a voltage event, for example. And so there's many different ways we can do this.

In this case, we used a state machine again to measure that and compare, so we're grid connected in this case. And now we're actually encountering a fault where in this voltage fault ride through scenario, we're actually providing extra reactive power. And then the simulation can continue. Now what's interesting, and if I hop over to Simulink here, is once we've encountered this voltage fault, you'll notice that I have this function here, voltage ride through, and we're providing the current grid voltage and then how much time has elapsed after that. And this is how we can basically see where we are on the grid code requirement using lookup tables. And if we're in the range where we must remain connected, we stay connected and provide that reactive power support. So this is how this can work.

Now to check these things, of course, you can use blocks as well. And so we've built some blocks that help test for common grid code requirements, such as 1547. These add a block where you can provide the voltage, the output of your simulation, and it will see where you are on the grid code. It's a great way to check and confirm that your control strategies are performing as you expect. Now with that, we've gone through a lot of the control design techniques that we need to do to build and implement this utility scale

solar facility. Now we want to actually implement it into hardware. And so I'm going to pass the presentation back to Carlos to show us how we can do both code generation and hardware-in-the-loop testing. Thank you.

Thank you, Jonathan. That's right. Now that we have designed the controller using desktop simulation, we can move to hardware. We're going to first generate code for the microcontroller. We're going to do this using embedded coder and the Texas Instruments C2000 hardware support package. These hardware support package includes IO blocks to link our Simulink model to the microcontroller's electrical interfaces. We then generate C code automatically from Simulink and build the code using Code Composer Studio. And finally, we deploy to the Texas Instruments microcontroller.

We have a similar but more integrated process when using Speedgoat real-time systems. We use Simulink Real-time and HDL Coder for automatic C and HDL code generation. This code can be deployed to multi-core CPUs and multiple FPGAs. There is also a wide range of IO connectivity communication protocols and IO functionality available, such as pulse width modulation and resolver emulators. In this workflow, we first combine Simulink and Simscape models with Speedgoat driver blocks. These driver blocks in this case are PWM capture and analog output. Then we generate C and HDL code automatically from Simulink and Simscape. We then build and deploy the model to the target computer using Simulink Real-time. We deploy to a Speedgoat real-time system that may be composed of one or more interconnected target computers. Once employed, you can modify parameters on the fly and log all the required signals.

Before starting the HIL testing, let us recap that we can use models from desktop simulation during HIL testing at different levels of fidelity, such as average models, phasor models, EMT models, and switch models, for example. Such models can be automatically converted to C or HDL code. During testing, we can use a wide range of evaluation and verification tools, such as Simulink Test, and that we can include switching dynamics for switching frequencies all the way to 100 kilohertz.

Here we have a Simulink model ready for real-time testing. We also have the PICO scope connected with two scopes, two probes connected to the PWM signals, and one probe connected to the voltage of the inverter in green, and one probe connected to the current of the inverter in orange below. Here on the lower left, we have the HIL set up consisting of the target computer, the microcontroller, and the PICO scope. We had initially designed a controller in desktop simulation. As the controller was implemented in the microcontroller for real time testing, we then replace the controller with Speedgoat driver blocks to interface to the electrical signals.

On the left in green, we have the analog outputs and SBI outputs. On the right, we have the red PWM capture inputs. The green color corresponds to the control sample time, and the red color corresponds to the same sample time as the electrical model, being 30 kilohertz in this case. We then deploy to the target with automatic code generation.

The HIL set up in this case includes the microcontroller, a PICO scope, and a performance real-time target machine with an FPGA. We start the simulation. First, the controller synchronizes the model to the grid. After 10 seconds, we connect to the grid, and so we start generating solar power to the grid using the maximum power point tracking.

In orange, we see the current of the inverter, and it changes as we change the irradience. The more irradience, the higher the amplitude of this current. And we can, for example, zoom in to see PWM switching frequency, in this case being five kilohertz. Also if we want to see the ripple current in the

inverter, we can use, in this case, Simulink Data inspector to go and see the ripple current with the switching dynamics, as we can see, of five kilohertz.

To summarize, we have shown how to develop and test a controller for our solar grid-tied inverter using model-based design, including hardware-in-the-loop testing. The advantage of this workflow for designing power electronic controllers can be summarized in three messages. First, that we can simplify control development for power electronics using Simscape Electrical and Speedgoat hardware. Second, that we can automatically generate C and HDL code for plant simulations and production code from Simulink and Simscape Electrical. And third, that we can use hardware-in-the-loop to test normal operation and fault conditions, such as fault ride through.

Thanks for your attention. At this point, we'll be going to the Q&A session. Please post your questions in the Q&A panel. We will take a few models to review them and then come back online to answer your questions. Thank you.