Using Simulink to Develop Grid-Tied Solar Inverter Controls - MATLAB & Simulink
Video Player is loading.
Current Time 0:00
Duration 26:46
Loaded: 1.93%
Stream Type LIVE
Remaining Time 26:46
 
1x
  • Chapters
  • descriptions off, selected
  • captions off, selected
      Video length is 26:46

      Using Simulink to Develop Grid-Tied Solar Inverter Controls

      Overview

      In this Webinar, you will learn how you can design, implement, and test the controller code for a 3-phase grid-tied solar inverter using Simulink.  The goal is to develop a controller that can adhere to grid codes and maintain inverter grid connection during upset conditions.

      In the session we will present how to model the photovoltaic (PV) system, solar inverter, and grid load with Simulink and Simscape Electrical.  This model is used to design and tune closed-loop and supervisory control algorithms for maximum power point tracking (MPPT), grid synchronization, and low voltage ride through (LVRT).  With Embedded Coder, the control algorithms are used to generate and deploy optimized C code to a Texas Instruments C2000 Piccolo™ MCU.  Finally, the implemented code is tested for a variety of emulated grid fault scenarios using a hardware-in-the-loop (HIL) simulation of the PV system, inverter, and grid load running on a Speedgoat real-time target machine using Simulink Real-Time.

      Highlights

      • Simulating a photovoltaic (PV) farm, a 3-phase grid-scale inverter, and grid load
      • Designing and tuning control algorithms for regulating voltage and maintaining grid synchronization using a phase-locked loop
      • Developing the maximum power point tracking (MPPT) algorithm to maximize PV output under varying conditions
      • Developing supervisory control for low-voltage ride through (LVRT) during a voltage or frequency disturbance
      • Generating C code from control algorithms and implementing them on a Texas Instruments C2000 Piccolo™ microcontroller
      • Generating C and HDL code from Simulink and Simscape Electrical to a Speedgoat real-time target machine with a multi-core CPU and FPGA
      • Conducting hardware-in-the-loop (HIL) simulation to test code running on the microcontroller

      About the Presenters

      Carlos Villegas has over 10 years of R&D experience in electrical machines, power electronics and automotive control systems, including in-vehicle rapid control prototyping at Daimler Research (Germany), and the development of renewable energy systems up to 2 MW. He is an inventor in 4 patents, and author of 20 technical papers. He received a Ph.D. degree in Engineering from the Hamilton Institute, NUI Maynooth, Ireland; an M.Sc. degree in Mechatronics from CINVESTAV, Mexico; and an M.Eng. degree in Electrical and Mechanical Engineering from Tec de Monterrey, Mexico. As Industry Manager for Electrification at Speedgoat, he is responsible for real-time solutions for electric motors, power electronics, battery systems, and power systems.

      Eva Pelster is a Senior Application Engineer at MathWorks. She holds degree in Aerospace Engineering from the University of Stuttgart. Her focus at MathWorks is on model-based design workflows and physical modeling applications.

      Recorded: 25 Nov 2021

      Hi, Welcome to this webinar on how to develop grid-tied inverter controls using Simulink. My name is Carlos Villegas, and I am the Electrification Industry Manager at Speedgoat. I'll be presenting together with Eva Pelzer, a Senior Application Engineer at MathWorks. 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 tasks that aim at capturing power from the solar panels, and also protecting the grid. We will 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 reuse 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 this, we're 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 grid inverter and solar panels. Then we'll also automatically generate C code to the microcontroller. We now can thoroughly test our grid inverter for normal and operating conditions. We will present a hardware demonstration to illustrate testing, including solar power generation and grid 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. This code supplies voltage and frequency considerations, and result in solar facilities having to supply sometimes excess reactant 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 for all conditions. There are many destructive tests-- 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 lab. 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 type inverter. Then we generate an electrical model, including the power electronics, the grid relays, inverter, et cetera. We designed our controller within this environment. Our goal is to test our controller with our real hardware prototype. In this case, a grid type inverter. As the first step, we can generate code to a Speedgoat code 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. And before connecting our grid type inverter to a hardware prototype, we use hardware-in-the-loop testing to thoroughly validate 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 planned 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, would we 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, Eva, 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 Eva Pelzer, and I am an application engineer at MathWorks. And in this portion of the webinar, I will take you through the steps that are involved in building a model of a utility scale solar system in Simulink. And once we have created this model, we will use it in a closed loop simulation to perform controlled design tasks on the power electronic side and the power systems side. The type of system we are looking at today typically has different layers of controls, and we will talk about that as well.

      But let's start now by looking at the model creation. Breaking the system up into its main components, we have the PV array itself, the three phase inverter, converting the DC input into the three phase waveform, and on the right hand side here, we have the point of connection to the grid. To create a system representation in Simulink, we will make use of pre-existing components that ship with Simscape electrical, and put together the identified structure.

      So this is what the model representation looks like in Simulink, compared to what we just saw in the slides, we just have a couple of elements added for visualization and interactive control right here. So I'll go ahead and start running the model. And while this is going on we, can look through some of the elements. So we have the building blocks out of the mentioned libraries, for the solar panel, the grid inverter, as well as the point of connection to the grid. And within some of the subsystems we have added the elements for the controls.

      So right now, the model is in idling mode, meaning the panel is not connected to the grid. I will go ahead and flip that switch and make that connection to the grid. And we can see the reaction right here in the visualization. And we have a second switch right here, which allows me to inject a fault into the system. So when I flip that switch, I can see an immediate reaction right here as well. So this allows us to see how the system and controls react to these types of events. So we have a running model that allows us to analyze it for different scenarios and eventualities. And this can all be done before taking it to an embedded system.

      With this model implemented, we can now move on to the control design. With the system we have at hand, or other similar systems that include power electronics, as well as power systems, we have different layers of control design present. And by different layers, we are referring to varying timescales of the different controls. There are fast controlled dynamics present on the power electronics side, the switch more control away from generation, for example. These loops would be operating at high speeds. As we see later in the context of hardware-in-the-loop testing, these will often be deployed to FPGAs. If we look at the elements like voltage, frequency control, or reactive power control, those will require less volatility. So this is where average value models come in helpful to reduce simulation time.

      And in comparison to the other elements, there are more long time scale control strategies involved. For example, for participation in energy markets, or smart integration of renewables. For that, having a model that allows us to look at all these different timescales will help us to validate all strategies. With the library Simscape electrical, we can choose between different types of simulation modes, from full switch mode to average value or aphasia simulation.

      Going back to our solar array system, we will start looking at the control system that is in place to regulate the DC voltage on the solar panel side. The aim here is to design a feedback loop which measures the current PV panel voltage, compares this to a given reference voltage value, and uses a PID control element to output a duty cycle. This will then be fed into the PWM generator, to pass the pulses along to the inverter. The PV panel will have a given operating point, also a maximum power point. And if we have this point available, we will want to set our demanded red switch according to that maximum power point.

      So we are going back to the Simulink model and having a look at the structure. If we navigate into the subsystem containing the grid inverter, we see the input into that block, the duty cycle for each of the phases. The block itself can be configured to represent different types of switching devices. So for full fidelity simulation, the input would be the PWM waves, instead of the duty cycle. Remembering that in this case, we are focused on the voltage control happening at a lower rate. We are fine with a lower fidelity option, with the approximation of an average volume model.

      So switching into the inverter control subsystem, we have the low level control, which is regulating the individual access. But for this example, we are focusing on the DC loop, the layout right here is the same one we just saw in the slide. So we have the voltage reference, which is a step signal, in this case. And we are also feeding back the measurement from the panel. And this error goes into the PID block. So I will go ahead and run the simulation, so we can have another look at the response.

      So the dashboard right here shows the reference voltage signal and the simulation PV voltage signal on top of it. The simulation looks as if it is tracking OK, however there is some overshoot. So this could potentially be improved by choosing different controller gains. There are several ways to adjust these PI controller gains. So for example, I could just manually tune these parameters. But we also offer functionality to automatically tune these gains. So hitting the Tune button right here will lead me to the PID tuning app.

      So the tuning app will be based on the linearized models, suggest PI gains. And I can go ahead and modify them by making the response slower or faster, or make the transient behavior more aggressive, for example. To gain more confidence in my design, I can add more visualization in time and frequency domain, to further analyze the behavior. I can add an open loop Bode plot. And once I'm happy with my design, I can choose to play back the parameters to the model.

      So with that, we now have created the model topology and tuned the controller so that we are able to set the reference voltage on the PV panel, which will help us to operate at the maximum power point. In the next step, we will modify the controller so that we can connect to the grid. And this adds another element or input to the system. That input will either generate a reference waveform if we are in islanding mode, or we can create a phase lock loop, or PLL, to track frequency and phase of the grid, and to synchronize the source with that grid.

      So let's see a representation of that in the model. This, again, is based on the same model as before. If I go into the inverter control, we can see that a couple of elements have been added. With the current regulator, the current priority, as well as some additional elements that are in place for maximum power point tracking, but we will come back to this later. And additionally, we have the PLL subsystem. This is containing the pre-built PLL block. This is measuring the grid voltage, and uses that to synchronize the source. Here, we are taking the current grid voltage, as well as the inverter output, and comparing the two to achieve a difference of 0. And this is also using a PIT loop to perform that task.

      Once this is achieved, we can use the switch to switch back to the standard voltage control we have designed. So I will go ahead and run this. And we can see a plot of the grid connections and the inverter output, and down here we see the two waveforms, from inverter and grid. At around 0.2 seconds, they are synchronized. And we can see that they are matched, and the grid gets connected.

      What we have in place now is the control loop to regulate the PV voltage, and the mechanism to connect to the grid. In the next step, we will take care of the maximum power point checking. With a maximum power point, we will have the according voltage reference to provide, to ensure that we produce the maximum power at different operating conditions of panel and load. So solar panels have these nonlinear curves of output power, with respect to the voltages. And at different irradiances, these change in size, so that for higher irradiance, we see a higher power output. And the location of the maximum power point also shifts with it. To include that into the system, we will have to design an algorithm that, depending on the conditions, will find the maximum power point. And with that, we can provide the right voltage reference.

      There are different strategies that can be chosen and implemented for MPPT. In this example, we are using a perturb and observed method. This approach adjusts the voltage by a small amount, and then checks the measured power increases, and then continues to make those adjustments. This is implemented as a Stateflow chart right here. So while this is running, we can see in the animation how the strategy is working during the simulation. So when we see a change in irradiance, we can witness how, after a while the corresponding power point is found.

      The steps that we have done, up until now, have focused on the individual solar utility. What we haven't seen yet is how to handle common grid code requirements, such as Fault-Ride Through. These grid codes can define how long the utility needs to remain connected to the grid if an event occurs, so that it can supply reactive power.

      Again, this can be implemented in different ways. Here, we are using another state machine that measures and compares. So in this example, when we encounter the fault voltage ride through, we can see how additional reactive power is provided. When I go to the same place in the model, we can see that once we are in the voltage fault mode, we are calling a function called VRT, so voltage ride through, and to the function we are providing the grid voltage and the elapsed time. This function uses lookup tables which allow us to see where we are on the grid code requirements, and if we are in the range where we must stay connected. So if the model stays connected, we can continue to provide the reactive power support.

      To make it more easy to test for these requirements, we have created some blocks that contain common grid codes. This is a method to validate if our controls are performing and reacting as expected. I will now go ahead and pass the presentation back to Carlos, and he will walk us through the workflow of automatic code generation and hardware-in-the-loop simulation.

      Thank you Eva. That's right. Now that we have designed the controller using desktop simulation, we can move to hardware. We're going to first generate a code for the microcontroller. We're going to do this using embedded Coder on the Texas Instruments C2000 hardware support package. This hardware support package includes I/O blocks to link our Simulink model to the microcontrollers 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 Instrument 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 I/O connectivity, communication protocols, and I/O functionality available, such as pools width modulation, and resolver emulators.

      In this workflow, we first combine Simulink and Simscape models with Speedgoat driver blocks. The driver blocks in this case are PWM capture and analog pump. 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 in real time. We deploy to a Speedgoat real time system, that may be composed of one or more interconnected target computers. Once deployed, you can modify parameters on the fly, and log all the required signals.

      Before starting the hill testing, let us recap. That we can use models from desktop simulation during hill testing at different levels of fidelity, such as our first models, phasor models, EMT models, and switching models, for example. Such models can be automatically converted to C or HDL code. During testing, we can use a wide range of validation and verification tools, such as a Simulink test, and that we can include switching dynamics for PWM 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 1 volt-- one probe connected to the current of the inverter, in orange below. Here on the lower left, we have the hill setup, consisting of the target computer, the microcontroller, and the pico scope.

      We had initially designed the controller in desktop simulation. As the controller was implemented in the microcontroller, for real time testing, we then replaced the controller with Speedgoat driver blocks, to interface to the electrical signals. On the left, in green, we have the analog outputs, and SPI 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 hill 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 irirradiance. The more irirradiance, the more the amplitude of this current. And we can, for example, zoom in to see the PWM switch frequency, in this case being 5 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 5 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 Simscape 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, will be going to the Q&A session. Please post your questions in the Q&A panel. We will take a few moments to review them and then come back online to answer your questions. Thank you.

      View more related videos