Gentle primer on feedback control loops

Here's yet another pass at the basic concepts using mostly pictures. Let me know if this works better for you or your students! I can adjust what I'm putting here to your needs and interests, but only if I get feedback!

The first picture shows rising and falling output. This is often what people mean or think of when they talk about "positive" and "negative" feedback.

Unfortunately, it's also their concept of where the "feedback" concept stops, so they missed all the good stuff.

The next picture shows converging output as a result of a simple control ("goal seeking") feedback loop.

The output rises or falls to some present value or "goal".

Then, the system can be "tweaked" a little so it converges faster on the goal, but that often will result in overshooting and coming back with a little bit (or a lot) of bouncing.

The next picture, of the car getting to a hill from the flatland below, is supposed to show how a speed control system should do a good job of maintaining the same speed, even when the outside world changes a lot.

Then the picture of the car going up and down the mounntain explains more about that. Without speed "control", the car would slow down going up the hill, and speed up a lot going down the hill. Instead, the speed is almost constant.

But, this whole effect of locking down or "latching" or "clamping" a value, such as speed, to some predetermined value is really confusing to statistical analysis. The effect is that a variation that is expected to be there is not there. There's no trace of it. So far as statistical analysis shows, there is absolutely no relationship between the slope of the hill and the speed of the car. Well, that's true and false. The speed may not be changing, but the speed of the engine has changed a lot.

The same kind of effect could be seen in an anti-smoking campaign. The level of smoking in a region is constant, and then you spend $10,000 to try to reduce smoking. The tobacco companies notice a slight drop and counter by spending $200,000 to increase advertising. The net result is zero change in the smoking rate. Did your intervention have no effect? Well, yes and no.

The output (cigarette sales) has been "clamped" to a set value by a feedback control loop, so it varies much less than you'd expect. Again, this is hard to "see" with statistics that assume there is no feedback loop involved in the process.

For that matter, the fact that the "usual" statistical tests should ONLY be used if there is no feedback loop is often either unknown or dismissed casually, when it's the most important fact on the table.

