Home | Login | Recent Changes | Search | All Pages | Help

ControllerModels

See also: ManagementMusings, FeedBackTopic

In ManagementMusings BobLee mentioned pattern 2 managers. Good comments, you should go read them if you haven't.

Let me share some thoughts on control, since this is part of my daily job in manufacturing automation. Control comes in 4 basic categories.

No control. This is where things just wander along and happen as they will. If it's a good thing great, if not, oh well. Oblivious is a good word for this. The weather outside might be an example of this.

Next we get into the feedback control categories. This is where some measurement value is selected, and we try to manipulate the system inputs and parameters to achieve that value (also know as the setpoint).

On-off control. This is when there is a desired outcome, but the controller has two states, on and off. As such, when the measured value is less than the desired value, the controller is full on. When the measured value is greater than or equal to the desired value, the controller is off. Due to system inertia, the measured value will continue to rise for a while, then start to fall. Like wise for when the measured value falls below the setpoint. Thus, the system output continuously oscillates around the setpoint. Most home heating and cooling systems work this way.

Continuous control. This is when the controller constantly compares the system output to the setpoint. The controller output changes based on the difference between the setpoint and the system output. There are three components to the controller output.

- The proportional term multiplies the difference by a constant. - The integral term accumulates the difference (with respect to time) and multiplies the value by a constant. - The derivative term measures the rate of output change and (you guessed it) multiplies the value by a constant.

Car speed cruise control systems operate on a continuous control basis.

One drawback to continuous feedback control is that from a steady state condition, an error is compensated for after it happens, instead of the system preventing the error.

Advanced control strategies

a. Feedforward control requires an accurate model of the system. In this case, based on what the inputs to the system are doing, the controller output can change before the system output deviates from the setpoint. This keeps the system output steady during upsets and transients in the system inputs.

b. Feedforward with feedback trim is used when the system model is close, but not close enough. The majority of the correcting occurs using feedforward control, and if needed, a feedback loop will complete correction.

The previous controller models work for many situations in industry. Their strength is when there is a single variable to be measured and controlled. When control situations involve multiple loops, or changing the output upsets another control loop, the system is second order, or the controlled value can't be measured, an advanced controller model is needed.

c. State control. In this controller model, the system is modeled, and the interactions, influencing, and intracibility is solved using a matrix of equations (which represent the various system components).

As MikeMelendez mentioned in ManagementMusings, the controller (manager) output is amplified by the system.

If anyone is interested, there is more to say. DonGray 02/08/2002


Regarding Advanced control strategies, these are applicable to a repeated process, such as an assembly line. The software development process is unique per project [not the same ingredients, not the same output] DeMarco, in Slack, points out that optimization is the enemy of flexibility and innovation. Looks like the Waterfall was an instance of attempting the State Control controller model for software development. I've seen it work in Embedded Systems, where the scope is so bounded, but I've seen it fail spectacularly when the embedded folks decided to take on some "easier" MIS application with the same process that had worked so well for them in embedded. They were totally flummoxed by movable requirement boundaries. BobLee 02/09/2002

Had the management had any inkling that there are other possibilities than what had made them successful in embedded systems, they wouldn't have been there either. They couldn't conceive of needing such a conference! BTW, they were the local Rational Software authorized trainer at the time. Sure looked like "That stuff is for others, not Us!" Sigh! BobLee 02/10/2002


I'm not sure what you're meaning. If you're meaning that there is no one-size-fits-all control model, I agree. If you're meaning that control is not possible, I'm not sure I agree. If your confused about why I choose to start a discussion on systems at the final element, I can definately agree.

As I wondered what else I would say (besides maybe I should have started with some other sub-topic), requisite variety, and models are what have my attention right now.

Models are not reality, but may as well be since they're our internal representation of reality (what ever that may be <g>). The problems with models are numerous; they are simplifications, they become static, they contain errors. But models also have advantages. They serve as check points for incoming information. They allow us to organize our knowledge. They become the basis for our actions. Many people never understand they use models. I have shared some models (most of which are simplistic in the context of human interaction) used in manufacturing automation. Although simplistic (and let me say that simplistic here refers to the lack of degrees of freedom), there are some parts of the models that do apply to human systems. These parts include having a setpoint (knowing what is wanted), a measurement to determine the current value of what is wanted, feedback, and a controller (something to guide the system to more of what is wanted).

Somewhere years ago I read something about requisite variety. Could'a been one of Jerry's book, although I can't put my hands on the exact reference. In systems parlance, variety is the number of states a system can hold. Requisite variety (as I remember it) says that to be able to control a system, the controller must be able to function in all the possible system states. In n-th Order Systems, the MBTI types are ENFP and INTJ. I (the ENFP) CANNOT get into the I space, and have a hard time with J. Rainer is exactly the opposite. When we problem solve together, we are able to achieve more states, and consider more solutions than either of us working along.

Managers need to have a repertoire of control models, and a meta-controller function that allows them to determine when to swap control models. Your example of what works here doesn't work there is to be expected. Had the management been attending the AYE Conference, they might have been able to avoid the problem.<vbg> DonGray 02/10/2002


This reaffirms me in my belief that we learn from our mistakes not our successes. If I can keep that in mind I'll keep trying to attend such conferences to improve the areas where I'm weak, whether I know what they are or not. But then I'm been a father for 32 years with six children (the youngest is five). And I know a lot more than six ways not to get the perfect child. MikeMelendez 020214
<Grin> My youngest is 18. I now feel I'm qualified to say I understand what it takes to be a parent. But if I hadn't started all those years ago ...

People don't necessarily learn from their mistakes. Learning from mistakes requires the feedback from what happened to what was desired. To make things different for the next iteration requires CHANGING something. One definition of insanity is doing the same thing over and over, and expecting a different result. DonGray 021402


I'm going to move some remarks from here to a new page called FeedBackTopic, as they're drifting, and this is a topic in its own right - one we do often at AYE. -JerryWeinberg


Updated: Tuesday, February 19, 2002