PID Control Made Easy

Hello, and welcome to our webinar, PID Control Made Easy. My name is Arkadiy Turevskiy. I work in the controls team at MathWorks. We'll start this webinar with a quick primer on PID control for those who don't remember or don't know what it is. And then we'll walk through a workflow for designing and implementing a PID controller in Simulink.

Before we start with the primer, let's quickly look at the final product that we will be creating today. For that, let me switch to MATLAB. And we will open a Simulink model.

This is a model of a closed-loop engine control system. This could be an automotive engine or an engine in an industrial machine. The engine is modeled in the subsystem, with an input of throttle and the output of speed. You also have the PID controller inside of this MyController subsystem.

If we run the simulation, you'll see that this PID controller works on fixed-point data types. You also see that it's a discrete time PID controller. You also see the results of the simulation on the right.

The yellow line that you see in the upper right plot is a speed reference signal. You see that you are commanding the speed to change from 2,000 RPO to 2,200 RPM. And the magenta line is the actual measured speed here. As you see, the control system or PID controller is doing a good job in providing fast and stable reference tracking.

Once we designed and verified the PID controller in Simulink, I then automatically generate C code from it. I will show you later how to do it in more detail. But for now, let me simply open the generated code and show you the file.

As you can see here, it's about 30 lines of code, where the actual PID algorithm is implemented in about 10 lines of efficient, compact, fixed-point code. Of course, the actual control system would include much more functionality than a simple PID controller. But in this webinar, I'll just focus on designing and generating code for the PID controller only.

So now, when we've seen the final product, let's step back and talk about primer on PID control. So what is PID control? PID stands for Proportional Integral Derivative. If you look at this picture of PID controller from Wikipedia, you'll see the process that we are trying to control, like our engine model.

You will see the measured output that is subtracted from the set point to calculate the error signal. And then the PID controller, shown here, creates the actuator request by using three different terms, shown in those three different boxes here: the proportional term, which is the error signal multiplied by the gain KP; the integral term, which is the integral gain KI by the integral of the error signal; and the derivative term, which is the derivative gain KD multiplied by the derivative of the error signal.

So why do we need these three different terms? Let's switch back to MATLAB. And let's use a simple script that I prepared here to see that.

In this script, we will use commands from Control System Toolbox such as TF to illustrate why we need three different terms. We'll start by creating a transfer function of the plant model. We call it sys. And as you see, it's a simple second-order transfer function with a time delay of 0.2 seconds.

Let's look at the step response of this transfer function. It looks like that. We can check the rise time of our open-loop system. We see it's about 7.7 seconds.

So we'll now start with designing a controller. And first, what we want to do is use a proportional only term. And let's start with a gain value of 3. Using commands from Control System Toolbox, we'll calculate the closed-loop system and plot its step response.

And the step response is now shown in the yellow line. We see that it's much faster than open-loop dynamics. But it's not providing 0 steady state error. In other words, the closed-loop step response here is not getting to the reference value of 1.

So we could try fixing that by increasing the proportional gain value. Let's try that. Using this little widget here, we can increase the gain and rerun the calculations in the script cell. If we do that several times, we will see that the steady state area is getting smaller and smaller, but at the expense of the stability of our closed-loop system, where we start to see isolations and increased overshoot. So increasing the proportional gain is not a good solution.

So let's now add the integral term, with an integral gain of 0.8, and rerun the calculations. Now we are comparing the response of the proportional-only controller with proportional gain of 0.3, the yellow line, with the proportional integral, or so-called PI controller, with a proportional gain of 3 and integral gain of 0.8. As you can see, the addition of integral term eliminated steady state error while still keeping the stability of the system nice so that our overshoot is small and we don't have a lot of isolations.

And we can use the derivative term that we will add here using the sort argument to the PID command to increase the stability of our system a little bit more. So let's do that. The PID controller response is shown in the green line. And as you see, it has about the same response time, rise time, as the PI controller, so it's also fast. But at the same time, we minimized overshoot and got rid of this undershoot here, so our system is even more stable.

So we need the proportional term to start with. And then the integral term eliminates the steady state error. And the derivative term allows us to increase the stability of our system.

So if PID controller is just about the three gains—proportional, integral, and derivative—what's the problem here? You could quickly write some C code, hook it up to the prototype of our machine, and start tweaking those gains.

Well, it turns out there are multiple challenges when you are doing that. Sometimes, your plant model is unstable. And so if you start tuning it on the prototype, your whole closed-loop system can become unstable. And this can damage your plant.

