Life's a Batch

...and then you plan an intelligent automation solution.

By Dave Christie

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.

Tea batch process overview.

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?

Then, what if there was a way for the system's treatment of the manual devices to evolve as field actuators added in the future? What if all this happened instantly, without anyone digging into the batch code at all? Here's the approach.

Think it Through

Take a basic batch process that has a recipe running from one mix tank to two reactors. Imagine that the operator starts a recipe running on one path using the MIXTANK and REACTOR1. This recipe charges ingredient to both vessels, starts their agitators, transfers material from the mix tank to the reactor, holds for a given time, and then dumps product from the reactor.

Next, imagine that the operator starts the same recipe on the alternate path of this process. On this path, all of the control modules are automatic except the REACTOR2 transfer valve (03XV003).

The first thing the recipe does is initialize MIXTANK and REACTOR2 by closing all their valves. But the control system cannot close manual valve 03XV003. So in this case, the system generates an operator dialogue message requesting operator assistance. This message appears on the operator's console and contains the following information:

• Date and time
• Name of the unit issuing the command— in this case, REACTOR2
• Text instruction to manually close a specific valve—in this case, 03XV003

The reactor's recipe procedure waits and will not proceed until the operator confirms the message.

Now pretend the operator has walked out to REACTOR2 and verified that this manual valve is indeed closed. The recipe then proceeds to its next step. Before doing so, the logic updates the graphic to reflect that 03XV003 is now closed. The valve's color on the monitor changes from green to red.

Later in the batch, when it is time to operate the same valve to transfer from the mix tank, the operator will again receive dialogue messages to OPEN or CLOSE the valve. In this example, this occurs for only one valve, but the same principle applies to any number of manual devices, be they valves, agitators, or the like.

Thus, the control system has overcome some of the problems described earlier. The computerized recipe procedure addresses not only the automatic field devices but also the manual valve. And the system has captured a permanent record of the manual device's operation.

Now move forward in time and imagine that the plant has found enough money to automate 03XV003 and wire it to the I/O subsystem. How difficult is it to update the valve's recipe logic?

The first step is to open the engineering builder for the REACTOR2 unit. This builder contains the reactor's tag name list. The tag name for the feed valve, 03XV003, is preceded by a special character, M, signifying manually operated. Remove the M, then recompile the code and download the unit. No other programming changes are necessary. The process requires about oneminute.

Now the operator starts the same recipe again using the REACTOR2 path. As the recipe proceeds, the system knows that the feed valve is automatic. This time, it operates the valve via the I/O subsystem without generating any operator dialogue messages. Thus, with a single, quick, online change, the batch logic has evolved to reflect the new and changed situation in the field.

What Magic is This?

So, how does all this work? The control system used for this demonstration depicts unit procedures and operations as sequential function charts, with the phase logic constructed in a batch programming language. The concept utilizes characteristics of this language whereby code can cross-reference to actual tag names in the batch unit's tag name table. The language also supports user-written program functions.

Thus, the batch phase might close the reactor feed valve by calling a user-written function and performing the following general logic:

1. Fetch the tag name (M03XV003) corresponding to the generic name (GFEED)
2. Parse out the left-most character of the tag name
3. Test to see whether the left-most character is an M
4. If the character is M,
   • Generate an operator dialogue requesting the operator to manipulate the manual valve
   • Embed the real tag name (03XV003) and desired state (CLOSED) into the dialogue
   • Wait until the operator confirms that the field device has been operated
   • Update the software status of the device (thus causing the valve to show red on the graphic)
   • Return to main phase logic
5. If the character is not M,
   • Operate the valve automatically via the I/O sub system
   • Test for answer back, and generate an alarm if valve fails to respond
   • The valve's actual answer back switches cause the graphic color to update to red
   • Return to main phase logic

That's it—29 lines of code. Because the actual tag name passes to the user function as an argument, one needs only a single piece of code for all field devices. In other words, the same code will work for all the manual valves in the project.

The reactor's recipe procedure waits for the operator to comply with the guide message. A record of the message appears in the history at 3:11:30 p.m. The operator confirmed at 3:13:07 p.m.

There's no Incentive to Wait

This approach has many practical advantages. First, it permits the original design team to create a clean design for the entire process, treating every field device as if it is automated, even if it will initially be manual.

The initial designers' subtle intentions regarding exception handling and sharing of resources are not subject to future misinterpretation. This design, in turn, supports the creation of a complete, electronic recipe for each product.

The combination of computer and paper procedures vanishes. The operators' lives are less confusing, and the recipe auditor is happier.

With this approach, the system provides guidance for all manual actions, be they opening and closing a valve, starting an air mixer, rinsing a vessel, or whatever. The documentation provides invaluable clues for engineers faced with the questions: "Why was this batch off specification?" or "Why are our cycle times so much longer on the weekends?"

This approach allows field devices to become automatic at any time and in any order. Actuators can fit to valves one at a time or in a larger automation phase, such as an entire header.

Significantly, there is no incentive to wait and bundle the activity into a larger project that might face a budget hurdle. Each single device easily changes over to automatic whenever the plant generates a few dollars.

The most important benefit of this method is that it does not require the plant to reengineer the batch logic when a device changes from manual to automatic. There is no throwaway of engineering effort from the original design.

Indeed, all this is reusable engineering. Once the concept works for a given platform, it can move from project to project without modification.

Operators Resent the System

Admittedly, there are potential drawbacks one should consider. First, although it is desirable for the plant's engineering and management groups to log all manual device activities, this can become burdensome for the process operators.

It is easier for them to go to the field and open a valve than to receive a dialog box, go manipulate a valve, and return to the CRT to acknowledge each individual action.

Depending on how conveniently the operator stations are located, the operator acknowledgements can take more time, even to the point of impacting total batch cycle time.

Also, the operators may dislike a system that dictates their every move, regardless of whether management perceives benefits. This is especially true if the control system is installing at an existing facility. Management needs to weigh these competing factors if the number of manual devices begins to creep above one-third of the total control modules.

Another precaution involves the up-front design. This technique makes it very easy and cost effective to add future automatic control modules, with virtually no overhead cost to modify the original logic. However, its effectiveness highly depends on the quality of the initial design.

If the original team does not exercise proper discipline, poorly modularized equipment or faulty treatment of shared resources can create havoc. The team must carefully avoid the detrimental tendency to focus on the automated devices and pay less attention to those that are initially manual. IT

Behind the byline
David Christie is consulting batch applications engineer at Yokogawa Corporation of America in Newnan, Ga. This article emanates from a paper that he presented at the World Batch Forum's North American Conference in Florida.