Another gentle introduction to control loops

So, my favorite reader tells me the diagram of the loop with 432 boxes or whatever "left her cold."

So, here's a little more gentle ramp up to that diagram I did yesterday. The classic model of "causality" is that one thing causes another thing. The "causality" goes only one way. B has no impact on A.

But, sometimes there is "feedback" and B does affect A.
Often, "feedback" is mistakenly described as "positive" or "negative". In control theory, feedback is just information. But since those terms are pretty common, let's review what the users mean by them.
P
Positive feedback (above). Things reinforce each other and we get an upwards spiral of whatever it is. Both sides chase each other upwards. A "virtuous spiral".


B keeps raining on A's parade, and after a while A gives up and stops trying. But, actually, feedback loops have many more different behaviors than those two. Here's a third possible outcome - an oscillating condition that keeps going in "cycles", like the economy or the number of birds in a given region.

Actually, again, in "control theory" the thing called "feedback" is just information. By itself it has no "positive" or "negative" content. All that meaning is actually supplied by some active entity, maybe a person, who has to interpret what that news means.

Take a new driver trying to keep the car on the road. He has a "goal", to stay in the right hand lane (in the US at least). He sees what's going on and responds by turning the steering wheel one way or another. (This is much more dramatic if he is learning how to drive in reverse and steer going backwards for the first time.)




OK, now to get from THERE to the picture I used or the format used in "control theory" textbooks, we need to identify a few more familiar parts and rearrange the pieces a little. Here goes. Let me add a "command" box with"turn left!", and a line called 'visual feedback'.

OK, so keep on unfolding, and add an explicit eyeball. (That's what that is supposed to be in the lower right). In general this is not always a visual feedback, and could be sound or tactile or whatever, so we break out a "sensor" of some kind (in this case, an eyeball).

And, finally we make the step to removing all my effort at drawing cars and people and roads, and get a very dry, abstract looking diagram that looks something like the one below. The"loop" is the part in green. The"controller" is a general term, and in this case, it's the driver of the car. Sticking off the loop, like some kind of side radical group in chemistry, are two boxes - the "goal" of the loop, and some external conditions that make life harder (usually), such as the fact that the road bends sharply to the left ahead.
In real life, there are some additional feedback paths if we look over a longer time window. For example, by picking the right controls of the steering wheel, the driver can pick one road instead of another, which indirectly changes the "road" box.

And, the thing that is following the loop around over and over is a very abstract thing - it's "control". "Control" flows, and like electricity, it can move through solid objects like current flows through solid copper wire. Control can happily leap from one medium to another, now being in a steering wheel position, now in a car position, now in light travelling to the driver's eyeballs, now in neural impulses going to the arm, etc. Control doesn't care who it hitches a ride from.

As I've said in earlier posts on this same subject, this makes it hard to find all the parts of a control loop sometimes. I trace out the parts in a person getting a glass of water out of a faucet in this prior post. (See "controlled by the Blue Gozinta")

OK, but why go to all this effort, you may well ask. The answer is that this can "solve" many problems for us. If we can rotate and stretch the problem around until we can see it as a control loop, then there are software programs that can tell us what could or will happen next, if we push here versus there. We can tweak and tune them. We can design them and redesign them. We can draw on a 100 year deep literature on "what goes wrong and why" so we know a classic problem when we see it. We can realize "Oh this is because we have a lag time between when we turn the boat's helm and when the boat gets around to responding" so we know what needs to be fixed or accounted for.

Or, it can help us design feedback-based interventions, as the IOM has suggested in "Crossing the Quality Chasm" for "microsystems" -- small teams of health care providers. I used a feedback model in my "Capstone" to inform the suggestion of what factors the diabetes team should be considering routinely and to be sure it forms some kind of coherent and complete set of topics while being as compact as possible.
Also, from control systems textbooks we can see quickly why "dashboards" have a very dangerous downside, if the data being used to steer an organization with is 2 months old -- and why that can tend to produce wild oscillations if it's used to steer by.

And, we can design "regulatory processes" and "regulations" that have a snowball's chance in a hot place of actually working, because we did our homework and computed the necessary numbers in the underlying feedback control process we're trying to tweak. Or we can realize there's no point in pressing there, because that point won't budge, and we need to save our pennies and find a better intervention point. We can model "what if" behavior.

That's what this is all good for. It connects a huge problem domain of public health to a huge solution set already found and in place in 'control system engineering" on the other side of campus. It makes the powerful analysis tools Engineers already use daily to design jet planes suddenly useful to redesign health care reimbursement policies. Etc.

As I've said before, to public health and control system engineers - you guys REALLY need to meet each other and form an alliance.