There could be a dangerous condition called integrator windup. And you need logic to protect against that. I'll explain that in a little bit more detail later.

A lot of times when people tune PID controllers, they use some sort of plant model to come off as PID controller gains. But a lot of times, this plant model is not available. What do we do in that situation?

If you need to implement your PID controller on a microprocessor, and specifically if this microprocessor has fixed-point architecture, then you need to account for discretization in sampling and parameters. And that's challenging as well.

The example that we looked at is a simple single-input single-output system. But a lot of systems out there have multiple inputs and multiple outputs. We need to be able to deal with them as well. And finally, even if you're dealing with a single-input single-output system, plant dynamics can be changing quite a bit from one operating condition to another. So these are just some of the challenges that people have to deal with when designing and implementing PID controllers.

And now I would like to go back to the example that we started with, engine control system, and walk through the workflow of designing a PID controller for that system, and in the process highlight how we can help you address some of those challenges. So let's now switch to MATLAB. And let's open the example that we will work with.

So here is a model where we will create a PID controller for our engine system. We don't have a PID controller here yet, but we have our engine subsystem. Let’s navigate inside of it.

Here we have multiple components. And if you go deeper into one of them, you will see that the equations that we have implemented here are non-linear. Here's another non-linear equation that was implemented here. And here's one more. So the plant dynamics is very non-linear in this case.

So in this top-level model, we have engine subsystem. We have the speed reference block. We have the sum block that calculates the error signal between the reference and measured speed.

Let's now go ahead and add a PID controller block. And we'll use a discrete PID controller. Let's connect this block to the rest of our system.

And let's not open the block dialog for this block. There are a lot of options here. I will not explain all of them. There is a very nice help file here that you can read to get details about all the different options in this PID controller block.

But I'll just highlight some ideas here. You can select the type of controllers that you want to implement: PI, PD, proportional only, integral only, or PID. You can choose the form. We provide two different forms here that you can select. As you change the form or make any other changes here in the block dialog, you see the form of the controller gets updated.

You can specify the sampling time, of course. Let's set that to 0.01 seconds. Let's click Apply.

We can change the gains of the controller. We will talk about that a little later. In the Advanced tab, we can specify output saturation. And if we want, we can enable anti-windup protection. Again, we'll talk about this all a bit later.

As we make these changes, if we want to see what's implemented under the hood here, we can always right-click on this block, go to the Mask menu, and look under the mask. And we will see the logic that we implement for this block using basic Simulink blocks, such as gains, filters, integrators, and summation blocks. So it's never a black box. You always see what's implemented here.

So let's go back here. Let's stay the simple settings here, PID controller. Let's skip parallel form. And let's turn off the limits on the output command. Okay.

And instead of using the default gains here of 1, 1, 0, and 100, let's parametrize this system. This parameter's kp, ki, kd. And those parameters have been set to exactly these values that we just saw here in MATLAB. I'll show you that in a second. Let's click Apply here.

And let's also change the initial value of an integrator in the PID controller so that the initial output of the PID controller block is equal to 9. And from playing with an engine subsystem, I know that you need a throttle request of about 9 to get an output speed of about 2,000 RPM. So let's click Apply here.

And just to convince you that you are starting with default gain values, let's go to MATLAB. And here you see the values of these parameters set at their default values.

Let's switch back to Simulink model. And now let's run the simulation. If we look at the results, we see that the response is unstable. And that's not surprising, because we didn't change gain values yet.

So now let's talk about how you can go and tune the gain values. We can do that by going into the block dialog and pressing the Tune button. This launches a tool called PID Tuner, which requires Simulink control design. This tool linearizes non-linear Simulink model at time 0 and opens up this PID Tuner app that you see here.

And using the transfer function that the tool got from the linear Simulink model, it automatically comes up with PID controller gains to provide nice reference tracking. You can check out PID parameters, the gain values, and other characteristics here. And if we like the design, we can simply update block parameters.

Nothing changes in the block dialog. But if you go to MATLAB, we see that the gain values have been updated.

Let's go back to our Simulink model. And let's rerun the simulation now. And let's look at the results.

So now we see we got rid of this instability. We have nice and stable response. But maybe we would like to eliminate this spike in the throttle command, because maybe that's not realistic.

So we can go back to the PID controller block, bring up this PID Tuner that we have, and maybe slow down the response of our system a little bit. And actually, we can look at another plot where we can look at the controller effort, so how much throttle we are commanding, and see how that is changing. So with the default design, we see a spike here. But if we keep making it a little slower, we reduce the spike.

