From generalist to specialist
BLOG The New Metropolis
C.G. Masi., Contributing Writer -- Packaging Digest, 1/29/2013 6:14:08 PM
One of the characteristics of a chaotic universe—of any chaotic system, for that matter—is unpredictability. You may be able to predict what's going to happen next, but what's going to happen after that is dicier, and what'll happen after that is a "who knows?"
The farther you move into the future, the more unpredictable events become.
To quote Jim Morrison, "The future's uncertain, and the end is always near."
That's a problem for pre-programmed automated systems. If you can't predict events in the future, how can you pre-program your automated system's responses to those events?
The usual strategy is to imagine all possible eventualities, and pre-program routines to, first, recognize them, and then respond to them. That strategy has at least two major problems.
The first major problem is that it takes an enormous amount of code to cover all possible eventualities. By "all possible," we have to mean even those with low probabilities of occurrance. Remember that in the future, the probability of whatever event actually occurs spikes to unity when it happens! Even the probability of a giant asteroid hitting the Earth in the next 20 seconds—which is darn close to zero at the moment—has happened. Ask the dinosaurs.
The second problem is that when the improbable happens, your pre-programmed automated system is up %@# creek! The Applied-Math term for this is "catastrophe."
Happily for automation engineers, the environments around the systems we're asked to create are pretty simple, and not too chaotic. Especially they're very, very predictable compared to the environment human beings are "designed" (by natural selection) to cope with.
That gives automation engineers a really neat shortcut for developing an automated system to perform any given task. The strategy is to first use a super-generalist automated system (people) to do whatever task you hope to develop a specialized automated system to perform. You then watch what the generalist system does, and mimic it with a simpler automated system designed for that particular task.
In other words, set up a manual system, then design your automated system to mimic, as closely as possible, what the humans do.
Experience shows that humans—with their great ability to think outside the box—quickly figure out solutions to the vast majority of surprising events that the chaotic universe throws at them. That provides you, the automation engineer, with a large box, indeed, of pre-programmed solutions.
On the other hand, if you're an industrialist hoping to build a manufacturing facility capable of staying in business for a reasonable period of time, don't forget to include a supply of those nasty, obnoxious, union-joining, break-taking, health-insurance-consuming, benefits-requiring, thinking-outside-the-box-capable humans to save the day when the chaotic universe throws something at your automated factory that it just isn't pre-programmed to handle.
Your stockholders will thank you.
C.G. Masi has been blogging about technology and society since 2006. In a career spanning more than a quarter century, he has written more than 400 articles for scholarly and technical journals, and six novels dealing with automation's place in technically advanced society. For more information, visit www.cgmasi.com.
In an automation system we don't have to consider all of the potential problems, only those that could possibly happen. Thus our challenge is reduced a bit. If we need to verify that a machine move has been made we can use two limit switches, and verify not only that it left where it was and also that it arrived where it was sent. That allows the detection of a large number of failures, both in actuator and sensors. Temperature sensing is a bit more complex, but proving that a temperature is where it is supposed to be can also be done using standard components. Dealing with operator errors can be a lot more complex because those errors can be in a bunch of different subsystems at the same time. Most of the programming for incorrect operator inputs must be handled in the manual portion of the control program, which should be ignored in the automatic mode.
Operator errors not related to command inputs are often outside of the controls area to detect, except as they cause incorrect machine operation and lead to incorrect motions detected. So those potential problems must also include the mechanical design of the machine. This means that controls design must work with both functional design and the mechanical design group. That sort of cooperation should start very close to the beginning of any design project.
William K. - 2013-31-1 15:01:44 EST
No related content found.