A Conceptual Approach to Controllability and Observability | State Space, Part 3

There are two really important questions in control systems engineering: Is your system controllable? And is it observable? Assuming you have a good linear model of your system, you can answer both these questions using some simple matrix operations and the A, B, and C matrices of your state-space model. 

My experience, though, is in the aerospace industry and I’ll be honest—I’ve never actually used these equations at my job to analyze my system. I’m not saying other industries or other systems within aerospace won’t use them. It’s just, for the projects I’ve worked on, we’ve relied mostly on just having a good understanding of the system and reasoning through the design to determine whether it was controllable or observable.

But with that being said, in order to develop that intuition you have to have an understanding of the concept of controllability and observability and part of gaining that understanding comes from studying these equations, so they’re worth spending some time on. Just not in this video; we’re not going to cover them at all, and I think with good reason. I feel that Steve Brunton already has done a fantastic job describing the math behind these equations in his Control Bootcamp series that I’ve linked to below and rather than duplicate that, I want to approach this topic from a more intuitive and conceptual direction. That way, combined with the math, you’ll have a deeper understanding of controllability and observability that I think will help you be a better control systems engineer.

I’m Brian, and welcome to a MATLAB Tech Talk.

To begin, let’s look at what control system design requires at a very high level. It starts with the system that you want to control. You’re able to poke and prod the system with actuators that impart control forces and energy. And you can measure specific states of the system like voltage, position, temperature, with sensors which produce the output of the system. Controller design comes down to figuring out how to use the sensor data along with a reference signal or some kind of command to generate the correct actuator commands. That’s essentially all we’re trying to do.

However, your controller design is bound to fail if your system doesn’t have the appropriate actuators that can affect the right parts of the system, or if you don’t have the appropriate sensors in place that can measure the right states. Without both of those, you won’t be able to adequately influence the system, it won’t be controllable, or you won’t know how the system is changing; it won’t be observable. In this way, controllability and observability are conditions of how the system works with the actuators and sensors, and it’s not tied to a specific control technique like PID or pole placement. If it’s uncontrollable, you have to address that problem by changing the system or the actuators, and the same goes for observability and the sensors.

Let’s look at sort of a formal written definition of the two. Controllability means that there exist control signals which allow the system to reach any state in a finite amount of time. This is also called reachability. Now, an important thing to realize is that controllability does not mean that the state must be maintained or held at that condition—just that it can be reached.

To understand what this means, let’s look at a nicely constrained problem like a monorail. There are two states: position and velocity. We’ll assume the monorail is controllable so by accelerating and braking, the monorail can get to any position on the track and it can speed up to any velocity within the state space. Here’s the key about reachability: Not only can each state variable be achieved individually, each combination of variables can also be achieved. For example, we could accelerate in a way that would get to a position of 1 km at 50 km/hr.  Hence, it can reach that state in the state space. However, it should be obvious that it’s physically impossible to maintain that state. This is why controllability requires the system to be able to reach any state, but not necessarily maintain it.

Okay, let’s move onto observability. Observability means that all states can be known from the outputs of the system. That is, we can know the value of every state in the system by using an appropriate selection of sensors and sensor locations. A quick side note about this, though. As I mentioned in the last video on pole placement, it’s impractical to impose the requirement that you know every state in a system. There are just too many and most don’t impact the system in any meaningful way. For example, the temperature of the monorail is a state, but knowing it is not necessary for controlling the position and velocity. So when I say states, I’m really referring to all critical states. Often, the critical states are the ones that are in the state vector of your model since your goal in modeling is usually to include only the relevant dynamics and leave out the rest. Therefore, for observability, we want to know every state in our state vector.

Okay, with these definitions out of the way, let’s see if we can make more sense of these concepts by looking at some examples.

For now, let’s ditch the constrained monorail problem and look at the higher dimensional state space of a car. We’ll say the states we care about are the x, y position, the x, y velocity, and the yaw angle and yaw rate. And let’s say for our sensors we have a speedometer to measure velocity and our own eyes to assess everything else. The actuators are the steering wheel and the gas and brake pedals. It’s essentially the actuators and sensors you’re using when you drive your car and therefore we can reason that with this setup, we’d be able to control the car to a specific position at a given velocity and yaw angle.

Let’s look at the concept of observability first and start with an extreme example to help illustrate its importance. We remove all sensor information by closing our eyes. This has the effect of zeroing out the C matrix and basically we have no way of knowing any of the states. You don’t know where you are, what speed you’re going, or the direction you’re facing. Let’s assume for this example that you can’t feel acceleration or hear the engine or anything. Now you still can control the car; that hasn’t been impacted since you’re able to move the steering wheel and press on the pedals. So in this way, lack of observability made it so you can’t control the car in the sense that you can’t drive it safely to a destination and know that you got there. However, the car is controllable within the definition that we set earlier. So that’s something to keep in mind when you’re talking about control and controllability.

Now let’s imagine the opposite situation. We remove the steering wheel and the pedals, which has the effect of zeroing out the B matrix. You can imagine how this could happen if you hit a large icy patch and the car skids along with no effect from steering or braking. Even though you can’t affect the state of the car, this system is still observable since you can watch the speedometer and track your position by looking outside. 