So let's try this design here. Update block parameters again. Rerun the simulation. And now we have nice, stable design with no spike in the throttle command.

So very quickly here, you saw how we can tune PID controller gains using PID Tuner app, and how we can fine-tune the design. If you would like to use more rigorous tuning with tools like Bode plot or root locus, we have another app that is called Control System Designer that you can use. But I'm not going to show it now.

What I would like to focus on next is a situation where you don't know the plant model. You don't know the equations describing the dynamics of your plant. But you might have the access to a prototype or to the actual process or the plants that you're trying to control.

So let's pretend we don't know the equations of our engine, but we're able to have access to an actual engine. And we can command inputs to the engine, like the throttle request here, and measure the outputs. In this case, we are doing open-loop test, where we just command the throttle to change in a step fashion from about 8.9 to about 9.4 at 2 seconds. But we could also be running the same preliminary controller that maybe we want to improve upon, so we could be commanding the speed reference change to that controller and measuring the resulting throttle and the resulting speed from an engine.

So what I'm trying to say is that the data that we could be using is not necessarily open-loop data, but it could be the data obtained as a result of a closed-loop engine operation. But once you measure the input to the plant and output of the plant, the idea here is that we could use this data to identify a plant model from data, and then use this identified plant model to tune our PID controller.

So let's do that. Let's open the PID Tuner app. Pretty much the same app that we just used to tune PID controller gains in our Simulink model. But now we don't have a plant model to start with, so we need to identify a new plant model.

This opens up another window for identifying a plant model. And we need to start by bringing the IO data into the tool. So here you can choose. You can bring arbitrary IO data. But in our case, we use the Step Response option, because the data we have is actually step response.

The output signal is stored in a variable output. And the input signal we know has an amplitude of 0.5. It starts at about 8.9, or actually we have the input signal, so we can just get the initial value from there. We know the step happens at about 2 seconds. And our time vector starts at 0, with assembling time of 1/100 of a second.

So let's bring the data in. We now see the green curve, which is the measured engine speed, and the blue curve, which has an output of a model that we are trying to feed to the green line. Let's also look at the input data, which is a step that we commanded to the engine, the throttle step.

Okay. So to get a better fit, let's remove the offset in the measured data. So instead of starting this engine speed at 2,000, we'll start it at 0. So we'll go to Preprocess, Remove an Offset. And let's remove an offset from All signals. And we remove the initial signal value.

So we'll update that. So here's our new data. And we'll close this dialog.

So here is the data with removed offset in the green line. And we are now trying to fit the first order model—you see the formula here—to this data. We can interactively adjust two parameters in our controls, the steady state gain and the time constant of this model.

We can try a different structure; for example; a pair of underdamped poles. So let's select a different model. We can tune this interactively, or we can let the tool automatically come up with the best parameter values that provides the optimal fit.

So if we do that, the tool is able to come up with a pretty good fit here, as you see here. In the bottom right corner, you see the parameters of the plant that it fitted. And now let's say we are happy with this plant model, so we can use it and close this dialog.

And so now we are tuning our PID controller for this plant model that we just identified. Let's select PID controller with derivative filter as the type of PID controller we want to use. We see that we now have nice step response with zero steady state error. We can maybe make it a little bit faster. And once we like this design, we can export it and save it in our MATLAB workspace in the variable c.

Now if we go back to MATLAB, we have a variable c. And if you look at what it is, it's a continuous time PID controller with these gain values. And we can access those gain values by typing c.kp, c.ki, and so on and so forth. So now we could take those gains and put them into a PID controller block in Simulink for further implementation.

So to summarize, in this section, we looked at two different ways of tuning PID controllers, one way when you have the plant model in Simulink with equations that describe the dynamics of your plant, and another way when you don't know the equations but have access to measured input/output data. And in this case, you use System Identification Toolbox integrated into the PID Tuner app to first identify a plant model from data and then use this identified plant model to tune the parameters of your—the gains of your PID controller.

So let's now talk about implementation. It's pretty much the same model that we just worked with. But here, we added zero order whole book to represent an A to D conversion. And we placed our PID controller inside of the subsystem here. And we also added data type conversion blocks.

So now what we would like to do is convert this floating point designed to fixed-point design for implementation on a fixed-point processor, and then generate code. So let's start by running the simulation. So let's say that this is the design that we are starting to work with. You see all the signals are doubles now.

