NAMUR
5.8 Exception Handling
• 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.
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 InTecharticle:
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 deviceis 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 stepsor actions associated with a state of pro- cessing with natural event boundaries. Normally the phaseboundaries 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. Operationsare naturally related to a distinct regime of production; for example, all processing carried out in one batch unitof a multiunit production line.
Procedure: A user-defined set of instructions whose purpose is to specify the order of execution of operationsand related control functions necessary to carry out the plan for making a specific class of end products (as modified by the formulaand unit descrip- tors). Typically a procedureconsists of a sequence of operationsbut 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 procedureor its subordinate operations. (This definition allows the distinction between the procedurefor a recipefrom 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 operationswhich define the control require- ments of a particular type or grade of product. Specifically the combination of procedureand 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 batchesof a lotare 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 Systemsby 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 termislands of automationreferred 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- sidered an external entity” because it was agreed that a high level of creativity was required, higher than any computer would ever be capable of performing. The PRM allows level 5 for control of several plants when the activities are algorithmic rather than creative. This level does not replace the enterprise level.
Information from the process is digested and fed upward to the next level. Each level uses that information to generate commands directed towards the process. A lower level never tells a higher level what to do. Each level figures out what to do from the information that is presented to it. This decouples the algorithms so that levels can be designed independently, given adequate coordination of inter-level information and command requirements.
Using computers in manufacturing provides the advantage of “control enforcement.”
That is, the computer does what it has been instructed to do all the time, without taking breaks or having a bad day. Well, almost all the time, depending on the com- plexity of the software and its need for maintenance. The hardware in the 1980s was also a reliability problem, which led to various redundancy schemes, which compli- cated the software, and so on.
Each level has to know what information it needs from the process and what com- mands it must be able to give. It also needs to know what commands it has to receive from above, what they mean, and what information to pass up to the next level.
The connections between levels identify the need for integration standards. These standards must define symbols, vocabulary, grammar, and punctuation for messages between layers. Communication between layers may be done by a variety of package
PRM Level ISO Name Function
4 Facility/Plant Production planning and scheduling
3 Section/Area Coordinating production and materials within an area 2 Cell Implementing cell schedule and coordinating stations 1 Station Generating command sequences and regulation 0 Equipment Implementing commands and regulation
delivery systems specified by communication standards, perhaps with the aid of some coordination agents.
The functions range from general business at level 4 to very process specific at level 0.
Level 2 for a continuous process consists of supervisory (as opposed to direct control) functions that optimize setpoints for the particular materials (variations in feedstock) and the set of customer requirements (99.4% pure). Level 2 for a discrete process opti- mizes the use of machines, considering reject rates and possibly tool use and bearing wear. Level 2 for batch control is not mentioned. Obviously, layer 1 is even more equipment specific, and layer 0 is too diverse to be dealt with in a generic manner.
Level 2 and down are considered to be shop floor functions in the ISO model for dis- crete manufacturing. Level 3 coordinates the activities of cells (level 2) below it, which must be specific to the kind of cell being used. Level 4 is a business management function used in all manufacturing businesses, but differing in each as to planning constraints and contents of the schedule.
The PRM characterizes levels 3 and 4 as “Production Scheduling and Management Information,” while levels 1 and 2 are “Control Computation and Control Enforce- ment.” Each layer contains functions for receiving, processing, and transmitting data, as well as for providing one or more human interfaces (visual and reports).
The border between business functions and manufacturing operations functions passes through level 3 somewhere, depending on the organization of the plant. It would have been better to make that a clean separation rather than bury it in a level that must be designed to do some of both.
Chapter 4 of the PRM describes a data flow graph that shows the functions as “bub- bles” connected by directed lines for each class of data to be exchanged. The
“principle of locality” is invoked in order to remove the more general and diffuse con- nections that would make the diagram a uniform shade of gray if they were included.
The principle requires that each bubble be relatively self-sufficient (localized) to reduce the number of connections to other bubbles. Even so, the diagram (Figure 4.3,
“Facility Model,” in the PRM) is quite busy. Nine functional entities are defined:
1 Process Orders 2 Schedule Production 3 Manage Production
4 Manage Raw Material and Energy 5 Manage Procurement
6 Assure Quality
7 Manage Product Inventory 8 Manage Product Costs 9 Manage Product Shipping
These may all be decomposed into subtasks, which are in turn composed of more detailed tasks. Process control is down in the basement level of Manage Production.
The subtasks of entity 3 are:
3.1 Process Support Engineering 3.2 Maintenance
3.3 Operations Control 3.4 Operations Planning
Operations Planning receives the schedule from entity 2, Schedule Production; turns it into a short-term Production Plan; and sends it to Operations Control, which has 19 connections. Entity 3.3 is subdivided into tasks as follows:
3.3.1 Operations Supervision—Set objectives, resolve conflicts, handle people, request maintenance, report
3.3.2 Operations Cost Control—Calculate operating and maintenance costs, maintain balances, report
3.3.3 Physical Process Control—(See below)
3.3.4 Operational Measurement Validation—Measure validity, tag data with quality and time, report
3.3.5 Equipment Monitoring—Assess performance, alarm equipment variables, report performance versus life
3.3.6 Production Optimization and Balancing—Optimize process, calculate material and energy balances
The tasks for Physical Process Control are listed as follows:
• Stabilize process values at defined operating setpoints.
• Alarm operating variables for exceptional conditions.
• Maintain operation against constraints or at specifications.
• Respond to operators’ and process engineers’ requests.
• Respond to emergencies.
There is no exact correlation between the data flow diagram of Chapter 4 in the PRM and the Scheduling and Control Hierarchy of Chapter 3. PRM Table 4-III shows the approximate correlations.