So you can see how it’s necessary to have a system that is capable of being observed and controlled. They work together. I mean, it should be pretty obvious that without any actuators or without any sensors your system is doomed to fail, but what might not be obvious at first is that even a system that is partially uncontrollable or unobservable is still troublesome.

Imagine trying to drive your car with the steering wheel detached. Even though you can still change speed with the pedals, I bet you’d still consider that an uncontrollable car since you’d have no way to change the yaw state. This is a common sentiment with all control systems. If any one critical state is uncontrollable, then the entire system is deemed to be uncontrollable. And if any one critical state is unobservable, then the entire system is deemed to be unobservable.

Okay, now let’s focus on what it means to observe a state. Clearly, directly measuring a state is one way of knowing it. However, we don’t have to measure every state to infer its value. Being able to estimate a state using available information is good enough to claim that the system is observable. 

For example, with the monorail, we wouldn’t have to install a speedometer and a position sensor in order to know both of those states. Velocity can be estimated by differentiating position and position could be estimated by integrating velocity. So you’d only need to measure one of those states and you can infer the other. This is why a system can still be observable even if the output, y, isn’t full state. That is, it doesn’t contain a direct measurement of every state variable.

Estimating states is a good way to reduce the hardware complexity of your system. Strategically measure only the necessary states with sensors and then you can estimate the rest using an observer like a Kalman Filter.

With that being said, even if you can estimate a state, some states could be highly sensitive to modeling and measurement errors. For example, differentiating a noisy position creates an even nosier velocity. Or a small bias in velocity measurement would cause an ever-growing error in position.

So we have this tradeoff. Observations can be sensitive to errors but adding additional sensors all over your system can be expensive in cost or weight or complexity or whatever metric that is important to your design. So we need to find a way to balance that tradeoff. Which states should we measure and which states should we estimate? If your system is difficult to reason through, the observability equations provide a methodical way to assess whether the states can be observed from the given outputs and a measure of their effectiveness. So you have a way of determining whether you have the right sensors in the right places.

There are a few more things I want to cover here and to do so, let’s consider a flexible cantilevered beam. If you imagine pulling down on the end of the beam and letting it flick back up, it’ll vibrate in some way that’s governed by the mechanical properties of the beam and eventually come to rest on its own after all of the energy has been damped out. Your job is to develop an active damping system that will stop that vibration faster.

You have access to accelerometers to measure the motion and actuators that move a counter mass with a damper to remove energy from the system. And for simplicity, we’ll say that a sensor and actuator come in a single package so they have to be placed in the same location, but where you place them along the beam is up to you. Well, with the exception that you can’t place it at the tip of the beam due to other engineering constraints.

So the question is, where should you place it and how does that placement affect controllability and observability? Well, we might reason that the beam motion will be larger the closer we get to the tip of the beam. So if we placed our hardware as close as we can to the end, it would produce the most motion for the sensor, so it would be easier to sense and allow the actuator to damp more energy. And visually, this looks like it might work.

However, the motion of the beam consists of contributions from a number of distinct bending modes. The first bending mode waves up and down like you’d expect, and then the second and third modes have slightly more complicated mode shapes. But the thing to notice is that our sensor and actuator location is placed directly at a node for the second bending mode. In this case, our original ideal placement is fantastic for the first and third bending modes, but makes the second bending mode both unobservable, since the sensor wouldn’t measure any motion, and uncontrollable, since the actuator would have no impact on this mode.

If we designed a controller with this hardware location, we’d find that no matter how hard we tuned the controller or came up with fancy mathematics, the beam would still vibrate at the second bending mode.

So rather than adding a second sensor and actuator at a location that’s ideal for the second bending mode, a cheaper alternative might be to just move the sensor and actuator to a place that can observe and control all of the critical bending modes. In doing this, however, we’ve reduced our ability to control the first mode and increased the cost of actuation, since the beam doesn’t physically move as much at this new location for the first bending mode. That is, it takes more effort for our actuator to dump the first mode from this location than it would from the other. So we get the benefit of handling the first three bending modes, but at the expense of effectiveness. Perhaps that’s a good compromise, though.

Hopefully, you now have a better understanding of why controllability and observability are concepts that you need to understand and consider when analyzing your system and actuators and sensors.

The equations I showed earlier provide a systematic way of assessing everything I just talked about. They can check for observability and controllability, help you think about the most effective places to add sensors and actuators, and to determine which states should you should measure and which you should just estimate.

And, again, I do think it’s important to understand these equations in detail and how you can perform these analyses in MATLAB because even if you don’t use them, it will be a good foundation on which you can build your intuition. MathWorks has put together a page with links to videos and other resources showing how to analyze controllability and in general work with state-space models. And if you want to learn more about why these equations work, definitely check out Steve Brunton’s Control Bootcamp videos. Links are in the description for everything I just talked about.

If you don’t want to miss the next Tech Talk video, don’t forget to subscribe to this channel.  Also, if you want to check out my channel, Control System Lectures, I cover more control theory topics there as well. Thanks for watching. I’ll see you next time.