And now to scale this design for fixed point, we'll launch Fixed Point Tool, which ships with our product called Fixed-Point Designer. Okay. So we have the results of the simulation that we just did here already. So you'll clear all the results and all runs first. And we'll start with overriding all the parameters in my controller subsystem with doubles. So that's what this setting does.

And we'll run the simulation. And we'll save the results of the simulation in a run that we will name Double. So let's do that. Let's simulate our model.

The results are shown here. As you can see, for all parameters inside of the PID controller block, we are using the double data types. And for all signals inside of the subsystem, we are capturing the min and max values during simulation.

Now what we will do is use those min and max values captured during simulation to automatically come up with fixed-point scaling. To do that, we'll scroll down. And here, we will configure the option to propose fraction lengths. We want to use fixed 16-bit word lengths. And for that fixed word lengths, we will want the tool to propose fraction lengths. So we will stay with this choice.

The default data type that we will want to use for floating point signals is going to be the same as embedded hardware integer. I'll explain in a second what this means. We will want to use simulation min/max data with some safety margin to come off as fixed-point scaling.

Now let me go back to a model for a second. In the model, what I did is that in the Model Configuration Parameter setting, there is a node called Hardware Implementation. And here, I have specified that we would like to implement our controller on a generic 16-bit embedded processor. I could have chosen a specific one there. But here, I wanted to stay with the generic architecture.

So the important thing here is that this way, the fixed-point tool, when we say the default data type is same as embedded hardware integer, it knows that we are targeting 16-bit processor. So with that, let's let the tool propose the fraction lengths for us. So let's click here.

So tool goes ahead and comes up with the proposal that you see here. Let's go ahead and apply the proposed fraction lengths for all the parameters.

And let's now go back to our Simulink model. Open the PID controller block and look at the data type step. So now you see that all the data types here are fixed point with 16-bit.

Now what we want to do is make sure that the fixed-point scaling that we just came up with will give us the results close to our floating point design. For that, instead of overriding all the data types to double, as we did first, we'll use local settings, the fixed-point scaling that we just saw. And we will save the results of the run into a run called Fixed Point.

So let's apply the changes. And let's run the simulation.

We see we now have two runs, Fixed Point and Double. Compiled DT column shows you the data types used during simulation. So you see that we used fixed point for the Fixed Point run and double data types was for the initial run.

Now let's look at the error signal. Let me show you where it is in the model. It's this signal here. You see that we are logging it. It's the difference between the reference set point, reference speed, and the measured speed.

And for the signal, we'll compare the runs. Here in the top, there are actually two plots. They look very close to each other.

But if you zoom in a little bit, you'll see there is a difference. And that's what you actually see. The difference between the two lines in the upper plot is what you see on the bottom plot. So let me zoom out.

So the interesting thing to note here is that there is a difference in steady state value between the floating point and fixed point. And you can see that if you zoom in here. Now, remember, this is a result of a simulation with fixed-point scaling. So the result of fixed-point scaling, you don't have zero steady state error anymore. So that's interesting. And that shows you that maybe you need to work on the scaling cell a bit more, or maybe live with this non-zero steady state error, or maybe go to a process service for a little bit.

But that's your choice as an engineer. The important point here was to show you how you can quickly do fixed points scaling with this fixed-point tool, as shown here.

So now, when we did that, the next step is to generate code. There are multiple webinars that talk about how to configure code generation. But I'll just quickly show you how to generate code specifically from this PID controller block. Again, in real life, your controller would be much more complicated than a simple PID controller block. But the idea is nevertheless applicable.

So let's say, build a subsystem. I have configured this model to generate efficient code, optimized for ROM and RAM efficiency. I'll make those controller gains parameters, tunable parameters. And we'll go ahead and generate code.

Here is the generated code. You see our gains here. You see some initialization code here. And the actual algorithm implementing our PID controller is here.

So what do you do with this generated code? Of course, you could put it on a processor and start testing, et cetera. But I would like very quickly to highlight an option that you have called software-in-the-loop testing. The idea here is to take this generated code and to test it on a host computer with a plant model in Simulink, to make sure that the generated code gives you exactly the same result as a block in your Simulink model.

To do that, we again go to Code Generation menu. But now we select an option to Generate an S-Function. Again, we can make those parameters tunable. We select this option, Create Software-in-the-Loop block, and click Build.

Again, the tool goes and generates code for us. But now it also creates a block that you will see here momentarily. This block is called Software-in-the-Loop, SIL. So let's take it from this model and let's copy it to our original model.