(The "General Linear Model" only gives you reliable results if the world is, well, "linear" -- and feedback loop relationships are NEVER linear, unless they're FLAT, which also confuses the statistical tests, and sometimes the statisticians or policy makers.

The good news is that there is a transformation of the data that makes it go back to "linear" again, which involves "Laplace Transforms", which I'm not going to get into today. But, stay tuned, we can make this circular world "linear" again so it can be analylzed and you guys can compute your "p-values" and statistical tests of significance and hypothesis testing, etc.)






OK, then, I illustrate INSTABILITY
caused by a "control loop" . In this case, a new driver with a poor set of rules thinks ("If slow, hit the gas. If fast, hit the brake pedal."). Those result in a very jerky ride alternating between going too fast and too slow.

Note, however, that the CAR is not broken. The Pedals are not broken. The only problem is that the mental rules used to transform the news about the speed into pedal action are a poor choice of rules - in this case, they have no "look ahead" built into them.


Then I have a really noisy picture that's really three pictures in one.

The left top side has a red line showing how some variable, say position of a ship in a river, varies over time. The ship stays mostly mid-stream until the boss decides to "help". Say the boss is up in the fog, and needs to get news from the deckhands, who can actually see the river and the river banks.

Unfortunately, the boss gets position reports by a runner, who takes 5 minutes to get up to the cabin.
As a result, using perfectly good RULES, the captain sees that the ship is heading too far to the right. (well, yes, that's PORT or STARBOARD or some nautical term. For now, call it "right").

So, she uses a good rule - if the ship is heading too far to the right, turn it more to the LEFT, and issues that command.

The problem is that the crew had already adjusted for the too much to the right problem, but too recently for the captain to know about, given the 5 minute delay. So, the captain tells them to turn even MORE to the left, which only makes the problem worse.

The resulting control loop has become unstable, and the ship will crash onto one or the other shores - not because any person is doing the wrong thing, but because the wrongness is extremely subtle. There is a LAG TIME between where the ship WAS and where the captain thinks it is NOW, based on her "dashboard".

That "little" change makes a stable system suddenly become unstable and deadly.

People who are familiar with the ways of control systems will be on the lookout for such effects, and take steps to counteract them. People who skipped this lesson are more likely to drive the ship onto the rocks, while complaining about baffling incompetency, either above or below their own level in the organization.



The last picture shows some of the things that "control system engineers" think about.

These are terms such as "rise time", "overshoot", "settling time", and "stability". And Cost.

These terms deal with how the system will respond to an external change, if one happened.

But a lot of the effort and tools are dedicated to being sure that the system, as built, will be STABLE, and won't cause reasonable components, doing reasonable things, to crash into something.

This kind of stability is a "system variable" in a very real sense that is lost when any heap of parts that interact is called "a system." It is something that has a very real physical meaning It is something that can be measured, directly or indirectly. It is something that can be managed and controlled, by very small changes such as reducing lag times for data to get from person A to person B.

And, my whole point, is that this is something people analyzing and designing organizational behavior and public health regulatory interventions should understand and use on a daily basis.

Maybe we need a simulator, or game, that is fun to play and gets people into situations where they have to understand these concepts, on a gut level, in order to "win" the game.

These are not "alien" concepts. Most of our lives we are in one or another kind of feedback control loop, and we have LOTS of experience with what goes right and wrong in them -- we just haven't categorized it into these buckets and recognized what's going on yet.

One thing I will confidently assert, is that once you understand what a feedback control loop looks like, and how to spot them, your eyes will open and the entire world around you will be transformed. Suddenly, you'll be surrounded by feedback loops that weren't there before.

The difficulty in seeing them may be due to the fact that what is flowing around this loop is "control information", and it can ride on any carrier, as I showed yesterday with the person getting a glass of water. The information can travel in liquids, solids, nerve cells, telephone wires, the internet, light rays, etc., and is pretty indifferent as to what it hitches a ride on.

The instruments keep changing, but the song is what matters.

You have to stop focusing on the instruments and listen to the song.

Control System Engineering is about the songs that everything around us is singing. Once we learn to hear them, they're everywhere. Life at every level is dense with them. And, they seem to be a little bit aware of each other, because sometimes they get into echos and harmonies across levels and seem to entrain each other.

It's beautiful to behold. I recommend it!

W.

Controlled by the Blue Gozinta

For those who are following this discussion of feedback loops, we're most of the way through the basic description of the insides of such a loop.

I showed how a microphone and speaker, or getting a glass of water represented kinds of feedback loops, and made a distinction between dumb feedback loops and smart - goal seeking - feedback loops, also known as control loops. And we showed how control loops are everywhere in nature, made up of almost any substance - animal, mineral, vegetable, light, chemicals -- and they don't care because the principles work regardless. Control is to the loop as a song is to the instrument - you can play the "same" song on almost any instrument, or sing it, and the "sameness" is there.

So, I need to give a name to the four parts that I had in the upper left in this picture I drew yesterday:



The basic diagram that Professor Gene Franklin uses in the book "Feedback Control of Dynamic Systems" is similar to that block diagram, except for pulling the "GOAL" out and lumping the three other boxes "comparer", "model", and "decider" into a single blue box that is labelled "?" in his diagram of a car's cruise-control system for maintaining a constant speed.


So, the diagram is from that book, as quoted by me in slide 16 of my Capstone presentation on patient team management of diabetes control. I think you may need to click on the picture to make it zoom up large enough to read the words.



In any case, the only box on that diagram that is blue is the one that the feedback "goes into", so I'm calling it a "blue gozinta" as just a funny name that rhymes and that no one else is using.

Besides, the word "controller" rings all sorts of bells I didn't want to ring, echoing back to parents and school and bosses, etc.

Well I guess I failed in that already, as I gave the example of "negative feedback " of a student getting "graded" by a teacher for performance on an "exam", and receiving a failing grade of zero percent, which could be quite discouraging and dampen enthusiasm for the subject.

Franklin's picture has two other minor differences from mine. First, he adds "sensor noise" to the bottom "speedometer" box, to emphasize that this loop is all built around a perception of reality, not reality, and the thing that does the perceiving may not be perfectly accurate. That's a pretty good model of human beings or any other regulatory agent or agency.

As John Gall would say in his book Systemantics -- inside a "system" the perception IS the reality. The medical chart IS the patient.

That effect is so strong that the patient can be dying in the bed but caregivers are so busy looking at the monitors showing something else that they don't see the problem -- which is part of what went on in the tragic Josie King case, where an 18 month child slowly died of thirst in the middle of one of the best hospitals in the world. So, yes, we better remember on our diagram that what our senses tell us is going on may be very wrong. We'll come back to that in a big way when discussing how human vision and perception get distorted by all sorts of invisible and insidious pressures - especially in groups with very strong beliefs.

The other difference between Franklin's diagram and mine is on the upper right, where he adds an incoming arrow labelled "road grade". This means the slope of the road, and how hilly it is, not what we think of the road. His point is that the behavior of a car and the speed it ends up going after we have set our end and put the gas pedal where we think it should be actually ALSO depends on factors that are outside the car - such as whether it's going up a steep hill.

That will also be a universal pattern. The results of our actions are mixed into the impact of outside actions, which makes it hard to disentangle the two from just looking at the end result. The good news is that there are software programs that can disentangle those two for us.

Anyway, the whole point of this post is to get the "blue gozinta" identified.

This little blue box is the heart of the problem, because "feedback" is really just information, and is not intrinsically "positive" or "negative". In this diagram, the "feedback" is the speed of the car, as measured by the speedometer. That's just a number.

The number becomes "positive" or "negative", leading to "more gas!" or "more brake!" actions, only because the blue box, the controller, the blue-gozinta, compared that number to the desired speed, and saw that it was less than desired. Then the controller had to check a mental model and use some rule like "if we're going too slow, push on the pedal on the right!"
"If we're going too fast, push on the pedal on the left!'

As anyone who has ever taught someone else to drive knows, that turns out NOT to be the actual rule that drivers use to control the gas pedal. The behavior those rules and that simplistic model of the world result in is holding down the gas until the car shoots past the correct speed, then slamming on the brake until the car passes the desired speed slowing down, then overshooting and slamming on the gas until the car passes the right speed on the way up, then slamming on the brake, etc. The car jerks back and forth in an unstable and very unpleasant oscillation forever if that's the only rule in use.

However, we can probably all think of organizational policies or laws that have exactly that behavior, and are either too harsh or too lenient, or something, and keep on going back and forth and never manage to get the right setting.

It has been hard to recognize those problems and go

• Hey, I've seen that behavior before!
• That's a "control loop" behavior.
• The way to fix it is to change what goes on in the blue gozinta box.
• What part of the process / law / policy I have corresponds to that box?
• That's where the problem can be fixed.

It's really important to see that there is nothing wrong with the car. The gas pedal works fine, and does not need to be replaced. The brake pedal works fine. The speedometer (in this case) works fine. What is wrong is inside the blue box, and is subtle - it's the "mental model" or rule that is used to decide what action to take depending on what information is coming into the box from outside.

And, the realization is that a very simple rule, a dumb rule, doesn't accomplish what we want, but a slightly better rule will make the very same parts behave correctly together.

The better rule requires a little more brains inside the box. We have to track more than just how fast we are going and how fast we want to go -- we have to figure out how fast we are converging on the goal, and start letting up on the gas as we get near the target speed, before we even get there.

The controller needs to "plan ahead" or "look ahead" and react to something that hasn't happened yet.

This seems to fly in the face of science and logic. How can a dumb box react to something that hasn't happened yet? We can't afford the "glimpse the future!" add on module, at $53 trillion.

Ahh, but here's another wonderful property of feedback loops. What goes around comes around. We've been here before. Nothing is new under the sun. The past is a guide to the future.

Either putting out the garbage can causes the garbage trucks to come, or we can learn the routine well enough that we can predict when the trucks will come based on past experience. It turns out, in a loop, the past and future become very blurred together.

Being able to recall the past IS being able to predict the future, in a control loop.

We don't just go around a control loop once or twice -- we go around a control loop thousands or millions of times. So, if we have any rudimentary learning capacity at all, we can start to notice certain patterns keep happening. We can detect what always seems to be happening JUST BEFORE the bad thing happens, and use THAT as the trigger event to react to instead.

So, we have a second rule that gets added by experience -- "When you get near the target goal, start easing up on the pressure to change and start increasing the pressure to stay right there and keep on doing exactly what you're doing."

This basic ability to learn from experience is the simplest definition of "intelligence" we can come up with. Do you recall the joke about Sven and Ollie that Garrison Keeler told?

Sven comes by Ollie's house and sees that Ollie has both ears bandaged.
"What happened?" he asks.
"Well", Ollie replies, "I was ironing and the phone rang and I picked up the iron by mistake and held it to my ear!"
"Oh.... So, what happened to your other ear?"
" Ahh.... once I was hurt, I tried to call an ambulance. "

So, the moral of all this post is that the key to the behavior of a system being managed by a feedback control loop is the blue box, the "blue gozinta."

Very simple changes to that box can change a horrible experience into a pleasant ride.

The heart of "Control System Engineering" is figuring out what to put in that box.

For human beings, a second major problem is that little tiny addition of "sensor noise", and figuring out how to prevent, reduce, or account for distortions in perception that can cause the system to be responding to a perception, not a reality.

And, for both, there's another very subtle but very well understood problem, and that is "lag time." I didn't draw "lag time" on the picture but I will in the future.

If we're trying to drive based on the speedometer reading from 5 minutes ago, things will not go well for us. In fact, the more we try to "control" things, the worse they can get.

This is a huge problem. A perfectly stable system that is perfectly controllable becomes a nightmare and unstable and can fly out of control just by there being too much of a lag between collecting the sensor data and presenting the picture to the controller.

Or, in hospitals and business, it's popular now to have a "dashboard" that shows indicators for everything, often exactly in "speedometer" type displays.

The problem is, the data shown may be two months old. We are trying to drive the car using yesterday's speedometer reading at this time of day. When I state it that way, the problem is obvious. But, I can't find any references at all in the Hospital Organization and Management literature about the risks caused by lag times in dashboard-based "control".

At this point, even with just this much understanding of control loops, you, dear reader, should be starting to realize how may places around you these loops are being managed incorrectly.

We're spending a huge amount of effort trying to improve the brakes and gas pedals, when the actual problem is a lag time in the messages to upper management, or that sort of problem.

None of these problems need to be in our face. These are all "Sven and Ollie" problems that we can fix with what we know today.

But that will only work if we're really sure about how control loops work, and how they fail, and can make that case to the right people in the right way at the right time.

Take home message -

Even a very basic understanding of control loops can help us ask the right questions, and realize where the problems may be lurking instead of where they appear to be at first glance, so we don't waste our time barking up the wrong tree.

Especially in complex organizations, the generator of failure is usually not that labor failed or management failed, or that any one person did something "wrong." What is killing us now is that we have a huge collection of "system problems" that are due to things like "lag time" and "feedback". Every piece of the system is correct, but the way they behave when connected is broken. There is a "second level" of existence, above the pieces, in the "emergent" world. Things can break THERE. Most of the systems humans built are broken there, or at least seriously in need of an engine mechanic, because we didn't even realize there WAS a THERE.

Worse, "management" still thinks that discussion of "higher level" problems means that someone is pointing the finger at THEM, and that leads to bad responses.

The problems are subtle. We won't see them unless we spend a little time studying how control systems work, and how they fail. Then, the patterns will be much more obvious, and our efforts will be much more likely to be successful. And, then we can stop blaming innocent people for problems that aren't their fault.

It is, however, in my mind, the fault of the whole enterprise of Public Health if this kind of insight is not taken advantage of when designing regulatory interventions or in helping individuals try to "control" behavior. That, in my mind, would be a clear failure of due diligence.

Or - it would be, if these concepts had been published in the peer-reviewed literature that's the only thing they read and pay attention to.

Which says, it's my fault for not publishing this and your fault, dear reader, if you don't get after me to do so.

After all - I depend on feedback from my readers to control my behavior. So, what I do depends on what you do.

Wow, doesn't that sound familiar?

Two more arguments for unity

I discussed in an earlier post some arguments for why it may be a bad idea to put off efforts to deal with large-scope problems "until we have all the smaller-scope ones completed."

This, again, is flying in the fact of exactly the opposite trend among many business leaders, who have jettisoned concern about long-range planning, or else reduced it to a horizon of 3 months and call that "long-range". And, it flies in the fact of advice from many PhD advisors, who try to train their students to focus on smaller, shorter-term, more "realistic" problems.

The implicit sense is that the total energy and effort required to complete a task gets larger as the scale of the activity gets broader. In mathematical terms, it is assumed that effort to do a credible and useful job is a "monotonically increasing function of scope."

I completely disagree with that, and feel that by the same logic, no one should study astronomy, or even make a map of the stars, until we understand atoms perfectly. Or, perhaps, no one should study sociology and government until we understand everything there is to know about individual people.

It seems obvious, on reflection, that we can learn a lot about people by observing precisely the emergent phenomena around us. We can learn a lot about air by observing the weather, clouds, thunderstorms, and tornadoes that we would have a hard time "seeing" in a beaker of air, regardless how well and how long we studied it.

Also, we would have to explain why it is that it is far easier to describe the equations governing water in pipes in our plumbing than it is to describe molecular quantum mechanics. That, alone, seems to be a counter-example that disproves the hypothesis that larger things must be harder to get a useful handle on.

This is particularly true when large scale phenomena are actually causal, by all our standard definitions of that word, and the small scale phenomena of which the large is composed is not causal. Pretty much any electronic device is an example of that, where we rely on the statistical behavior of "current", without actually caring whether particular electrons move or kick back and chill, so long as most of them do what we expected every time.

Newtonian and Laplacian bases of description.

These are big words but relatively simple concepts. Newton described things in terms of points, so we might describe a ball's motion by listing where it was at time "t" for t=1, t=2, etc. to whatever precision we desire. To describe anything "large" in size therefore takes a "large"number of such measurements, and is correspondingly expensive and difficult.

Note importantly that the Newtonian method is always, literally, "full of holes" at the times we did not specify. It is an incomplete description, but works for many purposes, especially if we "interpolate" and "extrapolate" to "fill in the missing pieces" and "connect the dots."

That's not the only way we can describe the position of a ball. An alternative method, equally capable of being "complete" to whatever accuracy we desire, is to start by stating where the ball's average position will be over the time period of interest. That's the first data point.

The second data point could be the "standard deviation" or other measure of the variability of the ball's position over the time period of interest. (Or, we could pick as second and third data points the maximum and minimum positions of the ball over the time period of interest.)

Now here's an interesting thing. The way Newton described things, with three data points of the temperature today, we'd have the temperature at Midnight, at 12:01 AM, and at 12:02 AM., and not know very much that people care about, regardless how precisely those three measurements were taken. On the other hand, if I tell you the average temperature today will be 83, with a low of 55 and and a high of 92 F, I've also told you exactly 3 things, but they contain global information, not local information, and are way more helpful to you in selecting
clothes to wear, etc.

This is another counter-example, where a global measure is actually far easier and more useful than an arbitrarily precise local measure.

The specification of something, starting with the "low frequency, large scale" average color, then adding successively higher frequency variations around that base color, is basically how the jpeg images are encoded. Again, if a progressive jpeg is downloaded, you may be able to see in the first few seconds that it's not what you want as it emerges from the mist, and move on to something else. Meanwhile, viewers of TIFF images, are waiting for the top row of pixels to arrive, then the second entire row., then the third entire row, etc. You could need to download most of the picture to see what it is and whether you want it.

JPEG's can be arbitrarily precise, as precise as TIFF images, but it is seldom necessary for what humans do with images.

All the above is one set of arguments for why "large scale" properties are no harder than "small scale ones", and are often easier, and should not be neglected just because they are "large."

And, for phenomena that are "context dependent", as so much is, it may be far more valuable to us to get the first few "moments" of a distribution (the average, the standard deviation, etc.)
than to get the first few data points of the time-series. So, it can be far faster for many real decisions we need to make.

And, in physics, there are conserved properties such as "total energy" and "total momentum" that don't care at all how these rearrange themselves at the local internal level, so long as the overall total remains constant as seen from outside.

A completely different case for working from the top-down, instead of the bottom up, is called precisely that - "top down design" and "top down computer programming". A few hundred thousand person years of experience programming have led experts to believe that it is much more effective to describe a problem starting at the top, in very broadest terms with the least depth, and work our way "down" into successively more detail -- than it is to go the other way.

The other way, bottom up, in fact, is viewed as the major source of time-consuming "bugs" and conceptual errors that are very hard to resolve and hard to locate. In fact, if an organization ever gets an "Escher waterfall" shape in place, and realizes it is flawed, they might simply choose to live with the pain of the flaw, because of the amount that has been vested in "getting the pieces right" so far, the pieces that everyone has adapted to and is willing to accept as "the devil we know" rather than "starting over." At that point, as Zorba the Greek might say, we have "the full catastrophe" of a flawed design that no one wants to let go of, even though it is demonstrably broken.

With top-down design, the details rest on the the larger and larger contexts, not vice versa.
This is great, because the things most likely to change are the details, not the largest contexts.
If we rested everything on the details, every time a detail changed we'd have to redo the entire program. If we rest on top-down hierarchy of contexts, usually all but the very last few, the most detailed, remain constant over the life of the program, and the amount of change to code required is minimized. Most of the code, the upper levels, remains stable and validated and doesn't need to be touched. In the "bottom up" world, if you change one detail, you probably need to rewrite everything.

So, what I'm arguing is that these principles seem to apply as well to descriptions and measurements of our social organizations. Top down metrics may be much easier to do and reveal everything we need to know much faster than trying to get a huge number of detailed data points at the bottom levels.

In my mind, then, the mathematics and science argue strongly for working top down, and getting the large conceptual pieces resolved before worrying about the details, not the other way around. This progression seems, also, to match up with what Fisher and Shapiro are arguing in "Getting to Yes", that our problems only seem intractable because we're trying to resolve them at the most detailed level of "positions" when we could and should move up a few levels to "interests", where it is far more likely that we can find common ground.

For these reasons, from the discussion of fraying and gaps in human responsibility of synthesized tasks, and many others, I urge exploration of the "larger issues" at least in parallel with the "smaller" ones.

There are two final reasons I'll add to the mix.

First, although scientists tend to forget it, the entire enterprise of science is a social entity, and, as scientists seem always shocked to rediscover, the enterprise rests on a political and social matrix in which it is embedded.

Put most simply, if the social interests and the scientific interests clash too much, it is the scientists who will be out of jobs, not the society. If the society collapses politically, or has a global thermonuclear war or global biological war, the rest of science becomes moot. It doesn't matter how precise you are when you're dead.

There is, in other words, some timetable, some urgency, to getting sufficient data together to make some very large, very important decisions that will need to be made soon, that will dramatically effect us all. A response to the global rising epidemic of drug-resistant Tuberculosis is one, and what trade off civil liberties should have versus the rights of "the public" to be protected from people who are carrying infectious diseases. Ditto for AIDS.
What we should do about the "middle east problem" is another.

We don't have time for Science to analyze molecules sufficiently well to be able to tell us who to vote for in 2008, and that won't happen regardless how long we wait. The data and factors and variables of interest to us don't even exist at the molecular level. The universe is not deterministic upwards, as physics has shown us finally.

So, if we have some hard, global decisions coming up, we cannot wait for a bottom-up assembly of concepts and fragments of knowledge to succeed, because even if it were possible to happen, which it seems not to be, it would take "longer than we have."

We have, maybe, a decade or two to decide our fate, in some rather permanent and irreversible ways.

Given all the above, this argues that at least some effort should be given to looking for a "top down" approach to understanding how things work and what our options are. In that conclusion, I find myself in complete agreement with the teachings of the Baha'i Faith, which I will close with, as quotes from http://www.bahai.org.

But First, Unity

Is unity a distant ideal to be achieved only after the other great problems of our time have been resolved?

Bahá’u’lláh says the opposite is the case. The disease of our time is disunity. Only after humanity has overcome it will our social, economic, political, and other problems find solution.

Today, several million people around the world are discovering what He means. We invite you to explore His message with us.

I didn't set out to "prove" that the Baha'i's are "right" and that is not why I raise the issue now. I raise it because the group has been focused for 150 years on precisely this core issue of "unity in diversity", the one that the rest of academia is finally recognizing, and the group has studied first hand by direct experience what it takes to make that work in various parts of this actual planet we live on. That experience is hard-won and we don't have time to replicate it.

In that regard, it seems "due diligence" to at least read what they have to say.

W.