• Held—The hold path normally stops all material and energy inputs to the process, so that things don’t get worse. It also does things that are specific to the procedural element that was interrupted. Maximum cooling may be started and left that way, if it doesn’t ruin the batch. Exception logic may issue the Stop or Abort commands. • Restarting—A Restart command has been entered by an operator that has deter-
mined that it is time to start the execution of the restart path. This path has procedural elements that determine if it is reasonable to restart and, if so, restore the material and energy flows to the process and possibly restart the agitator. When the restarting paths are complete, then the state changes to Running.
• Stopping—Procedural control has received a Stop command from an operator or from exception logic. The request is to stop batch processing quickly without endangering people or equipment. The batch may not survive. Execution immedi- ately changes from the normal algorithm to the stop algorithm. If you want to stop batch processing and resume again then use Hold. Stop is intended for situations like a contaminated batch. Each procedural element has a path through its logic that will bring its part of the procedure to a permanent stop. Part of the procedure may be to transfer the unit contents to storage or recovery or waste. When all stop paths are complete, the state changes to Stopped.
• Stopped—Execution of procedural elements is complete for the stop path. If or when the unit is capable of starting another batch, then an operator is required to check out the equipment before giving a Reset command to enter the Idle state. • Aborting—Procedural control has been given an Abort (or Emergency Stop) com-
mand, usually because there is imminent danger of something bad happening to equipment or people, like a cracked vessel or pipe. It doesn’t matter if the batch survives and there is no orderly shutdown. Execution immediately changes from the normal algorithm to the abort algorithm. Inputs of material and energy are stopped abruptly. Some material may be added that kills the reaction, especially if it is exothermic. When all abort paths are complete, the state changes to Aborted. • Aborted—Execution of procedural elements is complete for the abort path. An
operator is required to check out the equipment before giving a Reset command to enter the Idle state, which means that the unit is capable of starting another batch. There may be a lengthy delay while Maintenance fixes damaged equipment. • Complete—There are no more procedural elements to execute on the normal path.
The Reset command returns the state to Idle.
The following is a list of commands that may cause the changes of state shown in the diagram of Figure 9-3:
• Start—Enter the Running state. Ignored in any state except Idle. • Pause—Enter the Pausing state. Ignored in any state except Running. • Resume—Enter the Running state. Ignored in any state except Paused. • Hold—Enter the Holding state. Valid only in Running, Pausing or Paused.
• Restart—Enter the Restarting state. Ignored in any state except Held.
• Stop—Enter the Stopping state. Valid in any state except Idle, Completed, Stopping, Stopped, Aborting, and Aborted.
• Abort—Enter the Aborting state. Valid in any state except Idle, Completed, Stopped, Aborting, and Aborted.
• Reset—Enters the Idle state. Signifies human approval of readiness to start another batch. Valid only in Completed, Stopped, and Aborted.
5.8 Exception Handling
An exception is anything that prevents normal processing of a batch. Any control level may be designed to detect and handle an exception, as appropriate. Most excep- tions are sensed by equipment entities, but some exceptions cannot be detected. The equipment doesn’t know about the product and doesn’t know the consequences of an underfill or a temperature overshoot. Product exception detection and handling must be designed into the recipe procedure.
Four facets of exception handling must be investigated during the design phase of a project:
1. Determine the exceptions that could occur in the equipment and in the products. 2. Describe how each exception will be detected and what could prevent detection. 3. Plan how to handle each exception.
4. Plan how to recover from each exception.
Most of the exceptions are handled by commanding procedural control to Hold. This gives the operator time to evaluate the situation and take action. Hold would nor- mally be used when a valve fails to confirm its position. Product exceptions usually mean that the product is bad, so procedural control is commanded to Stop the process. If the problem is a shortage of material, Hold may be used while a smaller batch is set up. Detection of an exothermic runaway merits an Abort command, as does a broken weld or a bearing seizure. Interlocks and safety systems are used to handle control failures. Hazardous conditions require their own special review proce- dures, which may produce a list of exceptions for process control to handle.
Summary
This chapter discussed production schedules at the cell level. Discussion of the users of production information led into the difference between batch and common infor- mation as well as between batch history and batch reports. Schemes for assigning equipment entities using allocation, acquisition, and reservation were described. The more complex assignment methods of arbitration, priority, and preemption were pre- sented. The modes and states of basic and procedural control were discussed, with emphasis on the states of procedural control. The chapter ended with a brief intro- duction to exception handling.
88 Perspective and
Review
Introduction
Chapters 6 through 9 of this book have presented the material in Sections 4 and 5 of ANSI/ISA-88.01. Different words and points of view were used with the intent of clar- ifying the words and figures in 88.01. Sometimes alternatives were presented, in the hope that SP88 might consider them for the next revision of 88.01. Chapters 1 through 5 presented introductory material on processes, design principles, process control, controlled equipment, and recipes. This was done partly in order to make explicit those things that are taken for granted in 88.01. SP88 had enough to do with- out dwelling on the past, but each member of SP88 had some understanding of what each considered to be the fundamentals of batch control. Then SP88 went about the work of updating those fundamental concepts where appropriate.
This chapter provides some idea of where things were before 1980, as well as the developments during the 1980s that affected the work of SP88 and gave them shoul- ders on which to stand. This recapitulation of the history of batch control appears here in order to prepare you for the discussion of the Control Activities section of 88.01 that begins in the next chapter.
Before SP88
The oldest batch control concepts, dating back to the alchemists, are the formula and the procedure, although they were not necessarily known by those names at the time. Alchemists developed procedures for powdering raw materials, reacting things in cru- cibles and retorts, separating liquids with distillation, and separating fools from their gold. All of these survive today in forms significantly altered by advances in tech- nology. For instance, one can now use the Internet to separate a fool from his gold, but the fundamentals have not changed.
All procedures were manual in the days before the Industrial Revolution. Then machines became available to reduce the hard work of grinding and pumping a bel- lows for the fire, but people were still required to do the full procedures. Processes were not greatly scaled up until radio broadcasting made mass marketing possible and automatic regulatory control made scale-ups possible. Relays made automatic
discrete control possible and drum programmers (long used in music boxes) made sequential control possible. These advances did not materially reduce the number of people needed to do procedures because they only replaced the repetitious, do-it- without-thinking parts of processing. Also, relays and drum programmers were not particularly reliable, so operators had to take over at times. More maintenance people were needed to fix things that operators couldn’t fix. There was no procedural control as described by 88.01.
During that same span of time, formulas often contained the names of common proce- dures. At some point, probably in the Baker’s Guild, the formula and procedure were formally separated into a recipe. If a header existed in the recipe, it might have con- tained the source of the recipe. The equipment requirements were understood to be whatever was present in a well-equipped bakery or other manufacturing facility. OSHA did not exist and guild members were taught the procedures, so there was no “other” information. Also, recipes were kept secret because they represented an accumulation of knowledge that might have been won at considerable cost, so there was no need to make them readable by others, and especially not to make them transportable.
World War II accelerated technological development. The digital computer came into general use after the war, first in financial institutions that could afford them but also in technical colleges and universities. As computers evolved, they became less expen- sive, to the point that it was possible to consider them for process control. The greatest room for computational improvement was in continuous processes, so com- puters went into refineries, paper mills, and the like. Digital Equipment Corporation (DEC) and others were producing minicomputers in 1970 that weighed and cost a small fraction of the computers available in 1960. Minicomputers found their way into batch process control, and started a wave of developments in that field. The Pro- grammable Logic Controller (PLC) also became available, which quickly replaced huge cabinets full of relays in discrete manufacturing, starting with the automobile companies. Microprocessors spawned Distributed Control Systems (DCS) and drove control capability into field devices.
Developments in computer control caused changes in control fundamentals. Regula- tory control fundamentals were little changed until model-based controllers
challenged PID for the heart of regulatory control. Discrete control fundamentals were hardly changed because the PLC used the established ladder diagram language, until the Sequential Function Chart and network communications were added. Batch control needed large monolithic programs to implement the fundamentals of recipes, so changes began to be made in recipes that would make programming less expensive and more reliable. Fewer programs had to be written, if they were all similar enough to be directed by values in the formula. For example, a formula value of one meant heating and zero meant no heating in the procedure. Formulas grew from simple lists of inputs and outputs by adding parameters for the single batch control program.
Purdue Workshop WG4
In the 1980s, the Purdue Workshop on Industrial Computer Systems WG4, led by Edgar Bristol, evolved “a standardized terminology that would shape but not constrain practice” (“A Design Tool Kit for Batch Process Control,” InTech, October 1985). This was the first step towards models and terminology that would bring a common understanding to the problems and opportunities of batch control. Bristol writes, “The power brought to the world of continuous process control by the simple block diagram has not yet been made available in the batch environment.” Two years of work produced definitions that have held up pretty well. The following terminology definitions are quoted from the InTech article:
Process equipment terminology
Batch unit: A group of interrelated process components operating as a subprocess
(for carrying out one or more processing operations).
Device: A combination of basic elements, both analog and digital, that are treated in
terms of a single integrated control objective and that can be set in one of several col- lective states or values. Typically the device is chosen by the user to be simple and general purpose so as to fit in many applications.
Loop: The assembly of I/O equipment, algorithms and control modules used for oper-
ation of analog feedback regulatory control functions.
Processing action terminology
Step: The lowest level term which describes an operator observable event or action. Phase: A sequence or collection of steps or actions associated with a state of pro-
cessing with natural event boundaries. Normally the phase boundaries represent points of process transition, hold, or activity. The boundaries define major milestones and possible points of safe intervention.
Operation: A major programmed processing action or set of related actions, normally
consisting of one or more phases. Operations are naturally related to a distinct regime of production; for example, all processing carried out in one batch unit of a multiunit production line.
Procedure: A user-defined set of instructions whose purpose is to specify the order of
execution of operations and related control functions necessary to carry out the plan for making a specific class of end products (as modified by the formula and unit descrip-
tors). Typically a procedure consists of a sequence of operations but may include other
computations.
Process management terminology
Formula: The necessary data and procedural operations which define the distinct
control requirements of a particular type or grade of product. For example, a formula might take the form of a list of parameters for control but could include modifiers to
the procedure or its subordinate operations. (This definition allows the distinction between the procedure for a recipe from its data.) [Note: There must have been at least one alchemist in the group because the separation of formula and procedure is optional.]
Recipe: The complete set of data and operations which define the control require-
ments of a particular type or grade of product. Specifically the combination of
procedure and formula.
Unit descriptor: A set of parameters related only to the equipment that particularize
the quantities and identify the specific points or loops referenced generally in the pro- cedure. The initial and final equipment states and values are included.
Activity: The actual production of a batch in progress, resulting from a particular recipe, set of unit descriptors, and set of operator entered data.
Batch: The product which is produced by one execution of a recipe.
Lot: A collection of batches prepared using the same recipe. Typically, all batches of a lot are prepared from the same homogenous source of raw material.
Campaign: The total production run of one product, for example, for a single order or
season, consisting of one or more lots.
(This ends the excerpt from InTech.)
NAMUR
At about the same time as Purdue Workshop WG4, NAMUR WG6 was working on the material first published in 1987 that became NE 33 in 1993. The work detailed a two- dimensional hierarchy for recipes along the lines of reusable parts of recipes. The NE 33 table that summarizes the work is repeated below:
Table 10-1 Hierarchy for Recipes
The work of WG6 also specifically separated recipe and equipment procedures at the lowest level. This is essential in order to make recipe building blocks that can be built into recipes by people who are not completely familiar with the equipment. The NAMUR work significantly altered the fundamentals of batch control. The work receives scant mention here because it was covered in Chapter 5.
Process Source Recipe Basis Recipe Control Recipe Process Stage Partial SR Partial BR Partial CR
Chemo-Technical Unit Operation
Basis Operation Control Operation Basis Function Control Function
Batch Control Systems
The first edition of Batch Control Systems by Thomas G. Fisher appeared in 1990. It was much influenced by the events of the preceding decade but constrained by the available technology. Tom Fisher’s book is the foundation of 88.01.
Computer Integrated Manufacturing
During the early 1980s, the term islands of automation referred to the lack of integra- tion in the world of automation design. Part of the problem was that RS-232/485 was not a communication standard. That was supposed to be fixed by the Manufacturing Automation Protocol (MAP), a product of ISO’s Open Systems Integration (OSI) seven- layer stack model for communication. Sadly, MAP was an idea designed before hardware could support it. It took many seconds for a command to go up the stack and down the stack of intervening nodes before it got to its destination. The operators were not amused. At the same time, Computer Integrated Manufacturing (CIM) became popular as efforts were made to bring effective communication to the islands.
Purdue Reference Model
A major contribution to the CIM work was made by a group at Purdue University led by Ted Williams. They published “A Reference Model for Computer Integrated Manu- facturing (CIM),” also known as the Purdue Reference Model (PRM) in 1989. The PRM focused on information flows and the resulting control activities that could be aided by computers, if not automated. The PRM was followed by the Purdue Enterprise Ref- erence Architecture (PERA), which focused on the life cycle of a plant with concern for the human factors.
The PRM team saw information flows as the key to improving a business. The flows are common in function, if not in details, across all manufacturing businesses. The model is viewed as being all-inclusive. The PRM envisioned information integration to the point that anyone with a “need to know” could have access to any information permitted by security codes at any console anywhere in the plant. This required a relational database, plant-wide communication, data from each level, and decision support systems. These technologies have changed greatly in twenty years, but the principles of the PRM have not. This is because computers have not been pro- grammed to innovate in any useful manner and so the use of computers to run algorithms has not changed.
Material on the PRM is being presented here because the ISA 95 Standard must have interfaces to batch process control. The PRM does not talk specifically about any kind of control, but the supervisory control of continuous processes is plainly visible. It takes a little work to think of how the PRM may be applied to batch control. 95 is based on the PRM, and SP95 does have some batch expertise. More will be said about this in Chapter 16.
The PRM was generalized to cover the functions at any plant. It recognized that much of the model could be adopted without using expensive computers. Once the busi- ness became comfortable with operating more in line with the model, then computer
systems could be purchased, programmed, and integrated at a rate that did not dis- rupt the organization. See Chapter 10 of the PRM for an example of how this worked at Monsanto, and how well it worked because the plant people were involved in plan- ning it. Productivity at a plastic fiber plant jumped 50% in three years.
Chapter 3 of the PRM describes the generic functions of a CIM system. These are expressed in a four-layer hierarchy, with the existence of process equipment men- tioned at level zero, as the following table shows:
Table 10-2 Generic Functions of a CIM System
The equipment layer was set outside of the PRM “because of wide differences of equipment and functions between different industries.” The enterprise level was “con-