Let's delete this PID controller block that we designed and did fixed-point scaling for, and instead replace it with a Software-in-the-Loop block. If I run the simulation, I will get exactly the same result, as we will see in a second.

But if I look under the block mask now, it's not the PID controller block that we saw before. We are actually calling the generated code here. So again, we're just making sure that this generated code gives us exactly the same result as the PID controller block that we designed.

And this code is running on the host machine. So the next step would be to test it on the processor. But that's outside of the scope of what I wanted to cover today.

Okay. So now we have talked about designing the controller, tuning its gains, and implementing it, doing fixed-point scaling, and generating code. So let's close this model and next talk about the situation when plant dynamics is changing quite a bit from one operating condition to another. In this case, it's actually changing quite a bit, from 2,000 PM to 6,000 RPM.

Let me open the script and show you that. So in this script, we're going to be working—let me find it here—with an open-loop engine model that you see here. So we'll be linearizing this model from throttle input to measured speed output. The tool that we will use for that is called Simulink Control Design. This tool has a nice graphical app that you can do—that you can use to linearize a model or you can use programmatic workflows that I chose to use here for batch mode linearization.

In the script, we will linearize our plant model at a set of speed points ranging from 1,400 to 6,000 with a step of 200. Using commands from Simulink Control Design, such as findop and linearize, we will linearize the model at all these different operating points, and we'll plot the results in a Bode plot.

This calculation takes a second. And once the Bode plot is created, you see there are actually 24 different lines here plotted corresponding to engine dynamics at 24 different conditions, spanning from 1,4000 RPM to 6,000 RPM. And you see there are variations, significant variations in engine dynamics. The resulting variables that we just plotted are called sys.

If I look at that in my command window, I will see that that's an array of 24 transfer functions. Now what I would like to do is tune PID controllers for all those 24 transfer functions. I could do it individually, again, using tools such as PID Tuner app or Bode plot, or Control System Designer, or maybe root locus plot.

But there is also programmatic way to do it. There is a function in Control System Toolbox called PID Tune. And so what we are going to do is take this array of 24 transfer functions and design a set of 24 PID controllers to get closed-loop bandwidth of 10 radians per second and a phase margin of 70 degrees with just two lines of code. So let's execute this cell. Okay. And if we look at the results of the calculation, we see that we have an array of 24 PID controllers that we just created.

Let's look at how the gains of those controllers are changing the speed. Okay. So again, the speed goes from 1,400 RPM to 6,000 RPM. And we see that the gains are changing quite a bit. Here we are just looking at proportional and integral gain.

Let's compute and plot the closed-loop step responses of 24 PID controllers applied to our 24 linear plant models. So we see that that looks quite good.

And the next step, of course, to implement these 24 PID controllers in Simulink. And this is called gain scheduling. So for that, I'll open a different model. Okay. And what I would like to show you is that, again, we have our engine subsystem. We have our PID block.

But now, inside of this PID block, we chose this option for Source to be set to External. And when we do that, the block gets additional imports for PID gains. And we can now provide those using lookup tables block. So you see that we are measuring the speed signal here. And we are feeding the speed signal to the lookup blocks, lookup table blocks. And these lookup tables implement the proportional gain as a function of engine speed.

Okay. So here we see the shapes. And so the idea is that as the engine speed is changing from 1,400 RPM to 6,000 RPM, our controller gains are adjusted accordingly. So basically, we are switching from one controller to another as we change the operating condition.

Here we have a signal builder block, where we can create multiple test cases to test our controller. And the first test case I have here is a series of small steps up and a series of small steps down, to cover the whole operating range of an engine. So let's run the simulation. And let's look at the results.

Okay. So here we are looking at the reference, the magenta signal, and the actual engine speed, the blue signal here. So we see that we have pretty good reference tracking across the operating range.

So now let's go back to the model and run a different test case here. So now we will do a couple of large steps, all the way from 1,400 RPM to 6,000 RPM and back to 1,400 RPM. Let's run this scenario. Let's again look at the results.

So here, the reference is this red signal. And the actual speed is the green signal. You notice that there is some strange behavior here, where there is a large overshoot. And it takes a while for the signal to come down to the reference value. And the same happens when we step down.

This is actually the condition that I mentioned in the beginning of the webinar called integrator windup. What happens here is that with the gains that we chose here, the error signal between the reference and the actual speed is large enough that the integrator term integrates to a large positive number. And then it takes a while for you this integral term to come down back to 0 when our actual speed overshoots the reference. So as you see, it negatively impacts the performance of our controller.

