In a series of posts (Part 1, Part 2, Part 3, Part 4, Part 5, and Part 6), we have introduced the idea of feedback control as a way to keep complex systems on track, even when subject to uncertainty and change.
It is easy to be confused at this point, and to think that feedback is nothing more than an “adaptive system” that can modify its behavior in response to changes in its environment. But that would not be right. It depends on what quantity you are monitoring! A feedback system does not respond to changes in the environment—a feedback system changes specifically in response to changes in its own behavior. That’s a big difference.
Let’s recall that we try to control a “system”. This system has inputs and outputs. For feedback, we base our control actions on the outputs—we react to what our system is actually doing. If, on the other hand, we monitor the environment (including the system’s inputs) and base our control actions on that, then the resulting control strategy can be called “feedforward”.
Let’s make this concrete. Consider a server farm, handling web requests. In such a situation, a typical quality-of-service metric that we want to maintain is the average response time for each request. We want to keep this response time constant, even if traffic spikes.
For feedback control, it is necessary that we monitor the response time (that is, the actual quality-of-service metric), and base our control actions on that: as the response time begins to deteriorate, we add more servers. But if we only monitor the intensity of request traffic arriving at the servers and base our control actions on that, it’s not feedback, it’s feedforward. Why? Because we did not take the system’s actual behavior into account, only environmental factors.
This matters, because for feedback, we need to know less about our system. We only need to know: if the response time deteriorates, then add servers. (And if this doesn’t help, add more.) With feedforward, we need to know how many servers to add for a given increase in traffic intensity. And there’s the rub—usually, this information is not available with sufficient accuracy. For feedforward, that’s crippling. For feedback, it doesn’t matter at all: if your initial action didn’t help, add more.
But now there’s a problem: the behavior of feedforward systems is always simple. The behavior of feedback systems is often not simple. Feedback bases its actions on the output of the system—in other words, it is always somewhat delayed. And if things have changed in the meantime, then feedback is capable of creating exactly the wrong control actions at exactly the wrong moments. If this happens, the system either swings violently (adding servers now, shutting them down a moment later), or blows up completely.
Unfortunately, a naively built feedback controller is highly likely to show this sort of bad performance. To avoid it, it is necessary to have a deeper insight into the behavior of feedback loops in general, and to use the proper methods to “tune” the controller appropriately for each intended application. (This refers to the controller tuning methods described in an earlier post.)
In summary: feedback is a particular method to implement self-adaptive systems, but not every self-adaptive system is based on feedback principles. Systems based on feedback principles are more reliable than systems that only take environmental factors into account, but also exhibit more complicated behavior and require appropriate “tuning” to work well.
Is feedback therefore a method to achieve “optimal” behavior? That’s a question we’ll address in our next post. Stay tuned!