Life's a batch... and then you plan an intelligent automation solution

InTech, Jul 2001 by Christie, David

In an ideal automation project, time is unlimited, and project budgets are generous.

The plant implementing such a project has the luxury of automating all of its field actuators, great and small. These might run the gamut from major charging valves to agitators to small air-operated mixers to transfer valves to wash valves and more. The appropriate actuating solenoids and answer-back switches install, regardless of whether the device operates once an hour or once a quarter.

There are no half steps in this ideal world. If engineering automates the reactor, it also automates its supporting ingredient headers and premix tanks. If train A automates, so do trains B and C.

Reality is complicated

In reality, the ideal automation project rarely occurs. Instead of complete field automation, the partially automated plant is a more common reality. Here's a more likely scenario:

A small, single-reactor chemical plant has been operating manually and has been trying for years to get an automation system approved by corporate. When approval finally comes, money is tight. But it is delighted just to get the reactor onto recipe control, never mind the additive tanks and lesser mix vessels.

The plan is to actuate the key reactor valves and agitator up front. Perhaps the plant can later add actuator kits to additional purge, drain, and wash valves one at a time under a future maintenance budget.

Or maybe in a few years it will lobby for a follow-up project to retrofit all of the ingredient header system. At any rate, it is glad just to get the initial reactor automation system, and nobody is complaining about the longer picture.

Eventually, the plant will produce an off-- specification batch. Engineers will scurry around with clipboards, attempting to deduce what went wrong. But because records for manually operated ingredient valves don't exist, questions arise.

The ingredients charged to the reactor in the middle of the night. How long did it take? Are we sure that HV1007 opened before the catalyst charge began, or after? There is no way to know and no way to be sure what caused the off-spec batch.

Now suppose that despite its limited budget for field devices the plant anticipates all these problems and is clever enough to devise a solution. Although many of the valves remain manual, the plant includes these valves in the recipe procedure. When it comes time for the valve to move, the preprogrammed system issues a command to the operator and waits patiently for a typed-in response from that operator.

Dodging the bullet

Thus, the scheme has centralized the entire recipe and eliminated paper instructions, and the system captures a complete operating record of the operators' CRT responses. It works well enough . . . for the moment. The plant has dodged the bullet without incurring the cost of automating every field device!

The rub comes next summer, when a few dollars become available to automate the first additional field device. Perhaps it is an occasionally used crossover valve between two ingredient headers. What happens now? First, the plant engineers, who perhaps were not deeply involved in the initial batch design, must locate and remove the operator message for that valve.

This is probably not too hard-just find it and comment it out. Then comes the more difficult aspect of modifying the logic of existing batch operations that depend on the valve. Now people are messing in the program code itself, which may be quite complex and finely tuned to start with.

The person making the modification may not be aware of the design criteria, standards, or nuances of the original design. But somehow he gets it done, and after working out a few glitches, the new automated valve performs as desired.

Three months later, a bit more money comes available to automate the 12 valves on the water header. What now? The staffers go through the same drill all over again. Then the next year, the Phase II budget is approved to automate that second train, which was manual until now.

Over the course of time, these piecemeal, evolutionary changes probably deviate from the original, elegant design of the operation logic. The system requires patches, the commenting out of code, and work arounds. In the end, the system loses some of its flexibility and becomes increasingly difficult to modify.

To eliminate their own pain, the plant people stop asking for more automation budget, and the system comes to a suboptimal, steady-state condition. Their feeling is, "Pleeeease don't give us money to automate Train 3."

What if the application design team could treat all field-actuating devices as if they were automated, regardless of whether they were to be electrically actuated, manual, or even nonexistent but planned for future construction?

A completely integrated, well-thought-out design could then develop that would serve both present and future needs. Upon initial start-up, what if the system could automatically distinguish the nonautomated actuators and issue operator dialogues to manipulate them?