And we can fix that by adding the integrator anti-windup logic. And in the PID Controller block, it's really easy. You just select—it's really easy to do. You just select the anti-windup method you want to apply, click OK. And now we rerun the simulation.

And let's look at the results. And let me actually remove the previous run from the results. And let's just look at the new one. So now you see that the new run with the anti-windup logic gives us a very nice performance with not overshoot on the way up or no overshoot on the way down.

And we can also actually get an idea about what's happening by comparing the throttle commands that are created. So the red line on the bottom is the throttle command with the run where we didn't have the anti-windup protection. And the blue line is from the run with anti-windup production on. So as you see, when we turn anti-windup protection, the throttle command comes off the maximum value of 25 much faster.

This portion of the webinar showed you how you can quickly design and implement gain scheduled PID controllers in Simulink, and how you can protect against windup.

So the last thing I would like to address in this webinar is design of MIMO PID controllers. Let's close this model. And as I mentioned in the beginning of the webinar, many of the systems that we have to deal with are system with multiple inputs and multiple outputs. So let me open another model. It's a model of a diesel engine that we see here.

If I run the simulation, you will see the numbers on signal lines. Those numbers represent the dimensions, the size of signals. So we see that the reference signal is two signals, actually, boost reference and EGR reference. And the output from the diesel engine subsystem has two signals, boost and EGR. so there are two outputs that we are trying to control. And the two inputs to our engine are VGT position and EGR lift.

So here, we would like to implement a MIMO PID controller to do two-by-two control. If you look inside, you see that we have an integral gain ki, which is two-by-two matrix; the proportional gain kp, two-by-two matrix; and the gain to provide disturbance fit forward, also two-by-two matrix. So in total, there are 12 parameters that we want to tune. They are set to zeros by default.

So if we look at the results of the simulation, we see that we don't have good reference tracking at all. The yellow lines represents the step changes in boost and EGR. And we see that the magenta lines, the actual signal don't track reference signals at all.

So to design our MIMO PID controller, we can use a tool called Control System Tuner. This is a tool that you can use to design any type of MIMO or SISO controller in Simulink or MATLAB. The idea is that you specify the architecture of your controller in Simulink using the basic blocks, and then use this tool to tune the parameters of your controller.

So let's see how this works. Let's go to the Tuning tab here. Let's specify the parameters we want to tune.

In our MIMO PID controller, we want to tune those matrices. We'll specify them. And then here, we can specify a number of tuning goals. And there are all types of goals here.

And so let's start for example with step command tracking. We'll want to track from step response inputs, which are our reference signals. Let me show you the signals that they are. It's a boost reference and EGR reference. And the output signal is the output of the diesel engine subsystem and the signals here, boost and EGR.

We'll ask the tool to design the controller to give us a time constant of about 5 with first-order characteristics of the closed-loop system and show the step commands that we are commanding, our 10 for boost, and 3 for EGR, so you'll adjust for the magnitude accordingly. So you'll type those numbers here, 10 and 3. We can even ask for maybe something a little faster than 5, so maybe 3 seconds. Let's click OK.

The tool goes ahead and creates a plot of the tuning goal. The magenta line is the response that we're asking for, so good fast step response on the diagonal terms and zero signals on the off-diagonal terms to provide minimal cross-coupling between the channels.

Now we simply press Tune and the tool goes and tunes so those kp, ki, and kff parameters. Now, the tuning is very fast, as you can see. And all we have to do now is update the blocks in the Simulink model.

If we go inside of the subsystem here, we see all the block parameters have been updated. And we can now run the simulation and look at the results. And we now see that we have nice reference tracking with minimal cross-coupling. So when we do a step change in boost, there is little effect on the EGR. And vice versa: when we do step change on EGR, there is relatively little effect on the boost. So very quickly we designed a MIMO PID controller using PID Tuner tool.

So in summary, you saw a quick primer on PID control. And then you saw a simple workflow for how to go about tuning, implementing PID controllers in MATLAB and Simulink. The different products that we used were Simulink; Control System Toolbox; Simulink Control Design; System Identification Toolbox for creating plant model from input/output data; Robust Control Toolbox, which is a product you need to use Control System Tuner; Fixed-Point Designer, for doing fixed point scaling; and Embedded Coder for generating code.

If you want to learn more, Google "PID Control MATLAB" to get to the page that we've put together with all the resources on how to design and implement PID controllers in MATLAB and Simulink. So that's pretty much it. Thank you very much.