Batch Control Systems: Design, Application, and Implementation

batch front of book copy.qxd

4/24/2006

10:50 PM

Page xix

Preface This book is the second edition of ISA’s Batch Control Systems: Design, Application and Implementation written by Thomas G. Fisher and published in 1990. Twenty years later, process engineers still select batch processing for products that can’t be made continuously or discretely. Biotechnology has been added to the list in a big way. Hardware prices have come down, but vendors no longer own the computer-related technology. System prices will not go much lower. Field devices have enough metal work in them that they will not go much lower. Raising the price is the cost of software development, even though tools for doing software are improving. Twenty years ago there were few standards applicable to batch control. RS-232 was an electrical standard, not a communication standard. The first edition was the precursor to ISA’s 88 Batch Control - Models and Terminology standard. That standard improved the communication of batch control needs and solutions, and has affected all modern systems. An even bigger change in communication standards, such as TCP/IP and various kinds of fieldbus, has also impacted the way we do batch control today. This book brings the subject up-to-date with a discussion of ANSI/ISA-88.01-1995, Batch Control Part 1: Models and Terminology, as the central part of batch process control. This is basically a new book, because many of the original subjects were either made obsolete by advancing technology or redefined by SP88. The focus is batch control, but some of the techniques will improve any kind of process. Tom Fisher died in 2001. ISA asked me to update the book, now that 88 is widely recognized (but not widely understood). Tom wrote the first edition with what was available in the eighties and two years of SP88 meetings, led by his Lubrizol colleague, Rick Mergen. The book influenced SP88 to the extent that Tom’s work was a starting point for many of the discussions that eventually shaped the standard. I hope that this book is the second edition that he would have written, but perhaps he considered ANSI/ISA-88.01-1995 to be his second edition. Tom was responsible for founding the committee and was the recognized leader, serving as chairman for several years and as editor for many more. Although Rick and Lynn Craig served terms as chairman and left their own marks on the standard, Tom was the chairman and leader during the most critical period of SP88’s growth. That period included debates that defined most of the fundamental principles of 88. Tom served as the editor from the committee’s inception until his untimely death. He saw ISA-88.01-1995 published as a national and as an international standard. Tom also

xix

batch front of book copy.qxd

4/24/2006

10:50 PM

Page xx

served almost three years as chairman of the World Batch Forum, a group formed to spread the knowledge of ISA’s 88 series. Most of us know that standards do not create themselves. Strong leadership is required, with extra skill in herding cats that all want to go their own way. Creative leadership is required when no standard exists. This is not to say that 88 was created from thin air. Human history is a story of incremental progress, with the occasional major setback. Isaac Newton said, “If I have seen further it is by standing on the shoulders of Giants,” and many have found it fitting to apply that saying to their own subject. 88 was based on the work done by giants like Reiner Uhlig of NAMUR and Ted Williams of Purdue. 88 was also based on the work of many who have labored by the vats of a wide variety of batch processes. The analogy of standing on tall shoulders implies a certain instability. Perhaps it is more accurate to think of laying bricks in a wall. Many people have worked on batch process control over the years, each laying one or more bricks to contribute to the height of the wall. The result would have been a mess without leaders to keep the wall straight and level. SP88 has laid a lot of brick, more or less straight and level, but the wall isn’t done yet. Bill Hawkins August 2005

xx

batch chap1.qxd

4/24/2006

10:54 PM

Page 1

Chapter 1

Introduction to Manufacturing Processes The goal of this book is to explain batch process control as specified in ISA’s 88 Batch Control standards. It begins with that goal in the distance, so it looks attractive and interesting instead of the slithering mass of slippery details that it actually is. By the end of the book, most of the details will have stopped slithering and revealed their true nature. It is not possible to pin them all down, of course, because people will do unique things. Batch process control refers to one of three classes of manufacturing processes: discrete, batch, and continuous. This chapter will introduce some concepts to help you to identify processes, with examples to illustrate them. It will clarify the 88 definition of a batch process and briefly cover other kinds of processes. Finally, this chapter will discuss how to use this process knowledge to define boundaries in a set of processes that will simplify process design. The result of reading this chapter should be that you can at least tell a batch process from a buffalo, much like the Gilbert and Sullivan’s Modern Major General who could “tell at sight a Mauser rifle from a javelin.”

Manufacturing Manufacturing transforms raw materials into different forms that have more value than the materials that went into them. Whether the result is useful depends on your point of view. Lumber is manufactured from trees. Titanium ingots are manufactured from Australian beach sand. Aircraft are manufactured from parts manufactured from titanium ingots, among other things. Fuel is manufactured from crude oil that was manufactured by the Earth at a rate no human manager would tolerate. Manufacturing is performed at facilities whose locations are determined mostly by customer demand, shipping distance, and the complexity of the manufacturing process. Nobody manufactures aircraft from beach sand or houses from trees at a single location. These facilities are called “plants,” “sites,” or “plant sites.” Site refers to an area of ground and plant refers to a container for processes, so it is possible to have several plants on a site.

batch chap1.qxd

4/24/2006

2

10:54 PM

Page 2

Chapter 1

Process Process has different meanings in law, medicine, business, and computer science. In this book it is used as a contraction for “manufacturing process,” meaning the set of things that are done to incoming materials to produce at least one product that is more valuable than the inputs. In the words of the International Technology Education Association (www.iteawww.org), process is “a systematic sequence of actions that combines resources to produce an output.” As a verb, process means doing the things to materials that will produce products. Plastic toys are manufactured from crude oil using a series of processes. A process performs a part of the total transformation. To put it another way, manufacturing can be broken down into processes. Raw materials are processed into intermediate products that are used in other processes to manufacture an end product. The end product is sold to customers who have it shipped to their manufacturing or distribution locations. For example, the manufacture of lumber requires one process to strip the bark from the logs, another process to saw the logs into rough lumber, and a further process to produce finished lumber. Manufacturing plywood or particle board requires entirely different processes. Processes are divided into three classes. This is so because one of the laws of human nature says that most of the audience will get lost if a book introduces more than three things at one time. The classes are discrete, batch, and continuous: Discrete The product of a discrete process is an object that maintains its shape after processing. Each processed object could be labeled to distinguish it from other products of the same process. Liquids and gases can be packaged so they become part of the output of a discrete process, such as a beverage bottling line. Discrete processes usually resemble assembly lines, in which each part is carried past a machine that does something to it. Batch A batch process is similar to a discrete process in that a sequence of manipulations is performed in order to make one product. However, in a batch process the product is not a discrete part. Batch processes do not involve a constant flow of materials in and out of the process, and the output is normally a homogeneous mass, not discrete objects. After a useful chemical transformation is developed in a laboratory, skilled people reduce the conditions for the transformation to the minimum number required to make the product. These conditions include the amounts of each raw material and the procedures for transforming them. The result is a narrative recipe for making a product. The products of a batch process may be dough for bagels, terephthalic acid (TPA) for polyester yarn, the finish solution for permanent press goods, or the base for various shades of paint. The laboratory process may be scaled up to a commercial batch process in which the beakers and Bunsen

batch chap1.qxd

4/24/2006

10:54 PM

Page 3

Introduction to Manufacturing Processes

3

burners become highly agitated tantalum tanks and multimedia heat exchangers, or something less extreme. Continuous Continuous processes involve a relatively steady flow of materials in and out of the process, and are most efficient when they have reached a steady state. Any sequence of manipulations in a continuous process is confined to startup and shutdown. Continuous processes are developed when customer demand exceeds the ability of batch processes to make the lowest-cost product. Petroleum refining is an example of a continuous process, as is the conversion of fuel into electricity. Many specialty chemicals and some pharmaceuticals cannot be made using a continuous process.

Other Process Topics Do not confuse process with industry. While it’s true that the power, water, and petroleum industries are mostly continuous, they are not entirely so. Though the specialty chemicals, food, textile, glass, mining, and pharmaceutical industries are mostly batch manufacturing processes, their packing processes are discrete. A plastics industry plant may be mostly continuous, batch, or discrete, depending on what it makes. The term discontinuous has been used to categorize a process that is basically continuous, but in which the manufactured product changes frequently within the limits of the process. Such a process lies between continuous and batch. Discontinuous processes require additional controls so products can be changed economically. Examples include the seasonal change from gasoline to heating oil, multigrade paper machines, and the steel rolling mill that follows a continuous casting machine.

Process Classification The purpose of this section is to introduce the classification of processes to those who have not yet seen them or to provide a review for those who are certain that they know what will be said. Knowing the classification of a process helps engineers determine what the terms used in a process mean and the scope of the control that a process requires. This section will apply the three classes of manufacturing processes to a real manufacturing plant, which made blasting caps and other electro-explosive devices in the 1960s. This historical example allows us to discuss the plant’s processes in some detail, because the plant has been sold and the processes are obsolete. While the example is historical, the present tense will be used to describe it. Blasting caps are used to initiate explosions, most often to fracture rock so that it can be removed from a construction or mining site. They may seem an odd choice for an example, but the blasting-cap plant is rich with processes, unlike a boring refinery. Though the plant will be novel to almost everyone, the relevant process classifications should not be difficult. If you can classify the processes in a blasting cap plant, you can classify processes anywhere.

batch chap1.qxd

4/24/2006

10:54 PM

4

Page 4

Chapter 1

Blasting Cap Plant A blasting cap consists of a drawn copper shell about 0.25” (6 mm) in diameter and long enough to contain the detonating ingredients, time delay fuse, and plastic end plug. A pair of wires is attached to the two pins in the end plug, to be connected to a source of electricity. Different lengths of wire are used to accommodate the various depths of the holes that are drilled in the rock to be blasted. The major raw materials for the blasting cap plant’s processes are copper sheet for the shells, bare copper wire for the leads, explosive and time delay powders, plastics for the wire insulation and shell plugs, and fine wire for the bridge wire that heats and sets off the explosives. Figure 1-1 shows a cross-section of a blasting cap.

Figure 1-1 Cross-Section of a Blasting Cap Blasting caps are sold to mining and construction companies with different lengths of lead wires and various time delays between the electrical impulse and the detonation of the cap, including zero delay. When a tunnel bore is being blasted from rock, it is impossible to explode the entire tunnel face at once and still maintain the tunnel diameter. Instantaneous caps are used for a small area in the center of the bore. After that rock is loosened, millisecond-delay blasting caps are used to reduce a ring of rock around the center to rubble, and so on out to the bore diameter. Different kinds of rock require different delays. The plant has the following processes: 1. Shell Plant—Stamping presses draw tubular shells from copper sheet. The length of the shell varies depending on the time delay. The shells are collected in boxes sorted by length. The diameter does not vary. 2. Delay Fuse Plant—A powder mixing process produces a batch of fuse powder with a known rate of combustion. The powder is poured into lengths of lead tubing on a vibrating fixture. The lead tubes are drawn through a die that reduces the diameter to the ID of the shell and compacts the powder. The tubes are X-rayed to detect voids that would fire early or not at all. Then they are cut to length for a specific delay, and samples are tested.

batch chap1.qxd

4/24/2006

10:54 PM

Page 5

Introduction to Manufacturing Processes

5

3. Loading and Pressing Bays—Shells are manually placed into 500-shell press blocks. Each shell is loaded with a measured volume of explosive powder by a machine. The loaded shells are manually placed in a 500-pin press and pressed to compact the powder. The loading process may be repeated with a time delay fuse and is repeated with a second powder. For safety reasons, the operator steps behind a thick wall while operating the press. The press bays have one weak wall to relieve blast pressure, away from the operator, of course. 4. Wire Plant—Spools of thick copper wire are drawn down to #19 gauge wire through a series of dies. When a spool of wire ends, it is butt-welded to a wire from a new spool. The thick wire moves slowly relative to the drawn wire. Two wire drawing stands provide a pair of wires to the insulation extruder. Plastic insulation that has been treated to reduce static electricity is applied to the pair of bare wires in a special die. The result is a pair of insulated wires that are joined by a thin plastic bridge, which can be broken by pulling the ends of the wire apart. The paired wires run through a water trough that cools the plastic and detects pinhole faults. A capacitance gauge that contacts the insulation senses the location of the wire within the insulation, which tells a dead-time compensating controller how to adjust the position of the wire guides. Finally, the paired wires are wound into 5000 foot (1500 meter) spools in about ten minutes. One spool is enough wire to make an average of three hundred caps. 5. Assembly Plant—Assembly is done in three processes. Each process uses several assembly machines that are designed for one of the three processes. A basic assembly machine is a large round steel table that is rotated by a Geneva wheel positioning mechanism, which makes a precision partial rotation and stops. The table carries as many fixtures for holding the part to be assembled as there are stops on the Geneva wheel, typically six to twelve. Assembly operation stations are precisely located around the table in fixed positions. A part is placed in a fixture on the table at the feed station. The three assembly processes are as follows: a. Wire Folding—The table fixture is designed to hold a coiled length of wire on two pins. The feed station winds the desired length of wire around the fixture pins in a figure-eight pattern. The next station strips the insulation from one end of the pair. Next, a high-potential insulation test reveals any holes or shorts and flips a toggle on the fixture if the test fails. Then a color-coded strip of adhesive paper is wrapped around the center of the figure-eight coil. Finally, test rejects fall into a recycle container, and good product is stored in boxes. Each wire bundle will become the lead wires for one blasting cap. b. Plug Molding—5.5 mm plastic plugs are cast for the shells around two tinned copper wires. A fine wire is then welded to bridge the two wires in the plug. The bridge wire will contact the sensitive explosive. Each plug is pressed into a loaded shell. The fixture is designed to contain an explosion.

batch chap1.qxd

6

4/24/2006

10:54 PM

Page 6

Chapter 1 Some empty assembly stations provide time for a delay cap to detonate. Basic cap assemblies that pass a bridge-wire resistance check are boxed for transport to the final assembly machine. c. Cap Assembly—The folded lead wires are welded to a basic cap assembly. Plastic insulation is extruded over the welds, the bridge wire continuity is tested, and the assembled cap is either accepted or rejected.

The plant also makes time-delay caps. This process requires that special powders be mixed to achieve the right delay time. The powder mix is pressed into a lead sleeve, which is pressed into the shell between the bridge wire and the explosive charge. Statistical quality control methods are used because most tests are destructive. That is, one cannot sell a blasting cap that has been given a functional test. Figure 1-2 shows the approximate layout of buildings on the plant site. Explosives plants tend to have small buildings spread out according to the amount of explosive contained in the building. The distances to prevent explosive propagation have been learned from hard experience.

Figure 1-2 Approximate Layout of Explosives Plant

batch chap1.qxd

4/24/2006

10:54 PM

Page 7

Introduction to Manufacturing Processes

7

Characterizing the Processes in a Blasting Cap Plant Now that we have described the plant processes, we can characterize them as discrete, batch, or continuous. 1. Shell Plant—Copper sheets are transformed into copper shells. No chemical change or mixing is involved, although the metallurgy of the copper has changed. The product, a drawn shell, is distinct from other shells, and each shell could have been identified with a number, although this was not common practice forty years ago. The process is therefore discrete because the output is discrete. The press does go through a sequence of operations to make products, but this alone is not enough to make it a batch process. Of course, the operator says that “a batch” of shells has been made when the lid is closed on a box. This is the problem with using common terms. The box is actually a “lot” that can be statistically sampled, so that a bad lot of copper sheet or a bad machine can be identified. 2. Delay Fuse Plant—Powders made elsewhere are selected according to a recipe and mixed to produce a batch of fuse powder that will burn at so many inches per second. This qualifies as a batch process. The powder is poured into lengths of lead tubing, which are drawn through a die. The tubes are 100% X-rayed. They are cut to length for a specific delay, and samples are tested. These are discrete processes. The result is one lot of fuses that will almost certainly all provide the same time delay. 3. Loading and Pressing Bays—Empty shells are filled with measured amounts of powder according to a recipe, and they are pressed to compact the powder to a certain density. The powder is made at another plant, stored in bunkers, transferred to the loading room, and weighed into each shell. There is the following sequence: insert shells, load, press, load, press, and deliver to storage. The sequence must be repeated to make another rack of five hundred shells (a finite quantity). Nevertheless, the rack of shells is not a batch; it is a lot for statistical purposes. Chemistry is not involved, nor is mixing. Discrete parts come in and go out. Loading requires weighing charges of powder, but the powder hopper is periodically refilled as required. The charging process takes a continuous supply of powder and continuously supplies discrete charges to discrete shells. The loading and pressing processes are discrete. 4. Wire Plant—Wire is drawn, insulated, and spooled. These are three separate processes. Wire drawing does not change the chemistry, but it runs continuously for all practical purposes. No sequence of operations is required to make the product, once the startup procedure of threading the dies has been performed. Threading the dies is not a trivial procedure, which is why a butt-welder is included to attach the end of one spool to the beginning of another. Wire drawing is a continuous process.

batch chap1.qxd

4/24/2006

10:54 PM

Page 8

8

Chapter 1 Extrusion heats plastic pellets and mixes them with dye. But, more pellets are fed to the process as plastic is extruded, and no sequence of operations is required to produce product. So, extrusion is continuous. Spooling wire is a process that takes a continuous input and produces a discrete output. There is no mixing or chemical change, but the output can be distinguished from the stream of wire and labeled as a distinct item or part. A sequence of operations is required, but this is typical of discrete processing. The sequence is required to make a physical change in a discrete part. In this example, a wire spool is changed from empty to full.

5. Assembly Plant—No question here: assembly machines that move a discrete part to different tool stations (or vice versa) so as to make physical changes are the essence of a discrete process. The only batch process in the plant is the manufacture of the time delay powder. The rest of the book will provide many examples of batch processes.

Other Process Examples Consider a plant that converts scrap baling wire from hay and cotton bales into high quality iron oxide for magnetic tape. This process is referred to as a “bucket and paddle” operation because it is simple, but it is also highly profitable. There are only a few buckets, so each must be charged with bits of baling wire and secret ingredients, processed according to a secret procedure, and emptied so the next batch can begin. This is a classic example of batch processing: a vessel is filled, sequentially processed to chemically transform the added materials, and emptied before another cycle can begin. A continuous plant may also have sequenced equipment, such as the switch condensers that extract waxy hydrocarbons from the process gas stream. A switch condenser runs for a while with process gas flowing over tubes of chilled water that congeal the waxy product. Then the process gas is diverted to another condenser, and the chilled water is replaced with steam to melt the wax, which drains into a product pipe. The unit is switched back to cold water, and process gas once again flows through it. There is a sequence of operations, but it is designed to allow continuous flow through a set of process equipment. Other examples are gas dryers and centrifugal separators that must be stopped in order to remove product. The result is a continuous flow of product and the sequence never varies, so the processes are continuous. The procedure for starting up or shutting down continuous processes is definitely sequential, probably has chemical changes, and does not have a continuous output. But no oil refinery engineer would call startup a batch process. Startup is viewed as a temporary aberration in the life of a continuous process. The point is that the three categories of manufacturing processes are convenient divisions that make it possible to break a large problem into smaller parts. That is the

batch chap1.qxd

4/24/2006

10:54 PM

Page 9

Introduction to Manufacturing Processes

9

engineering use of categories. Marketing uses them to be able to say, “Mr. Customer, what you have there is a batch process. What we have is far and away the best batch control system available, and you need it.” This bold assertion can be used to bypass all sorts of pesky little details. The following sections will explain how to distinguish a batch process from other processes with a high probability of being correct.

Process Properties The following table presents some properties of processes, in an attempt to find one or two properties that always characterize the correct process. There are other processes in a plant, such as transportation and storage, but they will not be described here. Table 1-1 Process Properties Property

Discrete

Batch

Continuous

Input materials are mixed or chemically changed

Maybe

Yes

Maybe

Input materials are only changed physically

Yes

No

Maybe

Input materials must be fed continuously

Maybe

No

Yes

Product materials leave while materials are coming in

Yes

No

Yes

A sequence of operations is required for normal production

Yes

Yes

Maybe

A recipe is required

Yes

Yes

Yes

One or more production vessels require a mixing agitator

No

Yes

Maybe

Output is multiple objects that can be individually labeled

Yes

No

No

Output is an unbroken stream of product

No

No

Yes

Output requires that the production vessel(s) be emptied

Yes

Yes

No

Input materials are mixed or chemically changed Chemical change transforms the ingredients into materials that have a different chemistry. Mixing or blending transforms the ingredients into a product that is homogeneous, not discrete. A discrete process may cause a chemical change such as oxidation or flame hardening, but the change occurs in a discrete part. A continuous process usually changes chemistry, but it may only cause a physical separation. Input materials are only changed physically Physical change transforms one or more physical properties of the material, such as shape or hardness, or it adds other physical parts to make a different part. Some chemical change may occur, but that is not the principle reason for the process. Separation is a physical change, such as liquid from solid or individual hydrocarbon gases from natural gas. Discrete separation is called “sorting.”

batch chap1.qxd

4/24/2006

10:54 PM

10

Page 10

Chapter 1

Input materials must be fed continuously The law of conservation of mass requires that a process with a continuous output have a continuous feed. The transition from discrete barges or trucks or rail cars to continuous feed is done with a feed storage tank. Filling bottles is a discrete process that may be able to take a continuous feed. Such a process requires multiple filling nozzles, arranged so that a new bottle starts filling as a full bottle stops. Product materials leave while materials are coming in Continuous and discrete processes may be thought of as assembly lines. Input materials go through a series of operations and become exiting product while more material is coming in. Only a batch process contains all of the material that is being added and stops adding material before product is withdrawn. A sequence of operations is required for normal production A set of procedures performed in a prescribed order that may depend on current conditions is a sequence of operations. A discrete process example is the following: If part is in place, lower drill to surface of part. Feed drill to specified depth. Raise drill and signal completion. A batch process example: If reactor is ready, add a measured amount of ingredient A. Start agitator and heat to reaction temperature. Add ingredient B until reaction is complete. Cool to a stable temperature. Stop agitator and wait for permission to dump. A continuous process example: If time is up, divert process stream to dryer A for specified time. Heat and vent dryer B. Cool dryer B. Divert process stream to dryer B and repeat cycle with dryers reversed. A recipe is required All processes require a specification that defines how the product is to be made, including the quantities of raw materials and the specific processing sequence. The difference between the recipes of the three process types lies in the quantity and complexity of the details. A continuous process may have only a few specified products and does not call the specifications “recipes.” A discrete recipe may be called a “bill of materials.” The number of products that a discrete process can make is limited by the degree of specialization of the machinery. A wire folder cannot make washers. Almost anything that can

batch chap1.qxd

4/24/2006

10:54 PM

Page 11

Introduction to Manufacturing Processes

11

be homogenized can be made with a bucket and paddle, so the number of products possible from a batch process may be much larger than for either a continuous or discrete process. True, there are batch processes that are specialized by their physical limits or auxiliary equipment, but a reactor that has a heat exchanger and agitator is able to make more diverse products than the other processes. One or more production vessels require a mixing agitator It is difficult to induce chemical change without some form of mixer. Few discrete processes want to mix parts. A continuous process usually relies on flow to do the mixing but may require the help of an agitator. Output is multiple objects that can be individually labeled The objects may look identical, but each could have a unique label. The size of the label is not a consideration. Output is an unbroken stream of product The output of a bottling line or a pill press may seem continuous because of its speed, but the output is composed of discrete objects. A stream can be gas or liquid or an extrusion of solid material. Output requires that the production vessel(s) be emptied The “vessel” in a discrete process is the fixture that holds the part being processed. It has to be emptied so a new part can be inserted and processed. Continuous distillation must not empty the tower during processing. About the only thing that gets emptied in an operating continuous process is one of a set of devices that sequentially receive the process stream, perhaps to dry it or to separate a crystal slurry from solvent in several centrifuges. A batch reactor is filled with reactants until the required processing is complete; then the contents are transferred for further processing or packaging.

Properties for Process Classification The table presented in the preceding section shows just three properties that are not ambiguous: Table 1-2 Three Unambiguous Properties Property

Discrete

Batch

Continuous

Yes

No

No

Output is an unbroken stream of product

No

No

Yes

Product materials leave while materials are coming in

Yes

No

Yes

Output is multiple objects that can be individually labeled

batch chap1.qxd

4/24/2006

10:54 PM

Page 12

12

Chapter 1

The different processes each have one defining property: • A discrete process has an output of discrete objects. • A continuous process has an output that is a stream of something that is homogeneous. • A batch process does not have product materials leaving while materials are coming in. The other properties in the earlier table may help you to resolve an ambiguity between two processes. The following table shows two properties that each distinguish a batch from a continuous process: Table 1-3 Batch vs. Continuous Processes Batch

Continuous

Input materials must be fed continuously

No

Yes

Output requires the production vessel(s) to be emptied

Yes

No

Property

Batch Process Definition The word batch comes from the Old English word for “bake,” so one of the definitions for batch is “all the loaves of bread baked at the same time” (www.cogsci.princeton.edu /cgi-bin/webwn). The present-day general definition (from the same source) is “a collection of things or persons to be handled together.” The following definition of batch comes from www.bridgefieldgroup.com/glos1.htm, which provides education in enterprise-level matters such as enterprise resource planning (ERP) and supply chain management (this is not an endorsement): 1) In production, a lot or given quantity processed at the same time with the same process parameters. A batch may consist of more than one item number, but all items are considered to have the same characteristics for purposes of traceability. 2) In data processing, a set of files or records gathered and processed together instead of one at a time. Bridgefield Group’s first definition is directly related to the Old English meaning, which could apply to either discrete or batch processing as defined in this book. The second definition refers to the world of data processing, where it means a collection of data, as shown in the following definitions: An accumulation of data or programs intended for processing in a group or “batch,” typically at a later time, and scheduled by the computer—as opposed to “on-line,” immediate processing. [www.aits.uillinois.edu/live/site.xml?document=Glossary/glossaryb.html]

batch chap1.qxd

4/24/2006

10:54 PM

Page 13

Introduction to Manufacturing Processes

13

A group of statements processed as an entity. Execution of DOS batch files (such as AUTOEXEC.BAT) and SQL statements are examples of a batch process. [www.pace.ch/cours/glossary.htm] The following definition of batch is specific to the glass industry, but it is typical of other industry definitions: The mixture of raw materials (often silica, soda or potash, and lime) that is melted in a pot or tank to make glass. Cullet is added to help the melting process. [www.cmog.org/index.asp?pageID=687HPZ] The ANSI/ISA-88.01 standard definition of batch avoids the industry-specific or baking definitions by stating that batch means “the production of a batch.” Specifically, ANSI/ISA-88.01 definition 3.5 reads: 1) The material that is being produced or that has been produced by a single execution of a batch process. 2) An entity that represents the production of a material at any point in the process. A Google search defines entity as “that which is perceived or known or inferred to have its own distinct existence (living or nonliving).” That means that entity can refer to the actual material or to a column in a database structure. Also, an entity has a unique name that differentiates it from other entities. The words batch and lot are sometimes used interchangeably. It is common practice to say, “a batch of [discrete loaves of] bread” or to call a batch of material a lot, or to give it a lot number. The following definition equates batch and lot: In manufacturing production, a quantity scheduled to be produced together; also called a lot. [www.risnews.com/Glossary/glossary.html] The word lot is defined in ANSI/ISA-88.01 section 3.28 as “a unique amount of material having a set of common traits.” This means that a lot is “An identifiable quantity of material or discrete objects having a common set of characteristics.” A batch of product material is almost always homogeneous because it has been thoroughly stirred. A single sample taken from anywhere in the mass of the material represents the properties of the entire mass. Discrete objects have to be grouped into lots to discover the probable properties of any object in the lot. A random sample of objects in the lot is measured to get the statistical properties of the entire lot. If several batches with unique IDs are blended together, then the blend becomes a lot and receives a lot number. An example is a drum of plastic pellets obtained by mixing the output of four pelletizing extruders, each with its own polymerization reactor. The drum is given a lot number and not a batch ID.

batch chap1.qxd

4/24/2006

10:54 PM

14

Page 14

Chapter 1

Batch Process A variety of definitions of batch process can be found. None of them are completely correct, but it will be instructive to see why they are not. 1) A process for carrying out a reaction in which the reactants are fed in discrete and successive charges. [http://www.eere.energy.gov/consumerinfo/ energyglossary.html] An 88 batch is not always the product of a reaction. Paint may be mixed in batches. Reactants may be fed simultaneously, but not while product is withdrawn. 2) Any process on which operations are carried out on a limited number of articles, as opposed to continuous process. [www.windmill.co.uk/glossary.html] Unfortunately, this definition is not any different from that of a discrete process. Perhaps this idea of “batch” is related to baking. 3) Process in which no new material is fed into or removed from reactor vessel. [www.westp2net.org/hazwaste/app/glossary.html] This seems too restrictive. Polymerization reactions commonly add monomer during the reaction. We will clear this up in the discussion of semi-batch operation in the next section. 4) The feed is charged into the system at the beginning of the process, and the products are removed all at once some time later. No mass crosses the system boundaries between the time the feed is charged and the time the product is removed. [www.eng.usouthal.edu/huddleston/che_glossary.htm] This is not unlike definition 3, but the system boundaries could be extended to cover dosing or monomer feed.

Standard Definition We now have enough information to examine the standard definition of a batch manufacturing process. In the ANSI/ISA-88.01 standard, definition 3.7 of a batch process reads: “A process that leads to the production of finite quantities of material by subjecting quantities of input materials to an ordered set of processing activities over a finite period of time using one or more pieces of equipment.” You can see how difficult it is to capture an accurate definition of a batch process in one sentence. We can analyze this definition further as follows: A [manufacturing] process that leads to [results in] the production of finite quantities of material...

batch chap1.qxd

4/24/2006

10:54 PM

Page 15

Introduction to Manufacturing Processes

15

The finite quantity is measured in volume or weight, not as a count of objects. It is not a rate measurement like liters per minute. The volume is usually a large fraction of the volume of the processing vessel. ... by subjecting [measured] quantities of input materials [added at appropriate times] to an ordered set [sequence] of processing activities over a finite period of time... “Finite period” does not refer to the time it takes to produce a product. It means that each item in the sequence takes its own distinct amount of time. At least one of the items is always on the “critical path” that determines how long it takes to make a batch. Each item is either a timed wait of known duration or a process activity that has a deadline. If the deadline is exceeded, the operator is warned that the sequence might take forever if nothing is done. The same thing is true of a discrete process. Only a batch process does not withdraw product while it is adding material. ... using one or more pieces of [process] equipment. All processes use process equipment. The sentence was already too long to add that the batch of material being processed has exclusive use of the required processing equipment. That is, the processing vessel can hold zero or one batch of material, and the vessel’s auxiliary equipment is dedicated to processing that material. A batch process may require a series of production vessels, but each vessel holds no more than one batch at a time.

Semi-Batch Process Batch processes predate the SP88 committee work by many years, as the Internet definitions dissected above indicate. One of them was: “Process in which no new material is fed into or removed from reactor vessel.” This definition is used in academia because it was formalized shortly after the first batch of anything was made. Now it is common to add a material to a reactor while it is reacting, so academia introduced the idea of a “semi-batch process.” An Internet search yields five thousand references to semi-batch in academic papers, but no common definition. How about this one: Process in which new material is fed into or removed from the reactor vessel during reaction. This definition states that the material is fed or removed. An example of feeding during a batch process is the addition of monomer to a polymerization reaction, which is limited by the rate at which heat can be removed. An example of the removal of material during a batch process is batch distillation, where material is removed as distillate until it does not meet specifications or until there is nothing left to remove. These actions are allowed by the 88 definition.

batch chap1.qxd

4/24/2006

10:54 PM

16

Page 16

Chapter 1

Allowing material to be both added to and removed from the reactor means that the process can start like a batch process and then go into continuous reaction as reactants are fed in and product is withdrawn. This goes on until the supply for one of the reactants runs out, and then the outlet valve is closed and it finishes like a batch process. This blurs the distinction between batch and continuous processing. In fact, any continuous process is semi-batch in that sense. The difference lies in how long the process runs before the supply of a reactant runs out. This book will not discuss semi-batch processes further because the or variant is contained in the 88 definition. The and variant can be treated as a batch process that is interrupted by a continuous interval when both feed and product valves are open. Alternatively, it can be treated as a discontinuous process that is interrupted by some batch processing.

Auxiliary Processes Discrete, batch, and continuous are the three manufacturing processes in any plant. They all use equipment to accomplish their functions, but they are not the only users of equipment. Transportation, storage, and utilities enable manufacturing processes to operate, but they are distributed among processes so the equipment on which transportation, storage, and utilities rely is usually not contained within a process boundary. Each has its own set of details that should be separated from process details when boundaries are drawn. A plant’s storage facility uses vessels to maintain the integrity of its contents, in the same way that a boat is a vessel that separates cargo from the sea or a tank separates its contents from the ground. The transportation function uses pipes and pumps to move liquids and gases from one place to another. The materials that cannot be transported by pipe are moved by conveyor belts or vehicles. Pipe routes are changed by using block valves or manual coupling stations. Vehicles that are constrained by rails or roads have routing problems similar to those of piping systems. Other vehicles find their own way from source to destination. A plant’s utilities may provide common materials like water, or may source or sink energy, or they may convert waste products into something that can leave the plant. A boiler house is a utility in which fuel is converted into steam at one or more pressures as required by the processes. Lower steam pressures may be obtained by using turbines that turn electrical generators. A utility may burn fuel to heat water or oil to various pressures and temperatures. Refrigeration compressors may be used to cool a heattransfer medium in order to remove energy from a process. A distillation column may be required to separate recyclable material such as solvent from a wastewater stream. Storage, transportation, and utilities are found on almost all process diagrams. Each has its own set of details that must be contained within its own boundaries.

batch chap1.qxd

4/24/2006

10:54 PM

Page 17

Introduction to Manufacturing Processes

17

Process Boundaries Because of the amount of detail needed to describe, review, locate, purchase, install, test, operate, and maintain controlled equipment, boundaries must be defined that subdivide the processes into manageable portions. The number of details contained on a process diagram must not be allowed to accumulate beyond the capacity of the people who have to deal with them. People may not know that they are overloaded, but when they are, they will leave some details unstudied that may cause processing to halt at some unforeseen combination of events. The details can be segregated for easier comprehension by drawing boundaries around sets of items on a process diagram. If they are to be useful, these boundaries must minimize the interaction of the details they contain with the details of other processes. Points where the classes of processes change are strong candidates for the insertion of a boundary. Consider a specialty baking plant. The output is loaves of bread with different mixes of grains in the flour. The recipe for a particular product, like “Honey Oat Barley Rye Bread,” calls for measured quantities of wet and dry ingredients to be added to an industrial-size mixing bowl at various times. When the dough has the right consistency, the mixer is stopped and the bowl is emptied into a weigh feeder. The feeder drops the correct weight of dough into a series of baking pans on a conveyor belt. The belt carries the pans through a warm oven for rising, then through a baking oven, and finally through a cooler. The loaves are removed from the pans, sliced, bagged, and boxed for shipment. The process that makes the dough is definitely a batch process. Moving individual pans on a conveyor belt through machines that do things to the product is definitely a discrete process. Removing the loaf from its pan and slicing it is a discrete process that probably runs on a separate belt and may include bagging and boxing. The baking conveyor may take the empty pans through a cleaning station and return them for more dough.

Figure 1-3 Sample Specialty Baking Plant

batch chap1.qxd

4/24/2006

18

10:54 PM

Page 18

Chapter 1

In this example, there are at least two boundaries: one around the batch process and one around the discrete processes. Further boundaries may be drawn around the baking conveyor and its stations, and around the slicing conveyor and its stations. The weigh feeder could be a part of either the batch or the discrete process, or it could have a boundary of its own. Baking is a discrete process because individual loaves enter and leave the oven. The combustion process that heats the oven is continuous. The conveyor belts are transfer processes, and so is whatever removes a loaf from a baking pan and puts it on the slicer belt. You can go on drawing boundaries of smaller things, but you soon leave processes behind and get into the details of systems and components, down to a single baking pan or a spray head in the washer.

Summary This chapter has introduced manufacturing processes and developed a checklist for identifying each of the three major processes: discrete, batch, and continuous. It has used examples to show that sometimes assigning the class of a process is a judgment call. The definition of a batch process was also discussed in depth, and some auxiliary processes were introduced. Finally, the chapter introduced the concept of simplifying a process problem into regions with boundaries placed so that there are few connections with other regions.

batch chap 2.qxd

4/25/2006

2:30 PM

Page 19

Chapter 2

Introduction to Process Design and Construction The reason that we have manufacturing processes is that they offer a way to make money. There were processes before there was writing, but they didn’t proliferate until money was invented. The first manufacturing processes used readily available natural materials because no one owned the natural materials or made intermediate products. If a process is to make money, then the value of the incoming materials plus the work done must be less than the value of the product to customers. An early process like copper smelting used free materials and had no production costs because time had no measured value then. Another process may turn the copper into jewelry or axe heads for trade. When a technology change occurs, like the introduction of bronze, the smelter modifies the process to make bronze, and the coppersmith either learns how to work bronze and develops a market for it, or goes out of business. Add in the type of person that just has to own more stuff than anybody else and extend the idea of ownership to land and then mineral rights—oh, and add lawyers to make and interpret rules—and you have the basis for all of human history. So you see, manufacturing processes are important. The health of the planet is also important, but no monetary value has been placed on it. A process begins with a rough design. Sometimes it is a copy of someone else’s design. Some of the industrial spies who take pictures of operating processes are gathering data for design. The rest do it to prove patent infringement. The following is a generic description of the genesis of a project to build a process, whether it is brand new or an addition to or modification of an existing process. The description is followed by an example of a relatively simple but high energy batch process that was built circa 1974.

Initial Steps Many different skills are required to transform a process from an idea into a moneymaker, after the process has been shown to work on a small scale. The first things that need to be established are the extent of the demand for the product created by the new process, the probable duration of that demand, and the possible selling

batch chap 2.qxd

20

4/25/2006

2:30 PM

Page 20

Chapter 2

price. These establish an upper limit for the total cost of designing, building, operating, and decommissioning the new process. Market timing heavily influences the construction schedule. If the dollars and timing are acceptable to top management then representatives from Marketing, Engineering, and Operations meet to determine feasibility and risk. Each representative should be experienced in all three fields as well as dealing with top management. A representative should be able to see the connections between many aspects of a problem that other specialists cannot see because of their narrow training. Ideally, each has grown up in the organization and learned from senior people because they need to be capable of accurate guesswork and to know who has the information to support it. The key factors are analytical and intuitive intelligence, broad experience, and communication skills. Experience must be tempered by the fact that rapid changes in technology can make feasible something that failed only a few months ago. An organization that outsources any of these functions loses the training, experience and connectedness that accumulate with time spent working for the organization’s goals. If only the senior people are kept to write requirements for outsourcing organizations, then there will be no one to replace them. Even if top management expects to grow by buying new companies, when the purchased companies have been stripped and used up, a time will come when there is nothing available to purchase. Such management, frequently encountered in takeovers, replaces the goal of making good products for satisfied customers with the very narrow goal of making money now. If the process appears to be feasible, then the representatives prepare a preliminary project plan with a rough budget and schedule for presentation to top management, since they control the flow from the bucket of money that is the company. After discussions intended to reveal and resolve any unknown negative management factors, the plan is presented at a meeting to ratify the informal decision to proceed. If some negative factor cannot be resolved, then the project dies or goes to the back burner for further simmering, and the representatives go back to being knowledge and experience resources for their branches of the organization chart. Several things happen if the preliminary project plan is approved. Operations names a Plant or Operations Manager, who chooses the necessary people from Operations’ resources to review current project work, answer questions from other groups, and draft changes to the project as necessary. Project Management creates a new project and names a Project Manager who designates the people from Project Management resources that will work on the initial stages of the project, such as scheduling and site selection. Engineering names a Process Engineer for the new project and selects people from the engineering specialties to work on the initial design.

batch chap 2.qxd

4/25/2006

2:30 PM

Page 21

Introduction to Process Design and Construction

21

Other groups, such as Marketing, Information and Accounting, begin making their own preliminary plans. Engineering, in consultation with Operations and Projects, prepares a working process flow diagram (PFD) in enough detail to allow Projects to prepare an estimated budget. Adding a process to an existing plant introduces complications that are not found in a new plant. An operating budget is negotiated with Top Management if everything looks manageable. The project completion date is also set because it affects the budget. If approved, available money and the deadlines begin to make things happen. The Process Engineer meets with counterparts from Operations and Projects to prepare the final, detailed PFD and a detailed budget that provides money for the planning resources and gives a firmer estimate of the costs of major equipment and process operation. Instrument, piping, and construction costs are still just estimated percentages of the approved budget because no detail work can be done until the final PFD is available. Given the final PFD, project deadlines, and budget limits, the functional groups can now start the detailed designs for their functions. The number of groups becomes larger with the addition of Quality Assurance, Maintenance, Information, and other groups from Operations like Safety, Operator Training, Storage, Utilities, and Transportation. The representatives may stay in the design process or go back to what they were doing as the design is subdivided and becomes more internal to the functional groups. Both the level of experience and communication skills become more important as more people become involved. The mix of people will change over the life of the project. Adding a person that has insufficient experience and no one to turn to for help is like adding cold water to a boiler. Momentum is lost and will have to be built back up again. Adding an outside organization after the project has started is like putting out the fire and opening the safety valves, but it may be necessary if consultants don’t help. A successful project depends on a well-understood fixed goal, clear definitions of requirements and cross-functional as well as internal communications. Someone from top management must keep track of the project and show some enthusiasm for it, while refreshing the view of the goal and not allowing feature creep to dissipate the resources before the project is complete. Representatives must periodically review the work in progress to assure that it stays on track toward the stated goal. If your company has only one employee, all of the above still applies. You just have to write notes to yourself from the different perspectives described. Meetings are simplified, but the review function still needs to be scheduled, so that you don’t go too far without looking around.

batch chap 2.qxd

4/25/2006

2:30 PM

Page 22

22

Chapter 2

Process Flow Diagram The PFD is the initial problem statement that starts the detail engineering process. It shows major vessels with the energy and material flows among them, based on estimates of process requirements. Even if the final product is not known, enough information must be available to create a generic PFD because there is much work to be done. Often, the nature of the new product narrows down the choices considerably. Soap requires saponification and a polymer requires monomer injection and heat removal, but an unknown drug requires a general-purpose process. These all have a generic PFD that has to be scaled to the desired production rate. An example of a PFD is shown in Figure 2-1. It is for the TPA Process example below. A PFD is incomplete without a process narrative. This document describes the operation of the process beyond what is obvious from the connections of vessels and the material flows. A caution like “Do not allow the temperature of the heating jacket to exceed that of the contents by more than 50 degrees” would appear in this document. A batch process would have a description of each stage of the process. The PFDs for continuous and discrete processes only need to show the conditions for a given production rate. A batch process, by definition, does not have any continually maintained conditions. A material balance is only possible when levels are not changing, so batch conditions must be shown as snapshots in time. Similarly, an energy balance requires steady heat flows and temperatures. Energy flow for a utility such as steam may depend on where several batch processes are in time. The energy required for or released by the reaction must be known. All byproducts and their properties, including corrosion, must be known. These complications require that the PFD for a batch process be accompanied by a written description of the preliminary recipe that is used for the calculations, including approximate quantities of materials and a procedure for processing the materials. A material and energy balance PFD must be prepared for each major condition of the process, as described by the preliminary recipe. The balances are done on an average basis, like average mass per hour. The vessel and piping arrangement will be the same in each PFD unless the reactor is mobile. A PFD usually names the vessels and specifies the volume and general construction, including any special wetted materials. An example is “R-2207, 5 cubic meters, glasslined mild steel, with a steam/brine heat exchange jacket.” The PFD shows basic piping with maximum flow rates and pressure drops. Measurement and control locations may be shown in a generic manner, with ranges and units but no specifications for instruments. Vessel location is not specified, so there is no location or sizing specified for piping and instrumentation unless it is important to the operation of the process. The completed PFD marks the end of the process engineer’s input to the process, except to answer questions and resolve problems related to the drawing. This is not true if the rest of engineering is outsourced. Now the process engineer must communicate all of the details necessary to have the final process resemble the PFD, to people

batch chap 2.qxd

4/25/2006

2:30 PM

Page 23

Introduction to Process Design and Construction

23

Figure 2-1 Example of a PFD (TPA Process)

batch chap 2.qxd

4/25/2006

24

2:30 PM

Page 24

Chapter 2

who do not even share the goal. All aspects of the outside work must be checked for misunderstandings because people will nod and say, “Yes, I understand” when in fact they don’t know what they failed to understand.

Analysis The process design, as expressed by the PFD and recipe, must be analyzed down to the last little detail. The amount of detail necessary to describe, review, locate, purchase, install, test, operate, and maintain controlled equipment can be overwhelming. Analysis is the art of breaking down big problems into smaller ones. The first breakdown is done by drawing some nonintersecting boundaries around major sets of items on the PFD. The boundaries must minimize the interaction of the bounded details with the details of other processes, if they are to be useful. A change in the class of process strongly suggests a location for a boundary. Consider the specialty baking plant in Chapter 1. The seven labeled boxes and two conveyors in Figure 1-3 are a way to begin the analysis, even though Figure 1-3 is not a PFD. The Solids box conceals details about the kind of solids, their storage and measurement, when to feed what and how much. The Dough Mixer has special agitators (beaters, really) to mix the dough and the assembly must be cleaned and sanitized periodically. The Weigh Feeder may have a nozzle that moves with the baking pan in order to fill the pan properly. The Oven has to be designed to retain heat even though it runs with its doors open. The combustion system has to be properly sized and have the correct distribution of burners. And so on, from process to systems to components.

Piping and Instrumentation Diagram The final PFD becomes a requirements document for the detail designers in various engineering disciplines. First, the major vessels are sized (or selected from pre-owned vessels) so that they can be assigned locations on the construction site. While this is proceeding the instrument engineers begin the process of specifying sensors and actuators in order to find the long lead-time items. When the vessels are sized and located, the piping engineers start laying out the piping runs, after determining sizes and materials from the PFD. A 3-D model of the vessels and piping may be required to assure that pipes don’t occupy the same space as vessels or other pipes. Instrument engineers use the model to choose locations for sensors and valves. All of this activity may cause changes to the vessel penetrations, which causes rework of completed designs. Some engineers even use the model to be sure that there is reasonable human access to the instruments, especially those engineers who have been sent out to start up the part of the process that they designed. A rough example of a P&ID is shown in Figure 2-2. It is for the TPA Process example below. Work can begin on the Piping and Instrumentation Diagram (P&ID) when the model settles down. This set of drawings shows the details of vessel and piping locations, sizes, and materials. It also shows the location of sensors and valves. Different pages of the set are defined by boundaries drawn on the PFD, with a minimum number of

batch chap 2.qxd

4/25/2006

2:30 PM

Page 25

Introduction to Process Design and Construction

25

Figure 2-2 Rough Example of a P&ID

batch chap 2.qxd

4/25/2006

26

2:30 PM

Page 26

Chapter 2

pipes shown connecting to other pages, where possible. When the P&ID settles down, the instrument engineers can develop enough data to specify the sensors and valves that attach to pipes or vessels, and give the specs to Purchasing. Then the model is used to choose locations for junction boxes, conduits, and trenches or cable trays, and these are added to the model to prevent interference. It is expensive to modify the location of a vessel penetration or to rework a section of prefabricated bent and welded pipe after it has been brought to the construction site. Cable trays and conduits can be relocated on site, but the amount of wire ordered is based on lengths taken from the model. The P&ID is the basis for assigning tag numbers to field instruments. Someone takes a pencil and numbers each instrument from top left to bottom right with two digits for the P&ID page number followed by two digits counted from the top left. The last number used on a page may be noted in the notes section of the page. Your plant may require more digits, but this works fine for 500 to 1000 indicators and loops. ISA has a standard for naming tags with prefixes that give the purpose of the instrument, such as FT for Flow Transmitter. Ask for ISA-5. If the first instrument on page 1 of a relatively simple process is a flow transmitter, then its tag would be FT-101. The last tag of a P&ID with more than nine pages might be TT-2734. Computer systems need to allocate memory space for tag names. That space has grown from 5-8 characters at the dawn of the DCS to 32 circa 1995. Now the tag can contain the function and the site GPS coordinates for any instrument, but the 32 characters are usually used to add more hierarchical location information. Each instrument is ordered with its unique tag name, preferably engraved on a stainless steel tag that is affixed to the body of the instrument. This allows each instrument to be tracked through the vendor’s facility to the construction site’s receiving warehouse and then to its correct location in the process. The guy dragging the big pipe wrench on the ground just has to look for a tag number, without concern for the instrument span or materials of construction, and match it with a tag name at a location on a pipe or vessel drawing. This works well for construction as long as nobody transposes digits in all of the order processing. The maintenance department will not have stainless tags for the spare instruments. Spares are tracked by the serial number of the instrument, which is independent of location. The tag name defines a unique plant location and the type of instrument required. A physical digital instrument is uniquely defined by its 32-character Device ID. The stainless steel tags are going away as digital instruments replace analog.

Loop Sheets When the P&ID drawing set has been approved, work can begin on the final level of physical instrumentation details. A drawing is made for each indicator or control loop. Each drawing is called a loop sheet and is identified by an instrument tag number, usually the tag of the transmitter. A loop sheet shows the locations of instruments,

batch chap 2.qxd

4/25/2006

2:30 PM

Page 27

Introduction to Process Design and Construction

27

wiring, junction boxes, cable trays, blockhouse/control room entry points, and control system connections. Some loop sheets even show calibration values and other useful information, such as the things that will be affected if this instrument is disconnected. An example of a Loop Sheet is shown in Figure 2-3. It is for the TPA Process example below.

Figure 2-3 Example of a Loop Sheet The set of loop sheets provides the information necessary to order peripheral items such as junction boxes and spools of cable. The instruments are detailed in Specification Sheets (see ISA-20-1981), which are referenced on the loop sheets. Loop sheets also provide the information required to maintain the sensors and actuators during the life of the process. An operator uses the controller tag to report an instrument problem. A maintenance person uses that tag to locate a loop sheet for that indicator or control loop. Depending on the problem, the wiring may be examined from the control system to the field instrument, looking for junction boxes without covers and cables that have been used as ladder rungs. The instrument may be given a functional test and either repaired or replaced. Sometimes an operator will report a problem because a pressure gage or thermometer does not give the same reading as the transmitter, which costs ten times as much. A good loop sheet will reference or show instruments that give a second opinion, which allows Maintenance to ask the operator about this possibility and to check the less expensive instrument first. If the replacement instrument uses digital communication then it will need to have the proper tag entered before it is installed, along with the correct configuration for the new location. The data that stays with the instrument, such as calibration coefficients, is not changed when the tag is changed. The replaced instrument may be repaired and returned to the storehouse, but the stainless tag on it (if any) is now obsolete.

batch chap 2.qxd

28

4/25/2006

2:30 PM

Page 28

Chapter 2

Example of Process Design and Construction The market for polyester was expanding rapidly in the early 1970s. A new plant for continuously processing xylene into dimethyl terephthalate (DMT) was built with equipment scaled up by a factor of four. A shipment of DMT contains about 10% methanol, which the end user has to remove. In response to customer demand, a new batch process was designed and built that would strip the methanol from DMT and produce terephthalic acid (TPA) crystals. The process was simple—mix the DMT with water and drop the crystals into a slurry tank. The problem was that the reaction was reversible and weak at room temperature. A trade-off was made between yield and the cost of construction materials. The chosen design pressure was 750 psi at about 520°F. The process was developed in a high-pressure pilot plant at the research center. The result was a chemical procedure that quantified the ratios to be mixed, agitator power, pressure and temperature, waste products and a temperature trajectory for cooling and crystallizing. Note that the following numbers and diagrams are memories from thirty years ago. This data was innovative at the time, but the process is obsolete now because it is not the least expensive way to make TPA. Don’t even think about using these numbers for a new design. Process design engineers then worked the trade-offs required to arrive at a vessel size and batch cycle time for maximum production rate. Four batch reactors were required, each 16 feet in diameter and 40 feet high, with 6-inch-thick steel walls. Each had a 75 hp two-speed agitator with two blades on a stepped shaft. A hot water heater and a flare stack had to be in a remote area where open flames were safe. The flare was required for the poisonous gases given off at the start of the reaction. The slurry tank was located below the group of reactors, with a large blowout seal in case a hot reactor had to be dumped. TPA crystals were recovered from the slurry with a centrifuge. The water that was not consumed by the reaction was stripped of methanol and returned to the 750 psi heater. Many batch processes have a jacketed reactor and heat transfer fluid handling. A jacket is impractical with 6-inch thick reactor walls. Steam was used directly in the vessel to heat it up. Final heating was done by the large hot water charge. The DMT charge was also hot, to keep the DMT molten. Cooling was done by a vent condenser, which returned cooled condensate to the reactor. The rate of cooling was regulated by the rate of condensate flow. Initial cooling was done by boiling water to make 150 psi steam. When there was not enough heat in the reactor vapor to make 150 psi steam, the condenser was switched to a 30 psi header and then to atmosphere. You didn’t want to be up on the condenser deck when a condenser switched to atmosphere because the silencer was too small.

batch chap 2.qxd

4/25/2006

2:30 PM

Page 29

Introduction to Process Design and Construction

29

Process Flow Diagram The engineers produced a process flow diagram which was used to calculate material and energy balances for each stage of the process for one reactor, and to provide data for material flow rates for four reactors. The PFD is shown in Figure 2-1. The following material balance for one reactor is shown in the following table: Table 2-1 Material Balance for One Reactor Material

Flow

Density

Time

Amount

Metric

Steam for Heat

30 KPPH

0:20

10 KLb

4.5 Ton

Steam for Sparge

40 KPPH

0:30

20 KLb

9.1 Ton

Water Charge

1000 GPM

0.96

0:10

80 KLb

36.0 Ton

DMT Charge

800 GPM

1.2

0:20

160 KLb

73.0 Ton

Vent to Flare

12 KPPH

0:10

2 KLb

0.9 Ton

0:10

268 KLb

121.7 Ton

Dump to Slurry

2200 GPM

1.5

The Gantt chart four reactors over a two-hour cycle appears below: Table 2-2 Gantt Chart for Four Reactors/2-Hour Cycle Time

10

20

30

40

50

1:00

1:10

1:20

1:30

1:40 1:50

2:00

Reactor 1 Steam

Water DMT

React

Cool

Dump

Reactor 2 end Cool

Dump Steam

Water DMT

React

Cool

Reactor 4 end React Cool

Dump Steam

Water

Reactor 4 DMT

Cool

Dump Steam

React

DMT

React Water

Combining the material balance for one reactor with the Gantt chart produces the overall material balance for one hour of operation: Table 2-3 Overall Material Balance Material

English

Metric

Accum Steam

60 KLb

27.2 Ton

Accum Water

160 KLb

72.0 Ton

Recycle Water

70 KLb

32.0 Ton

BFW to Acc

150 KLb

68.0 Ton

DMT

320 KLb

146.0 Ton

Flare Stack

4 KLb

1.8 Ton

Slurry Tank

536 KLb

243.4 Ton

Liquor

85 KLb

39.0 Ton

Methanol

15 KLb

6.8 Ton

Dryer Vapor

21 KLb

9.4 Ton

430 KLb

195.0 Ton

Dry TPA

batch chap 2.qxd

4/25/2006

2:30 PM

Page 30

30

Chapter 2

Plant design engineers and draftsmen chose locations for the vessels and added the details to support them, providing decks for human access and piping to connect them. A physical model was built to verify that everything would fit together and that maintenance would have access to maintainable equipment. Instrumentation designers used the process flow diagram and physical model to locate and tag process control instruments. An instrument specification sheet was prepared for each tag on the drawing. A P&ID drawing was produced that showed all of the control functions (boxes or blocks) required to support the process sensors and actuators in order to provide the required process control. See Figure 2-2 for a sketch of an example. A loop sheet was prepared for every sensor tag that showed the location of wiring and junction boxes, along with calibration information. See Figure 2-3 for an example. If an operator reported trouble with FC1227 (the 27th tag on P&ID page 12), then Maintenance pulled the loop sheet for FT1227 in order to check it out. Any sequence or interlock logic was referenced to a separate diagram because this was regarded as a separate skill from designing or maintaining control loops.

Batch Design Meanwhile, logic design engineers used the sequence required to process a batch of TPA to produce a list of process stages (called “steps” at that time): 1. Verify that the reactor is ready from level, pressure and temperature sensors. 2. Heat the massive vessel for 20 minutes with flow-controlled high-pressure steam. 3. Charge a measured amount of hot water in 10 minutes; verify level, pressure, and temperature. 4. Start the agitator at high speed. 5. Add a measured amount of DMT to the reactor in 30 minutes. 6. Agitate for 30 minutes; begin venting non-condensable poisonous gasses to the flare stack. 7. Reduce agitator speed and start cooling along a temperature trajectory for 30 minutes. 8. Drain the reactor. A team of process, safety, and instrument engineers took this simple set of process stages and added things to do when something went wrong. They started with those things that might break a reactor, like hitting a hot reactor with cold water and vice versa. Overfilling a reactor would not be fatal because safety valves would relieve pressure, but there was a risk that someone would be in the area when a safety valve let go. Adding molten DMT with no agitation could result in a solid plug of DMT in the bottom of the reactor, making the dump valves useless. Cooling too fast would strain the reactor and the overhead condensers. Rate of cooling was controlled by the

batch chap 2.qxd

4/25/2006

2:30 PM

Page 31

Introduction to Process Design and Construction

31

level of condensate in a condenser. No cooling occurred if the condenser tubes were flooded, so the rate at which condensate was removed controlled cooling. Safety interlocks were designed by a group that was perhaps more paranoid than the optimistic control engineers. This was a high energy process capable of releasing poisonous gas as well as energy, so their job was not trivial. The interlocks varied during the processing of a batch of TPA. For example, the high level shutdown was lower for the water charge than it was for the DMT charge. The agitator had to be at high speed during DMT charging and low speed during cooling. State-sensitive interlocks were built that had simple integrated circuits, which were to be independent of the Digital Equipment PDP-11 that controlled the batch sequence. This activity provided the data for the design of a computer program, along with a list of computer I/O points and their connections to physical process control equipment. Additional logic design was required for the process interlocks and for the fixed sequence for selecting the vent condenser steam header. A process interlock differs from a safety interlock in that it is good if it works (the computer hasn’t gotten lost), but not essential to protect people and equipment. Each step was expanded in detail with reference to control equipment tags. The tags were generic in that the analysis was only done for one reactor procedure. The computer would handle substitution of the correct tags for the reactor to be run, a procedure called “aliasing tags.” Exception logic was designed to detect and handle hold, stop, and abort conditions. Then there was the problem of how to restart the computer while the process was running. On top of that, the existing DMT plant was all analog, untouched by computer control. Each stage had sub-stages (each of which had process actions): 1. Check that conditions are correct to perform this process stage. 2. Perform any setup actions, like clearing a totalizer or setting modes, and start processing. 3. Monitor process conditions and time, generate trajectory values as required, stop when done. 4. Generate and log the report items for the stage. 5. Check that conditions are correct to leave this stage. One of the setup actions was to change targets in a program that ran continuously to handle the process interlocks. In particular, the pattern of valve positions that must be open or closed or could be ignored changed during the stage. The response to a failure was always the same—close all inlet valves and stop making changes. In other words, hold.

batch chap 2.qxd

4/25/2006

32

2:30 PM

Page 32

Chapter 2

Construction When the process design was complete and approved, orders were placed for major equipment and ads were placed for operating personnel. Instrument spec sheets and logic design followed, and orders were placed for sensors, actuators and controllers, including the computer system. Operating personnel began training as plant construction started, the better to see how it all went together. Computer programs were coded and tested, then coded and tested again as changes rippled through the project. Instrument installation and checkout is always on the critical path of a project. First comes the mechanical completion of the vessels, supports, and piping along with equipment like pumps and valves, which are part of piping. Once that milestone has been reached, then instruments can be mounted and checked out. If mechanical completion is late, top management is fully alert and turns its spotlight on the instrument department, which makes it difficult to conceal the normal screw-ups. The insulating crew is also turned loose after mechanical completion, making things more interesting. When everything was physically ready to operate, water was run through the system to flush wrenches and lunchboxes out of the piping, along with drill chips and drawings. Any differential pressure instrument that was installed backwards was revealed. The TPA process required trial runs with hot water to see that nothing broke or leaked under pressure and that the cooling system worked as expected. The computer was allowed to control the second and subsequent hot water runs to flush out bugs in the programs. Finally, the process was ready to turn over to Operations. After the first run with DMT, fine crystals of TPA plugged all of the instrument impulse lines. The capacitance level probes in the reactors did not survive agitation of the thicker product. All pressure instruments in the water loop that used impulse lines had to be replaced with flush diaphragm instruments. The delay was not welcome, except to the computer programmers who were able to add enhancements whose need had become obvious when the process was run. Fortunately, the reactor vessels had spare penetrations at the top and bottom. Two of these on each vessel were used to install differential pressure transmitters with flush diaphragms on six-inch extensions in order to measure level. There was concern that the agitated erosive slurry would wear through the lower diaphragms, and so tests had to be run to determine the rate of erosion. You can imagine the interactions between top management and the instrument department as the project overran the estimated cost and schedule. After the startup difficulties were over, the process ran well for about ten years. Then it was closed down when a competitor developed a different process that made TPA directly with a one percent higher yield.

batch chap 2.qxd

4/25/2006

2:30 PM

Page 33

Introduction to Process Design and Construction

33

Later in this book we will go deep into the details of batch process control. The point of this example is to show that there is much more to realizing a batch process than detailing the recipe and procedure.

Modular Design The section “Analysis” earlier in this chapter discussed the usefulness of boundaries. A module is enclosed by a boundary, and contains the equipment or functions necessary to do a specific job. A module is most useful when it is used multiple times, but it is also useful for unique cases. A module only has to be designed and thoroughly tested once, which is a fine thing for FDA process validation. The operation of a module only has to be taught once, no matter how many times it is used in the process. A physical module is a container for a set of parts, devices, and equipment, with a boundary that is crossed by input and output connections to those of other modules. An example is an automotive alternator. The input is a pulley that supplies mechanical power from a belt. The output is 13.7 volts DC, above a certain input speed. In between is a marvelous assembly of axles, bearings, wire coils, slip rings, magnetic pole pieces, rectifiers, and a voltage regulator circuit. To use the generator, we only need to know where to put the belt and where to get the DC power. It helps to know such catalog information as maximum ratings, but we don’t need to know what goes on inside the alternator module. That knowledge is only required to maintain the module. Another example of a physical module is a television set. Connect it to power and an antenna and a vast wasteland appears, full of people pushing products or promoting themselves. An abstract module is defined by a boundary on a drawing of the contents. It has a defined interface in which lines representing information cross the boundary. Nothing enters or leaves the module without going through an interface. The module boundary is adjusted so that a minimum number of connections determine the behavior of the module. Each line in the interface has a specific behavior for a specific set of conditions at other lines. Think of the pins on an integrated circuit, the connections to a home hot water heater, or the public data for a software module. A module may be copied and used in another location, using the same interfaces with the same functions. If the interfaces or behavior have to be modified in the new location, then the copy is not a copy but a different module. For process control, a module is a closed box (not necessarily physical) that contains a fixed set of things that behave in predictable ways. It has interfaces at the sides of the box, like electrical connectors or pipes. The interfaces carry power, commands, and data into and out of the box. Every interface has defined behavior, so there is no need to guess what is inside the box. A box can be disconnected and replaced with another box of the same kind, perhaps one that has internal changes that improve cost or performance but do not change behavior. The box/module can be said to encapsulate a control function.

batch chap 2.qxd

4/25/2006

2:30 PM

Page 34

34

Chapter 2

Encapsulation is a lesson that can be learned from the evolution of computer programming. Back when 640 KB was enough for anybody, computer instructions allowed any running code to write any word in memory. Programmers needed programming rules to avoid stepping on each other. Even a single coder could forget where something was and write over it with another subroutine. Increasing computer capability required strong rules to prevent undesired interaction, which led to objectoriented programming (OOP). Basically, an OOP object contains methods and data that are only known to the object. This means that a subroutine and its data may be encapsulated so that no one who follows the rules can alter an object. Anyone needing the services of an object must send a request to an exposed receiver. An analogy is a person with a telephone and a set of ledger books. The telephone number is public but the location is not. The only way to read or write a number in the books is to call the person and ask for it to be done. The person organizes the books in any suitable way; the caller does not need to know how it is done. If you substitute “methods and data” for “person and books” then you have described an OOP object, which is very much like a module.

Pressure Control Example The following is an example of a module that controls pressure in any process that can use it. A pressure control loop contains a sensor, controller, and valve, each requiring the knowledge of many details to understand how they work. The sensor must be compatible with the process and have the required range. The controller has to be connected to the sensor and valve, which may require wires and junction boxes or tubing and fittings. The valve has to have the proper size and pressure rating in order to have an adequate control range. Now encapsulate all of this control equipment into a module and define the external interfaces. The pressure control module has two interfaces. The command interface carries commands to and status data from the module. This interface is used by whatever is operating the module. The command interface of the pressure control module has a setpoint and a mode as command inputs. These change the behavior of the module when either is changed. The new behavior is visible (or sensible) in status outputs from the command interface. The means of communication may be physical, where the operator turns a setpoint knob and moves a mode switch. Status is visible in the process value and valve position indicators. Digital communication allows commands to be entered and status to be displayed remotely. The control interface has the connections that send commands from and bring status data to the module. This interface is used to hook up the process to the valve and sensor. Sensor and valve data may be plumbed, wired or digitally communicated to the control interface. Plumbing and wiring have a severely limited repertoire of status signals as compared to digital communication.

batch chap 2.qxd

4/25/2006

2:30 PM

Page 35

Introduction to Process Design and Construction

35

The module will try to obey commands, but something below the control interface may prevent that. A command to set 90% pressure cannot be obeyed if the source is only at 85% pressure. The module may include malfunction alarms that are reported through the command interface. A module built in this manner shields the user of the command interface from knowledge of the details of how the module does its job or what goes on at or below the control interface. Of course, the sensor, controller, and valve are each a module. The pressure control module contains three instrument modules. Modules can contain modules in the same way that a Russian matrioshka doll contains nested dolls.

Function Blocks Block diagrams are a way of designing with modules. A rectangle (block) representing the module shows the possible interface connections for inputs and outputs. Other blocks representing other modules with needed functions are added to the drawing, and the proper interfaces are made between blocks. A block diagram is similar to a PFD, but it shows the flow of control information instead of fluids. Block diagrams are also useful for designing the contents of process control modules using function blocks. A simple example is shown in Figure 2-4.

Figure 2-4 Example of a Block Diagram The term function block needs to be qualified. The word function as an adjective of block can mean a program designed to accomplish a specific function, or it can mean the data associated with an instance of a common function. Here, the noun block is a metaphor for a module, be it hardware or software, that contains data or a program. The adjective function is actually a process control function, elementary or complex, that has been defined as a block. It does not refer to a process function, such as charging or reacting. Function blocks containing data are used to represent common control functions, such as PID, Ratio, Selector, and Device Control (for bistable devices like motors and

batch chap 2.qxd

4/25/2006

36

2:30 PM

Page 36

Chapter 2

block valves). The basic function that the block performs is mostly described by the name of the function. A function may have options whose function is not always clear without carefully reading the manual. Each kind (class) of data function block has a set of defined data that is put into each use (instantiation) of the block. Several kinds of data are stored in the block. Identification data includes a unique tag name, similar to the tags used to define process locations. Some of the data is configured by the user (control engineer) to adapt the function for a particular use, such as the tag, input interfaces, option selections, and tuning constants. This data is not modified by the program that uses the data in the block, so it is called “static” data. Some data may be changed by “executing” the block, but it must be remembered so that the block can be properly initialized after the processor restarts. It is called “non-volatile” data. The rest of the data is calculated by the function, but is stored in the block because it must persist from one execution to the next. It is called “dynamic” data. The program that manipulates the data in a data function block is built into the computer’s operating system. The user cannot change it in any way. Naturally, this doesn’t cover everything that the user needs to do. Function blocks that contain executable code allow the user to enter the instructions in one of several popular languages (see IEC 61131-3). The data to be processed appears at named inputs that correspond to variable names in the program. The results to be passed on to other blocks appear at named outputs. The block has no persistent data other than its unique identification and possibly the sources of its inputs. An unconnected input may be used to store a value that is needed for the next invocation of the block. If the user is allowed to name a program function block as a class, then instances of it may be used without writing the code again for each use. This means that a change to the class program affects all instances of the class. Of course, all of the blocks must be in the same processor. The alternative is to copy the block to another location, but this will mean that changes to the code are local. Either kind of function block may be used in a block diagram. They are all functions with connectable inputs and outputs. A good system does not involve the user in the connection process. Standards are necessary to make it possible to design good systems. Anyone who has configured a DCS or perhaps a PLC has encountered function blocks. Anyone who has configured two different systems knows that more work is needed on the standards.

Summary This chapter discussed some principles of process design that were used by the central engineering department of a medium-sized company thirty years ago and are still valid today. Well, except for the automation of all of the draftsmen. The principles were illustrated by an example of the construction of a batch process. A section on

batch chap 2.qxd

4/25/2006

2:30 PM

Page 37

Introduction to Process Design and Construction

37

modular design introduced concepts required to understand the 88 series that are useful in designing all kinds of processes. Function blocks were also introduced as a specific kind of module.

batch chap 3.qxd

4/25/2006

2:32 PM

Page 39

Chapter 3

Introduction to Process Control The word control comes from the Old French word contrerolle, which has to do with auditing a bookkeeping account (contre meaning counter plus rolle meaning account). Indeed, we still have the Office of Controller (or Comptroller from the same root), which directs audits. A current general meaning for control is “to exercise restraining or directing influence over: Regulate.” Turning to regulate, we find that the Latin meaning was to rule, but a modern meaning is “to bring order, method or uniformity to” (Webster’s New Collegiate Dictionary, 1973). Any process requires equipment. Discrete processes require equipment that is quite different from the fluid processes of continuous and batch, so discrete processes will not be discussed further. The equipment definitely needs to have order, method, and uniformity brought to it so that it can produce repeatable, predictable, and consistent results. Automated equipment also must be able to take direction so that it can be commanded to perform its processing properly and be restrained from doing something unwanted. In short, process equipment needs control to be useful. About 70% of continuous process control affects fluid flow. Batch process control is about 70% control of block valve position, but it does use flow control. Batch processing was still done with bucket and paddle operations when continuous processes began demanding better flow control. An early example comes from electric utility boiler control eighty years ago, as Charlie Smoot tells in his story of the founding of Smoot Controls (later bought by Republic, later bought by . . . well, you know how that goes). His father implemented an air flow controller for a 10,000 LBH coal boiler that was responsive to steam pressure and flow. He made an appointment to demonstrate it to a utility official on Armistice Day because it was the custom for industry to shut down for a moment of silence. The time came, the steam engines demanded much less steam, the boiler fires banked and the steam pressure held. When the wheels of industry began turning again, the boiler ran right on up as the generator and engine demanded more steam. The impressed executive placed an order on the spot. This story illustrates that the value of control lies in its ability to adjust equipment to adapt to changing conditions while holding the desired variable relatively constant.

batch chap 3.qxd

4/25/2006

2:32 PM

40

Page 40

Chapter 3

Types of Control Customers have expectations that become targets for the final product. The targets include quantity and quality, and may include final temperature and pressure. Plant management has targets for profits, in the form of conversion efficiency and energy use. Any deviation from a target means either lost profit or unhappy customers and lost sales. Continuous feedback control requires three things: 1. A sensor to measure a physical process property 2. A manipulator that can affect the reading of the sensor by making changes to the process 3. A controller that can compare the sensor reading to a target value and calculate an output The controller must calculate the amount and direction to move the manipulator. The PID controller with a sensor and valve has performed this function in an analog form for so many years that it is well known and trusted. But PID is not the only kind of controller that is required. A process is said to be under control when the target property measurements equal their respective targets. A process controller determines the action to be taken when the process is not under control and causes that action to be taken, if allowed to do so. Controllers may be divided into three classes—regulatory, discrete, and sequential.

Regulatory Consider a pump between a storage tank and a hundred feet of pipe. The pipe has a flow measuring device that can be anywhere on the pipe that is far enough from pump turbulence, because the fluid can’t be compressed enough to matter. The pump has a flow-versus-pressure curve for a fixed shaft speed. The pipe has a pressure-versus-flow curve that, combined with the pump curve, causes the flow to decrease as the pressure rises. The combination is self-regulating, so a steady pump pressure and flow are soon established when the pump is turned on. Figure 3-1 shows the pressure versus flow curves for the pump and pipe, with the operating pressure and flow at their intersection If there is a change in conditions, such as increased pipe friction or impeller wear, then a new stable flow will be established. If there is some economic reason for controlling the flow or pressure then a valve can be added anywhere along the pipe. The valve changes the pipe’s pressure-versus-flow curve by increasing the pressure required to maintain a specified flow rate at some value below the natural flow. If a human is added, and instructed in turning the valve while reading the flowmeter, then we have regulatory control. The human, now an operator, is given a target for the flowmeter reading and turns the valve to maintain it in the same way that a helmsman holds a course.

batch chap 3.qxd

4/25/2006

2:32 PM

Page 41

Introduction to Process Control

41

Figure 3-1 Pressure vs. Flow Curves This works until the operator is distracted or needs a biology break, so one valve requires two human operators per shift. No two people do things exactly the same way, so quality varies with the operator. Humans have reaction times measured in seconds, but flow disturbances are faster than that. It is no wonder that flow control was one of the first jobs to be automated. A regulatory controller frequently or continuously compares the sensor measurement to the setpoint target and calculates an output signal. This signal causes an actuator (control valve) to change the value of the measurement. This is called closed-loop control, where the loop may include a flow sensor, controller, valve and pipeline. Figure 3-2 shows the elements of a regulatory control loop.

Figure 3-2 The Elements of a Regulatory Control Loop

batch chap 3.qxd

4/25/2006

42

2:32 PM

Page 42

Chapter 3

If the valve does not have an effect on the flow sensor, then closed-loop control is not possible and the loop is said to be open. This can happen when the sensor is mounted on a pipe in a platform railing, by mistake. The control output may be on or off, as in the case of a thermostat, if the process has a long response time. Regulatory control is much the same in continuous and batch processes. Continuous processes may have longer time constants.

Control Terms The word term is used in the sense of part of an equation. The equation describing a traditional controller has one or more terms from the set of proportional, integral and derivative. Automatic regulatory control is mostly done with a two or three term feedback controller. There was a time when such controllers used air pressure in clever ways and were not made of silicon, back when control vendor companies had control of their core technology. The controller has a process measurement, a target (often called a setpoint) and an output to a valve or other actuator that manipulates the process in a way that primarily affects the measurement. The value of the output is computed from the measurement and setpoint by using an internal model of the affected part of the process. Many of the controlled processes can be modeled by a process gain and a single time constant. A single term controller ignores the time constant and computes a valve position directly from the difference between the setpoint and measurement (error). The model is made to match the process by adjusting the gain. In the early days, this gain was expressed as a percentage of the measurement span, such that a small value of P meant a large change in output for a small change in error. The band is the region in which the error can cause a change in the output between its closed and fully opened position for a valve. Proportional band is the inverse of gain, but like the QWERTY keyboard and repeats per minute, it is still with us today. The problem with a proportional controller is that the error must be nonzero in order to move the valve. If a human were doing this tedious job, he would keep moving the valve until the error went to zero. The automatic controller does this by integrating the error over time and adding this integral (I) term to the output, so the valve keeps moving until the error goes to zero. But this has the effect of adding a time-dependant gain to the overall gain, which means that the integral term has to be equal to or greater than the dominant time constant of the process in order to have stable control. This works very well for flow control with low gain and short integral time, which is usually the time constant of the flow valve actuator. A surge tank is a vessel designed to hold the output of a discontinuous upstream process so that the downstream continuous process can have a relatively steady feed. A surge tank is generally used for the feed to a distillation column. The upstream process may be batch, or one that requires frequent maintenance. The feed to the

batch chap 3.qxd

4/25/2006

2:32 PM

Page 43

Introduction to Process Control

43

continuous process is metered by a P-only controller from the tank level measurement. A wide proportional band (low gain) allows surges of inflow to have a smaller effect on the controlled flow. If the output flow is tightly controlled, such that the level hardly moves, then output flow is nearly equal to input flow. In other words, the tank becomes just an expensive wide spot in the pipe. The error-squared algorithm was added for control of surge tank level. Introducing the integral term in order to cancel proportional offset also introduces the problem of reset windup. The integrator will integrate at the reset rate (or time constant) for as long as an error exists. If the control loop is open then the error cannot be brought to zero. Pneumatic controllers with 3-15 psi signal spans could keep integrating right on up to the supply pressure of 25 psi. If someone turned the pump on and established flow after complete windup occurred, the valve stayed wide open until the integrator integrated back down again. This fact led to limits on the integral term, which reduced windup but did not eliminate it. Controllers for batch processes use rate limits on the setpoint to minimize windup while moving to the new setpoint. The rate limit reduces the error from the full size of the setpoint change to the difference between the ramped value and the changing measurement. The minimized windup decreases the overshoot at the new setpoint. There are many other ways to deal with the open loop conditions and windup caused by process state changes. Linear PID tuning analyzers will give the wrong results if rate limits are active during the tests. Temperature sensing is not always done by directly immersing the sensor element in the process fluid, particularly if the fluid is moving. A metal thermowell is used to protect the sensor from erosion or larger lumps, or to protect it from corrosive liquids. The thermowell adds a time delay as the mass of its material changes temperature. This delay is compensated by adding a derivative (D) term to the output, which is a function of the rate of change of the measurement. This additional time-dependent gain can also cause stability problems, but the science of controller tuning is outside the scope of this book.

PID Controller The result of adding all of these terms is the PID controller, well known for over sixty years as the way to regulate a process by controlling flow, pressure, temperature, and level. PID has an awesome base of users that take about twenty years to accept any control innovation. This is because the users have all learned not to fix what isn’t broken. The computer has allowed better mathematical models to be developed and implemented, possibly using multiple sensors. Changes in valve position sometimes interact, so the computed model may drive more than one output. The models require a computer to find the right constants for the model to match the process.

batch chap 3.qxd

44

4/25/2006

2:32 PM

Page 44

Chapter 3

Some models are only useful over a relatively narrow range of operating conditions, and may do the wrong thing outside of that range. The conservative plant engineer naturally resists having the process controlled by something that is not personally understood, but is under great pressure to adopt methods that have given an edge to the competition. There is also the problem of getting the operators to accept new control methods. The moment that the newfangled model does something suspicious, the operator bypasses it and goes back to the old way of doing things. As a result, model-based control has been slow to catch on, but has become more usable as computer power per dollar increases. Academia uses the term robustness to describe the ability of the model to recover from disturbances within a useful range of values. There is no scale for robustness, outside of the usual adjectives. Perhaps a model that works only under a very specific set of conditions should be called “weakly robust.” Cascade control uses two or more levels of controllers to improve control, and was doing so before computers changed the way control was done. The principle is that the upper controller output does not go to a valve but becomes the setpoint of the lower controller. The lowest controller output manipulates a valve, most often for flow control. Flow can have many fast disturbances that are removed by the flow controller, allowing the upper controller to request the flow required to meet its target without regard for flow variations. An oil refinery may have an optimization program that sets the target of a distillate analyzer, which sets the target of a tray temperature controller, which sets the target of a heating rate controller, which sets the target of a reboiler steam flow controller. Another control improvement that predates industrial computers is feedforward. If there is another measurement of a property that affects the controlled measurement, it is passed through gain and time constant adjustments and added directly to the output. The advantage here is that the second measurement may be on the upstream side of a process time lag, so it can predict movement of the controlled measurement. The PID controller requires an error before it can move the valve, while feedforward offers a way to start moving the valve before any error gets through the process time lag. If a reactor’s contents are being held at a specified temperature, the addition of a cold liquid will drop that temperature. The temperature measurement is delayed by a thermowell, and any change in the PID output is delayed by the mass of the reactor wall and contents. A properly tuned gain and time constant applied to the liquid flow rate can cause the heating valve to move in such a way that balance occurs without any error at the PID controller. Of course, there are too many possible disturbances for one set of tuning constants to always be right, but the PID makes up the difference. Another example is a demand hot water heater, where feedforward makes the difference between a warm shower and one punctuated with icy episodes followed by very hot water.

batch chap 3.qxd

4/25/2006

2:32 PM

Page 45

Introduction to Process Control

45

The mortal enemy of feedback control is dead time. You use feedback control to keep your car on the road and to make turns by using the steering wheel. Imagine trying to drive with your eyes seeing a tape-delayed image of the road. A slight delay makes you less accurate while more delay forces you to slow down and finally stop before you run into something. Dead time is caused by transport delay (the time it takes to get from actuator to sensor) or by a series of lags with similar time constants. The effects of dead time are not serious if the time is less than 10% of the dominant lag time. Longer times need help, usually by using a Smith predictor, which models the process by filtering the PID output and delaying it by the transport time (usually variable, like a conveyor belt) and then subtracting it from the measurement. This reduces the error and keeps the output from moving too far before the current output effect gets to the sensor. Computed PID controllers can be helped by maintaining the sampling time at the dead time, so that the effect of the last valve motion has time to reach the sensor. These methods only work well when disturbances do not change rapidly.

Control Modes There is one other thing to describe for regulatory control, and that is the mode. The word mode has too many meanings and the word’s root is no help, having to do with style. Meaning 6b in the 1973 edition of Webster’s is “a particular functioning arrangement or condition (a spacecraft in reentry ~).” This is clear enough except that it applies to far too many things. In “three mode controller,” mode refers to the way the output value is calculated. In “controller mode,” mode refers to what the operator can do with the controller. The most common controller mode names are automatic (AUTO) and manual (MAN). In a PID controller, these two modes can be implemented by a switch in the output line. In manual mode, the switch connects the output to a value that does not change unless an operator changes it. In automatic mode the switch selects the output of the calculation that is based on setpoint and measurement. The operator can adjust the setpoint, but the output adjustment has no effect. This seems simple enough, until you go to change the mode without changing the output. That’s a piece of cake for a computer, but it required clever analog circuits to achieve “bumpless transfer” from manual to automatic. Modern controllers have output rate limit settings. This is necessary when changes are made by entering numbers instead of twisting a dial, particularly in manual mode. In general, it is a bad idea to have output rate limits operating when the controller is in an automatic mode. The control loop is open while the rate limit is in effect. If the measurement is noisy, then the measurement needs to be filtered, not the output of the controller. If the valve is moving too much, causing frequent maintenance, consider retuning the controller with the goal of reducing movement. Level can be controlled with very high gain, but the valve will slew from open to closed and back in response to small changes in level.

batch chap 3.qxd

4/25/2006

2:32 PM

46

Page 46

Chapter 3

A setpoint switch can be used to switch between a local setpoint and a remote setpoint (CAS mode) when there is an upstream cascade controller. In this discussion, “stream” is a metaphor that describes the flow of control, which flows from the primary measurement through the controller(s) to the actuator and back through the process to the measurement. When the local controller is not in CAS mode, the upstream controller cannot affect its measurement and so must be prevented from integrating. The only way to get a bumpless transition from AUTO to CAS is to provide a signal from the local controller to the upstream controller. This signal must tell the upstream controller that its loop is open and that it should adjust its output to a certain value. The value may be either the local setpoint or the local measurement. When the cascade is closed, it is still useful to be able to tell the upstream controller to stop integrating in a certain direction, which is usually determined by the actuator reaching a limit. Back when digital computers were tolerated but not trusted (and it took a while to earn trust) it was necessary to have a backup analog controller ready to take over when the computer lost its way in the program. This added a remote cascade (RCAS) position to the setpoint switch and a remote output (ROUT) position to the output switch. Now RCAS is still used to allow computer access to the setpoint. Some batch systems may use ROUT to adjust the output, such as setting it to an initial value when the controller is about to be used. Bumpless transfer methods for the computer are required. Batch processes may require a mode (OFF) that secures the controller while it is not being used. This locks the output at zero or some negative number to ensure that the pressure converter is providing minimum pressure to the valve actuator. When the controller transitions to some other mode, the rate of rise of the actual setpoint or output is limited so as to minimize shock and overshoot. Different (or no) output rate limits may apply after the valve stops moving at the transition rate limit.

Discrete Control Before computers, a discrete control system was designed with relays. The first relays were used to copy weak telegraph signals at the end of a long line to another line, like the baton pass in a relay race or relaying the news from town to town. Timers and time-delay relays also found use in discrete control. The computer made it possible to construct relay and timer systems as stored programs. This allowed automobile makers to do the annual changes to production control systems without rebuilding and rewiring cabinets full of relays. The program was displayed as a ladder diagram because the ladder made the logic paths clear and because it had been in use for years. Now there are five standard programming languages, including ladder. Discrete control is so different from regulatory that vendors seldom did both. The programmable logic controller (PLC) and the digital control system (DCS) followed different evolutionary paths that are now gradually being merged as the market demands. Most discrete control involves bistable sensors and actuators. Regulatory control has a setpoint that is variable across the controllable span of the measurement. Bistable

batch chap 3.qxd

4/25/2006

2:32 PM

Page 47

Introduction to Process Control

47

devices have a setpoint that most people would call a switch. There is a continuum from the thousands of regulatory setpoint values to the two values for bistable devices. Somewhere in there is the border between regulatory and discrete control. As the number of possible values drops, they are referred to as states rather than values. The difference between open and closed states is more distinct than that between 195.6 and 195.7, and so it is appropriate to speak of discrete values rather than (almost) continuous analog values. Figure 3-3 shows a discrete control loop.

Figure 3-3 Discrete Control Loop The most common bistable pieces of equipment are motors and block valves. A block valve, unlike a regulating valve, is designed to be open or closed, and lacks the hardened parts that can survive constant restriction of flow. Before computers, setpoint entry was done with a pair of push buttons, often lighted. An operator could see the lighted red button and know that the pump was off. To start the pump, he (this is before political correctness) would push the green button and wait a few seconds to see that the red light went out and the green light came on. Two state valves with position sensors may be controlled in a similar way by buttons marked Open and Close. Indicator lights may be placed in a graphic representation of the process to show the path being taken by material in pipes or conveyor belts. About half of all industrial plants use red for off/closed and green for on/open. The other half reverses that color scheme. This reflects divided opinion on whether green represents “normal” or “safe.” When computer automation was added, it was necessary to receive a confirmation signal after changing the setpoint of a motor or valve. Otherwise, the program might continue even though the required action did not happen, and the program would soon become lost as a variety of unexpected things happened. The location of the device that detected a confirmation of state (a status) depended on the control require-

batch chap 3.qxd

4/25/2006

2:32 PM

48

Page 48

Chapter 3

ment. A pump might use an auxiliary contact on the motor control relay (still in use, just like the pneumatic valve), or it might have a pressure switch that confirmed that the pump was actually pumping. The computer program needed to run a timer while waiting for the confirmation signal, and generate an alarm if the timer ran out (timed out) so that a person could fix one of a hundred things that could go wrong. If not for the timer, the computer could wait forever for the confirmation signal. Computers, in general, do not have sensors to detect that someone has removed the pump because there was an error in a work order, or that a section of the control line to the pump is now copper sulfate because a junction box cover was not replaced.

Device Controller All bistable devices can be controlled by a common set of code called a Device Controller. It has a mode and a setpoint, one or two discrete confirm inputs, command outputs, and two timers. The controller called attention to itself by generating an alarm if the confirmed state did not match the setpoint state. This alarm was disabled for a user determined time when the setpoint was changed. In the case of a valve, this delay was called “travel time” because the valve had to move from one state to the other, and valve movement was called travel. The device controller is now a standard offering with added features and benefits. Three states can be controlled for two speed or bidirectional motors. Some offer a “crack timer” that sounds an alarm if the close confirm for a really big valve does not turn off after the setpoint has been changed to open. This is a handy feature if the travel time is measured in minutes. Some method is needed for giving names to the states. One system included a one-byte index for each state that specified a pair of names, one for the true state and one for the false, like “OPEN” and “open.” The names were displayed on faceplates and printed in alarms, so they were called message pairs. The system defined 128 names for common states and blank for zero. The other 128 were user-configurable. A common user complaint was that there were not enough user-configurable message pairs. Discrete control is not just for two or three state controllers. Any reasonable number of setpoint states can be used, but each state has to be confirmed and the equipment has to be stable in that state in spite of disturbances in the process. Further, the delay between changes of state must be caused by simple delays, such as travel time. Delays caused by going through a series of states before reaching the target state require a sequential controller, but only if the intermediate states must be confirmed by the controller. Consider a skid-mounted package boiler with fixed operating parameters, similar to a home heating furnace. The boiler can be controlled by a device controller because its states are on and off. Control equipment on the skid provides the sequence that lights and confirms the burner. The discrete controller just allows enough time for the main flame to confirm before timing out, and it has no control over the intervening sequence. An example of complex discrete control is a multi-vessel transfer header with its cross piping and valves. There may be two setpoints, one for the source vessel and one for

batch chap 3.qxd

4/25/2006

2:32 PM

Page 49

Introduction to Process Control

49

the destination, which may require a “go” button to indicate that vessel selection is complete. Or there may be a destination setpoint for each source vessel when crosstransfers are possible, with some transfers conditionally prohibited by other transfers in progress. It may take complex logic to sort out the commands and confirms, but this is simply part of the control algorithm. The controller has only three internal states—confirmed, timing and not confirmed. A discrete controller may have operational modes that select the source of the setpoint. It is less common to have a manual mode because the outputs reflect the setpoint. There is no integration. An operator can do the same thing with the setpoint as with manual control of the command outputs. This may not be true in a complex discrete controller, so it may be a user’s decision to allow manual control in unpredictable circumstances if the operator is responsible for safety. It seems easier to provide discrete controllers for each valve, with a choice of auto and cascade modes, where the discrete controllers are linked to a higher controller that can tell the valves what to do to satisfy its setpoint. Discrete controllers may be used in much more complex alarm and interlock arrangements. These usually require comparison of a regulatory value with a target to generate a different discrete value on either side of the target value. A linear sequence of interlocks and time delays may be used to start a complex set of pumps, valves and motors for a paper machine, or an assembly line. Continuous processes may use some discrete control for motor control, alarms and interlocks. Batch processes do that, and they also use discrete control for block or diverter valves to change the configuration of material flows.

Sequential Control Regulatory and Discrete controllers generally are concerned with maintaining a setpoint. Sequential controllers direct a series of equipment actions by changing setpoints. Each action is performed until some target is reached or the allowed time expires. Then the sequence controller has to determine the next action to start. A fixed sequence controller does not vary the order of actions, but may have new targets to determine when to stop one action and skip or start another. A variable sequence controller can receive different commands and targets depending on the product being made, and so its behavior is more complex. Early sequencing controllers could be built from relays, but the drum programmer was better for more complex systems. A metal drum with regularly punched holes was turned by a stepping mechanism or a clock motor. Pegs pushed into the holes, as required, actuated switches as the drum turned. These controllers were popular for fixed-sequence programs used for cycling regenerative gas dryers or simple batch processes. The drum pin settings were designed on a paper grid that had horizontal rows for steps in the process or for small quantities of time. The vertical columns each represented a switch that caused a valve to open or started a motor or unlocked a

batch chap 3.qxd

4/25/2006

2:32 PM

50

Page 50

Chapter 3

regulatory control function. At first, the computer emulated the fixed sequence drum function, using the same grid for programming. Now various languages are available to construct variable sequence controllers. It is possible to configure sequences with ladder logic or Boolean expressions. The best choice is the Sequential Function Chart (SFC) if you can afford the training. In contrast to ladder logic, the states in the sequence and the reason for changing them are easily visible for more than one actuator. Even if the job has to be done with real relays, the SFC makes a great design tool. Figure 3-4 shows a simple SFC. The blocks represent steps in the chart. The active step changes to the next step when the transition condition next to the horizontal bar below the step is true. This chart can have only one active step because there is only one path. A chart may have multiple paths with multiple active steps. The rules for designing charts prevent the indeterminate states that are possible with ladder logic.

Figure 3-4 Simple SFC Consider a reactor heat transfer jacket that heats with steam and cools with chilled water. The steam supply, chilled water supply, condensate return, and chilled water return are four separate pipes. When heating, block valves in the steam supply and condensate return must be open and the other two closed. The opposite is true for cooling. Transitions between heating and cooling require that the supply valve be closed and that the return valve be left open for a while. This allows the heat exchanger to drain either pure condensate back to the boiler water supply or salty brine to the chiller. Then the return valve closes, so that no valves are open. Finally,

batch chap 3.qxd

4/25/2006

2:32 PM

Page 51

Introduction to Process Control

51

the requested supply and return valves are opened. The setpoint for the sequential controller has just two positions, Heat and Cool. The SFC has five states: Heating, Draining Condensate, Off, Cooling and Draining Brine. Another example is a batch loader or totalizer. An operator sets the amount to be added and pushes a start button. The loader sequence is: 1. Idle, Ready, Not Active, or Pining for the fjords . . . 2. Reset the previous total and calculate a new target 3. Open a valve to start loading 4. Ramp the valve towards closed as the total nears the target 5. Maintain a trickle flow until the target is reached 6. Stop the flow 7. Wait for the line to drain 8. Report that loading is done and go to state 1. The same sequence is followed for every load, regardless of the target amount. An SFC for this device would have eight states. State 1 is the initial state, where the device can wait forever for the start command. Sequential control is not the same as procedural control, which is discussed in Chapter 5 on recipes. A sequential control device usually handles process configuration changes by manipulating block valves.

Constraint Control Every physical process is constrained by the laws of physics. Conservation of material says that if you add more material to a vessel than you take away, the level will rise until it overflows. Conservation of energy says that if you add more energy than you take away, the temperature will rise. Contrariwise, the level or temperature will head down and stop at zero. Particle physics says that solids will melt or sublime as the temperature goes up. Also, solids will pull apart as tension force per unit area goes up, which is also affected by temperature. The laws of thermodynamics place limits on efficiency, as do the laws of particle friction. The laws of electrochemistry determine the rate of corrosion. Every physical process is constrained by its design. If a vessel is designed to hold ten cubic meters, it will not hold eleven. If a pump is designed to deliver one hundred gallons per minute at one hundred psig, it will not deliver much more than that. The choice of materials limits operating pressure and temperature and forbids corrosive process materials that would destroy the vessels or piping.

batch chap 3.qxd

4/25/2006

52

2:32 PM

Page 52

Chapter 3

There are other constraints, such as economics, that will not be discussed here. For example, a racing car’s speed is limited, in the straight runs, by the engine’s ability to generate power at a speed versus the air and tire friction at a speed. In the curves, speed is limited by the driver’s skill. There are, broadly, three kinds of constraint control—alarms, overrides, and interlocks.

Alarms It is not possible for humans to monitor everything in the process all of the time. It is possible to attach an alarm to any process value that has a sensor. An alarm unit is a bistable device with an adjustable trip setpoint. Alarms are said to trip because early electric burglar alarms used trip wires to detect nefarious ne’er-do-wells. When tripped, the unit lights up a faceplate with a legend that identifies the alarm. The operator may not notice the silent addition of a light, so a horn blares (unless it has been disabled). The operator can shut off the horn by pressing an acknowledge (ack) button. The light stays on until the alarm condition clears. This is the common sequence. ANSI/ISA-18.1-1979 (R2004) lists many other sequences. Analog value alarms require some hysteresis so that the alarm doesn’t bounce. That is, when a value rises to the alarm trip value, it must fall below the trip value minus the hysteresis in order to clear the alarm. Temperature and pressure alarms do not need as much hysteresis as level alarms because the level bounces around more. The objective is to prevent the horn from going off too often, so that the operator does not become accustomed to hearing the horn and fails to notice it. For a low alarm, the hysteresis is added to the low trip point. Other analog alarm types include deviation and rate of change. Deviation is the difference between the measurement and the setpoint. It is the same as error in a PID controller. When the deviation is zero, the valve stops moving. This is a stable condition that causes no concern until the deviation becomes non-zero. A deviation alarm is used to tell the operator that this control loop is outside of its acceptable tolerance for error. Both high and low alarms can be set, usually in percent of control span. This works well in continuous plants where setpoints seldom change. If the control setpoint is changed, it can set off the deviation alarm. Some people get used to it; others design deviation alarms that widen the deviation band on a setpoint change to include the new setpoint and the changing measurement. Then there is no alarm unless the measurement moves further away from the setpoint or exceeds the setpoint in the direction of the change. The rate of change (ROC) alarm was rarely used in the days before computers unless there was an economic reason to assemble the hardware to implement it. In the time after DCS and before fieldbus devices, the ROC alarm was touted as a way to tell if the field device or wiring became shorted or open. Never mind that an open circuit would blow the alarm for low deviation, low advisory, and low critical conditions. This was a feature that could be sold as long as it could be called product differentiation.

batch chap 3.qxd

4/25/2006

2:32 PM

Page 53

Introduction to Process Control

53

Now everybody that calculates control has an ROC alarm, and it becomes just another alarm to be configured. An ROC alarm makes sense when the value is normally steady, but predicts trouble if it starts to move at an excessive rate that will not soon be caught by a deviation or advisory alarm. An example is a storage tank that has no level control but does have high and low level alarms. If the tank has no in or out flows, an ROC alarm will detect a leak long before the low level alarm goes off. Of course, the ROC alarm has to be disabled when material is being added to or removed from storage. Discrete alarms are either on or off. Typical sources are pressure, temperature, and level switches. Hysteresis must be built into the mechanism that operates the contact. It does no good to blow the horn after the tank has run over, so trip points are set in anticipation of the condition to be prevented or constraint to be violated. This allows human reaction time for the operator to do what has to be done. Computers made it possible to add alarms at no incremental cost, so almost all such systems offer Advisory and Critical alarms on all analog values. Advisory alarms are meant to give the operator plenty of time to determine and correct the problem. In practice, they operate like the “snooze” button on an alarm clock. The operator hits the ack button, sees an advisory alarm and goes back to whatever was going on elsewhere, unless this one could get nasty. The problem is that vendors make alarms available on everything. Systems integrators feel obligated to configure (and charge for) every one of them. The operator can barely start on another problem before the horn goes off again. This leads to horns with rags stuffed in them or disconnected, dismounted and thrown across the room. The excessive alarm syndrome is compounded by alarm lists and logs. If a process event occurs that causes an automatic process shutdown, about half of all the configured alarms will be instantly added to the list, while the noise from the horn distracts the operator from restoring order. The long list of alarms may make it difficult to find an alarm that will have dire consequences if it is not found and corrected, like low pressure at the fire pump. This problem is addressed by using an Alarm Management function somewhere in the control system. A simple management system requires the user to set one of a dozen or so priority levels for each alarm. The alarm list display program then allows the user to filter by priority so that only the most critical alarms are displayed. Alarm management becomes more complicated when the priority is a function of the situation, as it is in batch control applications. Some people disable alarms in batch units that are empty or out of service. It may be important to leave those alarms active that would detect leaks, like pressure, temperature, and level. The usual cause of nuisance alarms is a differential pressure transmitter that has liquid filled impulse lines. Steam tracing evaporates more liquid from one leg than the other, which causes a false measurement.

batch chap 3.qxd

4/25/2006

54

2:32 PM

Page 54

Chapter 3

Alarms are one method of constraint control, but they rely on human response times and training. If the Standard Operating Procedures manual (SOP) has an entry for every alarm, it will take time to find the book, find the section and find the alarm. SOP manuals are generally quite thick because they must cover every possible problem. Some form of automatic constraint control may be needed, which is the subject of following sections.

Overrides Override control attempts to automatically bring the process back from a constraint. Processes have regions within which automatic control is possible. The constraints are generally design constraints. A distillation column balances vapor flow upwards with liquid flow downwards. Too much vapor blows the liquid out of the trays and stops distillation. Too little vapor floods the trays with liquid, again stopping distillation. These constraints narrow the correct operating conditions for a particular column design, be it bubble tray, packed column or other. Page Buckley of DuPont became famous in the 1960s for finding clever ways to use pneumatic devices to control columns within their constraints. A typical batch process constraint is the cooling capacity of the jacket. Rather than solve complex heat exchange equations, approach to the constraint may be measured by the position of the cooling valve. When it nears wide open it is no longer possible to control the temperature with the selected cooling medium. A valve position controller can manipulate the flow of whatever is adding heat in order to stay within the cooling constraint. Override control is based on designs that let one controller override another. Instead of putting separate valves in a pipe for each constraint to be controlled, a control selector chooses which controller will move one valve. In the valve position control example, the flow of reactant to be reduced is already under flow control. The valve position controller monitors the implied valve position of the cooling controller’s output. When the valve position reaches 90%, the controller starts reducing its output from the upper limit, which reduces the monomer flow. Integral-only control is generally best for valve position controllers, to prevent oscillation between the reactant controller and the cooling flow controller. A device that selects the lowest of multiple controller outputs will ignore the high signal from the valve position controller until it wants less valve opening than the reactant flow controller. When the selector selects the signal from a constraint controller, that signal is said to override the normal controller. Figure 3-5 shows a function block diagram of the control scheme. Selectors may also be used for measurements, but that is a simple selection. The control selector is required to balance the de-selected controllers so that they do not experience reset windup. This is exactly the same problem that had to be solved for cascade control. The deselected controllers have open loops.

batch chap 3.qxd

4/25/2006

2:32 PM

Page 55

Introduction to Process Control

55

Figure 3-5 Override Control by Value Position

Interlocks Today’s scaled-up plants contain and control immense amounts of materials and energies. A failure to contain or control can lead to widespread damage to equipment and people. The probability of a failure cannot be reduced to zero, but an acceptable risk can be reached. The first step is to assure that no single event can cause an incident. An interlock provides the second thing that must fail before damage can occur. Put another way, an interlock prevents failure caused by a single event. Interlocks are primarily used with control loops. Welds still have to be inspected and buildings have to be built right. The Tower Bridge in London, completed in 1894, contains an interlock example from Victorian engineering. The two balanced bridge decks are raised and lowered by hydraulic motors using 750 PSI water from large accumulators. Each motor has a separate lever to control the raising or lowering of each of the four sides of the two decks. The levers are mechanically interlocked to prevent stressing a deck by the application of force to only one side. There is a small glass cabinet down in the engine room that contains four large brass keys (or there was in 1983). These are the keys to the interlocks. Because process control keeps the plant running, a control failure is unlikely to go unnoticed. Interlocks do not function during normal operation, and so they must be

batch chap 3.qxd

4/25/2006

2:32 PM

56

Page 56

Chapter 3

tested periodically. Testing while the process is running requires bypassing (unlocking) the interlock so that it does not shut down the process. Bypassing an interlock requires extra care to be sure that the bypass is removed. Once there was a paracymene (heat transfer oil, flammable) heater that ran continuously. The combustion chamber was lined with vertical 4-inch pipes. Each pipe had a flowmeter as the sensor for an interlock that would stop combustion if the flow was low, because the heater could melt a pipe with low flow. The differential pressure flow sensors were calibrated on a routine basis, which meant that the interlock had to be bypassed during calibration. Sure enough, one of the contract maintenance people forgot to remove a bypass, flow was blocked, and the pipe melted, delivering more fuel to the fire. The fire became so intense that no one could get close enough to the snuffing steam or paracymene shutoff valves to put out the fire. The plant instrument engineer, who was not responsible for contract maintenance, responded to the call to do something by asking if he should bring marshmallows. He knew there was no way to save the heater if the fire could not be snuffed. The result of the neglected bypass was a complete shutdown of the plant for three weeks while another heater was located, purchased, shipped, and installed.

Interlock Variations The decision to install an interlock is based on an analysis of the hazards in an operating process. A batch process must be analyzed for each of its operating conditions. Then an analysis must be made of each identified hazard to see if the hazard can be made negligible by some change to the process equipment or materials. Hazards due to corrosion or weld failure require testing, perhaps by pressure, at certain time intervals. Finally, there is a list of hazards that can be prevented by interlocks, such as overheating, overfilling, and unintended mixing. At some point, an economic decision must be made based on the cost of prevention versus the cost of the hazard becoming real, which involves the probability of an incident occurring. There are books and standards on this subject, so the topic will not be covered further in this book. There are block valve configuration interlocks that prevent the mixing of two fluids that should not be mixed, like beer and cleaning solution or various exothermic combinations. High temperature interlocks stop the inflow of energy, as high level interlocks stop the inflow of material. A batch reactor doing polymerization may prevent the buildup of unreacted monomer by comparing the amount of monomer added to the amount of energy removed.

Process Interlocks There was a time when all interlocks were safety interlocks. Now “safety” has a specific legal meaning and specific standards for design and operations, so there are two kinds of interlocks—safety and process. A process interlock does not have legal traps and standards to be met. It answers the need for a device that keeps the process out of trouble and catches problems before a safety interlock has to act.

batch chap 3.qxd

4/25/2006

2:32 PM

Page 57

Introduction to Process Control

57

Process interlocks can be applied anywhere that the product or equipment can be protected. If there is a safety concern, then a safety interlock may be added to the process interlock. The cost of the process interlock may be justified by the drastic effect that the safety interlock has on the process. Software process interlocks may be added to double-check existing instruments and take action before the safety interlock system acts. A common batch process interlock requires that the drain valve be shut while any inlet valve is open. If the interlock fails then product will be ruined, but people will not be directly affected. The interlock may be implemented in software that is no more reliable than the control system. The TPA process described previously had a fixed procedure, and so it was possible to hard-wire the interlocks. If a sensor failed (and the level sensor did so frequently) then the operator could get a jumper wire and bypass the interlock on the front panel of the interlock logic box after using other means to verify the condition of the reactor. The jumper wire was visible to foremen and supervisors, so it was not forgotten. The paracymene heater interlocks were bypassed with a clip-lead inside of a wiring junction box placed where no one normally went.

Safety Interlocks Safety systems are designed to be independent of existing instruments and should not be a part of an existing process control system. If the complexity of the process requires computers, then the control and safety shutdown computers should have different architectures and different programmers. Reliability is a concern because the shutdown system is not normally used. It has to be tested periodically, and it has to retain the ability to act between tests. When justified, reliability may be increased by using redundant systems or fault-tolerant “voting” systems. Fault-tolerant systems are somewhat less likely to fail because of switch-over problems. A redundant system usually means a “hot backup” system. One processor is active and the other is a spare. An automatic switchover occurs when the active processor stops resetting a watchdog timer. This requires that the spare be updated by the active processor as the state of the process changes. Redundancy works to the degree that the update is complete. That is no problem for a continuous process, but it is a problem for a batch process where state changes are relatively frequent. The spare processor must acknowledge that the state has changed before the active processor allows the batch process to proceed. Redundancy only protects against the failure of the processor, when it works, but failure of the processor disables the entire safety system that is attached to it. Faulttolerant systems run three active processors. The outputs of the processors enter one simple voting circuit that requires agreement between any two processors that the process should be allowed to proceed. An alarm is raised if there is dissent, and the offending processor is replaced without disturbing the rest of the system, in theory.

batch chap 3.qxd

4/25/2006

58

2:32 PM

Page 58

Chapter 3

In practice, opening the cabinet can be a disturbance all by itself when something comes loose and shorts the power supply, or the replacement card can be installed upside down, with a hammer, at 3 a.m. The problem of propagating process state changes to the fault-tolerant system remains. The universe does not allow complete safety. It is difficult to justify using the same sensor for safety as for normal control, when a fault in the sensor or its wiring could be what causes the hazard to become real. If the hazard does not justify the cost of a second valve in the line, the usual shutdown method is to use a solenoid valve to vent air from the control valve. This will not free a jammed valve, but the risk of a jammed valve may be acceptably low. Disclaimer: None of the above is meant to be advice on designing a safety system. It is an introduction to some of the concepts found in safety systems. As stated earlier, the design of a safety system begins with an analysis of the hazards, which requires judgment, brains, and maturity that cannot be acquired by reading this book.

Summary This chapter introduced process control and classified it as regulatory, discrete, and sequential. Many examples were given, but much more can be learned about process control. Constraint control was introduced as a way to maintain control of the process when something goes wrong, from operator error to a considered catastrophe. It’s the ones that were not considered that make the news. The chapter also introduced various kinds of interlocks and scratched the surface of the topic of safety interlock systems.

batch chap 4.qxd

4/25/2006

2:33 PM

Page 59

Chapter 4

Controlled Equipment Introduction to Controlled Equipment This chapter introduces batch processing equipment and the control that is applied to it. Every batch process consists of separate process functions that may be invoked by a recipe as required to make a product. Equipment is required to cause or contain each process function. Control is required to bring uniformity to the process function. It is useful to consider the combination as controlled equipment because the process function cannot be carried out by either component alone. The different kinds of control were described in the preceding chapter, but little was said about the human component of control. The following section describes different levels of human involvement in control. The decision is made by management, considering the requirements of the process, the capabilities of the people, and the costs. Some managers prefer to replace the uncertainties of people with the predictability that automation systems provide (after the last bug has been removed). There are too many factors governing this decision to consider in this book, beyond describing the levels.

The Role of Humans in Process Control The distinction between automatic and automated control, as used in this book, is that automatic control aids the operator while automation replaces the operator with a programmed machine. There are people who define automation as the addition of automatic controls to a process. This was true when automatic remote control was new. Now the cost of automation is always partly justified by the reduction in the number of operators, as well as improved product quality. This section is concerned with the human factors and so the definition of automation includes the effect on people. Automatic control will only hold a setpoint until the operator changes it. Most discussions of equipment control seem to assume complete automation, but that isn’t always possible. Since there are parts of the world where human labor is adequate and less expensive than automation (including support costs), it may be useful to consider something less than full automation. The following is a cost hierarchy from least to most complex control. Each level considers control, communication, cost and other factors.

batch chap 4.qxd

4/25/2006

2:33 PM

Page 60

60

Chapter 4

1. All control is manual Gages and hand valves are located on or close to process equipment or piping. An operator closes the control loop. Since the operator is directly responsible for the quality of the batch, continuous improvement may come with pride of accomplishment. All communications are verbal. There is no cost for equipment or maintenance, except possibly for radios. The initial cost for control equipment and design is low. Labor cost, both operating and maintenance, may also be low at the site because the equipment is simple to operate and maintain. Training is by experience, not done in classrooms. But, the process has to be capable of human control. No fast loops, no equipment too dangerous to be around while operating, nothing requiring more than human force to manipulate.

2. Some control is automatic Transmitters and automatic valves are mixed with gages and hand valves. Since the operator must be present for the manual functions, the automatic controllers are local. Fast loops and high forces are no longer problems with automatic control. Pride is still possible because simple automatic control is well understood as an extension of the operator’s capability. Operator communications are still verbal. Control communication may be pneumatic or electrical. One day, fieldbus may be a low-cost, low-maintenance method, providing that the fieldbus supports control in the field. The initial cost is somewhat higher, but the types of suitable processes are greatly expanded. The operator has less to do, which may enable a better job to be done. Maintenance is more expensive, depending on the reliability of the automatic controls. Classroom training is required for maintenance and may be required for operators.

3. Most control is remote The restrictions of hazardous equipment and inadequate force can be removed by using transmitters with remote indicators and valves with remote adjustment. Valve adjustment may be made automatic as money becomes available, which allows control of fast loops. Alarm units may be added to indicators as necessary. Operator communication adds the dialog between the remote operator and a field operator that takes direction from the remote operator and looks for trouble. This does not necessarily double the number of operators because both can handle more process units, with the help of alarm detection. If electrical signals are used to bridge the distance between the control panel and the process then the major cost of installing automatic control will be covered.

batch chap 4.qxd

4/25/2006

2:33 PM

Page 61

Controlled Equipment

61

4. Most control is automatic Transmitters and automatic valves are connected to a protected area that may contain the controls for several process units. Standard automatic controllers are available that will deliver a measured dose of an ingredient, change a setpoint as a function of time and follow a simple sequential function chart or ladder diagram. The central operator initiates controlled equipment actions and waits for them to finish while tending to the needs of other units. A field operator is necessary to walk around looking for trouble or to manipulate seldom-used block valves. Operator communications are still verbal, but almost certainly use radios. Control communication may be electrical or fieldbus. Intrinsic Safety has greatly reduced the need for pneumatic instruments, except for valves that need air for power. The initial cost is considerably higher, for engineering, equipment and training. Operating costs per unit and the cost of making recipes are much lower, assuming that principles from 88 are followed. Maintenance costs may be higher. Ongoing training is required to keep operations and maintenance familiar with the controlled equipment, since there is more of it per person. A DCS or large PLC or PAS is likely to have a MS operating system or graphical interface, which will put IT in charge of the box. Control in the field with fieldbus devices with proprietary realtime operating systems will reduce the IT problem to the graphical interfaces, which can be upgraded without shutting down the plant. Of course, the field devices must be independent of the upgraded software. This requires that each field device own the configuration data that causes it to do the right thing in its plant location.

5. Fully automated control Most or all automatic controls are operated by computers that are programmed to do the normal work of the operators and handle most exceptions, but not all. A computer may be an obvious box or it may be embedded in equipment. A computer does nothing that has not been programmed by fallible people. The difference is that when a computer program bug is fixed, it tends to stay fixed. Some people think that “the computer” is at fault when something goes wrong, but most often the fault can be found in a programmer who didn’t understand process control or plant safety. Another possibility is a team of programmers that did not communicate well together. Programmers also become human factors in control. Automation is used when the variability or cost of human control is too high, compared to an automation system that has high costs to create but lower operating costs. The operators assume the role of airline pilots with 95% of their time spent monitoring instruments and 5% reacting to unexpected problems. If the automation system is unable to handle a situation then the problem is given to an operator. The computer does nothing further until an operator finds the right combination of menus, clicks and keys to regain control. Like pilots, simulator training is useful to develop and maintain proficiency, now that all normal control is done by machines.

batch chap 4.qxd

4/25/2006

2:33 PM

62

Page 62

Chapter 4

It would be nice to be able to program computers to handle all possible faults, both in the process and in the control system. So far, no one has wanted to pay for the sensors and the program complexity required to handle all possible faults. The usual solution is to use redundant equipment for probable fault locations. Those who accept the fantasy that computers are infallible and power is immortal will receive a reality check at a time and place determined by the laws of probability. It is too bad that there are so few probability sensors. Communication of control information is mostly digital, allowing intelligent field devices to report problems. The operator needs to be able to understand the visual presentations of normal and unpredicted behavior that have been designed by a programmer who may not have fully understood the problem. The control room operator still needs eyes in the field that can communicate a fault situation as it develops or operate the odd manual valve. The initial cost is highest, for engineering, equipment, factory training, protected area, computers, networks and programming. Difficulties during plant startup may greatly increase project costs, if not properly managed. Operating costs per unit and the cost of making recipes should be much lower and process reliability much higher. Maintenance costs will be higher. Ongoing training is required to keep everyone familiar with what the computer programs are trying to do and what a program is trying to say when it needs to communicate with an operator. An automation system must be looked at as another employee, requiring health benefits, training and all that is required to keep this robot employee competent to do the job as things change.

Process Equipment Processes require many physical things, including process materials, piping, vessels, valves, sensors, supports, insulation, gaskets and bolts. Some of these things are classified as equipment, but definitions of equipment tend to be either fuzzy or too specific. The following is a summary of various web definitions of equipment. A piece of equipment is an item of tangible property that meets all of the following criteria: (1) It retains its original shape and purpose with use. (2) It does not lose its identity through fabrication or incorporation into a different or more complex unit. (3) It is non-expendable; that is, if the item is damaged or some of its parts are lost or worn out, it is more feasible to repair the item than to replace it. (4) Under normal conditions of use, including reasonable care and maintenance, it can be expected to serve its purpose for an acceptable lifetime.

batch chap 4.qxd

4/25/2006

2:33 PM

Page 63

Controlled Equipment

63

So an entity in a plant is a piece of equipment if it retains its original shape and purpose with use (except for wear), is not consumable or expendable, can be repaired with new parts, and has an adequate service life. That would exclude process materials, gaskets and bolts. Expendability is a fuzzy concept. There is no doubt that a paper towel is expendable. A dial thermometer may have an adequate service life, but it is not repaired if it gets broken. A control valve will probably be repaired. Equipment will be repaired if the cost of repair is less than the cost of replacement. Some equipment will be replaced, but the service life qualifies it as equipment rather than expendable, such as a transmitter. Don’t get caught up in these definitions. They are only guidelines, used by tax collectors to tell capital equipment from expendable material. If you can control it, it is probably equipment.

Controlled Process Equipment The combination of process equipment and control has a major role in ANSI/ISA88.01. Controlled equipment is able to perform a process function that is required, as one of many, to make a batch of product. What is needed is process functionality. Control and equipment are designed together to perform one of the functions of a batch process. Process equipment is controlled if something within it can be measured or manipulated, either in an analog or discrete manner. A manual valve is controlled equipment because an operator can manipulate it. If the valve is considered to be part of a piece of equipment then that equipment is controlled, but only if manipulating the valve does something to the operating conditions in the equipment. The control for process equipment may be either manual or automated, but those distinctions do not affect the fact that the equipment is controlled. The figures that will be referenced in the rest of this chapter should be understood to be highly schematic. The drawings leave out very many details in order to make simple points.

batch chap 4.qxd

4/25/2006

64

2:33 PM

Page 64

Chapter 4

Figure 4-1 A Combination of Process Equipment and Control The left side of Figure 4-1 shows a piece of equipment that is a jacketed high-pressure reactor with a safety valve and an agitator. They provide the capability to contain and homogenize a batch of process material. The middle of the figure shows some control equipment. From the top, the circles represent speed control, measurements of pressure, temperature, and level. The square and closed X represents a block valve. The right side of the figure shows the result of combining equipment and control, except that only control equipment is shown. The control algorithms may be in some remote control system or may be part of the devices represented by circles and squares. Control, particularly temperature control, may require more equipment that isn’t shown.

Examples of Controlled Equipment Many of you have applied control to equipment, but may not have thought of the result as controlled equipment. The concept is fundamental to understanding S88. It is treated abstractly in the standard because there are so many kinds of batch processing equipment, many of them unique to an industry or a plant. The following is a list of relatively common equipment. The list of equipment is not complete, but should be enough to give a solid grounding in controlled equipment before going into the abstract models of S88. Please add the word usually to any sweeping statement.

Batch Reactor A batch reactor is a vessel that contains a batch of material while it undergoes a chemical transformation, usually with an exchange of energy. It takes at least two materials to have a reaction. One of the materials must be a liquid, even if it is a solvent that does not participate in the reaction. The other material(s) may be solid, liquid or gaseous. An agitator is required to keep the ingredients homogenized. The atmosphere above the liquid in the vessel may be oxidizing, reducing or inert. The pressure may vary from vacuum to very high. The temperature may be cryogenic to near the loss of strength of the metal that contains the process.

batch chap 4.qxd

4/25/2006

2:33 PM

Page 65

Controlled Equipment

65

Figure 4-2a shows an instrumented reactor and an agitator with two blades. The high pressure safety valve is part of the equipment. Figure 4-2a only shows process and control equipment. The source of control is not shown. The vessel is constructed from some material that can withstand the combinations of temperature and pressure. The ASME has extensive standards for pressure vessels at different conditions. Reactor shapes vary from four times wider than high to four times higher than wide because requirements and budgets vary. A high pressure vessel is less expensive if the end bells are small. A wide Figure 4-2a Instrumented vessel is difficult to agitate. If the vessel material is not Reactor compatible with the process material, then the reactor is lined with a suitable material with a similar temperature coefficient, and the rate of temperature change must be limited so that the liner temperature does not get too far from the vessel temperature. The vessel requires penetrations for materials, samples, instruments and an agitator. Each penetration has a short piece of pipe with a standard flange welded to it. Penetrations are expensive because they alter the stress concentrations in the vessel and require certified welds, with expense increasing as the pressure rating goes up. At least one penetration is dedicated to pressure relief, by a relief valve or a rupture disk. A large penetration may be required for human entry into the vessel, perhaps to fold back the agitator blades for removal or to repair something inside. The same penetration may be used to add solids. Penetrations may be required for a clean-in-place system that is more complex than simple material addition, such as a movable nozzle that can be pointed to most of the inside of the vessel. The vessel may require an active heat transfer surface. This is most easily done with a coil of half pipe welded around the outside of the vessel, called a jacket. Larger vessels require fixed baffles to induce turbulence and prevent simple rotation of the entire mass. If the process material is compatible, better heat transfer can be obtained with internal coils of pipe at the expense of increased first cost and maintenance.

Associated Reactor Control The actuators for reactor control are valves mounted on the penetrations for materials and gasses or piped directly to them. Generally, input flows and heat transfer are controlled by other equipment that specializes in material measurement and heat transfer configuration. The reactor principally needs control to protect itself. The vessel must not be overfilled. The level must be measured, but that is the most difficult thing to do in an agitated reactor. The agitator tends to destroy level probes and generate foam that bothers level switches and non-contact methods. Agitation also makes the level non-uniform, being lower near the shaft than the wall. Differential

batch chap 4.qxd

4/25/2006

66

2:33 PM

Page 66

Chapter 4

pressure, perhaps with isolating diaphragms, may be used if the density of the mixture remains relatively constant or can be compensated. Load cells are the most expensive, have a maximum weight limit, and require flexible connections that are not practical as the pressure rating goes up. The last resort is to omit the level measurement, measure the inflows and hope it all drains out at the end. Sometimes level can be inferred from agitator power if the mixture does not change viscosity. Given a level measurement, any of the constraint control methods may be applied to prevent overfill. The reactor would not have a level control because the accuracy of level measurement is not adequate to measure materials. The vessel temperature must be measured. Again, the agitator may try to rip out the probe, but it is possible to support a temperature probe with brackets. In the worst case, a stationary temperature probe may be inserted into a hollow agitator shaft. Other equipment controls the temperature, unless a single heat exchanger fluid is used and the loop is quite simple. The measurement lag for large vessels will be a problem. The vessel pressure may have to be measured. The measurement may be used by constraint control that protects the reactor, although the ultimate protection is the rupture disk or one of the relief valves. If external equipment can change the reactor pressure, then the measurement is used by the control for that equipment. If the pressure comes from a single source like an inert gas line, then a reactor control may handle the pressure. Analytical measurements may be done inside the reactor if the environment permits an acceptable sensor life. Otherwise, sample penetrations are used to extract samples for measurement. Analytical control is too specialized to be a part of basic reactor control. In general, a control function is attached to external equipment, such as an analyzer, in order to keep the local equipment control simple.

Agitator Control people tend to think of the agitator as a motor-driven stirrer. It is actually an important piece of processing equipment, designed to have a specific effect on the process material. It also adds heat to the process as work is dissipated in the material. An agitator is driven by a motor or steam turbine, or both for redundancy when the material becomes solid if it isn’t agitated. Some kind of drive box is required to reduce the motor speed. The shaft must have a rotary seal, if only to keep things from falling into the reactor. Blade shape and number depend on requirements and budget. The entire blade and shaft assembly may be coated with glass. Control may be a single switch or a more complex device with feedback, or it may be based on power or speed. Even if it is simple, the agitator is a separate piece of controlled equipment from the reactor. They are separate because agitator design considerations are quite different from vessel designs.

batch chap 4.qxd

4/25/2006

2:33 PM

Page 67

Controlled Equipment

67

The purpose of classifying controlled equipment is to simplify designs by compartmentalizing them. In this case, after the reactor preliminary design is done, you put down the reactor data sheets and pick up the agitator design sheets. Perhaps a separate group that specializes in agitators can work in parallel with reactor design. If the reaction requires or can tolerate a sparge, then a mechanical agitator may not be required. Sparging gas requires a compressor, especially if the vessel atmosphere is recirculated. The agitation is not as efficient or as strong as mechanical agitation, but is well distributed. Since the ring of perforated pipe that admits the sparge gas is entirely inside the reactor, it may be considered a part of the reactor.

Bioreactor Seemingly similar to a chemical reactor, the similarity ends at containing the product because the reactor contains single-celled life. The agitator is never designed to add energy, just to stir the mixture so that it doesn’t stagnate but maintains reasonable uniformity. A thick glop may build up on the reactor walls, but the agitator cannot remove it without killing cells. A sparge ring may be used to add air, oxygen, nitrogen or other gasses. Figure 4-2b shows a schematic of a bioreactor with its agitator and sparge ring. This kind of reactor has to be completely sterilized between batches with cleaning solution and a timed exposure to steam. A temperature probe and its supports are replaced by a short probe in the side. This works because temperature differences are small between the jacket and the vessel. Also, the agitator keeps things stirred without adding extra energy to the solution. The level measurement uses a filled system with flush sanitary seals. An analyzer for the gas in the headspace of the reactor measures important properties of the batch. Figure 4-2b Bioreactor

The microbes may excrete the product as they grow, or the product may be contained within the cells, necessitating termination with extreme prejudice in order to extract the product. The usual measurements in the reactor are temperature, pH and dissolved oxygen in the mixture of cells and nutrient broth, but they are not the only factors that control production. The others have to be sampled and analyzed, including cell mass, broth composition, concentration of products produced external to the cell and the composition of the inside of the cell. Foaming can be a problem, although there are sensors that can measure foam level as well as liquid level. The composition of the gases in the headspace of the reactor is important. Growth rates may be inferred from rising carbon dioxide concentration, amount of cooling required or oxygen demand.

batch chap 4.qxd

4/25/2006

2:33 PM

Page 68

68

Chapter 4

Temperature may be controlled, but its measurement is necessary for compensation of pH and DO measurements. The pH may be controlled by reagents or by carbon dioxide in the sparge. DO is controlled by using oxygen, air or nitrogen as the value rises. These controls are hampered by significant measurement lags. The agitator speed may also be controlled. All of these values change as the batch of cells progresses towards the end of their life. Growth is encouraged at first, then discouraged as the mixture becomes saturated with cells. Since living cells will grow in the reactor, it is essential that cleaning chemicals and sterilization steam be able to reach microscopic corners of the reactor and everything in it. This requires special piping, valves and sensors that are also found in food and beverage processes for the same reasons. If a batch goes bad, no cell must be left alive in the reactor to grow again in the next batch. Besides the bioreactors, there are devices for cell separation like centrifuges and filters, cell disrupters like the cavitation bomb, and chromatography purification devices.

Mobile Reactor The mobile reactor is a key component of a pipeless batch plant. The reactor has much the same equipment as its stationary father, but it is transported to fixed stations where transfers of material and/or energy may take place, or the contents may be analyzed. The batch stays in the same vessel as reactions take place. This results in a very versatile set of batch processing equipment, capable of rapid response to new product design that results in fast time to market. The size of the reactor is limited by the transport mechanism. A mobile reactor requires some sort of docking assembly to connect itself to the fixed stations, either manual hoses and plugs or a NASA-style block containing all connections, that can be mated and disconnected by the transporter. Since the contents stay in the reactor, it is not possible to clean or sterilize in place after moving between stations without expensive additional valves and piping. Figure 4-2c shows an abstract drawing of a mobile reactor with a docking panel. The heavy dotted line represents power for the agitator with a connector in the docking panel. The light dotted lines represent fieldbus wiring with connectors in the docking panel. The reactor is drained by a suction pipe and not by gravity.

Figure 4-2c Mobile Reactor

Multiple mobile reactors are used to keep the fixed stations busy or to increase production. The usual control problems must be solved, with the addition of scheduling both for efficient use of stations and the need to prevent two reactors trying to occupy the same space

batch chap 4.qxd

4/25/2006

2:33 PM

Page 69

Controlled Equipment

69

at the same time. A typical problem is to route a reactor from an analysis station either back to a transfer station if more material is needed or on to the next process operation or to a waste transfer station if recovery is not possible. The reactor may require some way to power the agitator and maintain temperature if a situation might arise such that transport cannot be accomplished in an adiabatic manner. Fixed stations are similar to the stations on a discrete process assembly machine, but the machine only turns in one direction, so its stations must represent consecutive operations in the manufacturing sequence. Mobile reactors have no such limitation. Pipeless stations may perform as many functions as make sense in scheduling the flow of reactors through the fixed equipment. The fact that the reactor will disconnect from the station means that precautions have to be taken to keep the floor dry. Generally, there is no control on the reactor itself, only sensors. Consider the difficulties of maintaining loop operation while the reactor is in transit, never mind the fact that there is no material or energy source to control. The sensors should have transmitters so that low-level signals like thermocouples do not have to go through a frequently operated connection. Using a fieldbus may reduce the number of connector pins for sensors to two. If automatic block valves are required, piston actuators rather than spring-operated may be used without pneumatic power during transport.

Mixer A mixer is a vessel and stirrer that may be required to prepare a material to enter the reactor, which may be a solvent and assorted dissolved solid chemicals. A mixer may replace the reactor if the product is something like paint in many colors. Mixing requires a vessel and a stirrer, but the design possibilities are endless. The vessel may be open, so that no penetrations are required except for a horizontal stirrer shaft, and it may be emptied by tipping it over. Others may look like reactors with fewer penetrations, possibly with a heat transfer jacket. Control is seldom more complicated than a switch for the stirrer motor, but that control belongs with the mixer.

Ingredient Addition Repeatable batch quality requires repeatable masses of ingredients. The means to measure the mass may be a standard flowmeter like orifice, vortex, turbine, or positive displacement, or it may be loss in weight of a feed tank or gain in weight of the reactor. A level measurement seldom has the required accuracy. Dry ingredients may be pre-weighed into bar-coded packages destined for a specific batch, then emptied into a mixer or a manhole at the proper time in the process procedure. A local storage tank may be required to assure enough material to finish a batch, once started. Control of liquids and gasses is done with a throttling or block valve. Flowmeters require totalizers and weigh feeders require equipment to detect the desired change in weight. If a throttling valve is used, the valve is ramped down to a small percentage of

batch chap 4.qxd

4/25/2006

2:33 PM

70

Page 70

Chapter 4

full flow and shut off at the target. The ramp rate and reduced flow are a compromise between speed and accuracy. The block valve is wide open from the start of the charge or dose until it is closed at the target. The target may be biased to allow for valve reaction time and draining material between the valve and the vessel. This control belongs with the equipment containing the measurement and valve, even if it is only a piece of pipe. The pipe assembly becomes controlled equipment. An ingredient weigh tank and its outlet valve, and possibly inlet valves, is controlled equipment. If the reactor is weighed then the controlled equipment is the valve, because there may be several such material control valves. Or not, if you choose to add it to the burden of the reactor control group.

Transport Header A set of pipes and valves called a header may be required to distribute a measured material to one of several reactors. This is less expensive than duplicating the equipment at each reactor. Intermediate products may be distributed from one set of mixers or reactors to another. Gravity feed is preferred, but a pump may be required. The header may remain mostly flooded with one material, or it may be drained and washed between uses. Complex headers may handle many transfers at the same time by using block valves to configure paths. Such headers may be used to transfer materials to and from tanks in a storage area. The source and destination may have to be specified by a recipe. The transfer may be a function of the equipment, such that material from one unit may be automatically transferred to the next available unit. Automatic transfer is possible for similar product procedures, but would be undesirable in a multi-purpose group of units.

Heat Exchanger A heat exchanger passes heat from one flowing material to another without physically mixing them. One of the materials is the product to be adjusted and the other is the transfer material that provides (or removes) heat. A steam boiler is a special case of heat exchanger in that the transfer material is combustion gas that requires special controls. A vent condenser is a heat exchanger that cools the contents of a reactor by condensing the vapor from the reaction and returning the liquid to the reactor. The transfer material may be a chilled liquid or involve the boiling of a liquid to generate vapor at a lower pressure than the reactor contents. Usually, a batch heat exchanger does its work without creating a phase change in the materials flowing through it, except for steam. Heat exchangers are constructed from solid materials that conduct heat and do not corrode in the presence of the flowing materials. A common type of exchanger is a shell-and-tube design. This is required when one of the flowing materials may deposit solids on its side of the exchange surface, in this case the inside of the tube. Another design uses parallel plates to separate the flowing materials. Cleaning requires complete disassembly, but it is relatively easy to add or remove plates to get the desired heat transfer. Most heat exchangers are based on these two designs, but sterile processes may require additional work to assure that there are no stagnant areas in the exchanger. Clean-in-place must be able to completely clean the product side of the exchanger.

batch chap 4.qxd

4/25/2006

2:33 PM

Page 71

Controlled Equipment

71

Figure 4-3 Shell and Tube Heat Exchanger Figure 4-3 shows two cutaway views of a shell and tube heat exchanger. It requires a drain for the process fluid because the main piping is at the center of the end bells. The end bells can be unbolted and removed so that the tubes can be cleaned with long brushes. The controls for a heat exchanger are based on the measurement of temperature as an indication of heat flow. Indeed, the purpose of the batch process heat exchanger is to control product temperature to some recipe-specified value. This is true of exchangers built onto or into reactors as well as external exchangers. The means for control of product temperature is built into the equipment. At a minimum, there must be a product temperature sensor, PID controller and a valve that adjusts the flow of the transfer material. It may be necessary to use cascade control, so that the temperature controller adjusts a flow controller for the heat source or sink. More precise control may be achieved by calculating the caloric demand of the product and using the result to control the calculated caloric source from the transfer fluid. If the transfer fluid is steam, the level of condensate in a vertical shell-and-tube exchanger may be varied to control the heat exchange area. Proportional plus derivative control may be used for reactors because the gain can be set high enough that integral control is not required. Derivative speeds the control action, but it should be applied to the measurement and not the error. Batch process heat exchangers may be required to do both heating and cooling. This requires at least two transfer fluids and perhaps more, such as steam, tempered water and chilled brine. See Figure 4-4. Now a simple sequence controller is required to change the configuration of the transfer fluid piping to suit the sign and perhaps magnitude of the difference between inlet and outlet temperatures of the product flow. In the case of a reactor jacket, the temperature difference is between the jacket and the reactor contents. For this reason, there may be an additional cascade where the reactor contents temperature controller sets the jacket temperature controller, which may set the flow or caloric contribution of the transfer fluid. Be sure that your control vendor understands the bumpless-transfer aspects of cascade control, also called cascade initialization.

batch chap 4.qxd

72

4/25/2006

2:33 PM

Page 72

Chapter 4

Figure 4-4 Heat Exchanger for Heating and Cooling Figure 4-5 shows an arrangement of heat exchangers for heating and cooling a jacketed batch reactor.

Figure 4-5 Heat Exchangers for Jacketed Batch Reactor

batch chap 4.qxd

4/25/2006

2:33 PM

Page 73

Controlled Equipment

73

An intermediate heat transfer fluid is used to transfer heat to/from the jacket. The process requires hot oil for heating to about 200 degrees C without using high pressure steam, which is not available. Cooling is done with water, so a separate heat exchanger is required. Block valves isolate the exchangers so that only one has to be designed for high temperature operation.

Distillation Column Distillation was first done with a single boiler and condenser. If more distillation was required, the distillate was put back in the boiler for another pass. Now distillation is done with columns, packed or trays, that effectively stack a series of boilers and condensers. Heat moves up the column from the base as vapor while gravity returns distillate down the column. The up and down flows must be carefully balanced so that an excess of one does not cut off the flow of the other. The vapor that reaches the top has been stripped of heavier molecular weight components. It is condensed to distillate that is held in a tank. Some of the distillate is withdrawn as product or byproduct while the rest is sent back to the top of the column as reflux to do the condensing of vapor as it flows down the column. Heat is provided by a heat exchanger called a reboiler at the bottom of the column. The liquid at the bottom consists of the heavier molecular weight fraction of the feed material. The feed is introduced at the point in the column where the separation of light and heavy components matches the composition of the feed material. At least, that’s how the oil boilers do it. Batch distillation has no feed point in the column. The reactor becomes the reboiler, except that it just boils the contents until they won’t boil anymore. The composition at any point in the column keeps changing, so balancing the column becomes more interesting. Batch still columns are packed rather than trays for a wider range of efficiency. Batch distillation requires minimum holdup of the distillate in order to get the most product. Mixing distillate in a tank prevents rapid sensing of the moment when the product fraction falls off and another component ramps up, or the moment when the product fraction ramps up at the beginning. Batch columns may have the distillate condenser built into the top of the column, so the only holdup is in the reflux control piping. Batch distillation necessarily begins with the lightest fraction and progresses until no more heavy vapor can be obtained at the operating conditions. Vacuum is often used to lower the reactor temperature required to provide vapor, for products harmed by higher temperatures. Control of a column basically consists of maintaining a material and energy balance in the column. Energy is balanced when the heat into the reboiler equals the heat out of the condenser. Material is balanced when the outflows equal the inflow. The tricky part is that the proportions of the two (continuous) outflows must match the composition of the feed flow. This is not true for batch distillation, where the reactor level falls as components are removed from the distillate. The column is most efficient at the design vapor flow rate for the component being separated. Vapor flow is best measured by distillate flow, where that is possible. Differential column pressure depends on the amount of reflux and the condition of the packing, so it is not reliable

batch chap 4.qxd

4/25/2006

74

2:33 PM

Page 74

Chapter 4

with changing compositions. The vapor flow rate is used to control the heat flow to the reactor while a component is being extracted. Reactor temperature control is used to set up conditions for the next component separation. All of the above variables affect the component to be separated and the efficiency of separation. The most critical control for product quality is the ratio of reflux to product flow, called the reflux ratio. A column running on total reflux can achieve excellent separation, but no product is withdrawn. Reducing the reflux ratio as much as possible greatly improves the economics of the situation. If the column pressure is controlled then the column may be used as an analyzer. A temperature measurement near the top is a reliable measure of the components in the vapor, providing that the reflux liquid is not excessively cooled by the condenser. That temperature may be used to control the reflux ratio for the specific component temperature. The controller begins to close off the product flow as that component is withdrawn from the contents of the reactor. This condition may be used to end the product draw and switch to another storage tank. After the switch, the temperature is raised for the next heavier component(s). This method determines the end point for a component and all lighter components, so that is why batch distillation begins with the lightest components. There are many clever mechanisms for reflux control without excessive holdup. Perhaps you can see why most control engineers consider distillation to be a challenging subject, next to exothermic reactor temperature control.

Centrifuge Sugar beets are processed by chopping up the beets and dissolving the sugar in a solvent (water). Then the slurry is fed to a centrifuge where the product bearing liquid is separated from the beet fibers, and goes off to the evaporators. Then again, some products are crystals grown in an expensive solvent. When a centrifuge separates the two, the crystals left in the centrifuge are the product and the solvent can be recycled. A centrifuge can be a batch unit. The unit operation is separation, no chemicals change state and no special equipment is needed for energy balance, outside of the device that rotates the centrifuge and the bearings. A liquid suspension of product is introduced to the centrifuge and the heavy stuff (product or by-product) sticks to the walls while the liquid flows on through. The spin-dry cycle of a washing machine is a centrifuge. But the heavy stuff can’t build up forever. Either the liquid flow is blocked or the bearings give out, so the centrifuge has to be stopped periodically while the heavy stuff is scraped out, then started up again. Sequential control is required to cycle the centrifuge between loading and extraction of the solids. There are many opportunities for clever machine design when it comes to the extraction part of the sequence. The sequence itself is not specified by a recipe because it remains the same for all products. In some cases, the recipe may specify the loading time and, possibly, the speed of rotation. There are other controls to operate and protect the motor, as well as operate the brake and emergency brake.

batch chap 4.qxd

4/25/2006

2:33 PM

Page 75

Controlled Equipment

75

If there is a load sensor, then the recipe does not have to specify loading time and the equipment can be used to its capacity.

Common Equipment Because batch processing progresses in a series of process operations, it is possible to arrange the operation of batch units so that they are not all doing the same thing at the same time. Suppose a batch begins with a charge of hot water as a solvent for following reactions. It is not as cost effective to heat the water in the reactor as it is to heat it directly with combustion gases in a heater built for that purpose. If the batch units can be staggered so that each wants a charge of water after an external heater has had time to heat it, then a single heater becomes common equipment for a set of batch units. Only one unit may draw hot water at a time. The heater may also be called a common resource. In fact, the heater is an exclusive-use common resource. Control is required to regulate the water temperature, of course, as are the controls for combustion. Control is also required to make sure that only one reactor at a time can get hot water. This is coordination control. Either a person or a computer manages a request queue that takes requests from units and honors them in the order in which they were received, just like a telephone queue. It is possible that an automatic electromechanical device could do queue management, but computer automation is less expensive, given that the computer was purchased for other reasons. If the plant starts up from an extended shutdown, all of the attached units may ask for hot water at about the same time, but the heater isn’t up to temperature yet. As the heater answers requests, the unit processes become spread out in time. They will stay in that order until one of the units misses its window and makes a later request for hot water. Perhaps common equipment is used for post processing, like a centrifuge, filter or other separator. The same queue management may be used to allow one and only one unit to send its product to the separator at a time. Things get more complicated when a common resource can serve more than one unit, but less than all of them, at the same time. This is called a shared-use common resource. As you can see, calling common resources “shared equipment” is imprecise. You need to specify which kind of common resource, exclusive use or shared use, is meant unless the context makes the choice clear. Queue management is still used for shared-use common resources, in such a way that the common equipment is fully loaded before any unit requests are queued up and deferred. Then there is the case of priority management of a queue. Suppose a unit senses that the reaction products are thickening, which can be cured by an additional amount of solvent. This request must take precedence over all requests for a charge of solvent, lest the thickening result in a solid mass within the reactor. It is also possible that a

batch chap 4.qxd

4/25/2006

76

2:33 PM

Page 76

Chapter 4

production schedule may request a higher priority than the batches in progress. Now we are into allocation and arbitration, which will be discussed later.

Summary This chapter outlined the human factor in control as the complexity of control increased, with effects on cost, communication and other things. Then it defined equipment and controlled equipment. With those basics, the rest of the chapter discussed the control of various pieces of equipment, at a higher level than detailed control schemes. The specific sets of equipment discussed were a batch reactor, associated reactor control, agitator, bioreactor, mobile reactor, mixer, ingredient addition, transport header, heat exchanger, distillation column, centrifuge and common equipment.

batch chap 5.qxd

4/25/2006

2:34 PM

Page 77

Chapter 5

Recipes Much of what has gone before in this book is not specific to batch control. Any control engineer could have used this material as a warm-up for any discussion of process control. That is because we have not discussed recipes. Continuous processes have them, but a continuous process is just a static batch process, forever locked in the same place in the procedure, like Bill Murray in Groundhog Day. The Latin root for recipe means take, which doesn’t make much sense unless it is read as a procedure. Take one measure of saltpeter, one quarter measure of charcoal, and one quarter measure of sulfur, add some water to form a slurry, and mix well, then dry. This, loosely, is the “formula” found by Chinese alchemists for gunpowder (ca. 1000 AD), and then by the English alchemist Roger Bacon circa 1250. Sadly, civilization was not ready for the Bacon Prize for Peace. In another meaning of take, a medical prescription is abbreviated as R with a cross through the tail of the R. The crossed line stood for Jupiter, and the pair meant a recipe for making you well, Jupiter willing, if you take it as prescribed.

Definitions ANSI/ISA-88.01 concisely defines a recipe as, “The necessary set of information that uniquely defines the production requirements for a specific product.” Thus, all processes need at least one recipe. The set of information includes the properties of the materials and their proportions as well as the instructions for processing them. The information on materials is called the formula, adding to that word’s many other meanings. The instructions for processing are grouped into a procedure, which fits the common meaning—a sequence of things to be done to perform a task. Some treat formula as a synonym for recipe. The formula was enough for an alchemist because the usual procedure was “mix.” The word formulate in the sense of “invent” means to find the formula to make something. There is no “recipate.” So, formula has an ancient heritage of meaning the set of information necessary to make something that an alchemist might make. Although there are still bad guys that want to steal the secret formula, they’d do better to get the recipe. More recently, formula and procedure were separated, and the combination was called a recipe. This allows a common procedure to be used with different formulas. It is one result of the proliferation of products with formulas, as more people began formulating

batch chap 5.qxd

78

4/25/2006

2:34 PM

Page 78

Chapter 5

more products. It became impractical to modify the same procedure in a large set of recipes whenever a change was made to the process to improve production quality or rate. The computer makes it easy for a recipe to incorporate a common procedure file by reference. One way of organizing recipes is to have exactly one per individual product. Another way is to subdivide the recipe into grades, which is more popular in the coating kitchens of the paper industry. Each grade has a slightly different formula but the same procedure. Perhaps the amount of clay and the time to mix it in are the only changes. So a grade represents a subdivision of the formula. In this case, there is one recipe per procedure, with references to files that contain grade information. Either one recipe per product or one recipe per procedure will make products, so both have evolved significant user bases. Alas, other ways of defining a product have evolved. A web search for the definition of recipe yields this one from The Bridgefield Group at www.bridgefieldgroup.com/glos8.htm recipe- Used synonymously with bill of material in process industries. Chasing the link for bill of material we get: bill of material (BOM)- A structured list of the items used in making a parent assembly that reflects the actual production process in terms of timing and quantities consumed. It is constructed in conjunction with the routing, which describes the individual production steps and rates used. . . . BOMs are used by the MRP function to calculate component requirements when given a parent demand, and in building product costs. (Syn: product structure, recipe, formulation, ingredients list). The list of synonyms seems rather loose. It seems to be based on terms used in the discrete parts industries. This is one of the reasons why SP88 was necessary. Following up on routing we get an extended definition for procedure: routing- The detailed description of the requirements to produce a given item, which includes the operations performed, the order in which they are done, the labor or machine resources required at each operation, and the rate those resources process the item at each operation. It may also include tooling and process or other specifications, and serves as the basis for manufacturing leadtime calculations, detailed capacity planning and the cost standards associated with production. Released production orders normally include the standard routing and bill of material, unless modified for a specific order. In this case, it is the production order that combines formula and procedure. There are additional elements that are built into the routing and the BOM. They are time and cost, which are needed to forecast the manufacturing side of the business. The SP88 committee heard the argument that a recipe must not have such variables within it

batch chap 5.qxd

4/25/2006

2:34 PM

Page 79

Recipes

79

because they may vary within the lifetime of the recipe. A change in cost or an improvement in manufacturing time would mean revising the recipe. In some industries it is expensive to modify a recipe because the revisions have to go through a formal (not to say bureaucratic) review process. It is better to keep the current cost information in a file sorted by materials. Time duration information comes from a history of running the recipe (or process). Duration may be affected by process improvements or active statistical process control. Time information is stored in a file that is sorted by subdivisions of the procedure. In both cases, the advantage is that the time-varying data is current and not the data that was available when the recipe was written. That is why you will not find those variables in an 88 recipe. So far, a recipe contains a formula and a procedure, if only by reference. This is adequate if the process equipment configuration is fixed. If not, the recipe must contain information that defines the range of equipment that can be used to make the product. The usual limitations are pressure, temperature, any unwanted reaction with the surfaces that contain the process, the rate of energy exchange, and the agitator blade configuration and power. Requirements may include connections to certain sources or destinations as well as the configuration of vessels. If the recipe requires batch distillation with certain receiver tanks, that limits the equipment possibilities. An 88 recipe also contains a header and other information that will be discussed later.

NAMUR This book will discuss the 88 recipe concepts in detail, but this is a good place to introduce the group that produced the concepts that led to the SP88 work. Some comparisons will be made later, as the SP88 work unfolds. A group of several hundred German control experts from academia and companies such as Bayer and BASF met in Leverkusen in 1949 to form a group that would develop recommendations for the chemical process industries, but not standards or guidelines. They gave their group a suitable name, with the acronym NAMUR. As with other groups, their activities expanded beyond the original name, so the name of the group is now the acronym. NAMUR may be found on the web at www.namur.de, with pages for various languages, including English. NAMUR’s Working Group (WG) 6 for Batch Control was founded in 1966. It published several recommendations before computer use focused the group on software organization problems. WG 6, led by R. J. Uhlig, produced a paper in 1985 (generation of control sequences for batch processes with changing recipes by configuration, using predefined functional modules). The paper described the use of software building blocks that encoded process Grundoperationen (basic operations) to configure control programs. This work led to a published NAMUR status paper in 1987, and then WG 6 became inactive while NAMUR took a few years to reorganize.

batch chap 5.qxd

80

4/25/2006

2:34 PM

Page 80

Chapter 5

SP88 started in 1988, and then NAMUR WG 2.3 resumed batch work in 1990. After more work and some meetings with SP88, NAMUR published NE 33 (requirements to be met by systems for recipe-based operations). The most recent German publication date for NE 33 is 31 March 1993. The first edition of the English translation was published on 19 May 1992. There is now a version dated 17 Jan 2003, that presents the German and English text in two columns. See NAMUR’s web site to obtain a copy. A few terms were changed from 1992 to 2003 due to translation errors. Some of them are listed here to avoid tripping over them later: General recipe to Source recipe, which is a better translation of Urrezept. Basic to Basis, which is a subtle difference. The German root, grund, can mean either. In English, basic means “fundamental,” in the sense that something cannot be further subdivided. Basis means “foundation” in the sense that things can be built upon it, as the basis recipe is the basis for building the control recipe. But then again, maybe this distinction is too subtle. A 1996 paper by Uhlig uses both the terms basic recipe and basis recipe to mean the same thing. Line to Process Cell, perhaps for the same reasons that SP-88 avoided line, because it is not consistently used and is too general. What follows is a selected summary of, and commentary on, the 2003 English translation of NE 33. You should order a copy of NE 33, with the original German beside the English translation, in order to study the deeper meanings of the document. NE 33 describes the separation of the recipe from the process equipment. The process equipment structure and capabilities must be described independently of the products to be made by that equipment. This description becomes the basis for constructing physical equipment that can produce many products. The process structure (in the sense of procedure) and the process requirements must also be described. These are expressed in the form of a Source Recipe, which is independent of the actual processing equipment. Independence is gained at the price of detail, but the result is a recipe that may be made at any plant site. The last requirement is simply stated as “Matching process cell and process.” A great deal of work is required to get from a Source Recipe to a recipe that will run on the equipment at hand, but it is simply a matter of technical work. No new chemistry is required. NE 33 recommends that three generations of recipe be used: 1. Source to define the process structure and requirements. This is a Research function. 2. Basis to adapt the Source to the capabilities of available equipment. This is an Engineering function. 3. Control to adapt the Basis to specific equipment and its capabilities. This is a Production function.

batch chap 5.qxd

4/25/2006

2:34 PM

Page 81

Recipes

81

The Source Recipe contains specific details on materials that are inputs, intermediates and outputs of the process. It also contains the partial source recipes for the process stages and chemical unit operations necessary to make the outputs. The Source Recipe must include the processing conditions and the proportions of materials and energy ratioed to one of the products of the process. NE 33 defines a process stage as that part of a process that is mainly independent of the other stages in the process. A chemical unit operation is something that processing equipment does at a high level, e.g., react, distill. A Source Recipe is transformed to a Basis Recipe by first deciding what kind of process to use (continuous or some form of batch) and the scale of the process (grams, kilograms, or metric tons). A Basis Recipe may be made for a laboratory, pilot plant, or production plant. A work instruction (procedure) must be designed for each chemical unit operation. The instruction must define how that operation will be implemented in the target class of equipment. A work instruction is defined as an event-controlled combination of actions, such as those depicted by a sequential function chart (IEC 60848). A Basis Recipe is transformed into a Control Recipe by assigning available suitable resources (equipment and materials) to each process stage in the Basis Recipe. Additional information needed to operate the specific processing equipment may be defined in the Control Recipe. The original German Steuerrezept literally means “steering recipe,” as opposed to “regulation” (Regelungstechnik). The lowest level recipe certainly does steer the equipment through the procedure. NE 33 says that the structures of the process (recipe) and process cell (equipment) have to be compatible. It recommends some DIN standards for terms that will make compatibility possible. ANSI/ISA-88.01 also defines terms for this purpose, but more about that later. NE 33 then presents a block diagram of a process cell that is very similar to the Physical Model in ANSI/ISA-88.01. All terms are defined in DIN 28004 except Equipment Module. The literal translation of the German text is “technical equipment.” German does have a word for module. Works: The set of all areas on a common site, including infrastructure. Process Area: Group of several process cells and their auxiliaries. Process Cell: The set of all necessary and standby facilities and buildings required to implement a process. Unit: The smallest independent part of a process cell that can perform the requirements of a process stage. Device: A machine, apparatus, or instrument of a process cell, including passive parts such as vessels and pipes. Equipment Module: A group of devices that implement one or more technical functions. The diagram in NE 33 shows that each layer higher than a device consists of the layer

batch chap 5.qxd

4/25/2006

2:34 PM

Page 82

82

Chapter 5

below it, with the following exception. An equipment module may be formed from a group of devices to perform a process function, such as tempering the process material with a heat exchanger. A Unit may be equipped with Equipment Modules. NE 33 does not discuss common resources. The structural properties of process cells may be described as follows: Single Stream: The order of the units is fixed. Multiple Stream: A set of single stream lines with no product transfer between them. Single Product: Any line that produces the same product, possibly with variations in materials and procedures. Multi-product: Can produce different products by one of two methods: 1. All products have the same procedure, differing only in materials. 2. The products have different procedures. Fixed Path: All products follow the same path through the line. Variable Path: Products need not follow the same path. There are two possibilities: 1. The path is predetermined before production begins. 2. The path is determined by conditions during production. Concurrent Production: Different procedures are carried out in different units. The materials may be mixed in a following unit according to its procedure. Parallel Production: The processed material is split into separate units and processed in the same way at the same time. The material may be rejoined for further production. Section 7 of NE 33 is about structuring processes and recipes. The following table is a condensation of NE 33’s Figure 7.1, titled “Relationship Between Process and Recipe.” Process does not mean equipment. Table 5-1 Condensation of NE 33-Figure 7.1 Process

Source Recipe

Basis Recipe

Control Recipe

Process Stage

Partial SR

Partial BR

Partial CR

Basis Operation

Control Operation

Basis Function

Control Function

Chemo-Technical Unit Operation

The process can be described by Process Stages and Chemo-Technical Unit Operations, as previously described. The distinction of Chemo-Technical means that the Unit Operation is a chemical unit operation such as distillation or a reaction such as sulfonation. A biotechnical Unit Operation is fermentation. There are very few technical details for these operations. They are concepts that tell the author of a basis recipe approximately what is required of a unit, at the level of distill versus mix.

batch chap 5.qxd

4/25/2006

2:34 PM

Page 83

Recipes

83

The Source Recipe describes the process. The Process Stage may be called a Partial Source Recipe. Both are composed of Chemo-Technical Unit Operations, since both are intended to be independent of physical equipment at any plant. The Basis Recipe, now specific to a plant or process area, is also composed of partial recipes, which are composed of Basis Operations. Basis Operations are a reusable set of actions that are not specific to a process cell, so that they may be used in similar cells. Basis Operations are the building blocks of recipes. Basis Functions are those necessary to implement a Basis Operation, such as dosing and tempering. Basis Functions are not product or cell specific. The Control Recipe is a Basis Recipe made product and cell specific. The same is true of its partial recipes, Control Operations and Control Functions. Each Control Function is now able to instruct a Technical Function that is specific to the equipment being used. A Technical Function is the realization of a Basis Function in a specific Unit, including the process engineering purpose, equipment used (devices and equipment modules), and the work instruction (control program) for that equipment. The remainder of NE 33 provides more detail on the concepts presented previously. This summary was intended to present the NAMUR concepts as a precursor to delving into ANSI/ISA-88.01, so the additional explanatory detail will not be presented here. The document is well worth reading.

Recipes What follows will restate many of the ideas above. This is because you might as well put this book back on the shelf if you do not grasp the concepts that drove SP88 to do what it did. No, 88 is not just about recipes, but recipes are at the very heart of 88. The words will use the NAMUR concepts just explained, but 88 has standardized some different terms to be delved into in detail in following chapters. The differences will be noted.

Evolution of Recipes The last fifty years have seen some remarkable changes in the way recipes interact with processes, especially with process control computers automating much of the work. There are some basic principles that are looked at in new ways now, but are still recognizable. Before computers invaded batch process control, men (not women in those days) had to translate recipes into changes in a unit’s configuration and regulate process conditions by turning manual block valves and adjusting simple PID controllers. Batch control referred to special anti-windup circuits in a PID box. Dry ingredients might be weighed on a drum-sized scale and added through a manhole on the top of a vessel.

batch chap 5.qxd

84

4/25/2006

2:34 PM

Page 84

Chapter 5

The operator had a paper recipe on a clipboard showing the things to be done, step by step, along with things to watch out for (exceptions) and what to do about them. A batch identification name and/or number was written on the recipe either before the operator got it or after the batch was successfully completed. The paper recipe may have been one of many printed from a recipe master form. This recipe had all of the steps for a class of equipment, but may have had blank spaces to be filled in with some ingredient amounts and notes to the operator. The operator might cross out some of the things that did not apply to the equipment chosen for this batch. The paper recipe became the batch log as the operator noted the process conditions and the times when steps started, as well as any exceptions and how they were handled. The recipe master was perhaps written by the chemist in charge of developing the product. More likely, the chemist’s recipe was rewritten with more detail for the operator by someone in Operations who understood chemistry and knew the process equipment. If the chemist worked in a laboratory that was remote from the production plant, someone from Operations had to rewrite the recipe to account for the differences in environment. A glass beaker stirred with a glass rod had to become a metal reaction vessel stirred by a propeller on the end of a long motor shaft, and so on. That makes three levels of recipe back in 1950, but there were no standards to give them names. In those days, recipes just had steps. One of the earliest pieces of control equipment specifically built for batch control was the drum programmer, as built by Tenor and others. A batch procedure was configured on the drum by pressing plastic pegs into rows of holes underneath switches that activated various pieces of equipment. The drum reinforced the idea of a series of steps because all it did was step from one row to the next. A step occurred when some process condition with an alarm unit energized the coil that caused the drum to advance one step.

Changing from Drums to Digital Computers The paper design for a drum appeared as a matrix of columns representing switches, like “open water valve,” and rows of steps. The number of steps was limited by the circumference of the drum. The number of steps was limited to much larger values when computers could do that job. Programming hundreds of steps was quite tedious and prone to error, so the technology did not survive except where it was cost-effective. The drum era left behind many people who thought that batch procedures should be a list of steps. Some people noticed that repeating patterns appeared in the matrix, while others just found a better way to organize the steps that an operator or drum had to perform. Many of them called a group of steps a “phase.” There are still some who say that moons and matter have phases, but processes have something else. The word phase has many meanings. Among them is “the point or stage in a period of uniform circular motion ... to which the rotation ... has advanced” relative to a fixed position. A drum

batch chap 5.qxd

4/25/2006

2:34 PM

Page 85

Recipes

85

provides circular motion, but the points to which it has advanced are called steps. Still, it is logical to call a portion of a cycle a phase of that cycle, exactly as the moon has phases. The word phase is also used as “an aspect or part (as of a problem) under consideration.” SP88 used phase as the smallest part of a recipe procedure. NAMUR avoided phase with basis, control, and technical functions. Chapter 10 of the 1990 edition of this book refers to a hierarchy of Operation/Phase/ Control Step. A step describes one or more things done at the same time, as they would be shown on an operator’s recipe. A phase is a name for a logical group of steps, such as “add ingredient and heat.” An operation is a name for a logical group of phases, such as “charge and react.” Once again, we have three levels of complexity in the procedure. The 1990 edition discusses nine ways to diagram a sequence but has examples that show a single path. There is only one example of a parallel path. Parallel paths are required to shorten the batch cycle time, so they have become more common. The Sequential Function Chart, as described in IEC 60848, has evolved as the best way to clearly show a sequence with parallel paths. This is a good thing for the operator as well as the engineer. The advent of digital computers that were reliable enough to be considered for process control (instead of running batches of programs overnight) led to the development of ways to code a batch procedure. The programs were monolithic, containing the complete sequence, all references to equipment through I/O ports and all formula values. Human interfaces reflected the difference between programmers and plant operators, who did not understand each other. Each batch control program (implementation of a recipe) was a unique work of technical art that could only be modified successfully by the artist. Each program was unique to a set of process equipment and could not be used on another set of equipment, never mind transporting it to another plant. As users began to see the usefulness of computer batch control (repeatability, “as good as your best operator,” etc.) vendors began to see ways to fragment the monolithic programs into reusable parts. This was not popular with the systems integrators and their programmers, but the customers were very enthusiastic. By the early 1980s, the I/O references and the formula values were removed to lists. This made it possible to run the same program on similar sets of process equipment and to use the same sequence with many formulas. Sometimes, values were added to formulas that would tell the program which of a choice of sequences to use. The programs were still unique, and still required a programmer to make any changes or create new sequences. The programming task became one of finding a common program that would run on any unit given a table of unit-relative names and the tag names of individual unit equipment items. That is, if the program said “Open Valve A” then it was necessary to go into the table, find Valve A, then look up the real valve tag name based on the unit being run, and send the Open command to that valve’s discrete output. There was a different way of doing this for each batch system, since each company had its own programmers. In those days, this was seen as a way of differentiating a company from its competition.

batch chap 5.qxd

4/25/2006

2:34 PM

86

Page 86

Chapter 5

Modular Programming The breakthrough in the 1980s was to modularize the batch program with reusable sequence fragments. One of the first of these was called a “device control block,” which took a binary setpoint (Open/Close) and sent it to a discrete output. If there were position or run confirm switches, they could be input to the block so that an alarm could be generated if the confirm signal did not match the setpoint after waiting for the physical device to move. Blocks that are more complex have been slow to appear because user demand is not sufficient to overcome vendor inertia. This is partly because of the product differentiation thing and partly because there is no consensus among users. The device control block was very common. It took many lines of code out of batch programs that would have waited for a time to confirm the position of the device each time it was moved. Modularity has reduced the cost of building batch control systems for users. Monolithic program maintenance reaches a point where each bug fix breaks something else because of the complexity of the interactions. Modular code, particularly object-oriented code, allows only a few functions per module, preventing complex interactions. Modules simplify testing and lead to faster validation of new and modified processes. Modules also make it possible to train users in the behavior of each module, without regard for the code that provides the behavior. With the sequence code hidden in modular building blocks, it became possible to assemble batch control programs from these blocks, with some training in their assembly. This meant that the person who understood the process could produce a functional batch control program that was very likely to make the desired product on the first try.

Separating Recipe and Equipment Programming The next breakthrough was probably made by Uhlig’s NAMUR WG 6. A building block that could direct a part of the process on physical equipment was abstracted to a building block that could be used to construct a batch procedure that was independent of the equipment. This was called the Grundoperation, which translates to “basic operation” or “basis operation.” Further, basis operations could be abstracted to chemical unit operations at a level that a chemist would understand. This enables the chemist to specify a source recipe with unit operations. A plant engineer can translate that source recipe into a basis recipe that will run on any set of equipment available in the plant. If everything is arranged properly, the basis recipe can be automatically translated into a control recipe, and product can be made that the chemist would recognize. There is a lot of work that has to be done in the background, but new recipes no longer have to be explained to programmers who do not understand plant operations. The 1985 NAMUR work showed how the control function could be separated from the technical function of a specific piece of equipment. This further abstraction can be used to make even the control recipe independent of the target equipment. No recipe level needs any knowledge of the actual equipment to be operated. Of course, the

batch chap 5.qxd

4/25/2006

2:34 PM

Page 87

Recipes

87

choices of basis functions must match the capabilities of the equipment. One cannot heat if there is no heater. To separate the recipe and equipment, first determine the basis functions that will be required to make the desired products. For each basis function, a matching technical function is designed for a set of equipment. The technical function expects to receive any product-dependent information from the recipe control function that requests its services. This requires the development of a standard interface for making the request, but much more about that later. The technical function code may be written specifically for one set of hardware, or it may be written to work with I/O aliasing tables. The “code” could consist of standard continuous control function blocks (DCS style, not PLC) under the direction of a function block running an SFC, all configurable. A communication protocol for control in the field was introduced in 1996. It has now gained wide acceptance. There is no technical reason why this protocol will not allow technical functions to be completely implemented in field devices. This leaves the user free to select the best human interface and recipe execution software to run in standard computers under a narrow choice of operating systems, which the user’s IT department will be happy to provide. One day, recipe execution may reside in field devices, but first something has to wipe out the DCS and PLC dinosaurs so the next generation can thrive. Typically, this takes at least a generation of human managers, designers and operators. The existing systems have already been around for a generation, so perhaps it will go faster than that. The future is impenetrable. Technology-based predictions fail because technological advances are unpredictable. So are the economic and political drivers that favor one technology over another.

Summary This chapter has covered the concepts and history needed to understand why SP88 did what it did with regard to recipes. If anything regarding recipes in the following chapters is not clear, try re-reading this chapter to gain some insight. The evolution of recipes from alchemy explains the origin of some fundamental terms. The discussion of another definition for recipe illustrated why it was necessary for SP88 to define terms. The history of NAMUR in batch control was presented to show how some fundamental concepts entered our thinking and changed the way we do batch control. The history of batch control with computers was discussed in order to gain an appreciation of the importance of recipe building blocks and the separation of recipe and equipment. Consider what your life would be like if you had to submit every new recipe or process improvement to IT, where it would be programmed by someone who does not understand batch processing and is perhaps offshore.

batch chap 6.qxd

4/25/2006

2:35 PM

Page 89

Chapter 6

88 Physical Models A model is a representation of a selected part of reality with a lot fewer details. A model aircraft may fly, but it is far less complex than the real thing. One purpose of a model is to control the level of detail to be examined. Reduced detail allows one model to represent many real processes that differ down in the details. It is not possible to achieve common understanding of a complex subject without building a model. A group will discuss a model until they are comfortable with it (or don’t care) and then move on to the next model. Understanding has been reached when people stop changing the models. If you are building consensus in a group of people, you first list the items that need models and then pick one to start on. You have to have simple models that everyone understands. Everyone starts by throwing their pet model into the pot, and then the group members try to combine the best ideas into one agreeable model. This results in models that are not perfect but are able to work together. Each model provides a point for focusing analytical skills, which reduces the time wasted by debates among people who are not talking about the same thing. A standards committee must come up with a set of models that everyone can understand, even if that means leaving out the deeper meanings attached to the models. A standard that everyone understands differently is worthless. You could say that ANSI/ISA-88.01 is partly a communication standard for people that are discussing batch control.

Modeling Suppose that you are trying to fix your car, but what is under the hood does not look familiar. You go to the Internet and find a list of parts for your car, arranged numerically by part number. The list is not useful, unless you are a very remarkable person. What you need is a set of drawings with breakdowns of major parts of the car (e.g., engine, transmission, suspension, body) along with callouts of part numbers for the parts shown. The drawings are models because they are representations of the car and not the car itself. The difference between a list and a model is that the model shows the relationships of the items. The example above is actually a detailed model if it shows every part of a specific engine. SP88 could not use detailed models because the standard must cover all batch

batch chap 6.qxd

4/25/2006

2:35 PM

90

Page 90

Chapter 6

processes. The models must fall back from details to abstractions of the details of many plants. They are not as abstract as the paintings of Salvador Dali, but you may have trouble recognizing things. That is why so many words accompany a model. The 88.01 models are presented in the hope that you will recognize most of them in your processes, so that the models and their terminology will mean the same thing to you as they do to system integrators and vendors. You should check to be sure that everyone means the same thing when they use a term or make reference to a model. 88.01 is not a compliance standard, and there are no 88 Police or testing labs. You personally have to verify compliance. Perhaps that is why you are reading this book. Some vendors designed systems before the standard was published; using some concepts that later changed over the standard’s fourteen drafts. Now they have systems with the 88 terminology but the wrong meanings for some of the terms and the wrong models for some of the key concepts.

Models in 88.01 Most of the models in 88.01 are variations on block diagrams, with arrows to show the directions of named paths. Such diagrams are clearly (well, some more clearly than others) explained by accompanying text. SP88 began with some hierarchy models, but they were all later converted to entity-relationship models. Models often consist of entities. The word entity was introduced in the 88 definitions as meaning any distinct thing. One entity is distinguished from another by its attributes, especially identity. Behavior may also differentiate one entity from another. An entity may be physical or abstract, that is, tangible or an idea expressed graphically or in words. An entity may be a box that contains smaller boxes or a boundary enclosing other entities. An entity may be a person or a corporation, but most of the time in 88.01 an entity is a piece of controlled equipment.

Hierarchy A hierarchy is a graded or ranked series of entities. The relationship between entities is expressed by the position of the entities in a list, with the most important usually on top. No special relationship symbols are required. The relationship depends on the things being ranked. An officer’s hierarchy ranks a major over a lieutenant. This does not mean that the major contains lieutenants, nor is he composed of them. It just means that a major outranks lieutenants. Entities that are commanded by officers, like division, regiment, and company, are boundaries that do contain the entities that are below them. The difference is that a colonel is an individual and a regiment is a boundary that has been created to define the scope of control given to a colonel.

Entity Relationship An entity-relationship diagram shows, as you might guess, the relationships between the entities that have been chosen to make the model. Relational database designers use such diagrams to design large databases. Most people are not database designers

batch chap 6.qxd

4/25/2006

2:35 PM

Page 91

88 Physical Models

91

but they do care about relationships. Special symbols are used to express a relationship. See Appendix A of ANSI/ISA-88.01for definitions of the symbols. If you don’t know the symbols, then the layered models of 88.01 may be read as hierarchies with very little loss in meaning. One of the meanings for a connecting line in an entity-relationship diagram is “contains,” meaning that the upper entity contains the lower entities. This is not to be taken literally, unless the upper entity is a physical container. The phrase “is composed of” often works better than “contains.” A connecting line may start and end at the same entity. This is called recursion, if you think some database jargon would look good on your résumé. It means that the entity may be composed of entities with the same characteristics. For example, Units may be composed of Equipment Modules, but there is no recursion because the entities are different. Equipment Modules may be composed of equipment modules in the same way that an electronics module may be composed of smaller electronic modules. The modules don’t all have the same function but they all fit the description of a generic module.

Batch Processes and Equipment in 88.01 (Ref. ANSI ISA-88.01) The following discussion covers Clause 4 of 88.01. Key figures are shown and text is sometimes quoted, but this book was not meant to substitute for the standard. Throughout the remainder of the book, numbered paragraphs use the numbering of ANSI/ISA-88.01-1995, Batch Control Part 1: Models and Terminology.

4.1 Batch Processes Processes have already been discussed in Chapter 1, but here they are again from another perspective. Different words are used here instead of those in 88.01 in order to aid understanding.

4.1.1 Continuous processes Designed to operate with a continuous flow of material through the processing equipment. The equipment is not readily adaptable to a new process for a new product. An oil refinery may produce different mixes of products, but the equipment can’t be adapted to process food-grade vegetable oil. Process control is relatively simple and mostly regulatory because the process runs best in a steady state. Simple relative to recipe-based processes, that is. The people who design process models that run in supervisory computers do not think of them as simple.

(Not in 88.01) Discontinuous Designed to operate with a continuous flow of material but with better adaptability to different products. A process is discontinuous if it has to be shut down in order to change over to a different product. Occasionally, a process will use a controlled sequence to start up or shut down, but mostly the control is the same as in a continuous process.

batch chap 6.qxd

4/25/2006

2:36 PM

92

Page 92

Chapter 6

4.1.2 Discrete parts manufacturing processes Designed to produce identical solid products, quite different from the above fluid processes. Each product produced is physically different from the preceding product, even if they are intended to be identical. The laws of probability are obviously at play in discrete processes. Discrete process equipment ranges from versatile to highly specific. The equipment has to be set up for each type of part manufactured and runs like a discontinuous process, perhaps changing every year or every week. Control is done by discrete logic, which may be reprogrammed for each new run of parts. Individual machine tools may use numerical control to position a selection of tools to shape a part.

4.1.3 Batch processes Designed to operate with discontinuous flows of materials and energy while making one batch of product. The equipment is designed to run chemical process operations, such as mix, react, and separate, for the range of products intended to be produced. Control is designed to help equipment provide process functions. Figure 6-1 is similar to Figure 1 in 88.01. It looks like a hierarchy, but the decorations on the lines between levels make it an Entity-Relationship diagram. The meaning of a decorated and annotated line is as follows: An instance of the thing above me consists of an ordered set of one or more instances of the block below me. The set is ordered in the sense that items in the set have to be processed in a certain order if you want to get a useful result.

Figure 6-1 Process Model (Entity-Relationship Diagram) A batch process may be subdivided into a hierarchy based on the complexity of processing. The top level is a process, which represents the sequential transformation of materials into batches of product.

batch chap 6.qxd

4/25/2006

2:36 PM

Page 93

88 Physical Models

93

88.01 uses a polyvinyl chloride polymerization process as an example. The following paragraphs have the same section numbers as 88.01 but are more general, with no particular example.

4.1.3.1 Process stages The first subdivision is the process stage (as in a stage of life rather than a wooden platform supporting actors). A process stage may be physical or chemical. If chemical, it represents a reaction that creates new materials. If physical, it represents the preparation of materials for reaction or the separation of products after the reaction. If a batch process does not have a reaction, then a process stage may be a part of the process in which the entropy of the material is changed. Mixing a base paint with coloring represents an increase in the confused state of the universe, and so entropy increases because the mixing cannot be undone.

4.1.3.2 Process operations The next level down is the process operation. A process stage represents an ordered set of process operations. A process operation represents a major processing activity such as preparing a reactor, charging it with materials, bringing the materials to the right processing conditions for this process stage, making the reaction go or finishing the process stage.

4.1.3.3 Process actions The last level down is the process action. Each process operation represents an ordered set of process actions that will accomplish the process operation, such as add a material, transfer heat, agitate, or maintain reactor pressure.

4.2 Physical Model The 88 Part 1 physical model in Section 4.2, Figure 2, took applicable parts from Computer Integrated Manufacturing (CIM) models by Purdue, the U.S. National Institute of Standards and Technology (NIST), and the European International Standards Organization (ISO). A discussion of these models appears in Chapter 4 of the first edition of this book. The existing (in 1989) models were rejected as being for discrete or continuous processes. So applicable parts were taken from the existing models and new layers were added to create the batch model described in the first edition. The SP88 committee developed the current (1995) model starting from the 1989 batch model. Figure 6-2 is a representation of Figure 2 from 88.01. It shows the final physical model arrived at after countless discussions and revisions. The physical model started out as a four-level model, like Figure 6-1. It is possible that three more layers were added to make it a seven- layer model. Seven-layer models were hugely popular at the time, since ISO’s seven-layer Open Systems Interconnection (OSI) model for a communication stack was receiving much publicity in control magazines. More likely, the search for completeness drove SP88 to add Site to the model, which brought along Area and Enterprise.

batch chap 6.qxd

4/25/2006

2:36 PM

94

Page 94

Chapter 6

As an Entity-Relationship diagram, Figure 6-2 has the same decorated line, but the notes are different. They specify containment, but sometimes the container is logical instead of physical. Each unit and its controls are not all physically in the same container. Most of the notes specify “may contain.” This means that the box below doesn’t have to be there. The note above Unit states that the Process Cell must contain one or more units. Actually, this applies all the way up. Any one of Process Cell, Area, Site, or Enterprise, if they exist, must contain a unit or a lower box that contains a unit. There should have been a “must contain” above Control Module because the Unit causes changes in the process through the control modules that touch the process. Both Module boxes have a line that returns to the same box, which means that one module may contain many of the same kind of module. Clearly, this should have been “may consist of” rather than specifying physical containment. Then again, perhaps it meant abstract containment, but too much abstraction makes a model lose focus.

Figure 6-2 Physical Model The top three levels—Area, Site and Enterprise—are shown with fuzzy borders because they can’t possibly be defined by a batch control standard, but it is useful to give them names. We will meet Site recipes later, for instance. The top three levels follow below, again with different words for the section numbers in 88.01:

4.2.1 Enterprise level An enterprise consists of a Home Office and all of the layers below, if they exist. A simple business may locate the home office in a corner of a building on a site, although “enterprise” conveys something grander than that. An enterprise must contain a Unit

batch chap 6.qxd

4/25/2006

2:36 PM

Page 95

88 Physical Models

95

somewhere in order to be the subject of a batch control standard. The home (or corporate) office contains the people and equipment necessary to plan and run a business. This may include converting sales orders into production orders and assigning them to sites. One or more R&D labs may be directed to work on specific lines of products or they may serendipitously discover something like a not-so-sticky adhesive for notepads. The people approve new products for production and prepare the General recipes to control the properties of the products to be made at selected sites.

4.2.2 Site level A Site is anything the Enterprise wants it to be, but usually it is an owned amount of land, sea, or space where production occurs. A site may just be real estate with no buildings—a green field with grass roots. The site physically contains the lower layers that follow, if they exist.

4.2.3 Area level The Area was originally put forward as the physical entity that contained the highest process control functions. Discussion revealed that areas are really political subdivisions of a plant, whose borders are subject to the whims of management. The control of units requires something better defined than that. Eventually, SP88 reached consensus on the non-control status of Area, and so it joins Site and Enterprise as parts of the physical model that are defined by management and not by control engineers. There still seems to be a need for some real-time coordination control to direct process cells in large installations. At this point, such control would have to be sandwiched between Process Cell and Area. It has to be above the Process Cell in order to coordinate cells and below the Area because the Area is political and not capable of real-time control. The lower four layers are created by engineering activities for the purpose of producing one or more products. Each level consists of the physical processing and control equipment that is required to perform its part of the process hierarchy shown in Figure 6-1.

4.2.4 Process cell level The Process Cell is a compromise name for the function of coordinating the activities of the units bounded by it. SP88 converged on the term cell from the models for discrete processing. Figure 6-3 compares the ISO CIM model with the 88.01 physical model. The first edition of this book used Train/Line for this layer, but the SP88 group was uneasy about that. Both Train and Line suggest the linear progression of a product through equipment, which is common in continuous processes. A discrete manufacturing cell is a collection of machines that does not imply any order of processing. SP88 had to call this layer a Process Cell to distinguish it from the widely used discrete cell.

4.2.5 Unit level The Unit has retained the same functions in batch processing for many years. SP88 did not have to discuss the name, but some time was spent on putting its functions

batch chap 6.qxd

4/25/2006

2:36 PM

Page 96

96

Chapter 6

into words. A unit consists of all of the equipment and control necessary to carry out one or more major processing activities. A unit may temporarily extend its boundaries by acquiring additional common equipment, or it may negotiate with another unit for its services. A unit performs its processing activities independently of all other units, except for transfers, cleaning/sterilizing, and contending for common resources or utilities. A batch of material may be split among units, but a unit never contains more than one batch at a time. Do not confuse a Unit with a vessel. A Unit is a border around a set of controlled equipment. A Unit contains a major vessel such as a reactor in order to contain a batch and process it. A Unit may contain auxiliary equipment such as a heat exchanger. A Unit may temporarily contain common equipment such as an inert gas generator, solvent heater, or transfer header. There is some difficulty with the “contains a batch” concept if you call all of the loaves of bread from one batch of dough a batch and you call the conveyor-belt oven a unit. Don’t do that. As each lump of dough is dropped into a baking pan or onto a cookie sheet, it becomes an identifiable discrete product to be processed discretely. The batch of dough becomes a lot of loaves or cookies or donuts, where “lot” means a group of almost identical solid objects, not a relative expression of quantity. Baking with a conveyor is a continuous process because gas runs to the oven heaters until it is time to shut down the piece of equipment called an oven for maintenance. The baked objects are unique and so they are discrete. You see, a document can present a few concepts in a few clear words that cause you to think that you have completely understood the simple subject that was presented. Then Reality shows you one of its infinite variations that does not fit neatly into the concepts and casts doubt on your clear understanding. This is called a reality check.

4.2.6 Equipment module level The Equipment Module is defined by the process function (or functions) that it is designed to do. It consists of one or more Control modules and possibly of subordinate Equipment Modules. An Equipment Module may be permanently within the boundary of a Unit or it may be independent of any Unit. The module is also a border around a minor group of equipment that has a process function such as dosing, filtering or heating. The border contains all of the equipment and control that is required for the function.

batch chap 6.qxd

4/25/2006

2:36 PM

Page 97

88 Physical Models

97

Figure 6-3 ISO CIM Model Compared to 88.01 Model

4.2.7 Control module level The Control Module is defined by the fact that it is designed to hold the process at some commanded setpoint or hold equipment in a set configuration. It contains at least one sensor and/or actuator. If it contains an actuator then no other module may command that actuator. It only uses a mixture of the six kinds of process control described in Chapter 3. A Control Module may consist of subordinate Control Modules. A module may be designed with any level of complexity. The reason for designing a module is to make it a building block that is useful for constructing other modules. For example, a module that describes the operation of a block valve and its device controller will find use in other batch control module designs. These other designs are simplified because they don’t have to describe each block valve again. An equipment module may consist of control modules and other equipment modules that consist of other modules all the way down until there are no more modules to use.

4.3 Process Cell Classification A good idea of the range of complexity of a batch process may be gained from the defined classes of the process cell. This is necessary when describing the capabilities of a plant to a prospective vendor or customer. Two classifications are necessary to classify a process cell.

4.3.1 Classification by Number of Products A process cell may produce one product or more than one product. Single product cells may make a pharmaceutical product like insulin that is made exactly the same way every time or they may make something like colored paint that is made the same way except for the variations in color. Elsewhere, 88.01 says that every variation or

batch chap 6.qxd

98

4/25/2006

2:36 PM

Page 98

Chapter 6

grade is a different recipe that makes a different product. Here, it is a judgment call whether a variation makes a new product or not. Customers generally insist that a set of product specifications defines a product. If your customer says that certain variations do not make new products, then you are good to go with a single product process cell. The single product process cell has the advantage that the procedure does not change much. This means that the procedure and its variations can be wired into the controlled equipment, which can be narrowly specialized in its process actions. Recipes for the cell only need to specify the name of the procedure, and that is only necessary to prevent a mismatch of recipe and cell. The formula contains parameters that select the variants. Recipe management is simple because of the limited number of variations. A multi-product cell is the only other possibility. It seems closer to the truth to classify cells by the number of procedures that can be run because the number of products per procedure can be greater than one. There is a jump in complexity between one procedure and two. Multiple procedures require implementation of equipment procedural elements so that recipes may select the procedural elements that they require. Recipe management complexity increases because a library of procedures for process stages, operations, and actions is required to support the creation of new recipe procedures. Complexity also rises with the number of recipes, with one recipe per product. In the first edition of this book there are three ways to classify by number of products. Multi-grade is sandwiched between single-product and multi-product. Grades of product are separated by different formulas but not by procedures. Grades exist, but SP88 finally decided that there was one recipe per product, period. A grade is a different product so a grade requires a different recipe. The one-product/one-recipe rule actually simplifies the relationship between recipes and batch process control. And so, the multi-grade class was included in the multi-product class. While it is true that a different product requires a different recipe, it is not true that only one recipe can make a product. Sodium chloride may be made by evaporating seawater or by purifying salt rocks from a mine. It is unlikely that a single product process cell would be designed to do both procedures. A less drastic example is a product that can be made with varying amounts of recycled product. The amount of recycle causes variations in other ingredients, but the product is the same as far as the customer is concerned. It is possible that a single product process cell has two or more procedures that are different enough to make the cell as complex as a multi-product cell. Again, it seems better to classify the cells based on the number of procedures because that is what complicates the design, not the number of products or recipes.

4.3.2 Classification by Physical Structure There are three physical classifications: single path, multi-path and network. 88.01 shows these classifications in Figures 3, 4, and 5. They are shown another way in Figure 6-4.

batch chap 6.qxd

4/25/2006

2:36 PM

Page 99

88 Physical Models

99

Figure 6-4 Comparison of Physical Structures

batch chap 6.qxd

4/25/2006

100

2:36 PM

Page 100

Chapter 6

The single path is just what it says. There is exactly one path for the recipe procedure to follow. There are no agonizing decisions about what vessel to use next. 88.01 says, “Several batches may be in progress at the same time.” This would only be true if the path had more than one unit and if the timing of operations made it possible to run sequential batches down the path. The multiple path structure is a number of single paths running in parallel with no product transfer between paths. This may represent more capacity for a single product, or it may be necessary for a cell that produces more than one product. A path must be chosen somehow. The path may be included in the schedule, selected by the recipe, or chosen by the operator. The choice of paths may require complex calculations to find the combination of paths and products that makes optimum use of the equipment. The network path structure represents the ultimate in flexibility for stationary units. Each unit may be connected to one of several other units so that there is no single path. Consider a cell that has two premix units, three reactor units, four filter equipment modules and three post-processing units. Paths through the filters are first come, first served. Any filter can go to any post-processing unit, any reactor can go to any filter and any premix can go to any reactor. The paths are usually implemented with transport headers, as described in Chapter 4 of this book. Equipment optimization may be very complex if there are no constraints on source and destination. Usually there are constraints, as in the example above where a premix tank can only transfer to a reactor and a reactor can only transfer to a filter. Now add pumps that can send material back to the previous header, possibly for another reaction or to repeat filtration with a different grade of filter. If there is a distillation or other separation in the process then the path also separates. Another classification has been added since ANSI/ISA-88.01 was written. Pipeless plants have become popular for some processes. As discussed in Chapter 4 in the section on Mobile Reactors, there is pipe in a pipeless plant, but not permanently between the mobile reactor(s) and anything else. The reactor may follow a complex or a simple path depending on the product being made. A pipeless process does not fit the three path classifications because each batch is processed in one reactor while it wanders around among fixed stations that transfer materials and energy or perform analysis. A major advantage of the mobile reactor is that the processed material stays in the same tank until the final product is withdrawn, which minimizes the chances for contamination. We now leave 88.01 sections until the next chapter, which begins the discussion of 88.01 Section 5. The following discussion is not in 88.01. It is intended to help understand the standard by showing what did not survive the consensus process.

batch chap 6.qxd

4/25/2006

2:36 PM

Page 101

88 Physical Models

101

Other Physical Models The number of interpretations of the standard suggests that the physical model needs clarification. The model is a marvel of compression of thought. It started out as an equipment model to go with a control model to show the relationship of equipment to control. Many things were discussed and added and removed and tweaked, and finally SP88 called it a physical model. The following discussion may help to decompress the Physical Model. Other models will be used to show other possibilities for physical models. These models are sketches that are intended to illustrate without necessarily being complete.

Plant Physical Model The first model is a physical model of a plant. It shows classes and subclasses of physical things. The classes are site, buildings, equipment, and people. The model lists some subclasses but does not go lower, so that it does not become too crowded. It can not be represented as a seven layer stack. Site: The top box is the place where products are made because that is the upper scope of the model. Perimeter: The physical boundary of the plant segregates it from other human activities, and possibly large animals. Some degree of security is associated with the perimeter, depending on the value of things that could be stolen. Security is also required if wandering into the plant could harm an untrained person. Buildings: Many things need to be sheltered from the environment. Buildings contain equipment, although some equipment may be out under the sky. Factory: A building that houses process equipment and workers. Office: A building that houses business people, may be part of the factory building. Laboratory: A shelter for analytical equipment and people. Control House: A shelter for control equipment and shift personnel. Maintenance Shop: A place to put maintenance equipment and people. Usually two different buildings to protect electrical equipment from welding or machining chips and dust. May have another building for a paint shop. Warehouse: A shelter may be required for incoming, intermediate and outgoing materials. Storehouse: A shelter for spare parts and materials required to maintain plant equipment. Garage: A shelter for mobile equipment.

batch chap 6.qxd

4/25/2006

102

2:36 PM

Page 102

Chapter 6

Equipment: The empty buildings cannot make products. A plant also needs equipment. Process: This equipment makes products. Examples are batch reactors, distillation towers, filters, centrifuges, agitators, and process heat exchangers. Auxiliary: This equipment is necessary to make a product but does not alter the product directly. Examples are pumps, pipes, and non-process heat exchangers. Utility: A utility is a set of equipment that provides a generic material to the process, such as steam, hot fluids, chilled fluids, cleaning solution, electricity, solvents, and hydraulic or other fluid power. Control: The above equipment cannot do anything useful without control equipment. Control includes the control instruments such as dial gages, hand valves, sensors, and actuators. Maintenance: This equipment includes machines to make or repair parts, like lathes, welders, and electronic test equipment. May include cranes and earthmoving equipment. Transport: Anything that is required to move materials between processes or between process and storage, including pipes that are not considered to be a part of a piece of process equipment. The equipment is mobile if it is not stationary like a pipe or conveyor belt. Storage: Fluids are stored in tanks, granular materials in silos, films on spools, and solids in packages. Office: The office has always needed equipment, like desks, word processors, printers, and shredders. People: The equipment needs to be supervised and operated by people. Managers: Provide direction for the successful operation of the plant. Responsible for meeting goals. Supervisors: Provide direction to individuals. Responsible for shift coverage. Operators: Responsible for the safe operation of the plant. Maintenance: Responsible for predicted and unexpected repairs of plant equipment. Engineering: Responsible for the efficiency of plant operation, carry out improvement projects. Safety: Responsible for safety training and inspecting for hazards. Office: Take direction from managers. Laborers: Unspecialized, minimum wage workers. An Area is not included because it is not a physical entity. It represents as much equipment, buildings, and people as one person can control. A process cell is not a physical

batch chap 6.qxd

4/25/2006

2:36 PM

Page 103

88 Physical Models

103

entity but a name for a grouping of equipment. It represents as much equipment as can be conveniently controlled, considering reliability, availability, and the amount of information passed within and among cells. Units and process control modules are too detailed for this model.

Enterprise Model The second model is an abstract model of the organization that gives direction to plants. The plant model has quite a few components, but the levels above the plant contain only office and communication equipment. Nothing is manufactured above the plant, except a pot of other people’s money. Communication is required to give direction to the components of the enterprise. Home Office: Enterprise Management: A group of people who direct the enterprise. Contains the top-level management for all regional and plant functions. Contains the treasury and issues stock. Receives proposals to build new plants, as well as buying and selling plants. At one time, contained Central Engineering, now replaced by lawyers. Requires support for the usual office functions. Regions: Arbitrary subdivisions of the enterprise. May be divided by geography, native languages or product lines. Management: People who interpret enterprise direction in a way that will be best for the region, in terms of the enterprise. Marketing: Does regional market studies, attracts major customers, and directs advertising. Sales: Finds major new customers, pursues corporate clients and extracts orders. Operations: Provides direction to the plants in the region, in order to fill sales commitments. Support: Provides support to the region for communication, purchasing, hiring, legal, engineering, and so on. Sales Offices: Perform the local sales function, which may include retail stores. Management: The people who interpret regional direction in a way that will be best for their region and sometimes for their customers. Sales: Finds new customers, maintains human contact with customers, inquires about future work, handles satisfaction problems, recommends product solutions to local needs, reports changing customer information, takes orders. Support: Local product support and ordinary office or store support. Plants: Provide products in a timely manner.

batch chap 6.qxd

4/25/2006

2:36 PM

Page 104

104

Chapter 6

Control in the Physical Model The physical model is also a place to show control relationships. The following discussion is not in 88.01. The equipment module from 88.01 becomes “group” here, and the control module becomes “loop.” Instruments are introduced as separate entities instead of hidden in modules. These are well-known terms but they are not mentioned with 88.01.

Process Control Physical Model The Unit contains the highest level of process control that directly influences a batch process. This model covers four levels of controlled equipment. The Instrument level has been separated into Sensor and Actuator. Unit: A group of controlled equipment that is capable of batch processing. It may control groups and loops. Group: A group of controlled equipment with a complex command interface. It may control loops and actuators. Nothing is implied about the kind of control that is performed. The term group is simply a way to consolidate a number of loops that control the same piece of equipment. Loop: A smaller group of controlled equipment with a simple command interface. It may control actuators or other loops. Instrument: Either a sensor or an actuator that is necessary for control of equipment. Actuator: Receives commands from loops that cause something to directly affect a physical process property. Sensor: Directly measures a physical process property. May communicate with loops, groups, and units.

The Control Part of Controlled Equipment The relationships of process control can be quite detailed, and so they are not suitable for a high-level model. A distillation column needs control in order to maintain the conditions required to separate one material from another. The fact that five control loops are required and where they are placed is not important at this level. An agitator requires control, but the kind of control (on/off, two speed, variable speed) does not matter. Abstract control is used in high-level models to show that some form of control has been applied to equipment to make that equipment useful.

Abstract Communication Model This model is intended to show the communication of control commands and feedback. Control commands flow down the model while feedback from the effects of the commands flows upwards. The commands are discussed. The feedback is assumed. Inevitably, we end up with a hierarchy. It may take ten levels to get from the enterprise to the process.

batch chap 6.qxd

4/25/2006

2:36 PM

Page 105

88 Physical Models

105

Enterprise: Controls the people in the regions, responsible for everything that happens below. Region: Gives direction to plants. Plant: Source of local direction for producing products. Area: Gives direction to operations within its process, storage or utilities area. Cell: Requires coordination control in order to give direction to the units and stand-alone equipment modules. Unit: Gives direction to a set of controlled equipment that is capable of executing process functions. Group: Receives direction from a unit. Gives direction to a set of loops. Loop: Receives direction from a unit or group. Gives direction to an actuator instrument. Instrument: The source of control information or the destination of control direction. Process: Receives physical direction from actuators. Supplies information to sensors. Not all businesses will use all ten levels. The model for a simple, manually controlled process may contain four levels: Plant: Source of direction for producing products, usually given to unit supervisors. Unit: Gives instructions on paper to the personnel that perform the control part of controlled equipment. Instrument: The source of human control information or the destination of human control direction. Process: Responds to actuators and supplies information to thermometers, pressure gages, and level indicators.

Control Communications Models The following models appear as figures because figures are far more efficient than words, once you get away from simple hierarchies. They show the flow of control communication from the boardroom to the field instruments. All of the communication could be person to person, except for the instruments. Automatic control generally handles communication between loops and instruments. Process automation may go further up the hierarchy to the unit or even cell level. Business automation will be found from the boardroom down to the lowest political level, the Area. Somewhere around the Area, business automation must interface with process automation. The rules for reliable communication change at this interface because time sensitivity and data ownership are different.

batch chap 6.qxd

4/25/2006

106

2:36 PM

Page 106

Chapter 6

Figures 6-5 and 6-6 are divided at the Unit simply to keep the size of the figures manageable. No special border or interface is implied, although batch control does tend to center on the unit. Figure 6-5 shows the uppermost levels of communication. All of it is two-way, so no arrows are shown on the lines that represent communication paths.

Figure 6-5 Uppermost Levels of Communication Figure 6-6 shows the process control levels of communication. Instrument communication may be two-way for the communication of status, but one-way arrows are shown as the principle paths. Notice that a Unit may communicate with any of the lower levels, Groups with other Groups and Loops with other Loops. Commands may flow down or across levels. Sensor information may flow up to any level.

Figure 6-6 Process Control Levels of Communication Communication with the levels below a Unit is constrained to those things that are owned by that Unit, in order to prevent any conflict of commands. One unit may ask another to do something, like open its transfer valve, but the unit that owns the thing to be commanded must issue the command to it. The owning unit may reject the

batch chap 6.qxd

4/25/2006

2:36 PM

Page 107

88 Physical Models

107

request because something else is going on. The requesting unit may either wait for the owning unit or try another. The corollary to this arrangement is that each group, loop, and instrument must be owned by exactly one unit. There is no command communication path between the lower levels in one unit and those in another. Information may be freely available among units, but most of what goes on in a unit is not interesting to a different unit. The stand-alone Group is generally a set of common equipment. Equipment may be shared by units when there is no overlap in the use of that equipment. This arrangement requires a special case for Group communications to allow Units to negotiate for the services of the Group. The situation is slightly more complex when the Group can serve some, but not all, units in a Cell. Units and stand-alone groups in one cell do not communicate with their peers in another cell. Coordination communication is normally done between a cell and its units, but could be done among cells. A cell is supposed to be able to take direction from a schedule without regard for what other cells are scheduled to do, but there might be a utility limitation that requires the schedules to be adjusted among the cells.

Summary This chapter began with an introduction to models in general, and then discussed the models used in 88.01. The discussion went on to cover 88.01 Section 4, Batch Processing and Equipment. Batch processes were covered using different words and adding the discontinuous process. This was done for clarity and not to change the wording of the standard, which stands as it is until it is revised. The Physical Model was explained with the help of some new figures and different words. Batch process classification was discussed and a new classification for pipeless plants was suggested. Then the discussion turned to other ways of describing the material covered by the Physical Model. A plant model consisting of site, buildings, equipment and people was presented. Then came an enterprise model that consisted of a home office, regions, sales offices, and plants. These two models have nothing to do with batch process control but perhaps they helped to clear up what the 88.01 Physical Model did not contain. The next models showed how control, both business and process, might flow in the models that were presented earlier.

batch chap 7.qxd

4/25/2006

2:36 PM

Page 109

Chapter 7

88 Batch Control Concepts, Part 1 This and the following two chapters cover ANSI/ISA-88.01 Section 5, Batch Control Concepts. These concepts must be understood in order to grasp the meanings of Section 6, Batch Control Activities and Functions. Covered are equipment entities, recipes, production schedules and reports, allocation and arbitration, modes and states, and finally, exception handling. This chapter covers Sections 5.1 and 5.2 on equipment entities.

5.1 Structure for Batch Control There is a three-level hierarchy for the concept of control. The levels are Coordination, Procedural, and Basic control. See Figure7-1, which is not in 88.01. This hierarchy is necessary because each level requires a different way of thinking about a problem. In 2005, each level also requires different control equipment capabilities. This is not so much because different computers are required as it is that each level is worth more than the one below it, but that’s nothing that a free market can’t sort out.

Figure 7-1 Three-Level Hierarchy of Control

batch chap 7.qxd

4/25/2006

2:36 PM

Page 110

110

Chapter 7

5.1.1 Basic Control At the lowest, most basic level we find Basic control. There is no simpler control. It could also be called Basis control because the higher levels can not work without it. It is Basic control that can change and hold the state of the process material (e.g., pressure, temperature, agitation, composition of reactor headspace gas). It is Basic control that can change and hold the state of the equipment configuration (e.g., transfer header, heat exchange media). Basic control includes the six types of control discussed in Chapter 3—regulatory, discrete, sequential, alarm, override, and interlock. Simple examples are the functions of a PID or an on/off device controller. 88.01 adds monitoring and exception handling. Monitoring may just involve taking the measurement for someone else to monitor or it may mean accumulating trend or event data that is reported on demand. Exception handling is very basic because it is limited to one control module. Normally, exception handling takes place at higher levels that have a broader scope. Basic control usually is able to respond to process conditions that represent deviation from the desired state and correct the deviation. If a device does not respond then either it is a command input like a switch or it is a monitoring device, devoid of feedback control. 88.01 does not distinguish between open-loop and closed-loop control. Basic control must be able to accept commands to change its setpoint, if it has an actuator. The source of commands may be a human or a machine. Basic control may be able to report the status of its efforts. For example, a light switch has a visible position, if not a visible effect, which serves to report its status. Basic control for batch processes is similar to that for continuous processes. The batch control environment generates many more command-confirm dialogs to change modes and settings as the procedure progresses. Off is not one of the modes for a PID controller in a continuous process. The Off mode would command a PID to go into manual mode, disable low alarms, and close the valve, all with one command. Basic control is carried out with physical equipment in a manner that is completely independent of the product being made. No part of Basic control resides in a recipe, although executing a recipe procedure may result in commands being sent to Basic control. The results of the command to Basic control may affect the execution of the procedure.

5.1.2 Procedural Control The middle level of the control hierarchy is responsible for animating Basic control. The target states of individual Basic control schemes have to be changed to specified values in a specified sequence. These changes cause the controlled equipment to process a batch of material. The changes (commands) may originate from any process equipment level and propagate down to control modules. Batch process control is not possible without Procedural control to sequence the activities of Basic control in such a way as to produce meaningful activity. Just as

batch chap 7.qxd

4/25/2006

2:36 PM

Page 111

88 Batch Control Concepts, Part 1

111

physical equipment is static without Basic control, so Basic control targets are static without Procedural control. Procedural control has a hierarchy consisting of procedural elements. See Figure 7-2, which is Figure 6 in 88.01.

Figure 7-2 Procedural Control Model The top level is the Procedure. There is no higher level, so this is the entire procedure. Since the Procedure can be quite complex, it may consist of Unit procedures. Each Unit procedure may consist of Operations. Each Operation may consist of Phases. There is nothing simpler than a Phase because a Phase orders the activities of Basic control.

5.1.2.1 Procedure A Procedure orders a set of Unit Procedures. The Procedure should define the starting conditions for each Unit Procedure, even if there is only one Unit Procedure. There must be at least one Unit to contain the batch. An example of a Procedure for a specialty chemical is an entity labeled “Terephthalic Acid Procedure.” The process for making Terephthalic acid (TPA) was used as an example in Chapter 2. An example of a Procedure for a biological process could be “Miraculomycin Procedure.” The process grows cells that make a miraculous drug.

batch chap 7.qxd

4/25/2006

2:36 PM

Page 112

112

Chapter 7

5.1.2.2 Unit Procedure A Unit Procedure orders a set of Operations. The Unit Procedure should specify the starting conditions for each Operation. It is possible for a Unit Procedure to consist entirely of Phases, but this is not a good idea because there are no reusable subdivisions of the procedure. An example of a Unit Procedure could be “TPA Reaction.” There are four nearly identical units in the same process cell. They each empty into a common storage tank, so each unit does not make a different product. One Unit Procedure may be used for all Units. The Unit Procedure has to specify the Unit to be used. A biological process uses one bioreactor to grow cells because there must be no chance that an unknown cell will also grow. After growth is complete, the cells are transferred to a second unit that will either filter the exhausted cells from a product in the growth medium (e.g., alcohol) or harvest the cells to extract a product from within the cells (e.g., insulin, interferon). Multiple unit procedures are required, as specified by the Procedure.

5.1.2.3 Operation An Operation orders a set of Phases. The Operation should specify the starting conditions for each Phase. There must be at least one Phase to command an equipment entity. An ordered list of operations for making TPA follows: • preheat • charge water • charge DMT • react • cool • dump The operations are not complex, but product quality depends on the cooling operation. There are separate charge operations because the 750 psi water charge is violent. DMT and water don’t mix well without the aid of a powerful agitator, but the agitator can’t run during the water charge. An ordered list of operations for growing cells might include: • clean

• inoculate

• sterilize

• growth region A

• charge growth medium

batch chap 7.qxd

4/25/2006

2:36 PM

Page 113

88 Batch Control Concepts, Part 1

113

Again, the operations are not complex. Quality depends on all of them being done precisely according to a validated plan. Cleaning is necessary because life is messy. Sterilization heats and holds the heat long enough to kill the kind of cells that can live in human ambient conditions (i.e., not those on deep-sea volcanic vents). The growth medium may have been made in a unit procedure preceding growth, or it may be made in a common resource. It is brought to the proper temperature, pH, and dissolved oxygen levels during the operation. Inoculation adds cells grown from a much smaller process that will make the specific drug desired. The more cells, the faster growth goes to completion, but also the more chances for contamination. During the growth regions, control models are applied to adjust growing conditions as the cell mass grows to the limit of sustainability.

5.1.2.4 Phase The Phase is the lowest element in the procedural model. The phase should specify the commands that are to be sent to controlled equipment to change settings and perhaps modes. The phase would then wait for a response from the controlled equipment and then take one of the conditional actions specified in the phase. This may cause the next phase or phases to start, or it may start an exception-handling activity. A phase can also send a command to an operator through a human interface device and then wait for a response. The comment in 88.01 about subdividing refers to the steps or instructions required to accomplish the process-oriented task assigned to the phase. The fact that the lowest element is not basic but can be broken up suggests that the procedural model is incomplete. This will be cleared up in Section 5.3.3, where the separation of recipe and equipment procedures is described. When batch control is not automated, an operator receives a recipe from a supervisor, probably as several sheets on a clipboard. In those sheets is a page for the procedure, showing the unit procedures to be run. Depending on the complexity of the process, each unit procedure may have separate pages showing the list of operations for each. More sheets describe the phases in each operation and the sequence for running them. Each phase has a list of instructions telling the operator how to operate and observe various pieces of controlled equipment. This may result in some equipment actions running in parallel, up to the limit of what the operator can handle. Some phases may be used more than once, but only one page is needed to describe the actions to be taken to implement that phase. The operator refers to this page each time that the procedure mentions the phase. Automation consists of replicating what the operator does to basic control devices. That requires the ability to do several steps in parallel such as open valves A, B, and C, then monitor temperature and level to determine when to close A at temperature, B at level, and C when the mix tank runs dry. Other steps may cause the operator to modify alarm limits and tuning constants or make calculations based on current operating conditions. The operator may be prompted to do something for which there is no actuator or to gather electronic signatures as required.

batch chap 7.qxd

4/25/2006

2:36 PM

Page 114

114

Chapter 7

Macros The concept of a procedural element that is a collection of any number and type of procedural elements did not make it into 88.01. Macro is a programmer’s term for a named set of code that is used more than once in exactly the same form. When a programmer writes the name of a macro in a program then the compiler sees the entire set of code that was grouped into the name and inserts it into the code. The subject of macros as procedure elements came up when people began using Operations as macros, with no clear relationship to a process function. SP88 decided that macros were not procedural elements, partly because they messed up the symmetry of the models. Any use of macros is dependent on the system implementation, which is not specified in 88.01. If a batch process is properly structured with meaningful operations and phases then there is no need for macros. The things that are repeated are process operations and actions, not arbitrary segments of a procedure.

5.1.3 Coordination Control Procedural control represents partial automation of the operator’s function in batch control. Coordination control, by directing the activities of Procedural control, represents partial automation of the supervisor’s function. This level of control is required when a process cell can run more than one recipe at the same time. Timely action is required, so this level is still considered real-time control. Communication may consist more of transactions than it does of command and response. The following is a polite translation of the conversation between Coordination Control (CC) and one of the units in the cell: CC: “Unit 9, are you available to run a new recipe?” Unit 9: “Yes. I am yours to command.” CC: “Unit 9, here is your next recipe. Start when ready.” Unit 9: “Recipe received, integrity good. Starting now.” Unit 9: “CC, will need a filter in 32 minutes. Please select one.” CC: “Filter B is reserved, available in 35 minutes.” Unit 9: “Acknowledge Filter B in 35 minutes.” CC: “All units, we will run out of steam at this rate. Do not start anything that requires steam.” All units reply. CC: “Unit 7, please go to Hold and remain there until advised.” Unit 7: “I hear and obey.” When Unit 7 goes to hold and closes its steam valve, the steam pressure returns to normal. This ends the example. The translation was derived from binary data on the communication link, but binary could be natural language in ten years or so. The specific functions of coordination control will be covered later, in the discussion of Control Activities.

batch chap 7.qxd

4/25/2006

2:36 PM

Page 115

88 Batch Control Concepts, Part 1

115

The extent of coordination may exceed the borders of the process cell when there are utilities, transportation, or storage that are common to several cells and whose use must be managed. Communication at this level is among peers unless an area’s business function coordinates the activities of its process cells.

5.2 Equipment Entities The concept of controlled equipment was introduced in Chapter 4. This section formalizes the relationship of the control hierarchy to the physical hierarchy and relates the result to the process hierarchy. The phrase “equipment entity” takes on the special meaning of “controlled equipment entity” in 88.01. This statement is necessary because the phrase could also refer to uncontrolled equipment, since it is just another entity. From this point on, the terms process cell, unit, equipment module, and control module refer to controlled equipment entities. SP88 tried to use words that are automation-neutral. Controlled equipment is not supposed to conjure up images of microprocessors and systems integrators and startup delays. Controlled equipment is still an equipment entity even if it is only controlled by people, as best they can. Since equipment entities are the only entities that can be used to process materials they are necessary, but not sufficient, to produce a batch of product. Continuous processes also use controlled equipment, but designers never saw the need to define equipment entities, mostly because there was no procedural control hierarchy. Even though an equipment entity may be shown as a block in a block diagram, this does not mean that control and equipment are in the same physical box. That would be difficult for a human to do, and a person would not think of it as logical. Microprocessors in field instruments make it possible to provide any level of control that the micro can handle right out there on the equipment. As in so much of the modeling in 88.01, you must see the idea of controlled equipment as an abstraction, not to be taken literally. SP88, as a consensus committee, could not put specific implementation details into a “models and terminology” standard. Implementations were discussed, but they were boiled down to something that everyone could agree on. If you see something that looks like an implementation requirement, stop, perform some mental abstraction exercises, and read it again. 88.01 was written to facilitate the design and construction of batch processes by providing standard abstract models related to batch production, described with standard terms. 88.01 refers to language and implementation as things that were left out. Batch control languages were a big deal in the 1980s because the alternative was BASIC or FORTRAN. Computer scientists and vendors have come a long way since then. The use of block diagrams and sequential function charts on graphical user interfaces has largely eliminated the concern over the batch programming language.

batch chap 7.qxd

4/25/2006

2:36 PM

Page 116

116

Chapter 7

5.2.1 Relationship Model The relationship model is shown in Figure 7 of 88.01 and also in Figure 7-3. In general, a Procedural Element (Figure 6 or 7-2) directs the control of an Equipment Entity (Figure 2 or 6-2) to perform the functions of a Process Element (Figure 1 or 6-1).

Figure 7-3 Procedural Control/Equipment Mapping to Achieve Functionality Figure 7-3 is not an exact representation of Figure7 in 88.01. The physical model column says “Controlled Equipment” and not just “Equipment” because procedural control can’t be combined with plain old equipment. The first two columns were made plural with “(s)” at some point after “combined with a” had been written, perhaps because a transfer requires two of everything. Many procedures can run in many process cells, but it only takes one procedure running in one process cell to carry out one batch process specified by a recipe. Perhaps a recipe could include the processing in several cells, but 88 does not provide a way for the recipe to be distributed to the cells. There is no process control activity in an Area, just business functions. The Process Functionalities on the right are an abstract list of a batch process and its subdivisions. Each process function has to be realized by one or more equipment entities, or the batch will also be an abstraction. The Procedural Elements on the left are an abstract list of a procedure and its subdivisions. When realized in a product recipe they provide the direction to animate the Equipment Entities so that the processing necessary to make a product will occur. To put it another way, you can’t produce a specific product unless you can perform the process functions. You can’t do any processing unless you have the right controlled equipment. The controlled equipment requires direction from procedural elements in order to do the correct processing. We will soon see that the recipe provides the correct procedure.

batch chap 7.qxd

4/25/2006

2:36 PM

Page 117

88 Batch Control Concepts, Part 1

117

The concepts of ownership and acquisition will be discussed later in this chapter. An equipment entity can be owned by another equipment entity. Ownership implies that only the owner may give direction to the owned equipment entity. Ownership may be established by wiring or configuration. Acquisition is the process of temporarily obtaining ownership of common equipment entities (not otherwise owned) by using a simple negotiation. A release process is used after the process function is complete. The model of the relationship of procedural control to controlled equipment to process functionality is fundamental to the 88.01 standard. If you don’t understand this model, read on because things may clear up as you see how the model is used. If you can’t make your batch process fit this model, please write to ISA Standards and Practices with an explanation of the problem. Perhaps ANSI/ISA-88.01 will have to be revised.

5.2.2 Control in Equipment Entities The control that is associated with an equipment entity may be one or more of the three subdivisions of batch control: Basic, Procedural, and Coordination, as shown in Figure 7-1. The recipe has to contain that part of procedural control that is specific to making a product. The equipment may have associated procedural control that does not change with different products. For example, a heat exchanger has to establish the correct flow of the correct medium no matter what the product may be. A premixer may have a product-independent procedure, requiring only material sources and amounts from the recipe. Reactors tend to have associated basic control that receives direction from a recipe procedure.

5.2.2.1 Process Cell A process cell consists of units and common equipment modules. If there is only one unit then there are no common equipment modules. At a minimum, the cell must be able to receive a schedule of products to be made and retrieve the required recipes. The cell must be able to start the scheduled recipe in the chosen unit at the scheduled time. Cells may be more complicated than that, which requires coordination of units and common equipment. The cell may be required to allocate equipment ahead of each batch, or the units may be able to manage equipment among them. Also, the cell may manage auxiliary activities like cleaning and sterilization, or the units may be responsible for making themselves ready. A cell may manage its material inventory based on its knowledge of scheduled batches, or material management may be a business function. Complexity is relative, but it can be estimated from the number of units and common equipment in the cell. If any unit can transfer to any other unit then the complexity for that equipment count is at a maximum. This is reflected in the number of valves in the transfer piping. If there are no transfer selection valves then the paths through the units never vary, which is not particularly complex no matter how many units there may be. A cell may have to manage a few equipment and control modules, but units own most of the modules.

batch chap 7.qxd

4/25/2006

2:36 PM

118

Page 118

Chapter 7

Coordination Control: The main purpose of the process cell is to coordinate activities within the cell. It should come as no surprise that there is far more coordination control in a cell than there is procedural or basic control. Coordination begins with the selection of units to run unit procedures so that each batch will be able to finish in a timely manner without waiting for a procedure in another batch. If there are transfers between units, the cell may coordinate these for best use of available resources. If batches have priority levels (adding complexity to batch coordination) then the cell may determine which batch gets held or shut down so that a higher priority batch can run. It may be necessary for cells to coordinate as peers because only the business levels are higher. The following conversation between process cells might occur: PC1: “Chauncy, old peer, I seem to be running low on Ingredient B. Have you got some to spare?” PC3: “Sorry, Throckmorton, I don’t. Have you tried Lancelot? Keep up the good work and my best to you and your units.” (The humor in this, such as it is, will be lost on you if you have no knowledge of British peerage.) Procedural Control: Another purpose of the process cell is to acquire and initiate recipes. Procedural control is required to examine the recipe procedure for unit recipe procedures and to pass them on to the proper units in a timely manner. Any other procedural control done by the cell is not related to a product recipe. Perhaps the cell does cleaning procedures for transfer piping. Basic Control: The interlock propagation example given in 88.01 seems to be for coordination rather than basic control. A cell may give direction to a control module that it owns, but it makes no direct use of basic control. Interlocks initiate changes in procedural control, possibly at the cell level.

5.2.2.2 Unit The main purpose of the control that is associated with a unit is to execute that part of the recipe procedure that has been assigned to the unit. This requires that procedural commands be issued to the equipment and control modules that are owned by the unit. No coordination is needed if the modules are owned. If the process cell is complex, the unit may require coordination control in order to deal with other units and common equipment modules. The unit relies on its equipment and control modules to do basic control.

batch chap 7.qxd

4/25/2006

2:36 PM

Page 119

88 Batch Control Concepts, Part 1

119

Coordination Control: If the unit has to use equipment entities that it does not own then it must negotiate with the other entities to acquire their services and release them from service when done. Alternatively, the unit may have to make a request to the process cell to coordinate the connection. The following conversation between a unit and a common equipment module provides an example, where U is unit and EM is equipment module: U4: “EM3, can you supply 300 liters of hot water now?” EM3: “No, Fred, but you can get it in 15 minutes. Shall I put you down for that time?” U4: “I’ll take it, EM3.” EM3: “OK, Fred. Your confirmation number is 377.” U4: “Roger 377, EM3. Thanks.” This conversation is equivalent to a person making a reservation at a hotel. Talking to the process cell is like talking to a travel agent, perhaps asking for any available hotel. Procedural Control: The main purpose of the unit is to translate the recipe procedure into commands that can be given to the equipment entities that it owns or has acquired. This may require access to documents containing product-independent procedure elements such as phases and operations. For example, the recipe procedure may contain an operation named “Bulk Charge” that specifies a standard material and amount but contains no procedure. The unit controller would get a copy of the standard procedure for Bulk Charge and then execute that procedure, which may refer to standard phase procedures. The documents would be paper for an operator or disk files for a machine. Basic Control: The unit always uses its equipment and control modules to do basic control. That’s why 88.01 has such modules.

5.2.2.3 Equipment Module The main purpose of an equipment module is to provide a standard interface to a control function. The module encapsulates the control function and hides the details from the unit and the recipe procedure. A common function like heat exchange may be done in several different ways, but all of them require a temperature setpoint and perhaps a few other parameters. The equipment module conceals the details of the valve switching that are required to select the heat exchange medium. The operator or automator just sees a temperature setpoint. If the module is common to other units and not owned by only one unit then it will need coordination control. If the module can execute a phase, so that the phase procedure is not in the recipe or in the standard procedural element documents, then it

batch chap 7.qxd

4/25/2006

2:36 PM

120

Page 120

Chapter 7

needs procedural control. An equipment module must do all of its basic control through control modules that it owns or modules that it can acquire. Equipment modules can be recursive. The equipment module that contains all others provides the interface to the unit, so that all of the others are hidden. The underlying modules may be exposed when the mode of the top equipment module is manual. Coordination Control: The module must coordinate its component parts. Most of this is done by the connections of the parts and some combinatorial logic, which is normally a configuration activity. Configured or procedural exception handling logic also affects the interaction of the parts. Logic may be configured to propagate mode changes. All of this seems like basic or procedural control. No negotiation is required. If a unit or cell does not own an equipment module then the module must have coordination control in order to manage changes of ownership. An equipment module that is serving as common equipment must be able to be the server end of the acquire or release dialog. Procedural Control: An equipment module is required to have procedural control. The only procedural element that it can run is the phase. Operations and unit procedures only run in units, regardless of how capable the equipment module controller may be. If an equipment module could run an operation, it would be a unit. Further, an equipment module can only run one phase at a time, although the phase procedure may cause simultaneous things to happen. Basic Control: An equipment module sends commands to the control modules that it owns, which perform the necessary basic control.

5.2.2.4 Control Module A control module has nothing below it in the hierarchy of equipment entities. A control module owns instruments that are in contact with the process material or auxiliary process streams like steam or chilled water. A control module has exclusive use of an actuator, if it has one, but it may share a measurement with other entities. No other equipment entity can be directly connected to the process, so all commands that cause process actions to take place end up in control modules. The main purpose of a control module is basic control. Coordination Control: If an equipment module, unit or cell does not own a control module then the module must have coordination control in order to manage changes of ownership.

batch chap 7.qxd

4/25/2006

2:36 PM

Page 121

88 Batch Control Concepts, Part 1

121

Procedural Control: There’s no need to worry about procedural control in a control module because it is not supported. Basic Control: A control module may perform any or all six of the types of basic control. See Chapter 3 for a discussion of the six types of control.

5.2.3 Structuring Equipment Entities This section of 88.01 discusses some of the basic ideas necessary to locate the boundaries of process cells, units and equipment modules on a P&ID of a batch process. This would have been handy when discussing the physical model, but full knowledge of the relationships among controlled equipment entities was necessary. You now have that, so it is time to discuss structuring a process with equipment entities. Of course, an exact description of structuring methods would be a specification for implementation, so SP88 backed off from being specific in order to reach consensus. As you might expect, the structure of the controlled equipment greatly influences the ease with which a recipe can be translated into process actions that will build a product. This suggests that several structures should be tried on paper before choosing to commit one to equipment and control hardware. The third paragraph under Section 5.2.3 in 88.01 suggests that structuring might be trickier than you expect. If you do it wrong, you risk losing the benefits of the standard because the standard is built around the previously described controlled equipment entities. In practice, there has been more trouble defining units and equipment modules than process cells and control modules. Structuring requires a clear understanding of the purpose of each equipment entity in relation to its process function.

5.2.3.1 Process Cells What follows is more about general rules for identifying equipment entities than it is specific to the process cell. A process cell is defined by the limits of its procedural and coordination control, except for coordination with other cells. The control limits are defined by the required process functionality. The general rules follow: • The processing function of any equipment entity must be clear and precise. Ambiguous language like “in some cases” should be replaced by definitions of the exception cases. “Does the job well” requires more explanation. • The function performed by an equipment entity should correspond to a process function. The function should be independent of the product being made, except for the quantity and quality specified by the recipe. • A subordinate equipment entity should execute its process task independently of any other equipment entity. This relieves the ordinate task from controlling the

batch chap 7.qxd

4/25/2006

122

2:36 PM

Page 122

Chapter 7

details of the subordinate task. The master task simply wakes up the subordinate and tells it what to do, then does nothing further with the subordinate except to listen for a response, either “Done” or “Error.” • An equipment entity should have minimum interaction with other equipment entities, unless some cooperative activity like a material transfer is in progress. This allows the entities to be designed independently. • Each equipment entity must have clear boundaries. Each equipment entity has exclusive control of the equipment entities that it owns. Clear boundaries are required to show the limits of ownership and to make sure that there is no chance that two equipment entities can command the same subordinate equipment entity or actuator. • Equipment entities of the same type must have the same function, so that an operator cannot make a mistake by operating two instances of the type in the same manner. • When two equipment entities must interact, the coordination of the interaction is done by the same equipment entities or by one entity at the next higher level. There is no higher level to coordinate process cells.

5.2.3.2 Units A unit cannot be defined without first knowing what major processing activities are required and how they match the capabilities of the unit’s equipment. What follows is specific to a unit. The unit may handle one or more major processing activities (process stages), such as reactions that cause a complete chemical change, physical mixing, separation, or cell growth. A unit should be able to operate independently of any other unit, except when it is time to transfer contents between units. Extra coordination control will be required if the utilities are limited or common resources are used. A unit operates on only one batch at a time. Otherwise, you have a discontinuous process, and the batch ID is meaningless.

5.2.3.3 Equipment and Control Modules The definition of a unit’s process functions should reveal a set of process actions that are required in order to perform the unit’s tasks. Equipment modules can do procedural control that is related to one or more process actions. Control modules use basic control to accomplish a process action. Equipment modules may own control modules.

batch chap 7.qxd

4/25/2006

2:36 PM

Page 123

88 Batch Control Concepts, Part 1

123

Summary This chapter covered the structure for batch control as a hierarchy of coordination, procedural, and basic control. The hierarchy for procedural control is procedure, unit procedure, operation, and phase. Equipment entities were introduced as controlled equipment, relating each item in the control hierarchy to the equipment hierarchy of process cell, unit, equipment module, and control module. The relationship of procedural elements to equipment entities to process functions was described. Further definition of the equipment hierarchy was developed from rules for any equipment entity and rules specific to an equipment entity level in the hierarchy.

batch chap 8.qxd

4/25/2006

2:37 PM

Page 125

Chapter 8

88 Batch Control Concepts, Part 2 This chapter covers the entire recipe part of 88.01 Section 5, Batch Control Concepts.

5.3 Recipes Recipes are the central feature of batch control. The equipment is designed to implement the recipes. Each recipe describes all that needs to be known in order to make a product. If a business loses its equipment in some disaster, that equipment can be rebuilt. If a business loses its recipes, it will have to start over and redevelop each one of them again, which could cause the business to lose its customers. Recipes in general were covered in Chapter 5 of this book. There are four types of recipe entities. They differ in their use and the amount of detail they contain, with the most detail in the lowest level. Each recipe contains five types of information. Some recipes need to be distributed to locations remote from where the recipe was generated. You will learn all about this and more if you press on.

5.3.1 Recipe Types A recipe entity contains, at a minimum, enough information to make a product. SP88 decided that four types were enough to make recipe models. They cover the distribution needs of the entities in the Physical Model. The four types are shown in Figure 8-1, which looks like Figure 8 in 88.01. The symbols on the drawing illustrate the following relationships. A General recipe contains the processing information that will make one product at any location in the enterprise, but the information can not be specific to any location. It must be transformed into a Site or Master recipe. A Site recipe contains the processing information that will make one product at any location in the site, but the information can not be specific to any process cell. It must be transformed into a Master recipe. If your enterprise consists of one site where products are made, then you may choose to omit the General and Site recipes. A Master recipe is needed to make more than one batch. A Control recipe is needed for each batch. That is, it is based on one Master recipe and includes the information for exactly one batch.

batch chap 8.qxd

4/25/2006

2:37 PM

126

Page 126

Chapter 8

Figure 8-1 Recipe Types A recipe created at the enterprise level may cause intermediate products to be made at different sites, with final processing being done at other sites. One general recipe may create several site recipes, which in turn create several master recipes, which are copied to many control recipes. It must be possible to trace a control recipe back through the genealogy of recipes to discover the parent general recipe. A recipe contains the process-related information needed to make the product. A recipe does not contain information about the estimated time required for procedural elements. Such information varies with events that are outside the scope of the recipe. Many recipes have change control procedures that are designed to discourage change. If the timing changes because a process improvement has shortened the time to do an operation then that should not be a reason to change the recipe and go back through the approval process. Save the timing statistics in a separate file, organized by procedural element and normalized as required. An elapsed time specification in a formula value is a requirement, not an estimate. The master and control recipe procedures are designed to operate specific equipment. The general and site recipe procedures can not be specific to equipment because they will be used at many sites and many process cells. As 88.01 says, the difference is between describing the technique (without being specific about the equipment) and describing the task that specific equipment must perform. The need for four types of recipes arises in a distributed enterprise that has multiple manufacturing sites. This is the most complex situation. This book will start with the simplest situation and work up, rather than from the enterprise down. Not everyone will need all four types in order to live long and prosper in their business.

batch chap 8.qxd

4/25/2006

2:37 PM

Page 127

88 Batch Control Concepts, Part 2

127

5.3.1.4 Control Recipe The recipe closest to the controlled equipment that will do the processing is called the control recipe. This recipe is essential to making a batch because it contains the details necessary to command the equipment. The control recipe at least identifies the unit in which processing will start and must identify all units and material selections that cannot be chosen while running. A control recipe may be modified as processing progresses. Modifications may include adjustments to the procedure as actual units become known, if they are not all prearranged. Some formula values may be modified based on analysis of the product in progress. The control recipe does not become the complete record of what actually happened because it does not contain time. A separate information system creates that record as a batch report. Then there is the problem of translating the report for a “golden” batch back into a recipe so that the golden batch may be repeated. But if you think about it, if the system allowed enough variance for a random golden batch to happen then that system is unlikely to be able to duplicate it. If the golden batch was not random but was created by deliberate variations in successive control recipes then the information required to create a new recipe is owned by the experimenter. Each control recipe for each batch is translated from the master recipe for the desired product. The control recipe is a copy of the master except for a unique batch ID and the tailoring required for specific equipment entities or material sources.

5.3.1.3 Master Recipe The master recipe is created for one process cell using knowledge of the equipment entities within the cell. There may be more than one master recipe per product if the differences in controlled equipment require that distinction. Generally, process cells have enough variation that a master recipe must be specific to one cell. A master recipe may be useful for several cells when designers become accustomed to creating identical operating interfaces that conceal the differences in equipment. Further, the control recipe may become a simple copy of the master recipe, with formula values adjusted by simple calculations for the size of the batch, and a unique batch ID. The master recipe is required for batch production. Even a plant that has just one unit requires a master recipe for each product in order to create control recipes for each batch of that product. The following are some additional characteristics of master recipes: • A master recipe fails in its purpose if control recipes generated from it do not operate the equipment properly. The control recipe procedure is a duplicate of the master recipe procedure, unless somebody changes the control recipe. Generally, changes are made to the control recipe to choose specific equipment within the cell, not to alter the procedure.

batch chap 8.qxd

4/25/2006

2:37 PM

128

Page 128

Chapter 8

• A master recipe must contain product-specific information required for equipment and material selection if a selection exists. This information may be used by a scheduler to select materials and equipment for future batches. • Formula data relating to batch size may be normalized to a base batch size or it may be calculated from specified equations or simple fixed values, depending on the equipment control requirements. • A master recipe may be created for equipment that has manual control, some automatic control, or full automation. • A master recipe is created by translating the requirements of a general or site recipe into something that the cell can do, if there is a general or site recipe. If not, then the master recipe can be created from a sketch on the back of an envelope or as a modification of another master recipe. The relationship of master recipe to general or site recipes is not limited to one to one. There will be as many master recipes as there are different process cells or sets of equipment that can make the product specified by the site recipe.

5.3.1.2 Site Recipe The site recipe is a recipe that is specific to a site but not to specific equipment at the site. It teaches the technique but not the task. The site recipe describes the process functionality that is required to make a product, in the local language of the site. The processing may be modified to match the materials that are available at the site, for example, solid material from a local mine instead of powdered or dissolved material. Also, local materials may vary in concentration and impurities enough to require preprocessing or changes in the formula. The site recipe contains information that may be used for site business planning, such as material and energy production and consumption. If site recipes exist then master recipes must be derived from them. Even if there is only one site, the site recipe can assure consistency of multiple master recipes. If there is only one process cell in only one site then the site recipe level is not required. Remember that site means anything that the enterprise wants it to mean. Mostly it means a manufacturing facility, but it can mean a country or a region. The site recipe may be derived from a general recipe and may be one of several site recipes required by that general recipe. If no general recipe exists then the site recipe is created at the site, which can then be transferred to a few other sites for adaptation to those sites. If the number of sites is larger than two (or maybe three) then managing the consistency of the site recipes may not be possible without having a general recipe to set the standard.

batch chap 8.qxd

4/25/2006

2:37 PM

Page 129

88 Batch Control Concepts, Part 2

129

5.3.1.1 General Recipe The general recipe is required for an enterprise that has more than a few sites, and especially for an enterprise with a corporate research center. The general recipe becomes the standard from which all site recipes are derived. A general recipe is not written for specific equipment but uses process stages, operations, and actions to refer to process functions. You saw how equipment entities are related to process functions in the previous chapter. Again, the general recipe teaches the technique but not the specific task. NE 33 calls the general recipe the source recipe, with no site recipes. It is written by a chemist, biologist, or other scientist using process functions for the procedure. In NE 33, a source recipe may be used to derive a basis recipe (corresponding to a master recipe) that may be used by a laboratory, pilot plant, or production plant. SP88 developed the opinion that this was too broad because the available technologies are so different. The process functions used to write the 88 general recipe are those that are or could be implemented by equipment entities in any production facility. This view simplifies the task of translating a general recipe into a site recipe. The general recipe contains formula values that are related to batch size as normalized values, for example, percentages of a unit measure of product. Pressure, temperature, and analysis values are fixed because they do not change with batch size. For specialty chemicals, there may be equipment requirements related to materials of construction that would either catalyze unwanted reactions or corrode enough to affect the product. Bioreactors tend to be stainless steel, although not all cells of interest thrive on a pH of about 7 in a medium that is mostly water. The general recipe contains information that may be used for high-level business planning, such as exact normalized quantities of materials and enough information to estimate the cost of equipment. Regulatory agencies may be interested in the overview of the process and materials that an edited general recipe can provide— edited, that is, in the sense that the process operations and actions are removed.

5.3.2 Recipe Contents The first edition of this book described four categories of recipe information—header, equipment requirements, formula, and procedure. SP88 decided that other categories were also required, so we compromised on a category called Other Information. Some categories are treated differently depending on the type of recipe that contains them, as noted below.

5.3.2.1 Header The header contains information needed to manage recipes but not to produce a product. The header contains a category of information that identifies the product to be made with this recipe. For example, it includes information that traces the genealogy of this recipe, including authors and the version numbers of parents. The header grows larger as you go down the recipe hierarchy. It includes information that

batch chap 8.qxd

4/25/2006

2:37 PM

Page 130

130

Chapter 8

contains the details of the approval process and the level of progress toward a status of “released to production.” A site, master, or control recipe will include information naming the location where that information is valid. SP88 did not even try to standardize the contents of the header because there are so many variations in use.

5.3.2.2 Formula The formula was discussed in general in Chapter 5. A formula contains three categories of information that group values for easy searching. They are process inputs, process parameters, and process outputs. Process Inputs may be subdivided into materials, energy, and people. Material data may include more than name and amount, and may include possible alternate sources for a material. Energy and material are specified as a ratio to the product output so that they are independent of batch size. A control recipe will have actual amounts because the batch size is known. The number of people required to make a batch is not known in a general recipe, possibly known in a site recipe, and certainly known in a master recipe and control recipe. Process Outputs may be subdivided into products, by-products, and waste products. These may be materials or energy, but so far there is no industrial process that makes people. One of the products is selected as the one to which all other batch size values will be normalized. This is the major product of the recipe. Process Parameters contain anything that is not an input or an output. Constant values may be used for values like temperature, pressure, pH, and time. The values are always associated with a procedural element, but 88.01 does not provide a way to make the association because it is not an implementation standard. SP88 would have had to describe an implementation in order to deal with parameters that are split among procedural elements. There is also the problem of dealing with a procedural element that is used more than once in a sequence. The information for process inputs is like the ingredient list for a cooking recipe. The ingredients must be on hand or you’d better not start breaking eggs. Substitutions may be suggested, like chicken instead of meat from an endangered species. Cooking time and temperature are in the procedure paragraphs, as are instructions to split an ingredient for different parts of the procedure. There is one output, which is the title of the recipe. That is, one output if you don’t count the waste products, like eggshells.

5.3.2.3 Equipment Requirements If there is no choice of wetted materials (e.g., glass, 304 stainless, tantalum), strength of materials, or other capabilities in process equipment then this category of information of a general or site recipe may be empty. Master and control recipes must be specific about equipment. A multipurpose batch process cell is likely to have a selection of wetted materials, pressure ratings, agitator designs, and other equipment capabilities. If the process cell contains units that are constrained by transfer piping,

batch chap 8.qxd

4/25/2006

2:37 PM

Page 131

88 Batch Control Concepts, Part 2

131

then the equipment requirements category must contain enough information to choose the correct train. (Perhaps train is a contraction of constrain and should be written as ‘train. More likely, the major equipment looks like coupled railroad cars.) The equipment requirements category of the recipe contains the information necessary to choose the proper equipment entities to make a batch. A scheduler may use this information to select the specific equipment that might be available at the right time. The process cell may use this information to choose the unit that will start the recipe, and it may allocate or reserve other units as required as the recipe procedure progresses. Other cells may be designed to choose transfer destinations when needed. One user who attended SP88 meetings wanted to be absolutely certain that the standard did not require procedural elements for transfers. In his plant, when a unit procedure ended, control was passed back to the cell. The cell accomplished the transfer and started the next unit procedure in the selected unit. Of course, other processes usually require that the destination unit start its unit procedure before the transfer takes place. The equipment requirements category of a general and site recipe cannot refer to specific equipment. It must offer guidance and constraints for the selection of actual equipment. For example, “reactor must vent non-condensable gasses to a flare stack because they are poisonous” or “agitator must provide at least x joules per liter during reaction.” A master recipe may be able to condense the guidance into “use R-xx3 or Rxx4 for unit procedure React.” A control recipe may say “use R-743 for unit procedure React,” or it may leave the master recipe choices in place until the batch is started by the process cell. If the process cell has been designed with trains then the designations for the allowable trains may be all that is in equipment requirements.

5.3.2.4 Recipe Procedure The recipe procedure defines the plan of action for making a product. General and site recipe procedures are constructed using the stages, operations, and actions of the process model described in Section 4.1.3 and Figure 6-1 in Chapter 6. These elements describe process functions without making any reference to actual equipment. Master and control recipe procedures are built using the procedural elements of Section 5.1.2 and Figure 7-1. These elements describe functions of controlled equipment, which are related to process functions as described in Section 5.2.1 and Figure 7-2. A general recipe author is constrained to use process functions that are generally available at the sites. It would require a business decision to create a new process function at one or more sites to enable the author to use a new function. A master recipe author is constrained to use equipment functions that are available in the process cell. Constraints may be reduced or eliminated by carefully matching the enterprise process stages with a process cell’s unit procedures, and so on down the hierarchies of process functions and procedural elements.

batch chap 8.qxd

4/25/2006

132

2:37 PM

Page 132

Chapter 8

General Recipe As stated above, the general recipe procedure consists of the three process functions— stages, operations, and actions. The procedure consists of an ordered set of stages. Each stage consists of an ordered set of operations. Each operation consists of an ordered set of actions, as shown on the left side of Figure 8-2. We will deal with the other relationships shortly. Process stages, operations, and actions do not have to fit within unit or even process cell boundaries in the target production facilities. This is because the general recipe must be independent of the various manufacturing facilities. A general recipe may call for processing that has to be done in different facilities. In this case, the general recipe leads to several site recipes, and Figure 8-2 applies not to the general recipe but to one of the site recipes.

Site Recipe The site recipe procedure is a copy of that part of the general recipe procedure that applies to the site. Normally, there is no change in the process functions. Authorized alterations may be made to the copy in order to accommodate the peculiarities of the site. There was a time when corporate engineering could make the sites reasonably uniform, but now the fashion is to buy out your competition and so some of the purchased sites are quite peculiar.

Master Recipe The master recipe procedure consists of the three procedural control elements—unit procedures, operations, and phases. See the right side of Figure 8-2. The procedure may be an ordered set of unit procedures, and so on down the hierarchy. The words “may be” are used instead of “is” because some SP88 members wanted the model to be collapsible. The reason for this will become apparent in Section 5.3.3. The relationships between a general or site recipe and a master recipe are complex, as shown in Figure 8-2. This is because the abstract meaning on the left becomes concrete on the right. A master recipe procedure must be able to operate equipment entities when it is copied to a control recipe. The figure shows that the relationship may be that one process function translates to one or more procedural elements or that several process functions may become one procedural element. There is always the possibility that the equipment design may require more or fewer procedural elements than the occurrence of each process function in the site or general recipe procedure. There is also the possibility that a process stage may be just another set of operations to be carried out in the same unit, or that a process operation becomes a set of phases added to an existing equipment operation. All things are possible, provided that the master recipe procedure makes the product that is described by the general or site recipe.

batch chap 8.qxd

4/25/2006

2:37 PM

Page 133

88 Batch Control Concepts, Part 2

133

Figure 8-2 Relationship of General or Site Recipe and Master Recipe It is possible to reverse the relationships when a facility grows into an enterprise, and master recipes have to be turned into site and general recipes. That is not the subject of this Section, though.

Control Recipe The control recipe procedure begins as a copy of the master recipe procedure, and may remain that way to the end of the batch. The uniqueness of the control recipe allows it to be customized for the set of equipment that has been planned to make the batch. The control recipe procedure may have to be modified to work around some equipment or material problem during batch processing. That is not a problem because the changes affect one batch and do not change the master recipe procedure. The control recipe may become a part of the batch record at the end of the batch because the recipe could have been changed.

5.3.2.5 Other Information This category of recipe information started out as safety information that could have been put in the header. It was separated into a category because SP88 felt that it should stand out from the header. Later this category became “safety and regulatory information,” and finally people said, “It’s only disk space.” Now Other Information may contain anything else that is pertinent to the recipe. It may contain references (links) to process descriptions and flow sheets or other drawings. Since the advent of

batch chap 8.qxd

4/25/2006

134

2:37 PM

Page 134

Chapter 8

the Occupational Safety and Health Administration (OSHA), this category may contain references to the Material Safety Data Sheets for the materials used or generated in processing. It may contain references to Food and Drug Administration (FDA) requirements for the processing and the product. The word references is used because OSHA and FDA requirements are not specific to one product. The Other Information category may contain instructions for packing and labeling if those functions are performed within the process cell and the recipe procedure includes them. Otherwise, the batch is added to a storage tank for the same product, and other equipment takes care of packaging and labeling. The recipe ends when the batch is transferred to storage. The power of hypertext markup language (HTML) was relatively new when 88.01 was written. Now it would not be unusual for the contents of Other Information to be expressed as a series of web pages.

5.3.3 Recipe–Equipment Relationship This section is essential to understanding 88. We have described procedures that end in phases with no possibility of subdivision. Now we will see that the subdivisions of phases are in the control of equipment entities. That is why the concept of an equipment entity as combined control and equipment is so important, as opposed to hunks of equipment all run by some disturbed control system. Now, that may be the way control is actually done, but it is not the right way to think about it when working with recipe procedures. The following example introduces an “interface” to controlled equipment. An operator or automation gives commands and parameter values to an equipment entity through this interface and receives status information from the interface. The interface is abstract in that the interface designed for humans is quite different than the one designed for machine communication. This concept smelled too much like implementation to suit SP88, so it doesn’t appear in 88.01. It is used here to provide a more intuitive explanation of what is happening than the more abstract concept of “linking” the recipe procedure to the equipment procedure. This concept is amplified in 5.3.3.3. A final recipe translation must occur when the control recipe has to cause a piece of controlled equipment to do something. Suppose an operator is making a batch by reading the control recipe procedure for that product. The procedure says to add 42 grams of Perfectly Adequate Catalyst powder to the reactor. The operator has been trained in the procedure for adding packages of powder to a reactor (the training is not product specific). The operator finds the preweighed package of powder, checks the condition of the reactor for safety, puts on the required protective equipment, opens the manhole, tears off the top of the package and empties it down the hole, closes the manhole, and discards the empty package. All of this happened because the recipe procedure told the operator to add the powder.

batch chap 8.qxd

4/25/2006

2:37 PM

Page 135

88 Batch Control Concepts, Part 2

135

Suppose the next phase of the procedure says to heat the reactor contents to 107°C. The operator walks over to the reactor temperature controller and sets it to 107 degrees, or as close to that as the dial can be read, after setting up the reactor jacket for heating. Now suppose that the process has been automated. The information in the control recipe procedure still has to be applied to the equipment. The first step in automation is to improve the equipment control to get as much product-independent process functionality into the equipment as possible. The heat exchanger has to be able to switch to the heating or cooling medium under its own control. The catalyst has to be able to be added to the reactor automatically, perhaps as precise, well-mixed slurry with some inert liquid. Each of these controlled equipment functions requires an automation operating interface, consisting of a list of parameters that are necessary to set up, operate, and report the status of the function. The procedural elements in the control recipe procedure must contain all of the information required by the operating interface of the corresponding controlled equipment.

5.3.3.1 Control Recipe/Equipment Control Separation Separating the recipe from the equipment entities allows a master recipe author to create recipes using only a functional knowledge of the interface to an equipment entity. It is not necessary to know exactly what the equipment entity must do to perform its process function because that is built into the entity. For example, you can drive a car because you understand the functions of the controls and the indicators. The firing order of spark plugs or the carburetor settings are not your concern while driving. The interface to an equipment entity provides the user controls and indicators. The sequencing of valves is of no concern to the phase that operates the controls of the entity. A control recipe procedure may contain unit procedures, operations, and phases. The control for a unit may contain the same three levels of procedural elements. An equipment module may contain phases. Control modules contain no procedural elements. The procedural elements, as building blocks, provide the flexibility needed to use a multi-purpose process cell effectively. To use that flexibility, the procedural elements must be in the recipe procedure, where they are product specific. However, the recipe procedural elements do not instruct the equipment in how to do its job. They do tell the equipment which procedural element to execute, with what values, and when to start. The recipe procedure then pauses in that path until the equipment reports that it has succeeded or failed. In a sense, the recipe phase operates an equipment phase, where operate means transferring the setup parameters to the equipment interface, “pushing” the start button, and receiving status reports. If translation of a general or site recipe procedure to a master recipe procedure requires certain procedural elements to make the product, then it does not matter if the procedural elements exist in the control recipe or in the equipment. However, if the next general recipe has a completely different arrangement of procedural elements, then a designer is constrained to keep this variety in the master and control recipes. There is no point to building any fixed procedural element higher than a

batch chap 8.qxd

4/25/2006

136

2:37 PM

Page 136

Chapter 8

phase into the equipment, where it becomes inflexible, so the equipment is designed to do phases. If the general recipes repeat the same process operations then it is possible to design those operations into the control associated with a unit. In this case, the operation in the control recipe procedure would set up, start, and listen to an operation that consisted of multiple phases in the equipment. Are the general recipes so boring that they all have the same stages? In that case, the equipment can be designed to run unit procedures that are set up, started, and monitored by the recipe procedure. Do you only use one procedure? No problem, design the equipment to run that procedure.

5.3.3.2 Control Recipe/Equipment Procedural Elements This section discusses the requirements for transferring control from the control recipe to the equipment entities. We already know that a recipe contains the following three things that affect processing: • Equipment Requirements—Constrain or specify the equipment entities to implement the process functions. • Procedure—Describes the process functions required and the order in which to do them. • Formula—Contains the product-specific values of parameters of the process functions. This information must be transferred from the recipe to the equipment entity so that it will do the right thing. The transfer requires a destination “address” or other location identification. Equipment Requirements select the equipment entity. The procedure selects the equipment procedural element to be executed. Passing the formula values to the right locations is also a problem. SP88 couldn’t talk about how this was done (implementation), so we came up with the following requirements for equipment entities: • Identification—Something that the recipe can use to locate the right equipment procedural element. The usual example is “phase name,” but that may become a problem when the same phase name is used more than once. • Execution Logic—Refers to the procedure, which is different from recipe procedural elements because it has to have elements below the phase. • Parameters—Names of variables that match formula values. A single structured parameter may contain all of the values that the equipment entity needs. • Functionality—Describes the process functions provided. The master recipe author uses this information to select the correct identification references and parameters to put in the recipe.

5.3.3.3 Control Recipe Procedure/Equipment Control Linking This section discusses the possible variations in the transfer of control from recipe to equipment entities. The term linking encompasses all of the implementation details of locating, establishing communication, and controlling any level of process functionality that an equipment entity may have to offer. This is where we separate the

batch chap 8.qxd

4/25/2006

2:37 PM

Page 137

88 Batch Control Concepts, Part 2

137

product-specific information in the recipe from the equipment-specific process functionality of an equipment entity. Time spent designing uniform interfaces for each process function pays off in simpler recipes, less debugging, and faster time to market for a new product. The statement in 88.01 that the same recipe procedural element may use different equipment procedural elements does not mean that the identification or behavior of the elements is different. It means that individual pieces of controlled equipment may have different implementations of the same behavior due to the relentless advance of technology. Clearly, this cannot be done without a standard equipment entity identification and interface for each process function. An interface also makes it possible to control the process function from other sources, like an operator or a shutdown system. Figure 8-3 shows the general case for linking between a control recipe and an equipment entity. The recipe may be linked to other equipment entities as well, but that is not shown here.

Figure 8-3 Linking of Control Recipe and Equipment Entity The control recipe procedural element hierarchy on the left in Figure 8-3 is the same as the master recipe hierarchy in Figure 8-2. The equipment entity hierarchy on the right has the same element names, but everything above the Equipment Phase is dotted. The most product flexibility is obtained by linking at the phase level. This allows the master recipe author to have full control of the capabilities that were engineered into the equipment entities.

batch chap 8.qxd

4/25/2006

138

2:37 PM

Page 138

Chapter 8

If all of the recipes communicate with the controlled equipment at the phase level, then the dotted lines and the words they contain vanish. It is not necessary to have all links at the same level. Perhaps there is one process operation that may be implemented in equipment without losing any product flexibility. Then the dotted lines associated with Equipment Operation become solid, and the other dotted lines vanish. In this case, the recipe phase is not required, and so the Recipe Phase and its lines go away. The diagram is now specific to one Recipe Operation in the control recipe. Other recipe operations may still have an ordered set of phases. An ordered set of equipment phases below the Equipment Operation does not have to exist, although it would seem to be good practice. In the equipment entity, any procedural element may be a monolithic block of code or ladder rungs. Phases help the operator to monitor progress, but are not required. Figure 8-4 shows the situation when a unit procedure is built into equipment entities. Suppose your batch process requires distillation, and one batch still is required to handle the output of two reactors, since distillation time is less than half of the reaction time. The still is a separate unit, filled with the reactor contents and emptied before the next distillation. The distillation procedure does not vary, although temperatures, reflux ratios, and cut points are specified by the recipe. You have a unit procedure that can be built into the equipment.

Figure 8-4 Unit Procedure Built into Equipment Entity

batch chap 8.qxd

4/25/2006

2:37 PM

Page 139

88 Batch Control Concepts, Part 2

139

Figure 8-4 represents a snapshot of the control recipe as it executes the distillation unit procedure. The Recipe Unit Procedure is linked to the Equipment Unit Procedure that is built into the distillation unit. The dotted lines for Equipment Operation and Equipment Phase indicate that they are optional, depending on the control design of the equipment entity. It is possible to extend this concept to the Recipe Procedure, but this leaves the formula as the only way to vary the products. If the linkage is made at the procedure level then there is no possibility of having any other procedural elements in the recipe. The entire procedure must be performed by a self-coordinated set of equipment entities.

5.3.3.4 Control Recipe Procedure/Equipment Control Collapsibility This section describes the combinations that occur when a recipe procedural element is left out of the middle of the hierarchy, such as a unit procedure or operation. Collapsibility seemed like a good idea at the time—a natural extension of the principle of keeping things general. A distinguished teacher of 88 has discovered that collapsibility causes more confusion than it is worth. If you only have one unit and never expect to expand, it still doesn’t cost anything to have a recipe procedure that contains one unit procedure. It is harder to think of examples where one unit performs one operation and that situation will never change. People who design recipe procedures that contain only phases have not understood the benefits of grouping phases into operations. Or maybe they need help in handling things that have to keep going across operations, like an agitator or circulation pump. It is possible to turn something on in one operation and turn it off in another, letting the equipment or a phase in each operation monitor the activity.

5.3.4 Recipe Transportability Several different computer systems may be involved in creating general, site, and master recipes. Control recipes are often-used copies of master recipes. It is reasonable to expect that master and control recipes would be created on the same computer system, so that there are no compatibility problems. The whole 88 recipe hierarchy fails if information cannot be transported from general to site recipes and from general or site to master recipes. Humans with a common understanding and language have no trouble passing information from one group to another when the information is technical and specific. Translations are possible. This is not necessarily true of different computer systems. Communication standards are necessary just to transport packages containing information. Further standards are necessary for the recipient to understand what is in the sender’s package. Information has not been transported if the recipient does not understand the message. A general recipe is transportable to any site. A site recipe is transportable within a site, where a site may be a wide geographic area as well as a plant. A master recipe is trans-

batch chap 8.qxd

4/25/2006

140

2:37 PM

Page 140

Chapter 8

portable to another process cell, but it may need some work to determine the required changes and make them. A control recipe is not transportable. Transportation is only a part of the problem. Each level must be converted before it can be used at the transport destination. The general recipe is transported to a site, where it is converted into one or more site recipes. The site recipes are transported to process cells, where they are converted into master recipes. Within each cell, master recipes are converted into control recipes. It is possible to automate most of the conversion process if the recipe hierarchy is designed as a single system that is implemented on different computer systems. It is even possible to reverse the process, converting a control recipe into a master recipe, master into site, and site into general. Transportation and conversion can be really difficult when management buys another facility that has a workable but different recipe system. Or your control system vendor could merge with another company that your management finds unacceptable. As support is withdrawn for your current system, you have to install something completely different. Either way, there is the problem of transporting (and translating) recipes from one kind of system to another. Manual methods are out of the question if translation is required and there are more than a few recipes. Think of the opportunities for transposing digits and misplacing information. The folks that design big databases and were members of SP88 came up with a system for transporting recipes to foreign systems. To no one’s surprise, it used Structured Query Language (SQL). All that the designers of database A need do is sit down with the designers of database B and design SQL statements that will read each item in A and write it to the correct place in B. Hopefully, the structure of all of the recipes stored in A is the same. Sometimes there isn’t a place to put an item from A, and then this simple task becomes more challenging. This system is explained further in Part 2 of 88. There are other ways to translate structures, but you always have to know the meaning of each item in each structure. If the translation is successful then recipes can be transported from A to B.

Summary This chapter discussed recipes as described in Section 5.3 of ANSI/ISA-88.01. There are four and only four types of recipes: general, site, master, and control. Each type contains five categories of information: header, formula, equipment requirements, procedure, and other information. The difference was explained between the recipes that teach how to make a product and those that make the product with the aid of physical equipment. The relationship of recipe procedural elements to equipment procedural elements was described, along with the possible separation points between recipe and equipment. Finally, the transportability of recipes was discussed.

batch chap 9.qxd

4/25/2006

2:39 PM

Page 141

Chapter 9

88 Batch Control Concepts, Part 3 This chapter covers the remaining parts of ANSI/ISA-88.01 Section 5, Batch Control Concepts. These are Production Plans and Schedules, Production Information, Allocation and Arbitration, Modes and States, and Exception Handling.

5.4 Production Plans and Schedules Business planning, based on the art of forecasting demand, provides a general strategy for the production mix of products. Other planning predicts the level of inventory of materials that the process will require. At the business level, schedules are detailed plans that allocate time and resources to the production of products, within the capabilities of the organization. Schedules may reveal that there is a lack of resources to implement the plans, which can cause plans to be made to acquire those resources. Business planning and scheduling is not within the scope of this standard. See the SP95 work for details. 88.01 begins down at the process cell, although a lot of 95-level work has to be done to arrive at a schedule for a cell. Basically, the batch schedule tells the cell what to make and how much and when to make it. Depending on the cell and unit control schemes, the schedule may have to specify the units to be used or the path to take. The same sort of thing is true for personnel, material options, and packaging requirements. A process cell schedule is a list of products to be made, listed in the order in which they are to be made. Each listed product contains a set of information, which may contain some of the following items: • Product name—If not obvious from the master recipe name • Master recipe name and version or other identification—Required • Batch size—Required if variable • Batch ID—Required if preassigned • Destination for the batch—Required if there is a choice • Lot ID—Required if preassigned

batch chap 9.qxd

4/25/2006

2:39 PM

Page 142

142

Chapter 9

• Specific customer requirements—Required if they will affect the control recipe • Specific equipment to use or a permitted selection to use—Affects the control recipe, if required • Specific material sources to use or a permitted selection to use—Affects the control recipe, if required • Projected mode of operation—If a mode selection is necessary • Projected start and end time—If reliable • Order of initiation—If not defined by start time • Priority—If required A schedule represents an attempt to predict an uncertain future. The law of probability named after Murphy will require constant vigilance and corrections. (Actually, Capt. Edward A. Murphy was investigating high G forces by testing a rocket sled at Edwards Air Force Base in 1949. A technician had installed a connector backwards, so a run was wasted with no data returned. Murphy said, “If there is any way to do it wrong, he’ll find it.” A project manager, George E. Nichols, wrote this down in a book on laws of projects that he was compiling. Somehow, this “law” was changed from being an observation about people to an implacable law of probability. That probably happened when the media got hold of it. Perhaps it is because “If anything can go wrong, it will” sounds better than “Not my fault.” What many now call Murphy’s law is ancient in many languages. It would be remarkable if such a universal truth had not been discovered before 1949. If Murphy had any other last name, he would probably be lost in history. Col. John P. Stapp, the first to quote Murphy to reporters, came up with Stapp’s Ironical Paradox, which says, “The universal aptitude for ineptitude makes any human accomplishment an incredible miracle.” Stapp was a medical doctor who rode one of Murphy’s sleds to a 45 G deceleration.)

5.5 Production Information So far, we have talked about the aspect of control that issues commands to various entities. All of these commands have been caused, directly or indirectly, by humans. Humans can learn from experience, unlike today’s software systems. We need feedback from the effects of our commands in order to learn. Information on actual performance must be collected from production activities and digested into a form that we can compare with our commands, so that we can improve them. Then there are the customers and their government representatives, such as the FDA. They were not there when the batch was made, and they have a strong interest in what, if anything, went wrong. Information must be collected that can satisfy their requirements.

batch chap 9.qxd

4/25/2006

2:39 PM

Page 143

88 Batch Control Concepts, Part 3

143

Somewhere, there are people that need information to make decisions. The information must be collected for that purpose, along with all of the other purposes. The dead time between command and feedback must be minimized so that a busy operator can make the connection between the data and the command. Just as in PID control, excessive dead time dulls the response. The folks from Process Design can’t seem to get enough data. Indeed, they may install additional sensors on and about a test reactor. This data will not be recorded as production information if the database has to be rebuilt in order to add it. Portable data recording systems are readily available if the existing system cannot handle the extra load. It is important to accurately timestamp data, preferably at the source. If something unexpected happens, the cause is probably the change that has the earliest timestamp in a chain of events or the one just before the alarm timestamp. If the event is not detected and stamped at the source then the time may be offset by communication and processing delays in intervening machines. 88.01 classifies production data as batch specific and non–batch specific (common) information. It also distinguishes between batch history and batch reports.

5.5.1 Batch-specific Information There follows a list of examples of data that could be called batch specific: • A copy of the final control recipe—The initial control recipe may be modified during the batch. • Recipe formula data as actual values—This data needs to be viewed as formula data so it can be compared to the targets in the recipe. • Recipe-specified data—Although this wasn’t mentioned under recipes, procedural elements could contain specifications for data to be collected and specify the sampling interval. The procedure could turn trending on and off. This does not apply to exceptions such as alarms, which are always captured. • Summary batch data—Utilities consumption, equipment run times, parameter statistics, and so on. • Operator comments—These may be invaluable for troubleshooting. “12:30 Hammering sound from R322 at about the speed of the agitator.” “14:02 Strong thunderstorm dumped cold rain on units, lightning strikes.” Generally, control rooms have shift logs so that the next shift can read about any current news or exceptions. If this data can be identified by batch and operator, it should go into batch-specific information. It may be useful to log maintenance and supervisors comments as well. • Continuous data—Recorded just like a continuous plant. An idle unit may fill up with condensate from a leaking steam valve or worse. A spike in any reading associated with an idle unit may indicate trouble, as may a reading that stays up after it should have gone down.

batch chap 9.qxd

4/25/2006

2:39 PM

Page 144

144

Chapter 9

• Event data—The best thing to do with event data is to record all that is available with timestamps and source identification. Event data usually includes procedural element start and end, mode and state changes, exceptions, and so on. • Operator data—Operator data records commands given by the operator that override the recipe procedure or change the control recipe, with the operator’s ID and time. Such data may also include telephone or radio conversations if they can be related to a batch. If not, the operator should log them under operator comments. • Analysis data—No problem if process analyzers are used, otherwise the data is not real-time. Worse, someone could report the wrong sample and then ask to have the correct results recorded, or realize that one of the numbers was way off and re-analyze the sample. It is best to record all of this rather than go back and change history by replacing the sample report. Include time stamps and identify the people involved.

5.5.2 Common Information A list of examples of data that would be called common follows: • Quality Assurance (QA) information—This includes approvals, possibly with qualifications, of process input material lots and the process output products. The product may be blended into a lot, where the analysis is made. Also includes approvals of process conformance to documented standards. • Utility systems information—Continuous and event data from boilers, chillers, oil or water heaters, and so on. • Equipment history—Includes the operating time since the last overhaul, calibration records, time since last inspection, indications of deterioration, over-temperature or over-pressure events, repair history, and so on. • Operational documentation—Summary data on percent utilization, downtime, amount of products produced, average inventory levels, utilities consumed, and so on. • Materials information—Records of materials received and produced; high, low, and average quality measurements; records of labels on incoming and outgoing materials, and so on.

5.5.3 Batch History If the process cell is small, then the stream of batch information may be captured on paper or in flat files. At some point, it makes more sense to use a relational database or its equivalent. The database may be so expensive that it is centralized, or databases may exist for each cell and collection of common information. Whatever, something has to catch the streams of data and make them effectively immortal. In a regulated environment, what you record must be what you are willing to show outsiders. The product of a batch process may be worthless if there is no batch history available or if what the customer wants to see is missing. It may be necessary to trace the genealogy of the batch as well as its QA tests.

batch chap 9.qxd

4/25/2006

2:39 PM

Page 145

88 Batch Control Concepts, Part 3

145

Batch information must be recorded with appropriate key fields, such as the source of the data and the associated equipment identification, time stamp, and value. The information will be sorted into various views in order to make it more useful. The start and end times of a batch along with the equipment ID of the first unit make it possible to sort out everything for one batch, including batch and common data. Sorting is even easier if batch ID is included, although that is not possible for common data.

5.5.4 Batch Reports Each report represents a different view of batch history. Once the history is captured, reports can be requested whenever recipients need them. Report formats or views may be altered to show different data without modifying the batch history records, unless the data is not in the history. Graphic data may be required. The following is a partial list of possible reports and recipients: • Production management—Summaries of manufacturing costs, actual and promised manufacturing dates, cost of inventory, equipment utilization, human resource levels, and so on. • Product development—Detailed reports of equipment activities and analysis results, statistics for many batches, comparisons of similar data among equipment, and so forth. • Plant operations—Reports of current operations in the plant, summaries of past production. • Quality management—Reports of data associated with quality for specific batches or equipment, statistical charts summarizing recent and long-term production, and others. • Authorities—Carefully compiled reports of compliance with regulatory requirements, with nothing extraneous that might be misunderstood. • Customers—Whatever they want that they can’t be talked out of, usually related to product quality and process uniformity. Again, nothing extraneous should be included.

5.6 Allocation and Arbitration First a few words about some of the terms: • Allocation—Setting aside something so that no one else can use it until the intended user is finished. The use may be in the future, but the thing allocated is not available from the time that the allocation is made. • Reservation—Like allocation, but for a future time slot. The allocation begins in the future so that others may use the thing before the reserved time. • Acquisition—The result of negotiation between two entities, one of which owns the thing to be acquired. After the owner and the requester have agreed, the owner may allocate the thing to the requester or make a reservation for later use.

batch chap 9.qxd

4/25/2006

2:39 PM

146

Page 146

Chapter 9

If a batch schedule does not name the equipment to be used, then the cell must allocate a starting unit when a scheduled batch is due to start. Allocation is done by coordination control. In the event that two or more resources are available, some algorithm is necessary to choose one of them. Hotels use “room nearest the elevator” and restaurants use “table nearest the kitchen.” A process cell might choose “leastused equipment” in order to distribute wear on the equipment. If things are not so simple then the cell or the unit or the common resource must have a way to resolve any conflicts. Conflicts are reduced, but not eliminated, by making reservations. Since the decision is made by the resource and the equipment entity that is competing for the resource has no recourse to a more favorable decision, the procedure for resolving the conflict is called arbitration. If there is no priority structure then an algorithm like “please hold, your call will be answered in the order in which it was received” or “serve the smallest request first” may be sufficient. If there is a priority structure then the request queue must be sorted by priority each time a new request comes in. Things are more complex if a priority request can stop a service in progress. Part of the contents of a supply tank may be reserved for a specific batch, which may result in arbitration. This also applies to space in a storage tank. The following discussion is about equipment, but it works as well for operators and other resources.

5.6.1 Allocation Batch processing is performed in process cells that contain units and common resources. If you have only one unit then you probably won’t find the rest of this very interesting, though it might be useful for planning future growth. Process cells generally don’t do anything that isn’t requested by a schedule. When a batch is scheduled to run, the cell must allocate at least one unit for that batch. The choice may depend on the connectivity to following units in order to assure completion of the batch. After the batch is started, the unit does its processing relatively independently of the rest of the process cell. That is, the unit is independent until it needs the services of a common resource or another unit, perhaps for transfer. If the cell has successfully allocated the resource then there is no problem. If the unit requests service from the resource without warning, then the resource may not be available. Some batch processes may require a resource for a fraction of the batch processing time, leaving the resource free to serve other similar processes. No one wants an idle resource in their plant, unless it is the fire pump or something like that, so processes are designed to time-share the resource, now called a common resource. A common resource may be a unit, if the resource must actually process the batch. More likely, the resource may provide some service to the unit containing the batch, like delivering a material, filtering the product, or providing additional heat transfer capability. In that case, the resource can not be a unit but may be an equipment module. The equipment module may have procedural control at the phase level.

batch chap 9.qxd

4/25/2006

2:39 PM

Page 147

88 Batch Control Concepts, Part 3

147

Common resources have also been called shared resources, but this is imprecise. Common resources can be exclusive-use resources when they are dedicated to a requesting unit or shared-use resources if more than one but less than all units may use the resource at the same time. If all of the units can use it at the same time then it does not require allocation. Exclusive-use resources may become bottlenecks in cell processing. A bottleneck is a narrow passage that slows down everything behind it when it is overloaded. That’s why some beer bottles have wide mouths and no neck, so that the beer is not delayed on its journey to becoming fat and waste. An exclusive-use resource must have some idle capacity. If not, then it is limiting the production rate, possibly leaving much more expensive units idle while they wait for the resource. In any event, exclusive-use common resources require allocation and possibly arbitration. Shared-use common resources reduce the bottleneck effect but may not eliminate it. A shared-use resource may be a pump and two flow totalizers, with paths for any totalizer to any of four units. The pump can handle two charges at once but no more. The result is that only two batches may acquire this equipment module at the same time. The third request will have to be allocated to a queue or arbitrated. Allocation or acquisition is required when two or more units may compete for a common transfer line. Consider the case of a multipath transfer header that is too complex for reasonable coordination control among units, but the header can only serve one source and destination. The header and its control comprise an exclusiveuse common resource that is common to many sources and destinations. The use of the header may be decided by anything from simple allocation to preemption.

5.6.2 Arbitration Arbitration algorithms are used to resolve allocations of a single resource to multiple requests. A simple solution is a queue of the first-in, first-out variety. Each request in the queue represents a delayed allocation. A reservation system helps to reduce arbitration by allocating requests to time slots. A hotel reservation system allocates people to rooms on certain dates. This usually works very well, as long as the schedule stays on track. A priority scheme is required when there are more requests than there are open reservation slots. Perhaps the system already has a priority scheme. Either way, when priority is exercised the current occupant of the resource or a reservation slot must be preempted. Then something must be done with the preemptee. A falling-domino effect may ensue. Preemption means that a higher priority request for a resource is allowed to stop the service to the current user and start serving the preemptor. A simple example is an exclusive-use common resource that charges solvent to reactors. The charges take a long time. A unit that is in the final stages of the reaction may discover that it needs a comparatively small amount of solvent to complete the reaction. This unit is allowed

batch chap 9.qxd

4/25/2006

2:39 PM

Page 148

148

Chapter 9

to preempt the solvent charge in progress, obtain what it needs, and return control to the charge in progress. Other examples require that the batch in progress be pumped to storage so that the preempting batch may use that unit.

5.7 Modes and States The words mode and state have many meanings. They require explicit definitions for the context in which they are used. The following are definitions for process control that are used in this book: • A control mode describes the behavior that a control algorithm (human or machine) will exhibit, if it has a selection of behaviors. For example, the basic modes of control are Automatic and Manual. For a PID controller, an operator can not adjust the output while the mode is Automatic, which lets an automatic controller fulfill its purpose. Manual mode allows an operator to stop automatic operation and take control of the output. The PID controller can behave in two ways with respect to the operator. The operator selects one of these two with a Mode switch. • A control state refers to one of a selection of algorithms that cause a specific activity to happen until the state is changed. The algorithm for one state responds to a subset of all inputs, produces a subset of possible responses, and changes state to a subset of all possible states in response to an event. For example, the basic states of control are On and Off. A drill press controller may be in the following states: Idle if the drill bit is up and off, Running if the motor is on, Lowering as the drill bit approaches the work, Drilling, and Raising. A continuous controller like PID has one state (On) with one algorithm. Selection of a path through the algorithm depends on the mode. The discussion of Section 5.7.1 and 5.7.2 in 88.01 is about modes and states as they are applied to equipment entities and procedural elements. This causes some confusion by directing attention to the result of control rather than to the controller. Perhaps the discussion is too abstract. In an equipment context, state refers to the physical configuration and activity that is the result of executing a control state’s algorithm. Naturally, the control state tends to have the same name as the physical state that it causes, which adds to the confusion. The definitions of mode and state given above are for the control context, not the controlled equipment. Consider the situation when control is performed by a human. It is the operator that has a mode, which is set by a supervisor. That mode is Work—not Sleep, Eat, or Party. The operator keeps track of the state of procedural control by knowing where he or she is in the printed procedure. The procedural elements on the paper do not change state. A controller can have status in addition to mode and state. A status concisely describes the current condition of a controller, perhaps by health, alarms, limitations, and current activity, which include the mode and state.

batch chap 9.qxd

4/25/2006

2:39 PM

Page 149

88 Batch Control Concepts, Part 3

149

In the discussion that follows, modes and states are applied to basic control instead of equipment entities and to procedural control instead of procedural elements.

5.7.1 Modes 88.01 does not define the behavior of modes or limit their number. The intent is to define the names of two or three common modes and provide examples of how they have been used in practice. The users in SP88 wanted standard mode behavior, but the vendors had user bases to protect. Even the method for selecting a mode differs among vendors. If the mode of a controller is automatic, then the controller may change its mode as required by conditions. If the mode is manual, then the controller is not allowed to change to an automatic mode.

Basic Control Basic control has at least two modes: automatic and manual. Other modes will be present if the controller can be set by another controller or a remote computer. Modes select the behaviors of basic control. Automatic mode causes outputs to the equipment to be determined by the control algorithm. Manual mode causes outputs to hold their last values. Modes also select the commands that will be accepted by a controller. Automatic mode causes control to accept only commands to change the setpoint or mode. Manual mode adds the possibility of changing the output. Basic control logic may be used to propagate a mode change to other associated controllers. This makes it possible to lock a set of controllers into automatic mode if one controller is set to automatic. A set of controllers may be locked or unlocked by procedural control, so that the mode of procedural control may be propagated to basic control. Other logic signals, like interlocks, may affect modes as well as states. The examples so far have been specific, but they are a small subset of the behaviors that a mode can select in different kinds of basic control. It pays to read the manual of an unfamiliar device.

Procedural Control This type of control requires a control entity that executes procedural elements according to the active paths in the procedure. One way to choose a path is by transition conditions such as “procedural element complete,” meaning that the procedure defined by the element is done. When a transition condition associated with an active procedural element is true, then the next procedural element in the path is started and the previous element becomes inactive. This is commonly expressed with a Sequential Function Chart (SFC), as specified in IEC 60848 or 61131.3.

batch chap 9.qxd

4/25/2006

150

2:39 PM

Page 150

Chapter 9

The procedural modes, with example behavior and command limitations, follow: • Automatic—Active and true transitions cause a change from one procedural element to the next. An operator can not force a transition to be true. • Semiautomatic—Active and true transitions do not cause a change. An operator may be able to enable a change or may be able to turn off the active element and turn on another somewhere else in the path. Direct control of the elements can cause serious problems if the operator did not understand all of the training. • Manual—Active and true transitions do not cause a change. An operator can force transitions to be true. When a transition is forced, it forces a change to the next active element. Direct control of the elements may be possible. Again, these are examples of a wider range of possible behaviors. You will find procedural control that replaces Semi-automatic with Single Step mode. Transitions do not cause a change until the Start command is given. Some people call Hold a mode. Hold causes active elements to go to a safe state right now. Single and Semi modes wait for active elements to finish. SP88 treated Hold as a state, as discussed below.

5.7.2 States Basic control and procedural control may have states. A control state defines the desired condition of an equipment entity. States are changed by commands or by the completion of a process function. Each control state has an algorithm that runs while the state is active. The algorithm is independent of other states’ algorithms, but may depend upon other states to set up the conditions for it to run properly. In the drill press example, the Drilling state will fail to perform its function if previous states did not include Running and Lowering. The entity that causes states to change along directed paths and executes the active state algorithms is usually modeled as a finite state machine. The machine has states, transitions, transition conditions, paths, inputs, outputs, and commands. Each state has one entrance path and one exit path that leads to one or more transitions. There is only one transition that controls the path between two states. The active state may have several algorithms, but only one of them is active. The algorithm may use a subset of inputs or simply set the outputs. The outputs are a subset of all of the machine’s outputs. The transition condition is either true or false. Its value may be calculated from a subset of inputs and commands. If the state that precedes the transition is active and the transition condition is true, then the preceding state becomes inactive and the following state becomes active. More than one state may be active in the machine at one time on parallel paths. More detail may be found in IEC 60848, which standardizes the rules for an SFC.

batch chap 9.qxd

4/25/2006

2:39 PM

Page 151

88 Batch Control Concepts, Part 3

151

Basic Control Figure 9-1a shows the two most simple basic control states with an SFC.

Figure 9-1a Simple Basic Control The figure shows the control function for a simple switch. There are only two states, On and Off. There are just two commands, ON and OFF. The double box that contains Off shows that this is the initial condition that will be used when the sequence controller starts up. If the ON command becomes true then the state will transition from Off to On. Further ON commands will be ignored because the state above the transition is no longer active. The OFF command will transition the state from On to Off. An arrowhead is shown on this path to show that the path is not in the default downward direction. This example is shown primarily to show how the SFC works.

Figure 9-1b Transfer Header Figure 9-1b shows a simple sequence for a transfer header from one unit to one of three destinations. The header is clean and closed when the state machine is in the Idle state. The command OPEN A or OPEN B or OPEN C will transition the state from Idle to the state matching the first command received. After the transition, the Idle state is inactive, and the commands are disabled. If the commands are simultaneous, they are evaluated from left to right and the first one wins. If OPEN A and OPEN C arrive at the controller at the same time, OPEN A will win. A common CLOSE command transitions whichever state was active (there can only be one) to its Wash state. The SFC has levels so that a

batch chap 9.qxd

4/25/2006

2:39 PM

152

Page 152

Chapter 9

state like Wash A can have a level below it that cycles through the wash sequence. The Wash A state transitions to Idle when the lower level is done. Figure 9-2 shows the sequence that is required to run a motor with a heavy load (like an elevator car) in two directions. A FWD or REV command will transition the initial Off state to either the Forward or Reverse state. From either of those states, commands may reverse direction or stop the motor. In any event, the motor must be braked to a stop before entering a new state.

Figure 9-2 Sequence for Two Directions An SFC can describe any kind of sequential control and a state machine can perform the state transitions. Something like them may be used to describe and do procedural control, where the boxes represent procedural elements and the transition conditions are mostly “Done.” The SFC-like display is covered in Section 6 Procedure Function Charts in ANSI/ISA-88.00.02-2001.

Procedural Control Procedural control uses states in two ways. Procedural elements may be either active or inactive. The active/inactive states of procedural elements and the conditions for changing those states determine the path that a procedure will take through its logic. Procedural control itself has a state machine that evaluates the transition conditions and changes the states of the procedural elements. The state of procedural control is determined by a state-transition diagram in the example used in Figure 18 of 88.01. This diagram has an enclosed symbol for each

batch chap 9.qxd

4/25/2006

2:39 PM

Page 153

88 Batch Control Concepts, Part 3

153

state and a directed line (arrow) that shows each possible path between states. The lines are labeled with commands or other events. (The line from Pausing to Paused is missing in some published versions of 88.01.) This book uses an SFC to describe exactly the same thing, as shown in Figure 9-3. Like Figure 18, this figure does not show that you can STOP or ABORT from any active state because that would require a three-dimensional model. The following is a description of the behavior associated with the states as used in Figure 9-3: • Idle—Procedural control is waiting for a Start command. This is the initial state for procedural control. A new recipe procedure or element may be loaded into memory or put on the operator’s clipboard during the Idle state. • Running—Procedural control is executing procedural elements on the normal execution path. • Pausing—A Pause command has been received. Procedural elements continue to run on their normal path until there is a transition to the next procedural element, when the state changes to Paused. The transitions in the lowest-level recipe procedural element in each active path are monitored. An element may prohibit pause in order to finish a critical sequence. If parallel phases are running, no transitions are made, and the Paused state is entered when all parallel paths have stopped at transitions. For Pause to be safe, the steps that open a valve and close it when the fill is complete must be built into the equipment. See Holding. • Paused—The execution of procedural elements has been stopped at points between procedural elements so that a clean restart is possible, provided that the mode isn’t changed to manual. The duration of a pause is up to the operator. A Resume command will restart execution where it left off. This seems to duplicate the function of the semiautomatic mode, except that it is intended for short durations to allow the operator to investigate something suspicious without seriously disturbing the process. Most of the time there is no problem and execution is resumed. Other responses are possible, although the diagram doesn’t show them. There should be paths from Pausing and Paused to Hold, Stop, and Abort. Suppose the rattle gets worse or the noisy bearing starts screaming while Pausing is still waiting for all active procedural elements to finish. • Holding—A Hold command has been received by procedural control. The command may have come from exception handling or from an operator. Execution immediately changes from the normal algorithm to the hold algorithm. Hold is intended to bring the process to a relatively safe state and give the operator time to deal with some problem. Some procedural element logic may delay the hold if what it is doing is not interruptible. When all hold paths are complete, the state changes to Held.

batch chap 9.qxd

4/25/2006

154

2:39 PM

Page 154

Chapter 9

Figure 9-3 State Transition Diagram

batch chap 9.qxd

4/25/2006

2:39 PM

Page 155

88 Batch Control Concepts, Part 3

155

• 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 determined 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 immediately 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) command, 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.

batch chap 9.qxd

4/25/2006

2:39 PM

Page 156

156

Chapter 9

• 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 exceptions 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 normally 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 procedures, 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 information 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 presented. 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 introduction to exception handling.

batch chap 10.qxd

4/25/2006

2:41 PM

Page 157

Chapter 10

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 clarifying 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 without 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 shoulders 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 crucibles and retorts, separating liquids with distillation, and separating fools from their gold. All of these survive today in forms significantly altered by advances in technology. 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 bellows 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

batch chap 10.qxd

158

4/25/2006

2:41 PM

Page 158

Chapter 10

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-itwithout-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 procedures. 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 contained 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 expensive, to the point that it was possible to consider them for process control. The greatest room for computational improvement was in continuous processes, so computers 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 Programmable 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. Regulatory 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.

batch chap 10.qxd

4/25/2006

2:41 PM

Page 159

88 Perspective and Review

159

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 collective 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 operation 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 processing 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 descriptors). 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

batch chap 10.qxd

4/25/2006

2:41 PM

Page 160

160

Chapter 10

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 requirements 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 procedure. 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 twodimensional 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 Process

Source Recipe

Basis Recipe

Control Recipe

Process Stage

Partial SR

Partial BR

Partial CR

Basis Operation

Control Operation

Basis Function

Control Function

Chemo-Technical Unit Operation

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.

batch chap 10.qxd

4/25/2006

2:41 PM

Page 161

88 Perspective and Review

161

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 integration 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) sevenlayer 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 Manufacturing (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 Reference 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 programmed 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 business became comfortable with operating more in line with the model, then computer

batch chap 10.qxd

4/25/2006

2:41 PM

Page 162

162

Chapter 10

systems could be purchased, programmed, and integrated at a rate that did not disrupt 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 planning 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 mentioned at level zero, as the following table shows: Table 10-2 Generic Functions of a CIM System 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

The equipment layer was set outside of the PRM “because of wide differences of equipment and functions between different industries.” The enterprise level was “considered 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 complexity 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 complicated the software, and so on. Each level has to know what information it needs from the process and what commands 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

batch chap 10.qxd

4/25/2006

2:41 PM

Page 163

88 Perspective and Review

163

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 optimizes 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 discrete 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 Enforcement.” 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 “bubbles” 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 connections 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

batch chap 10.qxd

4/25/2006

2:41 PM

Page 164

164

Chapter 10

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.

batch chap 10.qxd

4/25/2006

2:41 PM

Page 165

88 Perspective and Review

165

During SP88 The following is a discussion of how SP88 changed the fundamentals of batch control in Sections 4 and 5 of 88.01. The discussion serves as a review of 88.01 so far, before we take a different look at the concepts in Chapters 11 and 12.

The Equipment Section 4 has a seven-layer stack not unlike the hierarchy in the ISO CIM model. Equipment is not only present but is divided into the unit, equipment module, and control module layers. This does not square with the PRM, where the equipment is in level zero and the layers above it consist of control functions based on available information. SP88 associated control with equipment because 88.01 had a four-layer structure for the process model, the physical model (minus enterprise, site, and area), and the procedural control model. The reason for doing this was shown in Figure 7-3 (Figure 7 in 88.01), where the procedural control model and the physical model are combined to provide the functionality of the process model. The combination of a set of equipment and the control that animates it was defined to be an equipment entity. The equipment entity is a new fundamental concept in batch control. SP88 also defined three kinds of batch control: basic, procedural, and coordination. Basic control dominates control modules. Procedural control is mostly done by units, although equipment modules may execute phases. Coordination control results in the assignment of tasks to equipment. It is mostly done by the process cell, but may be found with decreasing probability in the unit, equipment module, and control module entities.

The Procedure The need for equipment entities became clear in Section 5.3.3 where the separation of the recipe and equipment procedures was described. Recipe building blocks are not possible without the process functionality building blocks represented by equipment entities. This concept changed the way procedures are designed. No longer does a monolithic procedure in level 1 direct the activities of a shapeless mass of generic equipment in level 0. Batch process control requires intimate knowledge of the processing capabilities of the equipment because the equipment is multipurpose. Equipment is not dedicated to a single function, as in a continuous or discrete process. The separation of recipe and batch procedural control may occur at any level of the procedural control model, but is most likely to occur at the phase because phases are the elementary building blocks of procedures. An equipment phase procedure has steps, but SP88 chose not to dwell on that because it is too close to implementation. Maybe the equipment phase has ladder rungs instead of steps.

The Formula A formula still consists of input and output materials and the process parameters that were added for early monolithic procedures.

batch chap 10.qxd

4/25/2006

2:41 PM

Page 166

166

Chapter 10

The Recipe Recipes contain header information, formula, equipment entity requirements, procedure and other information. Equipment entity requirements are yet another reason to associate control capability with equipment, to simplify the specification of requirements. Other information is simply an adaptation to changing technology (you can do it, you have the technology) and regulations (you shall do it). A fundamental change took place in the types of recipes. General recipes are formalized instructions to production facilities that define, in general, what must be done to make the product. Site recipes define, in general, what must be done to make the product at a specific location, written in the language of and adapted to the resources at the location/site/plant/facility. Master recipes are specific to the equipment within and resources available to a particular class or instance of a process cell. Control recipes are specific to a particular set of equipment entities and resources that are available or reserved when a batch is started. Each control recipe is used exactly once to make a specific batch. Each master recipe is used every time that a control recipe is copied from it. Each site recipe is used to make as many master recipes as are required for different process cells. Each general recipe is used to make as many site recipes as there are sites. Master and control recipes are different from general and site recipes in that the equipment requirements are specific to a known set of equipment entities or the equipment entities can only be described by their process functions. All recipe procedures have the same four-level structure—complete procedure, unit procedure, operations within each unit procedure, and tasks to be done by each operation. Each recipe type should be designed to facilitate translation to the next lower recipe type except, of course, the control recipe. This is called transportability.

Production Plans and Schedules Nothing new here.

Production Information This section defines information as what is kept in batch history, along the lines of a database system. Batch reports are separated from the gathering and historicization of batch information. They become views of the database that are customized to fit the user’s requirements and may be extended by data from other databases.

Arbitration and Allocation These are fundamental concepts that SP88 did not change much. They were defined by a set of words that reached consensus, which is no small accomplishment.

Modes and States SP88 defined a set of modes and states that do not change the fundamentals of batch control. The names were defined and given example behavior in the hope that vendors would accept the definitions.

batch chap 10.qxd

4/25/2006

2:41 PM

Page 167

88 Perspective and Review

167

Exception Handling Nothing new here.

Summary This chapter has reviewed the changes to the fundamentals of batch control over the years as a foundation for discussing the control activities in Section 6 of 88.01, coming up in the next chapter. The work of the Purdue Workshop on Industrial Computer Systems WG4 and the Purdue Reference Model committee were summarized. The NAMUR work already presented in Chapter 5 was referenced. Finally, the material in Sections 4 and 5 of 88.01 was summarized with emphasis on changes to the fundamentals of batch process control.

batch chap 11.qxd

4/25/2006

2:45 PM

Page 169

Chapter 11

88 Control Activities and Functions, Part 1 The previous sections of ANSI/ISA-88.01 have talked about the separate entities of equipment and recipes. This chapter will begin the discussion of Section 6, which describes the activities that take place in a system composed of those entities. In other words, this chapter will show how the things and concepts previously discussed interact when used to produce batches. As you might expect by now, the terms activity and function are words in general use that have special meanings in this section of 88.01. There are only seven batch process control activities and one of them is set outside the scope of the standard. Each activity is decomposed into functions that describe things that may be done by the activity. Another way of looking at this is to consider each activity as a department in an organization. Each department contains people that perform the functions of that department. This chapter should improve your understanding of why 88.01 said what it said so far. Don’t be shy about going back and re-reading something in a new light. 88.01 cannot be understood after the first reading—unless you read it with this book as a companion. Even then, you may not reach full understanding until you have designed the control for a complete process cell and started it up. The first three activities listed below had no interface to the functions of a business at the time that 88.01 was published. They are discussed in this chapter as they were written in 88.01, even though the current effort to connect 88 to 95 could change things. Possible changes are discussed in Chapter 16 under Joining 95 and 88.

6.1 Control Activities The control activities are listed below, starting with those furthest from the process: • Recipe Management – Provides recipes as required; performs translations and editing with add, modify, delete. • Production Planning and Scheduling – Provides batch schedules to the process cell. • Production Information Management – Digests raw process data and provides the results to other activities.

batch chap 11.qxd

4/25/2006

2:45 PM

Page 170

170

Chapter 11

Note: The above three activities were defined before SP95 existed, so there is considerable overlap with 95. At the time, SP88 as a group had only cursory knowledge of the business functions and no time to learn. The focus was on Batch Process Control, not business functions. • Process Management – Manages the functions of the process cell. • Unit Supervision – Supervises unit functions and executes unit recipes; functions as a combined supervisor and operator. • Process Control – Operates the equipment and control modules. • Personnel and Environmental Protection – Provides separate control actions that prevent bad things from happening, regardless of what Process Control may be telling the unit to do. This activity is outside the scope of this standard because SP88 had no qualified experts. Protection is the work of other standards groups, such as 84. The four activities above will be covered in Chapter 12. The word management is used in three of the activities. It does not refer to people management in the sense of leading a group of functions. It is closer to the kind of management that you find in computer books, such as File Manager and Device Manager. Process Management actually coordinates the functions of the process cell. It does not make business decisions.

6.1.1 Control Activity Model The figure that follows shows the seven control activities defined by 88.01. Each is connected by lines representing the relationship of each activity to the others. These relationships will be discussed, along with each activity, in this chapter and the next. The figure resembles Figure 19 in 88.01. A dashed horizontal line is used to separate the business functions from their counterparts in Operations (also called Manufacturing or Production). The activities discussed in 88.01 are not restricted by physical boundaries. Some of the things associated with the first three activities—Recipe Management, Production Planning and Scheduling, and Production Information Management—may actually be business functions. Business functions are outside the scope of this standard. The first three activities meet the following needs of the batch manufacturing environment: • Recipe Management – Recipes must be stored securely somewhere, new recipes must be able to be added, and existing recipes must be copied to the process cell in order to make the batch specified by the schedule. • Production Planning and Scheduling – The functions of this activity are divided between business and manufacturing. The dividing line may vary by industry or plant. The end result must be a schedule for making batches in each process cell, with enough additional information to be able to satisfy customer requirements.

batch chap 11.qxd

4/25/2006

2:45 PM

Page 171

88 Control Activities and Functions, Part 1

171

Figure 11-1 Control Activity Model • Information Management – The information from the operation of the process cell has to be stored somewhere. Various bits of process, product, and material knowledge must be made available to manufacturing functions. Special algorithms are used to compress and summarize continuous and event data. Trending may be turned on and off by procedural control. The next three activities meet the needs of the process cell: • Process Management – Generates control recipes for specific batches, initiates batches after assigning resources, coordinates transfers and equipment, and generates reports or passes the information to Information Management. • Unit Supervision – Execute recipe procedures, acquire resources, may coordinate Process Control activities. • Process Control – Execute equipment procedures, perform Basic control tasks. Note that executing procedures is really not a supervisory function—it is a control function. If there is no automation then it is the operator, not the supervisor, that reads the recipe procedure and follows its instructions.

batch chap 11.qxd

4/25/2006

2:45 PM

Page 172

172

Chapter 11

There is a dashed horizontal line between Process Control and Personnel and Environmental Protection because Protection is outside the scope of this standard. Protection used to be called a “Safety Shutdown System,” but “Safety” now has special meaning for trial lawyers. The activity model did not always look like this. During a SP88 meeting in Phoenix, Arizona, it bore a strong resemblance to a tall cactus with two arms representing Recipe Management and Information Management. Above the cactus was the clear blue sky, with some fluffy white clouds. Three of those clouds appeared to be attached to the top of the cactus and its arms. Later, the clouds were identified as vapor that condensed into 95.

6.1.2 Information Handling All of the activities communicate in one way or another. That’s how relationships are formed. There are some common information handling aspects that apply to all six activities, whether done by people or machines. These are: • Reference information • Security • Availability • Archives • Change management • Reference tracking

Reference information This is information that must be requested from another activity, as opposed to the stream of information within an activity or that which is published by control instrumentation. There are more activities in a plant than are shown in the control activity model. Communication with those other activities is required in order to request and receive information that is external to batch process control. Each source of reference information must organize and store it, and act as a server for client requests. Each control activity, as a client, should be able to get the reference information that it requires. Examples of reference information include master recipes, maintenance schedules, inventory control reports, benchmark consumptions, and yields. 88.01 provides a more extensive list of examples of reference information. The information may be restricted to one process cell, one area, one site, or one enterprise.

Security In the exciting days that followed the discovery of digital control and networks, some boasted that a person in the boardroom could open a valve in any manufacturing

batch chap 11.qxd

4/25/2006

2:45 PM

Page 173

88 Control Activities and Functions, Part 1

173

facility. This is a very bad idea. A manufacturing area maintains control over a number of process cells by endless safety training and the diligent application of safety principles by the operators. They keep the hazardous stuff contained. Anyone outside of manufacturing, and especially at the boardroom level, is unlikely to have had any safety training. It is essential that the ability to directly alter control settings be restricted to those who have been trained in the consequences of such actions. The business side may include individuals who have an exaggerated need for the power to change anything, so it is necessary to put a control firewall between manufacturing and business, particularly Information Technology. Of course, business must be able to direct manufacturing activities, but it must do so by going through procedures that protect the people who must work in close proximity to the process— like Scotty: Captain Kirk: “More power, Scotty!” Scotty: “She canna take much more, Captain! I’m giving yer all she’s got!” The captain can demand, but the engineer (operator) knows the limits of what can be done.

Availability Information must be available in a timely manner. Process control information has a useful life of milliseconds to minutes, so it is used directly and not captured, stored, and referenced. One of the direct uses may be to capture it for historical storage. Redundant systems may be required to assure a continuous stream of process data. Stored data requires periodic backups, even if storage is redundant. The timing of the backups depends on the control time horizon of the information. Don’t forget that business makes control decisions based on digested process control data. If a source of stored data fails, will you be able to get that information back on line in a timely manner? The following three activities may be changed by 88.00.04 when it is published.

Archival Nothing is more constant in manufacturing than change, especially if the principle of “continuous improvement” has any value to the enterprise. Regulatory commission rules and attack lawyers make it a very good idea to be able to reconstruct how a product was made, even though the facility may no longer make it that way. That makes it necessary to archive information that is no longer useful for current production. Of course, the physical archive media must be updated to keep up with storage technology.

Change management The changes to the ways in which products are produced should originate with someone who submits the proposed change to an approval process. The control activities must prohibit unauthorized changes so that there is no one who is unaware of the change. An approved change must alter the header description of the information in some way, usually by changing a version number. The reasons for the change and the methods for making it must be documented and tied to the version number of the changed information.

batch chap 11.qxd

4/25/2006

2:45 PM

174

Page 174

Chapter 11

Some regulations require that the change be validated before it is put into production. If so, then the validation procedure and results must be documented and referenced to the information that implements the change. When any document is changed, the change should be logged with the time and date in a summary list, which acts as a directory of changes. The new document should be a new file instead of an alteration of the original, as was done when documents and drawings were created manually. This assures that each change will be archived without losing the previous changes and their dates. The paragraph above refers to static information. Sometimes dynamic information must be changed, like a lab analysis or data that is entered to simulate readings from a bad transmitter. An audit trail that lists “why who did what and when” is more appropriate than a formal change order process. The audit trail must be reviewed in a timely manner to catch any changes that should not have been made. Access to change dynamic information must be restricted.

Reference tracking A large amount of data from different sources may be needed to reconstruct the way that a product was made. This usually starts with a batch or lot ID from the product or its invoice. That must be tracked to find the date and time when the batch was made. Change logs and audit trails must be reviewed for events within a time range. If any are found, they must be tracked back to their change descriptions to see if they affected the batch in question. It may be necessary to look at events weeks away from when the batch was made. Perhaps someone found a problem caused by a change to the process a month before, but no one else noticed it. The change logs include recipe changes as well as changes to equipment entities. Perhaps maintenance logs must also be searched to see if some equipment event may have dropped something into the batch. Tracking may be necessary to find the reason for a change in production performance that is not readily apparent from trend and event data. Tracking may be used to demonstrate the absence of evidence that anything had changed during the production of a batch. This demonstration may be necessary before the customer will pay for the product. Some of the references that need to be tracked may have been archived, so there must be a reasonable way to search for and recover the archived information.

6.1.3 Process and Control Engineering There is no doubt that engineering is required in order to design batch processes. The only question is one of engineering specialties and coordination. Even if lawyers have replaced your engineers, you should have some understanding of how the outsourced engineering will be done so that you will have some chance of getting what you require. Design engineering is one part of the life cycle. Engineering is required to start up, maintain, and dismantle both equipment and software, but this section is only concerned with design.

batch chap 11.qxd

4/25/2006

2:45 PM

Page 175

88 Control Activities and Functions, Part 1

175

The design of General and Site recipes does not include specific equipment, but it does include process functions that will be performed by equipment entities. These recipes instruct the Master recipe engineers in the chemistry and procedure that is required to make a product. There are two sides to the development process for new master recipes. These are shown in Figure 11-2, which is redrawn from Figure 20 in 88.01.

Figure 11-2 Concurrent Definition/Selection One side (the left) concerns the design of the recipe building blocks. The other side (the right) concerns the process functionality of equipment entities, because the recipe must be able to direct the equipment entities to make a product. Assuming that there is more than one engineer, one must take the recipe side and determine what procedural elements and equipment are needed to satisfy a range of product requirements that are appropriate for the facility. The other engineer must take the equipment entity side and determine what equipment and control is needed to provide the required process functionality. The two engineers actually represent engineering functions that may be accomplished by one person or two teams. “Processing Considerations” include the General or Site recipe, product specifications, and any process exception handling that is not done by the equipment entities. “Equipment Considerations” include the General or Site definition of Process Functions, the available equipment entities, and equipment exception handling. There are always equipment exceptions to be predicted and handled.

batch chap 11.qxd

4/25/2006

2:45 PM

Page 176

176

Chapter 11

The recipe orders the procedural elements, among other things. Similarly, the path orders the equipment entities. The degree of flexibility of the path depends on the requirements of the range of products being manufactured. This is an iterative process. If some equipment entities exist, then the recipe engineer fits them in as available process functions and asks the entity engineer to design new entities as required. If the facility is presently a green field with grass roots, then the recipe engineer begins the design by discovering the required process functionality and requesting it. The entity engineer designs entities that are constrained by technology, availability, and cost. This means that they may not exactly meet the process functionality requirements. The engineers meet to resolve the differences and produce a set of recipe building blocks that will work in a particular cell. Each recipe phase, operation, or unit procedure that connects to an equipment entity must match an equipment phase, operation, or unit procedure. These blocks are used to build Master recipes from Site or General recipes. Similar engineering is required at the site and general recipe levels. Although there are no equipment entities, the process designers must make an effort to choose process functions that are available at the target facility or facilities. Meetings with the engineers who do master recipe building blocks are required in order to reduce the work that is necessary to translate a site or general recipe into a master recipe. Careful engineering may allow future translations to be automated, if the relationship between a process function and an equipment phase can be reduced to an algorithm. If possible, the equipment entities should be designed to maximize the things that can be done with each entity. If the design staff can develop a complete list of process functions that might be encountered at a particular facility or cell, then work can begin on creating equipment entities in isolation from recipe development. Management may order the construction of a facility to make a class of product before recipe development has even started. It is a rare engineer who builds something that cannot be improved. Version 1 is never the last version. For this reason, the engineers at a facility will have work to do as improvements become evident, but only if they cut costs.

6.2 Recipe Management This control activity contains the functions that create, maintain, and archive all recipes above the control recipe. It also contains the functions that define, create, and maintain recipe procedural elements that are the building blocks of recipes. The functions do not have to take place in any particular physical location. The interoperable function of recipe management is to deliver a master recipe to Process Management upon request. 88.00.02 contains a first attempt at defining the process of passing a master recipe from one system to another. It relies on a great deal of SQL work to make the translations. It does not define the command/

batch chap 11.qxd

4/25/2006

2:45 PM

Page 177

88 Control Activities and Functions, Part 1

177

response set necessary to control the flow of master recipes. A specific interoperability standard is still required. Figure 11-3 is redrawn from 88.01 Figure 21. It shows the functions within the Recipe Management activity and the delivery to Process Management.

Figure 11-3 Recipe Management The functions of Recipe Management follow:

6.2.1 Manage General Recipes This function creates and maintains general recipes. Each product recipe is stored on paper or in a file in a way that allows it to be referenced by other functions within Recipe Management and anyone else with a need to know. Specific equipment is unknown at this level if the process cells have different kinds of equipment. Equipment requirements are specified by physical properties such as working pressure and temperature as well as wetted surface requirements for contamination and corrosion.

batch chap 11.qxd

4/25/2006

2:45 PM

Page 178

178

Chapter 11

This function may have the following capabilities: • Select and arrange procedural elements to build the recipe procedure. • Incorporate formula information, with amounts normalized to a unit amount of product. • Specify generic equipment requirements. • Manage the recipe change process.

6.2.2 Define General Recipe Procedural Elements This function defines, creates, and maintains procedural elements for general and site recipes. Each procedural element is stored on paper or in a file in a way that allows it to be referenced by other functions within Recipe Management and anyone else with a need to know. The interactive tasks necessary to define procedural elements were described above in Section 6.1.3, “Process and Control Engineering.” See 88.00.03 for more thorough coverage of recipes. 88.01 only set out to define the models and terms associated with recipes. This function may have the following capabilities: • Name each procedural element as the key to finding an element. • Name each adjustable parameter, such as a formula value. • Describe the process functionality and the use of parameters for each element. • If lower elements are used (as phases in an operation), select and arrange those elements. • Create and do file management for the elements. • Maintain a directory of procedural elements. • Manage the procedural element change process, including performing a thorough review of the effects of the change.

6.2.3 Manage Site Recipes The capabilities for this activity are similar to those for a general recipe. The site recipe is a modified copy of the general recipe, with no creative additions. That is, there are no additions unless the procedures for material preparation and addition have to be changed because the site can save money by purchasing local materials and processing them. Some vendors or users may require the site recipe procedure to be identical to the general recipe procedure. This will require different general recipes for the same product, one for sites without local materials and one for each site with different local materials.

6.2.4 Manage Master Recipes This function creates and maintains master recipes. Each product recipe is stored on paper or in a file in a way that allows it to be referenced by other functions within Recipe Management and anyone else with a need to know.

batch chap 11.qxd

4/25/2006

2:45 PM

Page 179

88 Control Activities and Functions, Part 1

179

If a general or site recipe exists then the creation of a master recipe is constrained to translating the intent of the generic recipe into a recipe that can be implemented by the equipment within a specific process cell. This requires matching master recipe procedural elements to general recipe procedural elements. This work may require engineering, or it may be automated if the two sets of elements can be aligned. This function may have the following capabilities: • Select and arrange procedural elements to build the recipe procedure. • Incorporate formula information, with amounts normalized to a unit amount of product. • Specify available equipment requirements. • Create and do file management for the recipes. • Respond to requests for recipes in a standard manner, with standard error messages. • Maintain a directory of master recipes. • Manage the recipe change process.

6.2.5 Define Master Recipe Procedural Elements This function is similar to the one for the general recipe elements except for the names and the use of specific equipment entities. Each master recipe building block must have a counterpart in an equipment entity at the point in the procedural element hierarchy where a recipe procedural element is implemented by an equipment procedural element. Automatic translation of a general to a master recipe procedure requires that one or a set of master recipe building blocks must have the same process functionality as the matching general recipe building block. Engineering is required for each translation if this is not possible. Using building blocks to construct procedures makes it possible to put any block anywhere, except for the few rules stated in the description of recipes. The best way to assure that a procedure assembled from blocks will actually work is to hire competent recipe authors. A strong review process that will question anything that does not look right is essential, because humans are not infallible. This function may define constraints for the assembly of blocks, but this will likely result in a false sense of security, because the constraints can’t cover everything. This function may have the following capabilities: • Name each procedural element as the key to finding an element. • Name each adjustable parameter, such as a formula value. • Describe the process functionality and the use of parameters for each element. • If lower elements are used (as phases in an operation), select and arrange those elements.

batch chap 11.qxd

180

4/25/2006

2:45 PM

Page 180

Chapter 11

• Create and do file management for the elements. • Maintain a directory of procedural elements. • Manage the procedural element change process, including performing a thorough review of the effects of the change.

6.3 Production Planning and Scheduling This activity is one that SP88 knew contained mostly business functions, which are outside the scope of the standard. Still, the process cell must receive direction concerning what to make and approximately when (or what order) to make it. The required function for this activity is to take business direction and turn it into a locally based schedule that is influenced by conditions within the process cell. 88.01 calls this function “develop batch schedules.” This activity must be able to tell Process Management the identification of the recipe to be run next, possibly with exact timing, specific equipment, and any permitted variants or special condition for the specific batch in question. The schedule item is specific to a particular batch in the same way that the master recipe is specific to a particular product. Given the recipe identification, Process Management can request the master recipe, determine when it will have the required equipment entities and materials to start, and specify quantities based on batch size. This information goes into building the control recipe. Scheduling provides the information required by Process Management to know what to do next. It contains at least one function—develop batch schedules. The capabilities associated with this function are as follows: • Develop a local, short time horizon schedule from business direction using scheduling algorithms. • Develop a new schedule on demand if local conditions change. • Allow manual corrections to the schedule. • Determine the availability of suitable resources for the foreseeable future. • Schedule one lot of material by determining the proper size of consecutive batches. • Evaluate the feasibility of the schedule each time the environment changes. • Transmit schedules in a standard manner, with standard error messages. The interoperable function of production planning and scheduling is to deliver a schedule to Process Management when a new schedule is received from above. 88.00.02 contains a first attempt at defining the process of passing a schedule from one system to another. Again, it relies on SQL to make the translations work. It does not define the command/response set necessary to control the flow of schedules. A specific interoperability standard is still required if the scheduling activity is to be separable from the Process Management activity.

batch chap 11.qxd

4/25/2006

2:45 PM

Page 181

88 Control Activities and Functions, Part 1

181

6.4 Production Information Management This activity also contains business functions that are outside the scope of the standard. SP88 felt that something was required within Operations/Manufacturing that would store information required for reference by other production activities. Also, something had to condense the stream of real-time events and readings into information that was more suited to the business activities. SP88 had experts who knew what kinds of data were generated by a batch process cell and what kinds of reports had to be printed, but did not know enough about how they would be used outside of the manufacturing environment. We settled on a function called “Manage batch history.” Batch history and reporting is the subject of Part 4 of 88. Present thinking is that capturing and reporting are two different activities because so many reports can be generated from the same captured data. What follows may be changed by 88.00.04 when it is published. Perhaps it will address interoperable data export and its control messages. Batch history is defined in 88.01 as a set of data related to a specific batch. The process sends a continuous stream of data and events that could be recorded raw. A good deal of work would be required to extract the data for a specific batch, but it could be done if someone had an idea of where to start looking. Extracting the history of one batch is easier if an arrangement has been made to assign a key, like the batch ID, to each event. The events can provide the time information needed to locate and extract a set of continuous trend data that is specific to a batch. The following list contains a few examples of events: Received new schedule Delivered master recipe Created control recipe Finished control recipe follows Unresolved equipment conflict Insufficient resources, OK? Received unit recipe Started/Ended Ignition Operation Valve in wrong position, holding High pressure alarm occurred/cleared Operator comment follows 88.01 says that the “manage batch history” function has three capabilities: • Receive and store information. • Manipulate stored data.

batch chap 11.qxd

4/25/2006

2:45 PM

182

Page 182

Chapter 11

• Produce batch reports. These capabilities are detailed below.

6.4.1 Receiving and Storing Batch History Information Information is collected by the Process Management, Unit Supervision, and Process Control activities, which send their information to the Production Information Management activity. This capability receives those messages. Interoperability may be useful here, and could be provided by OPC or a capable fieldbus system. The following headings refer to the received data. Storage is done under the general rules of Information Handling (6.1.2) except as noted.

General collection and storage guidelines The received data should have some key information attached to it. This capability should add a key if it is missing. Examples of keys follow: • Batch identification • Time of day stamp (made as close to the source as possible) • Identification of procedural element that caused the event to happen • Time relative to the start of the batch or the start of an identified procedural element • Identification of the person that entered data if it was not done by a tagged equipment entity • The tag of the equipment entity that generated the event There must be adequate storage capacity to allow archiving of complete batch histories after residing in local storage for an adequate time. Batch histories should not cross archive boundaries. The archive may be a larger storage function in the business data systems rather than a locked safe in a basement somewhere. The batch data will be archived eventually, and kept until everyone who might have had an interest in the batch has died. People will want to know what is in local storage and what is in remote storage. This requires a directory of batches and their status, including in-progress, complete (and local), remote, and archived. There may also be a directory of batch reports and their status. People will want to know what is going on now. This requires a display (or web page) that can answer frequent status queries. This is not mentioned in 88.01, but it seems to be a logical use of a historian. Then again, the function may be done by the control system.

batch chap 11.qxd

4/25/2006

2:45 PM

Page 183

88 Control Activities and Functions, Part 1

183

Reliability of batch history entries The following is a list of things to consider when designing a batch history receiver: • Access control – The degree of security of the receiver’s configuration and of the received data (secure connection). • Audit trail – A log of any changes to any data, who made them, when, and why. • Logging reliability – A specification for the relative need to capture all related data (see note below). • Level of detail – A filter for incoming messages that may toss some messages without recording them. • Logging actual data – Saving data from the process instruments instead of the recipe requirement. • Long-term consistency – Refers to the problem of locating all historical information relevant to a batch. • Speed of collection – Largely a bandwidth issue now; not a problem if time stamped at the source. Note that 88.01 lists three levels of reliability/availability of data: 1. No specific action taken if data is lost. 2. Loss of data is tolerated if the period of the loss can be logged. 3. Loss of data is not tolerated. If a few retries don’t work then the process is held and fixed or the product is lost. Any communication system can lose data. A parameter called Quality of Service may be set to determine how much loss is acceptable. A specified number of retries may be attempted in secure communication. Then there is the problem of the sender not putting any messages into the transmission queue. The receiver has to have a way to know that the sender is alive if the messages are generated at random times. The receiver cannot tell if a message has been missed unless sequence numbers for the messages are used. It is possible for the receiver to tell Process Management to hold or stop the batch if the quality of communication is too low. Hold is useful if a welder causes a temporary problem.

Batch and material tracing If the data collected includes a specification of the units and materials used to make a batch then the history of a batch can be traced (or tracked) through its lifetime in production. Backward tracing starts at the end product and identifies every batch and raw material that went into making that product. Forward tracing follows a material from its source through all of the batches that used the material or any part of a batch that used the material. Forward tracing is used to track a contaminated material, as

batch chap 11.qxd

4/25/2006

184

2:45 PM

Page 184

Chapter 11

E. coli contamination is traced from a ground beef supply to each store that sold it. Backward tracing is the first step in determining why a batch is off specification or why a customer is upset about some property of the batch that was not specified.

Logging from Process Management Process Management should send messages to History that log the use of master recipes, the assignment of equipment entities, the creation and modification of control recipes, the batch start and end times, the schedule modifications, and so on. Operator comments with operator ID and time should also be logged. The control recipe becomes fragmented into unit procedures during batch processing. The historian must receive enough information from the units to be able to reconstruct the control recipe.

Logging from Unit Supervision and Process Control It is best to record everything and sort it out later. Operating experience will determine what makes sense. Information may come from a common resource equipment entity. If it is an exclusive-use common resource then its data should carry the batch ID of the batch in the unit that has acquired it. If it is a shared-use common resource then messages from the resource must be duplicated as many times as there are users. Each message must have the batch ID of one of the users. Common resources that are not owned by anybody at the time may report events without a batch ID. Pre-specified batch data is data that is specified to be logged during execution of a control recipe, in addition to the events generated by equipment entities. Specification may come from the recipe or be configured somehow. If the method for specifying data to be logged in a recipe is not standardized then it will become a recipe-system interoperability issue. Pre-configuration should be done in the configuration of the collector. It is not clear that this concept includes changes while the recipe is running. All events should be logged, whether unpredictable or predictable. An event message is a message that describes the change of state of an alarm or the occurrence of an event. An event message should contain the following: • Time stamp • Batch ID • Identification of source, usually a tag name • A description of the source in 32 characters or less (optional, can be added later) • Priority for ranking alarms and events (optional, but most users want it) • Description of alarm: high critical, high advisory, low advisory or low critical, or event text

batch chap 11.qxd

4/25/2006

2:45 PM

Page 185

88 Control Activities and Functions, Part 1

185

• Alarm limit that was exceeded (not used for event messages) • Current value of parameter that caused the alarm • Type of event: occur, clear, acknowledge, or event Information like maximum deviation or trending must be added by a post-processor somewhere that digests the alert messages into a single summary of the events, from occur to clear. It may be a problem to capture the operator entry that acknowledges the alarm because the source of the Occur and Clear messages is normally unaware of operator acknowledgment. Post processing may find the Acknowledge message from some human interface and append it to the summary.

Late entries An operator, lab technician, or analyzer may enter data that is not real-time, in the sense that a sample valve event may be real-time but the logging of the sample taken and the result of the analysis are entered later, perhaps hours later. It is necessary to have fields in the messages that tie a message back to the real-time event that started the process that takes a while to complete. The field examples shown in Section 6.4.1.6 represent a summary of two messages, one from the operator and the other from the lab technician at a later time.

6.4.2 Manipulating Historical Data Speaking of late entries, sometimes a mistake in entered data must be corrected. If regulations do not permit alterations to logged data, then the mistake and the correct value must be logged with enough information to tie it back to the correct batch. Other manipulations of historical data may be done, by computing new data from the existing data and adding it to the history. Perhaps data like yield and cost per unit mass should be calculated in real-time as a way for the operator to measure improvement. Any calculation may be made and appended to the record. The thing that does the calculation is probably a part of the system that implements the Production Information Management activity. Calculation would require additional configuration by the user. Another form of computation provides data reduction or compression. Standard or widely used algorithms for compressing trend data, like boxcar compression, are available. The user must configure the minimum amount of change in the value that will trigger a recording, as well as the maximum amount of time without a change that will trigger a recording. No disk space will be consumed as long as the trend stays within the configured boxcar of value and time. Reducing the volume of data may also be done at the source if a recipe procedural element is able to switch recording on and off. If that is done, the historian should still capture all events and trends as equipment entity related data. This data may be required to trace a failure in processing a batch that was not anticipated by the recipe author.

batch chap 11.qxd

4/25/2006

2:45 PM

Page 186

186

Chapter 11

The data required in order to trace or track material or batches should be entered automatically. If it is not, then it should be possible for a person to enter that data. If that is not possible, then a person must be able to log the disposition of each batch, including splits to other batches. Perhaps the system records the transfer of each batch to a storage tank or shipping terminal and records the source of batch materials by storage tank but does not tie the source batch ID to what is in the tank. If you blend batches in a storage tank then you may use a lot ID or you don’t really care. A late entry is required to make the association between the batch that produced an intermediate material and its use by subsequent batches. It would be best to fix the system so that this entry is automatic.

6.4.3 Producing Batch Reports You cannot produce a batch report from equipment entity data unless that data is keyed to a batch ID. The rest of the batch report section of 88.01 is subject to change by 88.00.04.

Summary This chapter has discussed the control activity model and the control activities named Recipe Management, Production Planning and Scheduling, and Production Information Management. The other four activities are discussed in the next chapter. Common aspects of information handling were presented. Process and control engineering were discussed as they relate to designing recipe building blocks and equipment entities. Recipe Management functions were discussed, from General to Master recipe creation, with the emphasis on delivering a master recipe to Process Management. Production Planning and Scheduling functions were discussed with emphasis on delivering a schedule to Process Management. Production Information Management functions were discussed in great detail, including collection guidelines, reliability, tracking, logging, and manipulating historical data.

batch chap 12.qxd

4/25/2006

2:48 PM

Page 187

Chapter 12

88 Control Activities and Functions, Part 2 This chapter continues and concludes the discussion of batch control activities and their functions that we began in Chapter 11. The control activities in this chapter are directly related to batch operations/manufacturing. What follows focuses on one part of batch manufacturing, specifically the batch process cell. The control activities that contain business functions were described in the previous chapter. Recipe Management delivers a copy of a master recipe to Process Management on request. Production Planning and Scheduling delivers a schedule to Process Management when a new schedule is generated. Production Information Management collects information from the process activities and makes it available to both business and manufacturing. See Figure11-1 for the relationships of activities. The following activities are covered in this chapter: • Process Management – Coordinates the batch process functions of the process cell. • Unit Supervision – Supervises unit functions and executes unit recipes. • Process Control – Operates the equipment and control modules. • Personnel and Environmental Protection – Provides separate control actions to keep bad things from happening.

6.5 Process Management This is the activity that controls batch production by translating the schedule information into commands and information that can be understood by the Unit Supervision activity. A copy of the master recipe specified by the schedule is obtained and converted to a control recipe. Equipment is selected and assigned to the scheduled batch. The batch is initiated at the specified time (or right away) in the first and succeeding units. Information from batch operation and equipment status is collected and passed to a historian. See Figure12-1 (similar to Figure22 in ANSI/ISA-88.01) for a graphic presentation of the Process Management control activity. One process management control activity controls one process cell. The span of control is all active batches and all active or idle equipment entities within the cell. A batch is active from the time that a control recipe is created until it is completed or fails.

batch chap 12.qxd

4/25/2006

2:48 PM

Page 188

188

Chapter 12

Figure 12-1 Process Management The control recipe ends when a normal batch leaves the cell or goes into storage as an intermediate product. 88.01 does not discuss storage as part of a cell or even as an equipment entity. It is not uncommon in chemical batch processing to use a reactor to make an intermediate, store it locally, and then use some of the intermediate in following reactions as an efficient use of resources. The problem with intermediate storage within the cell is that a unit is the only equipment entity that may contain all or part of a batch, with the understanding that process functions will be applied to the batch as directed by a recipe. A storage tank may hold a batch, but there is no control that is directed by a recipe. It does not appear to be either a unit or an equipment module, but is closer to a unit. Equipment entities are monitored more than they are controlled because the main concern with equipment entities at this level is availability. A batch can’t be started or transferred to another unit if everything is busy or something is broken. All equipment entities contain control functionality to monitor their integrity, independent of any recipe-directed activity. Not all flaws in integrity may be detectable, so human judgment is still required, even though humans are unable to detect all flaws in their own integrity.

batch chap 12.qxd

4/25/2006

2:48 PM

Page 189

88 Control Activities and Functions, Part 2

189

There is no control activity in 88.01 that coordinates process cells, should that be necessary. Process Management can be decomposed into a zillion functions, but we’ll start with the top three: • Manage Batches - Create control recipes and distribute them to units, initiate batches. • Manage Process Cell Resources - Handle the schedule, monitor resources, allocate and arbitrate assignments. • Collect Batch and Process Cell Information - Produce information for the historian.

6.5.1 Manage Batches This is the control function that prepares control and unit recipes. At the proper time, Manage Batches gives a unit recipe to a unit and starts it. This function keeps track of unit recipe progress and reports the general status of batches in progress to Manage Process Cell Resources. True, 88.01 does not discuss unit recipes in Section 5, but they are defined in Section 3.62 as follows: “The part of a control recipe that uniquely defines the contiguous production requirements for a unit. Note - The unit recipe contains the unit procedure and its related formula, header, equipment requirements, and other information.” A unit recipe is required if the unit is to have all of the information that it needs for independent operation, in the true sense of distributed control. The following list of capabilities is not a requirement specification but a way to define and assign terms to functions that may be found in available control systems. This statement is true for all such lists for control activities. There are no interface standards for these activities, so they are abstracts of what may exist in vendor’s offerings or user’s internal designs. Typical capabilities for Manage Batches: — Receive schedule information for the next batch. Request and receive a copy of the required master recipe. Add header information to the copied master recipe, which will become the control recipe. Gather and add the information necessary to make the control recipe unique, such as schedule, inventory, and analytical data. If operator intervention is required, present the control recipe on an HMI display and accept certain changes. The timing of these tasks is not important, but they must be done before the batch can be started. It may be possible to accept changes as the batch progresses, provided that the changed item has not been executed yet. Indeed, the control recipe may be incomplete at the start of the batch and created

batch chap 12.qxd

190

4/25/2006

2:48 PM

Page 190

Chapter 12

incrementally, as information becomes available. An example of this is a unit recipe that finishes with a transfer to any unit that is available at the time. — Assign a unique identifier to each control recipe, so that all control recipes are unique. The identifier may be a composite of enterprise, facility, and cell identifiers plus a serial number. Only the serial number may be necessary within the cell. The customer may require a different identification, which must also become a part of the control recipe. Customer identification would probably come from the schedule. A cell serial number could be provided by Manage Batches. There must not be a duplicate serial number in any other control recipe during the life of the cell. The thing called a Batch ID may be either the unique ID or the customer ID. — Verify that the control recipe (what there is of it) can be executed. Verify that all of each unit recipe can be executed before passing it to the unit for execution. There must not be any run-time errors due to missing equipment procedural elements, missing or abnormal formula values, unavailable equipment entities, or unavailable operators. — If the formula contains normalized values, then obtain the required batch size and calculate the actual values, replacing the normalized values. The batch size normally comes from the schedule but may be an operator entry. In either case, the size must be checked to see that it is within the range that the recipe can process. It is possible for the schedule to specify a large size and let Process Management figure out how many batches to make to fulfill the requirement. — Manage Batches must keep track of all of the control recipes for batches that have been started. The recipe passes out of Process Management and into history when there is nothing left to do in the procedure. Hopefully, the batch of material has been stored by this time. — Each unit recipe has to be started, but when? The combination of a sophisticated scheduler and a process cell that has no random problems may allow the schedule to set the start time. More likely, the schedule specifies the order to start batches, and the availability of units determines when to start the next batch. Availability may mean the first available unit, or it may require allocation/reservation of all units required by the control recipe. A batch may wait on the availability of materials or utilities. The decision to start may be made by an operator, perhaps based on observation of things that can not be measured. 88.01 mentions the effect of priority on the start time. Manage Batches has no control over priority, so Manage Process Cell Resources must send schedule items to it in priority order. — Some batch processes may want to allow an operator to modify the recipe based on something that just happened, due to lack of reliability or process knowledge. This requires a set of HMI displays that let the operator change the operating mode to manual and make modifications where possible. A number of tests must be passed

batch chap 12.qxd

4/25/2006

2:48 PM

Page 191

88 Control Activities and Functions, Part 2

191

before a modification is actually made to a control recipe. The first test is that the past is immutable, so only future changes may be made. There may be restrictions on adding or deleting procedural elements, which must be specified by the recipe unless it is possible to make general rules. All of this has to be thought out carefully, as carefully as exception handling. There will be opportunities for misunderstanding that will make the solution worse than the problem unless there is adequate training for all exceptions. Modification may require reaching into a unit to modify its recipe. — 88.01 says that Manage Batches may request and release equipment entities. This is done by asking Manage Process Cell Resources to allocate/reserve the equipment and then report back when the equipment is released (if Manage Resources hasn’t already got that information). — Monitor and control the recipes in progress in order to maintain a summary of their current status. 88 says “controlling” the recipes, but most of the procedural control is done in the units, not Manage Batches. Units may request coordination control from Manage Batches if they are not able to do it themselves. The control done by Manage Batches consists mostly of timing the initiation of unit recipes. — Process requests for state and mode changes. 88 says the changes will be made to procedural elements. Perhaps your philosophy says that a recipe is either fully automated or it is fully manual. In that case you would want a single mode and state for all procedural control associated with a recipe. The 88 method requires an independent mode and state for each procedural controller in Manage Batches, units and equipment modules, but they can be tied together. — Allow a control recipe to span multiple units in the same cell. This is done by distributing unit recipes in a timely manner and starting units as required, based on information in the control recipe. — Allow a batch to be temporarily removed from production and returned at a later time. This assumes that the chemistry of the batch will permit such an interruption. This may be done because emergency maintenance is required or because a higher priority batch has bumped it out of production. Execution of the control recipe is suspended while the batch is not in production. This requires some highclass exception handling, if it is automated. — Maintain batch status information in a way that lets the final, actual control recipe be recorded either during processing or after it is all over. The actual control recipe, not the planned version, must be passed to the historian. — Send all information, no matter how trivial, to the Collect Batch and Process Cell Information function. The information consists entirely of events and control recipes.

batch chap 12.qxd

192

4/25/2006

2:48 PM

Page 192

Chapter 12

6.5.2 Manage Process Cell Resources Manage Batches is mostly concerned with batch production and recipes. Manage Process Cell Resources is mostly concerned with providing resources to Manage Batches and keeping track of unallocated resources. Resources are units and common equipment within the cell, materials stored within the cell or available to the cell, storage facilities within the cell, available storage outside the cell, and the personnel required to make batches. Equipment, materials, storage, and personnel are all subject to allocation to a batch, perhaps as a percentage of a resource that can be shared. The process of allocation starts when a schedule is created. The schedule contains a number of items representing the batches to be made, out to the time horizon of the scheduler. A schedule item may request specific equipment, materials, and/or storage. It is possible that specific people would be requested. A truly flexible batch system would be able to take schedule items that did not specify allocations. If you have a new system to design, consider the cost of a local self-scheduling algorithm for the process cell versus the cost of managing the schedule at the area level. If local scheduling is used then schedule management can focus on the business requirements for shipments. Process cells would be chosen based on sufficient quantities of available materials and equipment. Local scheduling can shield schedule management from short-term variations in local equipment availability, if the cell is designed for it. If we were talking about hotels, the incoming schedule would be a list of clients from a travel agent. Each client requires variations of bed, view, and smoke. The clients have been sorted by hotel. The hotel reservations clerk assigns rooms according to client requests, as a local schedule of occupancy. Various things can happen that may require a client to be assigned to a different room (or hotel) when the client arrives. Manage Process Cell Resources presents schedule items to Manage Batches with enough lead-time to prepare a control recipe for each item. The schedule items do include resource allocations or reservations because there is no point to sending a batch to Manage Batches that can’t be started. Some batch processes allow resource selection at the time that the resource is needed and not before. If Production Planning and Scheduling assigns resources, then Manage Process Cell Resources must be one of many activities that report changes in allocations/reservations back to Planning and Scheduling. During operation, Manage Batches may discover a resource conflict that it can’t resolve. Manage Process Cell Resources must be requested to solve the problem with a different allocation, which may have to be resolved by an operator with the appropriate displays and control handles.

batch chap 12.qxd

4/25/2006

2:48 PM

Page 193

88 Control Activities and Functions, Part 2

193

Typical capabilities for Manage Process Cell Resources: — Receive schedule information from Production Planning and Scheduling. Process the batches, requirements, and priorities into a detailed local schedule. The local schedule may require resource allocations. Send local schedule items to Manage Batches in a timely manner, not all at once. Perhaps Manage Batches will request the next item when it is ready to create another control recipe. — Respond to requests from Manage Batches to allocate or reserve resources if everything was not done during the scheduling process or if something wasn’t available when needed. This capability may be called upon to set up transfer routing if the units can’t do that. — Arbitrate multiple requests for the same resource. Simple algorithms for arbitration include queued order of request, reservation time, and batch priority. More complex algorithms may minimize cleaning requirements, minimize energy consumption, or maximize throughput. The final arbitrator may be human, so a useful human interface is required. An example from air travel is the case of two people who have the same seat assignment. A flight attendant has to resolve the conflict by finding a seat for the second claimant. — Monitor process cell resources that are not currently in use. If equipment is down for maintenance or material is not available then try to predict when it will be available so that future use may be scheduled. Maintain a status display for resources. — Receive resource status information from the Unit Supervision control activity. — Send status change information to the Collect Batch and Process Cell Information function of Process Management. — Send information relevant to the scheduling activity up to Production Planning and Scheduling, as required by the type of scheduling. The scheduler may obtain other information from Production Information Management.

6.5.3 Collect Batch and Process Cell Information This control function passes data from Manage Batches and Manage Resources to Production Information Management. There may be some data processing, but most of that should happen in the generating function. This function may generate displays of the status of process cell resources, updating the display with each change notification. This function may display completed control recipes that are no longer in the Manage Batches function. 88.01 lists the following examples of information: • Mode and state changes

batch chap 12.qxd

4/25/2006

2:48 PM

Page 194

194

Chapter 12

• An incremental copy of a control recipe as each portion is finished • Commands sent to Unit Supervision, with timestamp • Time that a unit recipe was sent to Unit Supervision • Time lost due to unavailable resources • Time of allocation, reservation and release of resources • Requests and responses for resources that required arbitration • Status changes in unallocated resources • Operator intervention, with times and operator’s explanation

6.6 Unit Supervision The main function of this control activity is to process unit recipes from Process Management into commands for Process Control. In other words, this activity executes unit recipes. A unit may need to change its configuration while executing a recipe, perhaps by acquiring and releasing common equipment. The associated details are handled by the Manage Unit Resources function. The third function controls the flow of data to Production Information Management. There is one Unit Supervision activity per unit. See Figure 12-2 (based on Figure 23 in 88.01) for a block diagram of this activity.

Figure 12-2 Unit Supervision

batch chap 12.qxd

4/25/2006

2:48 PM

Page 195

88 Control Activities and Functions, Part 2

195

6.6.1 Acquire and Execute Procedural Elements This function performs Procedural Control at the unit equipment entity level by executing a unit recipe. The recipe contains the required unit resources, which have been checked by the Manage Unit Resources function. The recipe also contains the required procedural elements that will cause processing to occur, along with the order in which to initiate each element. If this activity is not automated then the operator acquires and executes procedural elements. Note that “execute procedural elements” refers to recipe procedural elements. Equipment procedural elements are executed by the Process Control activity. Procedural Control reads the recipe procedure to find the first procedural element, which must be a unit procedure. The unit procedure either contains recipe operations and phases or it matches an equipment unit procedure for this unit. If there is an equipment unit procedure, then this function transfers parameters from the recipe to the equipment unit procedure and initiates it. Otherwise, this function looks for the first operation in the recipe procedure. If this function finds a recipe operation, then the operation either contains recipe phases or it matches an equipment operation for this unit. If there is an equipment operation, then this function transfers parameters from the recipe to the equipment operation and initiates it. Otherwise, this function looks for the first phase in the recipe procedure. Procedural Control reads the sequencing information in the recipe to see if there is more than one phase to start. At this point, there must be at least one phase to execute. This function transfers parameters from the recipe to each eligible equipment phase and initiates one or more phases. A recipe procedural element makes process functions happen by sending commands and data to Process Control that will cause the corresponding equipment procedural element to be executed. A series of commands may be sent at about the same time if several phases start in parallel. In general, Procedural Control waits for a return status after sending a command and before sending the next command. When the last element has been executed then this function notifies the other functions that it has completed the unit recipe. An equipment procedural element makes process functions happen by sending commands to Process Control. In general, an element waits for a return status after sending a command and before sending the next command. A series of commands may be sent at about the same time if several phases start in parallel. Once one or more equipment procedural elements have been started, this function executes the equipment procedure(s) to completion. If a phase was executed in an equipment module then it must signal completion. Then this function goes back to the

batch chap 12.qxd

4/25/2006

2:48 PM

Page 196

196

Chapter 12

recipe to find the next element to execute. When the last element has been executed then this function notifies the other functions that it has completed the unit recipe. Completion does not necessarily mean success. The returned status may require exception handling. The unit will have a selection of exception handling routines. Some routines can handle exceptions while a procedural element is running. Others are started based on the returned status. Some exception handling must be done by an operator. An equipment procedural element may require the acquisition of a resource that is outside of the unit. Acquisition must occur before the procedural element can be started. This may be done by asking Manage Unit Resources to obtain exclusive or shared use of an external resource. The external resource must be released when it is no longer required. If an operator may modify a recipe, then this Acquire and Execute Procedural Elements function must provide a display to allow the modifications to be entered, as well as placing limits on what can be entered. Any changes must be sent to Manage Batches so that the control recipe may be updated. This function should generate information about the start and end of procedural elements, the acquisition and release of resources (with any waiting time), as well as the status changes within procedural control. The following examples of capabilities may be included in this control function: • Determine which procedural elements are to be executed. • Verify that corresponding equipment procedural elements exist in this unit. • Execute the unit recipe procedural elements. • Determine when an equipment procedural element is required. • Parameterize and initiate equipment procedural elements. • Determine when an equipment procedural element is done. • Send all procedural control information to Collect Batch and Unit Information.

6.6.2 Manage Unit Resources This control function mostly monitors the functionality of the resources that it owns permanently. A unit operates relatively independently of other equipment entities. It may be necessary, from time to time, for a unit to acquire an external resource. This requires coordination control. The coordination may be direct from the unit, but more likely will involve Process Management, because it monitors and controls the use of resources within the process cell. It all depends on the required complexity of coordination.

batch chap 12.qxd

4/25/2006

2:48 PM

Page 197

88 Control Activities and Functions, Part 2

197

Procedural control may ask Manage Unit Resources to acquire a resource, either as a result of recipe information or because an equipment procedural element was executed. This function may negotiate with other resources or it may request the resource from the Process Management control activity. If the negotiation or the response is successful then the procedural element may be started. That element and following elements may send requests to the acquired resource to perform one or more tasks. If this function negotiates directly with other resources, it may fail to acquire any resource. This function may request that it be added to the queue for the requested resource, if it has a queue. This function may turn to Process Management for arbitration. The result may be that this function must wait until it receives a successful response. Eventually, some procedural element declares that it is done with the acquired resource and releases it. Another possibility is that the acquired resource declares that it has finished the requested task. Either way, Process Management must be notified that the resource is now available. The Acquire and Execute Procedural Elements function must know that it can no longer send requests or commands to the formerly acquired resource. Acquisition of a resource assumes that the resource is not doing anything at the time. Otherwise, the resource prevents acquisition by declaring that it is busy. When two units coordinate for a transfer, they are both busy. 88.01 states in this section that “Although units cannot acquire other units, they can request services from or provide services to another unit as long as the recipe has specified compatible procedural logic for both units.” The key to a transfer is that both units are running unit recipes from the same control recipe with the same batch ID. Coordination should be handled through Process Management. Each unit may tell Manage Batches that it is ready to send or receive the transfer. When both units are ready, Manage Batches may tell them both to start the transfer. The end of the transfer must be similarly coordinated. Note that this is not a requirement but an example of how to coordinate a transfer. There are processes that manage transfers by other means, perhaps with a control activity called Transfer Management. If an operator can make changes to the status of unit resources, including acquired resources, then a display must be provided that makes those changes possible. Again, Process Management must be notified of any changes. This function should generate information about the acquisition and release of resources (with any waiting time), the use of arbitration, any transfer coordination, and status changes within the unit.

batch chap 12.qxd

4/25/2006

2:48 PM

Page 198

198

Chapter 12

This function may have the following capabilities: • Initiating coordination control to acquire and release a resource. • Initiating coordination control to start and stop a transfer between units. • React to mode and state changes for Procedural Control. • Assure that information from an acquired resource is associated with this batch. • Send all information on unit resources to Collect Batch and Unit Information.

6.6.3 Collect Batch and Unit Information This control function passes data from procedural control and Manage Resources to Production Information Management. Again, “collect” is probably inaccurate. This function may generate displays of the status of unit resources, updating the display with each change notification. This function may display the unit recipe that is in progress. Different levels of detail may be required for different batches. For example, an experimental batch requires every detail, while a production batch may not need so much detail. This function may have to handle conditional data. The conditions may be based on recipe data or on a verbose/summary switch set by the operator. The following are examples of collected information: • Mode and state changes • Timing of the execution of procedural control elements, both start and end • Values derived during execution of elements • Commands sent to Process Control, with timestamp • Details of acquisition and release of resources • Details of transfer coordination • Time lost due to unavailable resources • Status changes

6.7 Process Control The main function of this control activity is to perform the control that will cause processing functions to be carried out on the batch. This is the only control activity that actually touches the process. Two functions are used to provide control. Execute Equipment Phases is procedural control that performs the steps that make up the phase, with no capability to execute a partial recipe. Execute Basic Control does the regulatory, discrete, sequential, interlocking control and monitoring required by equipment procedural elements. The Collect Data function controls the flow of data to Production Information Management. There is one Process Control activity per

batch chap 12.qxd

4/25/2006

2:48 PM

Page 199

88 Control Activities and Functions, Part 2

199

unit, distributed throughout its owned equipment entities. This does not mean that there is only one controller for the unit. See Figure 12-3 (based on Figure 24 in 88.01), for a block diagram of this activity.

Figure 12-3 Process Control

6.7.1 Execute Equipment Phases This function executes equipment phases in equipment modules, if there are any. Usually an equipment module contains common equipment entities that have their own Process Control activity with a function to Execute Equipment Phases. It is generally not useful to start an equipment phase without first sending it some parameter values. Some communication system is required to handle the exchange of information with common equipment. This function may require a display to show the progress through the steps of a phase. The display may also have to allow operator intervention, if that is permitted. Only one phase may execute at a time, but each step may have an ordered set of sub-steps. Possibly each sub-step may have an ordered set of sub-sub-steps but two levels seems to be enough. This function handles the propagation of modes and states. In particular, an interlock may cause other control modules to change mode or state. This condition may need

batch chap 12.qxd

4/25/2006

2:48 PM

Page 200

200

Chapter 12

to be propagated to the state of procedural control. See the discussion of this subject in Chapter 14. This function may generate data from the execution of a phase and other things.

6.7.2 Execute Basic Control Basic control does not execute so much as it evaluates an algorithm from time to time. This function receives commands from the execution of procedural control elements or by manual intervention. The commands may be generic, requiring translation for the target equipment entity. This function sends commands to change such things as the mode and setpoint of one or more control modules. Usually, a command causes a control module to do something different to the process. Each command requires a response that tells of the success or failure of the command. If there is a failure or an alarm is generated later, then this activity may use logic or rules configured for simple equipment exception handling. For example, if a valve fails to confirm in position then send a request to Unit Supervision to set the Holding state for unit procedure control. 88.01 says, “Some other basic control functions that may be included are exception handling, calculations and treatment of operator-entered information, etc.” Unfortunately, these concepts are not expanded. All three may reach a level of complexity that is beyond the scope of Basic Control. 88.01 says, “Equipment entities capable of performing this control function are control modules, equipment modules and units.” This may be misleading. The only way to manipulate the process is through basic control in control modules. No other equipment entity has direct access to the process through sensors and actuators. The other entities may have some form of basic control (see 5.2.2) but not the kind that touches the process. Perhaps a new category, like Auxiliary Processing, could handle recipe-generated requests for things that aren’t process control, like running a calculation or prompting an operator for input. This function handles the propagation of modes and states. See the discussion of this subject in Chapter 14. If this function is part of a common equipment entity, it must be able to participate in the acquire/release dialogs as the server, not the client. Queue management may be required if the entity supports queued requests. If a queue exists then arbitration by Process Management should be able to shuffle the entries. This is simple coordination control, not basic control. This function may generate data from the exchange of commands and status with control modules and other things.

batch chap 12.qxd

4/25/2006

2:48 PM

Page 201

88 Control Activities and Functions, Part 2

201

6.7.3 Collect Data This control activity does not so much collect data as it receives data generated by control modules and equipment modules that are owned or acquired by the unit. This data may come from sources that have no knowledge of the batch being processed. As a result, batch identification has to be added to all such data before it goes to Production Information Management. Data collection may be conditional, as described in 6.6.3. Some data may be processed or calculated by algorithms known only to Collect Data. Analog data may be compressed, and it may be summarized or filed as blocks of data associated with each batch.

6.8 Personnel and Environmental Protection This control activity prevents detectable conditions from developing into a safety hazard or an actual release of harmful energy or material. This activity is commonly implemented by a safety or shutdown system. This activity is shown at the bottom of Figure12-3. Below it is the controlled process. The shutdown system is a separate system, with its own sensors and actuators, and is engineered in a separate environment. Shutdown actuators are normally solenoid valves that must be energized in order to apply pneumatic power to big, expensive valves. When the shutdown system removes air from the solenoid valve, the big valve is vented so that it goes to its “fail-safe” or no air position. Continuous plants have shutdown systems that have no input from or output to the control system. Batch control has to tell the shutdown logic about each change in configuration or operating point that is caused by procedural control. The shutdown system has to tell procedural control that it has shut something down, so that further batch execution will stop. A complete discussion of personnel and environmental protection is outside the scope of 88.01.

Summary This chapter has discussed the four remaining Control Activities, named Process Management, Unit Supervision, Process Control, and Personnel and Environmental Protection. The first three of these activities are the heart of batch control. Protection may be necessary, but the art of designing protection systems is quite different from designing batch control systems. Process Management receives batch schedules and requests master recipes. It creates control recipes and coordinates the assignment of unit recipes to units. Unit Supervision maintains the unit in readiness and executes unit recipes as they are received.

batch chap 12.qxd

202

4/25/2006

2:48 PM

Page 202

Chapter 12

It exchanges commands and status with Process Control. Process Control sends commands to and receives status from equipment entities and may execute phases. It abstractly encompasses all process control functions in the equipment entities of one unit.

batch chap 13.qxd

4/25/2006

3:15 PM

Page 203

Chapter 13

88 Definitions This chapter will discuss the definitions listed in ANSI/ISA-88.01. They appear here after the models, concepts, and activities have been discussed because that is the way that SP88 did definitions. After trying definitions first a few times, SP88 decided to do them last, in order to improve productivity. It was no good arguing about a definition when the concept that it defined had not reached consensus. You will find that some of the definitions assume that you know the underlying concept. Sadly, this is what happens when the definitions are done just before publishing. Life is full of trade-offs. The numbered definitions and their notes are from Section 3 in 88.01. The 88.01 words are enclosed in quotes. The next paragraph contains added references to sections of 88.01 that affect the definition, perhaps by describing another property of the thing being defined. The paragraphs following that contain commentary on the preceding definition.

3 Definitions 3.1

allocation: “A form of coordination control that assigns a resource to a batch or unit.” NOTE — “An allocation can be for the entire resource or for portions of a resource.”

Reference: 5.6 Allocation also marks the allocated item as being in use, whether it is actually in use or will be used later. The note refers to resources that have the capacity to serve more than one unit at a time, such as a hot water heater. Partial allocation is possible for a shared-use common resource or for the contents of a storage facility. 3.2

arbitration: “A form of coordination control that determines how a resource should be allocated when there are more requests for the resource than can be accommodated at one time.”

Reference: 5.6.2 This is a concise statement that covers some very complex options. It implies a waiting queue, which raises the possibility of re-sorting the queue during operation. If the resource is fully booked then another resource may be chosen.

batch chap 13.qxd

204 3.3

4/25/2006

3:15 PM

Page 204

Chapter 13 area: “A component of a batch manufacturing site that is identified by physical, geographical, or logical segmentation within the site.” NOTE — “An area may contain process cells, units, equipment modules, and control modules.”

Reference: 4.2.3 An area is optional. It is not a process control boundary like a process cell. If it exists, it is bounded by a site. The note restates the physical model, but fails to state that the area must contain at least one unit. 3.4

basic control: “Control that is dedicated to establishing and maintaining a specific state of equipment or process condition.” NOTE — “Basic control may include regulatory control, interlocking, monitoring, exception handling, and discrete or sequential control.”

Reference: 5.1.1, 5.1.2 That is, the process will not change state unless basic control receives a command. Basic control acts on its own to correct the effects of disturbances. The note implies that you may have discrete control or sequential control, but not both. This does not make sense. Interlocking is basic control but exception handling is not. See Chapter 14 on exception handling. 3.5

batch: “1.) The material that is being produced or that has been produced by a single execution of a batch process. 2.) An entity that represents the production of a material at any point in the process.” NOTE — “Batch means both the material made by and during the process and also an entity that represents the production of that material. Batch is used as an abstract contraction of the words ‘the production of a batch.’”

Reference: 4.1 The phrase an entity that represents the production of . . . material refers to an abstraction such as a scheduled batch that hasn’t been started yet. The abstract form is used when something is allocated to a batch or when referring to a batch history. See Chapter 1 for a dissection of this definition. 3.6

batch control: “Control activities and control functions that provide a means to process finite quantities of input materials by subjecting them to an ordered set of processing activities over a finite period of time using one or more pieces of equipment.”

Reference: 5, 6 This definition could have read, “Control activities and control functions that provide a means for controlling a batch process.” See definition 3.7.

batch chap 13.qxd

4/25/2006

3:15 PM

Page 205

88 Definitions 3.7

205

batch process: “A process that leads to the production of finite quantities of material by subjecting quantities of input materials to an ordered set of processing activities over a finite period of time using one or more pieces of equipment.”

Reference: 4 This definition appears in Section 4.1 and 4.1.3 of 88.01. “Finite quantities of material” are differentiated from infinite quantities of material from a continuous process and finite quantities of parts from a discrete process. “Finite period of time” again differentiates it from a continuous process. See Chapter 1 for a discussion of this definition. 3.8

batch schedule: “A list of batches to be produced in a specific process cell.” NOTE — “The batch schedule typically contains such information as what is to be produced, how much is to be produced, when or in what order the batches are to be produced, and what equipment is to be used.”

Reference: 5.4, 6.3 3.9

common resource: “A resource that can provide services to more than one requester.” NOTE — “Common resources are identified as either exclusive-use resources or shared-use resources (3.22 and 3.54).”

Reference: 5.6.1 Yes, but people persist in calling them shared resources when they are actually exclusive-use common resources. See 88.00.02, for instance. When someone uses the term shared resource or common resource, ask them what they mean by that. 3.10

control module: “The lowest level grouping of equipment in the physical model that can carry out basic control.” NOTE — “This term applies to both the physical equipment and the equipment entity.”

Reference: 4.2.7, 5.2.2.4 3.11

control recipe: “A type of recipe which, through its execution, defines the manufacture of a single batch of a specific product.”

Reference: 5.3.1.4, 5.1.3.2.4.4, 5.3.3 Execute means to carry out fully, as a soldier carries out orders. The control recipe defines the set of orders for making a product, but conditions in the process cell define the manufacture of the product. 3.12

coordination control: “A type of control that directs, initiates, and/or modifies the execution of procedural control and the utilization of equipment entities.” Reference: 5.1.3, 5.2.2

batch chap 13.qxd

4/25/2006

206 3.13

3:15 PM

Page 206

Chapter 13 enterprise: “An organization that coordinates the operation of one or more sites.”

Reference: 4.2.1 3.14

equipment control: “The equipment-specific functionality that provides the actual control capability for an equipment entity, including procedural, basic, and coordination control, and that is not part of the recipe.”

Reference: 5.2 3.15

equipment entity: “A collection of physical processing and control equipment and equipment control grouped together to perform a certain control function or set of control functions.”

Reference: 5.2 This definition appears to be incorrect. The phrase “control function or set of control functions” should read “process function or set of process functions” because it is clear from the rest of 88.01 that equipment entities exist to perform process functions. Sadly, neither process function nor process activity is defined, but see the end of this chapter. The section on Control Activities would lead you to believe that functions are parts of activities. A common dictionary says that activities are parts of functions and are associated with life. This is why we need standards to define terms. 3.16

equipment module: “A functional group of equipment that can carry out a finite number of specific minor processing activities.” NOTES “1. An equipment module is typically centered around a piece of process equipment (a weigh tank, a process heater, a scrubber, etc.). This term applies to both the physical equipment and the equipment entity.” “2. Examples of minor process activities are dosing and weighing.”

Reference: 4.2.6, 5.2.2.3, 5.2.3.3, 6.6.1, 6.7.1 3.17

equipment operation: “An operation that is part of equipment control.”

Reference: 5.1.2.3 This is a name, but not much of a definition, for an equipment procedural element. See operation. 3.18

equipment phase: “A phase that is part of equipment control.”

Reference: 5.1.2.4 This is a name, but not much of a definition, for an equipment procedural element. See phase.

batch chap 13.qxd

4/25/2006

3:15 PM

Page 207

88 Definitions 3.19

207

equipment procedure: “A procedure that is part of equipment control.”

Reference: 5.1.2.1 This is a name, but not much of a definition, for an equipment procedural element. See procedure. 3.20

equipment unit procedure: “A unit procedure that is part of equipment control.”

Reference: 5.1.2.2 This is a name, but not much of a definition, for an equipment procedural element. See unit procedure. 3.21

exception handling: “Those functions that deal with plant or process contingencies and other events which occur outside the normal or desired behavior of batch control.”

Reference: 5.8 This definition appears to have too wide a scope. It would include safety systems and basic interlocks, which already have definitions that are widely used. Exception handling in batch control mostly concerns procedural or coordination control. 3.22

exclusive-use resource: “A common resource that only one user can use at any given time.”

Reference: 4.2.6, 5.6.1 3.23

formula: “A category of recipe information that includes process inputs, process parameters, and process outputs.”

Reference: 5.3.2.2 This is not the alchemist’s formula, which can be instantly recognized as a formula by its format. The formula is an abstraction, so that SP88 did not have to specify how process parameters were related to procedural elements. Process inputs and process outputs may appear in a recognizable list because they are useful for making other manufacturing and business decisions. 3.24

general recipe: “A type of recipe that expresses equipment and site independent processing requirements.”

Reference: 5.3.1.1, 5.3.2.4.1, 5.3.4, 6.2.1, 6.2.2 This definition suffers from excess brevity, as do many other definitions. In this case, see 5.3.1.1 in 88.01, where it will be seen that “expresses equipment . . . requirements” means non-specific requirements. For example, requiring a rotating separator but not a Podbielniak 9700 separator.

batch chap 13.qxd

208 3.25

4/25/2006

3:15 PM

Page 208

Chapter 13 header: “Information about the purpose, source and version of the recipe such as recipe and product identification, creator, and issue date.”

Reference: 5.3.2.1 There are other headers for reports or piping. This one implies “recipe header.” 3.26

ID: “A unique identifier for batches, lots, operators, technicians, and raw materials.”

Reference: 6.5.1 The list is not all-inclusive. Perhaps the definition could read, “A contraction of identifier.” 3.27

line; train: “See definition for train.”

Reference: 5.2.4. Line is not used in this sense in 88. 3.28

lot: “A unique amount of material having a set of common traits.” NOTE — “Some examples of common traits are material source, the master recipe used to produce the material, and distinct physical properties.”

Reference: Not defined in 88 text, only used twice. Alternatively, a lot is a quantity of material that may be made up of complete or partial batches. Common traits are necessary if the lot is supposed to be statistically similar to any batch that went into it. 3.29

master recipe: “A type of recipe that accounts for equipment capabilities and may include process cell-specific information.”

Reference: 5.3.1.3, 5.3.2.3, 5.3.2.4.3, 5.3.4, 6.2.4, 6.2.5 Everywhere that the term master recipe is used in 88.01, it means a recipe that has been created or transformed for use in a specific process cell or a set of identical cells. There is no “may” about it. A master recipe does contain process cell-specific information. 3.30

mode: “The manner in which the transition of sequential functions are carried out within a procedural element or the accessibility for manipulating the states of equipment entities manually or by other types of control.”

Reference: 5.7.1 See the discussion in the section “Control Modes” in Chapter 3.

batch chap 13.qxd

4/25/2006

3:15 PM

Page 209

88 Definitions 3.31

209

operation: “A procedural element defining an independent processing activity consisting of the algorithm necessary for the initiation, organization, and control of phases.”

Reference: 5.1.2.3 Operation has many meanings. This is just the meaning for the procedural element. Reference is also made to plant operation in the text of 88. It may be a recipe operation or an equipment operation, but it is not a process operation as defined in 4.1.3.2. 3.32

path; stream: “The order of equipment within a process cell that is used, or is expected to be used, in the production of a specific batch.”

Reference: 4.2.4. Stream is not used in the text of 88.01. 3.33

personnel and environmental protection: “The control activity that — prevents events from occurring that would cause the process to react in a manner that would jeopardize personnel safety and/or harm the environment; and/or — takes additional measures, such as starting standby equipment, to prevent an abnormal condition from proceeding to a more undesirable state that would jeopardize personnel safety and/or harm the environment.”

Reference: 6.8 Actually, it takes a detectable event to initiate this control activity. When it does act, it prevents other control signals from interfering with its action. This control activity is designed to prevent an incident, but unforeseen or unpreventable conditions, like a jammed valve that won’t close or a fire pump that won’t start, may make prevention impossible. 3.34

phase: “The lowest level of procedural element in the procedural control model.”

Reference: 5.1.2.4, 5.2.3.3, 5.2.3.4, 6.6.1, 6.7.2 This is an example of extreme brevity. Section 5.1.2.4 in 88.01 defines it as “The smallest element of procedural control that can accomplish a process-oriented task . . .” Additional qualifications are needed to separate a phase from a sequence, which may also carry out a process-oriented task. 3.35

procedural control: “Control that directs equipment-oriented actions to take place in an ordered sequence in order to carry out some process-oriented task.”

Reference: 5.1.2, 5.2.1 A sequencer can also do that, but it is basic control, not procedural. Procedural control operates on recipe procedures down to the phase level.

batch chap 13.qxd

4/25/2006

3:15 PM

210 3.36

Page 210

Chapter 13 procedural element: “A building block for procedural control that is defined by the procedural control model.”

Reference: 5.1.2 The procedural elements are procedure, unit procedure, operation, and phase. 3.37

procedure: “The strategy for carrying out a process.” NOTE — “In general, it refers to the strategy for making a batch within a process cell. It may also refer to a process that does not result in the production of product, such as a clean-in-place procedure.”

Reference: 5.1.2.1, 5.3.2.4, 5.3.3 A common dictionary defines procedure as a series of steps followed in a regular, definite order. A strategy is a large-scale plan with tactics for carrying out the plan. A procedure may be a strategy, but it is also an ordered set of procedural elements. 3.38

process: “A sequence of chemical, physical, or biological activities for the conversion, transport, or storage of material or energy.”

Reference: 4.1 3.39

process action: “Minor processing activities that are combined to make up a process operation.” NOTE — “Process actions are the lowest level of processing activity within the process model.”

Reference: 4.1.3.3 3.40

process cell: “A logical grouping of equipment that includes the equipment required for production of one or more batches. It defines the span of logical control of one set of process equipment within an area.” NOTE — “This term applies to both the physical equipment and the equipment entity.”

Reference: 4.2.4, 4.3, 5.2.2.1, 5.2.3.1, 6.5.2 That is, the control activities in one process cell cannot directly affect the equipment entities in another process cell. 3.41

process control: “The control activity that includes the control functions needed to provide sequential, regulatory, and discrete control and to gather and display data.”

Reference: 6.7 This definition is specific to 88.01 control activities. The rest of the world thinks of process control as the sensors, actuators, and control functions that enable a process

batch chap 13.qxd

4/25/2006

3:15 PM

Page 211

88 Definitions

211

to be carried out. But then, the rest of the world doesn’t have equipment entities. The ISA’s Automation, Systems, and Instrumentation Dictionary, fourth edition, does list the above definition as meaning number 5, but it is quite different from the first four. Again, it is best to test the other person’s definition of process control. 3.42

process input: “The identification and quantity of a raw material or other resource required to make a product.”

Reference: 5.3.2.2 3.43

process management: “The control activity that includes the control functions needed to manage batch production within a process cell.”

Reference: 6.5 Manage might be a bit strong, compared to the business management functions. A dictionary definition for management is the judicious use of means to accomplish an end. Judicious implies human judgment (by a manager), but most of this control activity is based on algorithms that can be automated. 3.44

process operation: “A major processing activity that usually results in a chemical or physical change in the material being processed and that is defined without consideration of the actual target equipment configuration.”

Reference: 4.1.3.2 This is the middle activity in the process model, between stage and action. 3.45

process output: “An identification and quantity of material or energy expected to result from one execution of a control recipe.”

Reference: 5.3.2.2 3.46

process parameter: “Information that is needed to manufacture a material but does not fall into the classification of process input or process output.” NOTE — “Examples of process parameter information are temperature, pressure, and time.”

Reference: 5.3.2.2 3.47

process stage: “A part of a process that usually operates independently from other process stages and that usually results in a planned sequence of chemical or physical changes in the material being processed.”

Reference: 4.1.3.1, 5.3.2.4.3 Heisenberg would be proud of the uncertainty introduced by those two instances of “usually” that deprive the definition of any certain meaning. SP88 uses the word

batch chap 13.qxd

4/25/2006

212

3:15 PM

Page 212

Chapter 13

“usually” to mean that it cannot come to consensus on the definition without the qualifiers. We had a committee member who could usually be counted on to insist on the insertion of usually, because the world was usually not as it seemed. 3.48

recipe: “The necessary set of information that uniquely defines the production requirements for a specific product.” NOTE — “There are four types of recipes defined in this standard: general, site, master, and control.”

Reference: 5.3.1 Necessary, but not sufficient, because a great deal of information must exist before the recipe can be created or translated. More information must be referenced in order to find a place to run the recipe and make a batch of product. 3.49

recipe management: “The control activity that includes the control functions needed to create, store, and maintain general, site, and master recipes.”

Reference: 6.2 3.50

recipe operation: “An operation that is part of a recipe procedure in a master or control recipe.”

Reference: None This is a name, but not much of a definition, for a recipe procedural element. See operation. 3.51

recipe phase: “A phase that is part of a recipe procedure in a master or control recipe.”

Reference: None This is a name, but not much of a definition, for a recipe procedural element. See phase. 3.52

recipe procedure: “The part of a recipe that defines the strategy for producing a batch.”

Reference: 5.3.2.4, 5.3.3 This is a name, but not much of a definition, for a recipe procedural element. See procedure. 3.53

recipe unit procedure: “A unit procedure that is part of a recipe procedure in a master or control recipe.”

Reference: None This is a name, but not much of a definition, for a recipe procedural element. See unit procedure.

batch chap 13.qxd

4/25/2006

3:15 PM

Page 213

88 Definitions 3.54

213

shared-use resource: “A common resource that can be used by more than one user at a time.”

Reference: 4.2.6, 5.6.1 See the definition of common resource. 3.55

site: “A component of a batch manufacturing enterprise that is identified by physical, geographical, or logical segmentation within the enterprise.” NOTE — “A site may contain areas, process cells, units, equipment modules, and control modules.”

Reference: 4.2.2 Note well: almost anybody would think that site was synonymous with plant or facility. This definition lets a site be a region or a country. Be sure you know what the other person means by site. A definition for facility is needed if a site can be a country. 3.56

site recipe: “A type of recipe that is site specific.” NOTE — “Site recipes may be derived from general recipes recognizing local constraints, such as language and available raw materials.”

Reference: 5.3.1.2, 5.3.4, 6.2.3 3.57

state: “The condition of an equipment entity or of a procedural element at a given time.” NOTE — “The number of possible states and their names vary for equipment and for procedural elements.”

Reference: 5.7.2 Also applies to procedural controllers. See the “Modes and States” section in Chapter 14. 3.58

stream; path: “See definition for path.”

Reference: 4.2.4. Stream is not used in the text of 88.01. 3.59

train; line: “A collection of one or more units and associated lower level equipment groupings that has the ability to be used to make a batch of material.”

Reference: 5.2.4. Line is not used in this sense in 88. This definition stretches words associated with linear movement beyond their normal meaning. Train and line have no meaning in a multipath process cell.

batch chap 13.qxd

214 3.60

4/25/2006

3:15 PM

Page 214

Chapter 13 unit: “A collection of associated control modules and/or equipment modules and other process equipment in which one or more major processing activities can be conducted.” NOTES 1. “Units are presumed to operate on only one batch at a time. Units operate relatively independently of one another.” 2. “This term applies to both the physical equipment and the equipment entity.” 3. “Examples of major processing activities are react, crystallize, and make a solution.”

Reference: 4.2.5, 5.2.2.2 The word presumed is another uncertainty word, like usually. You can, if you like, get into trouble by saying that the oven that bakes many batches of bread is a unit. In fact, the oven is a discrete processing apparatus that holds a continuous temperature. 88.01 elsewhere shows that a unit may contain an entire batch or part of a batch that is being processed in parallel. There is no discussion of how to identify partial batches. 88.01 is based on the idea of one batch per unit. 3.61

unit procedure: “A strategy for carrying out a contiguous process within a unit. It consists of contiguous operations and the algorithm necessary for the initiation, organization, and control of those operations.”

Reference: 5.1.2.2 This is a procedural element that is described in the Procedural Control model. Again, strategy may not be the right word. A unit procedure looks more like a tactic in that it is a detailed plan for a single objective. 3.62

unit recipe: “The part of a control recipe that uniquely defines the contiguous production requirements for a unit.” NOTE — “The unit recipe contains the unit procedure and its related formula, header, equipment requirements, and other information.”

Reference: 6.5.1 There are parts of 88.01 that use unit procedure and parts that use unit recipe. The unit recipe is necessary because a unit must have all of the recipe information that is required to perform its part of batch processing autonomously. A unit recipe only contains information that is relevant to the target unit. 3.63

unit supervision: “The control activity that includes control functions needed to supervise the unit and the unit’s resources.” Reference: 6.6

batch chap 13.qxd

4/25/2006

3:15 PM

Page 215

88 Definitions

215

Other Definitions Some terms did not make it into the list of definitions but probably should have. They include the following: activity: A name for the highest level set of things of a particular nature that take place within some larger entity, like a plant. Similar to a class, but not applied to physical objects. Also, an overview of what is going on with few details on how the activity does what it does. May be a strategy for things to be done. function: A subdivision of an activity, similar to a subclass. More details are available without exceeding the reader’s grasp of what is going on. May be a tactic for specific things to be done. plant; facility: A structure with a street address, built on real property, that contains equipment that is required to make products.

Summary This chapter has examined the definitions in Section 3 of 88.01. The comments on these definitions show where additional work by SP88 would be useful.

batch chap 14.qxd

4/25/2006

3:16 PM

Page 217

Chapter 14

Further 88 Clarifications This chapter discusses some issues that were not finished when ANSI/ISA-88.01 went to press. You’ve heard the expression, “It’s time to kill the engineers and get on with production.” The same is true for standards—stop work and sell the product. Things that don’t work can be fixed later. Well, now is later, and it’s time to fix some things. If you believe that standards committees are infallible and that the present 88.01 represents perfection itself, then read no further in this chapter. Your belief will be tested, but this book does not represent itself as the One True Way nor does it promise enlightenment. The discussions in this chapter are here to make you think about alternatives to the way things are presented in 88. You are encouraged to use what works for you if you find something in the standard that will not work in your case, but only after you’ve tried to make it work. Be aware that vendors use 88 to design their next systems, so please write to ISA Standards and Practices if you find something that doesn’t work for you. Implementations may be used as examples in the following discussions, but they are for clarification of the concept, not specification of the only way to do it. This chapter does not alter 88.01. Nothing changes in 88 until SP88 comes to consensus and says it is changed. The standard is overdue for its five-year revision.

Definitions The definitions in 88 are mostly too-short summaries of concepts. Instead of attaching notes to them, it would be better to reference the text where the concept was defined. Then perhaps the definitions could have been the normative part of the standard. Some of the models could have been made normative, too. Then again, several things were not defined in just one place in the text. SP88 both defined terms and recommended best practices. Some of the best practices were invented by the SP88 committee and never actually tried out, so that their definitions were not solid. Now that ten years have passed, SP88 ought to be able to say what works and make the associated definitions normative. Then ISA needs to form a group that evaluates vendors’ literature for misuses of 88. The users do not get much out of the standard until the models and terminology are used consistently.

batch chap 14.qxd

4/25/2006

3:16 PM

218

Page 218

Chapter 14

Physical Model The model shown in 88.01 Figure 2 should be considered as a simplified introduction to physical models. It serves to illustrate the definition of some terms. The model was arbitrarily limited to seven levels. That limit has caused some definitions of levels to lose their clarity, as when Site included Region. This section discusses these problems and proposes a crisper physical model without the use of definitions that homogenize necessary concepts into less useful mixtures. A review of Chapter 6 may help explain what this discussion is about. The physical model suffers from being in the first part of the standard. Like first impressions, people will read about the physical model and form conceptions of what each of the seven blocks mean before they have been introduced to equipment entities. The physical model is interpreted differently the second time that the standard is read, because the model is not purely physical. Perhaps the physical model could have been presented as a simple hierarchy with a discussion of the meaning of each layer, with forward references to control concepts where necessary. Some in SP88 thought that forward references in the document were a Very Bad Thing. At least one member of SP88 spent a long time wandering in ignorance because his first impression of the equipment module made it hard to see the need to complicate it with a phase. A simple forward reference to procedural control would have cleared it up. Figure 14-1 shows a complete physical model. It is still a mixture of business and manufacturing boxes, so it could be simplified by separating business from batch manufacturing. Like Figure 2 of 88.01, Figure 14-1 does not show the expansion of levels, except to show that a process cell may contain both units and storage units. As defined in 88.01, a Site may be a geographical location like a country or a continent. It may also be a single manufacturing facility. That definition seems too broad. Even in context, it may not be clear which is meant. Region would have been a good name for a geographical area, as a separate definition. One definition for a Site is a physical nexus or node in a distribution network. A Region is a geographical area. The word area was deemed to be a political concept, and optional. That left us with no name for a group of process cells and no home for the coordination control of process cells from a higher level. A hierarchy that encompasses business and manufacturing needs a well-defined point of separation between the people that focus on data and the people that focus on operational safety. The point of separation is the highest level in the plant where realtime response and safe operation are significant issues. Both kinds of people want data from operations.

batch chap 14.qxd

4/25/2006

3:16 PM

Page 219

Further 88 Clarifications

219

Figure 14-1 Complete Physical Model

batch chap 14.qxd

220

4/25/2006

3:16 PM

Page 220

Chapter 14

The problem is that there is only one source of each datum. The sources and their networks must not be overwhelmed by requests for data in a way that degrades realtime response. A delayed response adds dead time to a control loop, which can cause it to oscillate. This is generally not a good thing. The proper way to isolate the world of data from the world of control is with computers that gather the manufacturing data that is made available to the data people. The computer is an interface machine, at the interface between the data wolves and the control system rabbits. The data people may hammer these machines with search requests without being able to degrade process control, which could lead to unpredictable unsafe results. If an interface machine becomes overloaded then it is the business data that slows down and not the process data. An interface machine also protects the process control system from unsafe commands from the business data side. A business command may affect the progress of a process but it is not allowed to affect any individual control component. Commands to schedule processes and to modify schedules of processes that have not started will be obeyed. Commands to change setpoints or valve positions will be rejected, should a data person make it possible to send that kind of command. The people that operate processes are a specialized team. Any one of them would not hesitate to walk through the process equipment because they have all had the safety training necessary to keep bad things from happening. Walking through a set of equipment that is all that stands between you and death is an interesting experience, not unlike walking through a high-voltage substation. There are still fatalities from weld failures, but a weld failure was not caused by someone that changed a setpoint without knowing the consequences of that action. The preceding paragraphs were necessary to introduce the interface problem because it is not discussed in 88. The interface has an impact on the physical model. An interface should lie between layers instead of being concealed at an undefined place within a layer. Lack of standardization leads to an assortment of proprietary solutions. The 88 physical model would have had the interface between the process cell and the area, had we had time to think about interface issues. (95 was formed to address the interface location, but it was taken over by the data people. There are many data models but no data/control interfaces.) That location would mean that each cell was isolated, with no possibility of real-time coordination. A process may consist of several cells that do batch, continuous and discrete processing as a coordinated group. A group of identical cells may be coordinated so that a manufacturing work order is passed to the first available cell, with no human intervention. The coordination must go on in a layer between area and process cells because area has been defined as something that has political rather than engineered boundaries. An area is as much territory as a person can seize and defend, which varies with the person. Something more stable is required for real-time control.

batch chap 14.qxd

4/25/2006

3:16 PM

Page 221

Further 88 Clarifications

221

The phrase “cell group” is proposed for a group of process cells. The level is optional. If you can draw the line between data and control right above Process Cell then you don’t need it. Storage equipment was not discussed in 88.01, but it is introduced in Chapter 12 near Figure 12-1 and is covered in Chapter 16 under “Missing Interfaces.” Storage units should be added to the physical model. The alternative is to broaden the meaning of Unit, but this will only add to the confusion. You must have a process unit, but you don’t have to have a storage unit. Common equipment refers to those equipment entities that would have been present in every unit in a set of similar units, but time or proximity allowed the equipment to be shared. When laying out the equipment locations in a plant, common equipment is located separately from but adjacent to the units that share it. Common equipment may be acquired by any unit but is not physically contained by any unit. A separate Physical Model box is not required for common equipment because such a box can be either an equipment module or a control module. This gets confusing because the modules are listed under the Unit box with a “may contain” relationship. This is only true for part of the time in the case of common equipment. The confusion is the result of packing too much meaning into a seven-layer model. Similarly, the fact that the Equipment Module box lies between the unit and a control module does not mean that units can’t contain control modules unless they are connected to equipment modules. The confusion will be dispelled in Chapter 15. You really can’t understand the meaning of the present physical model the first time that you look at it, but no better way of explaining it is apparent. The definitions of modules in Section 3 of 88.01 and in Chapter 13 note that a module may be either a basket of equipment or an equipment entity. This doesn’t really help things, but it does allow modules to appear in the physical model. The problem is that the module can’t be completely defined without specifying the type of control that animates it. SP88 tried doing it on the basis of equipment alone, but the border between modules was defined by complexity, which is too fuzzy.

Modules Revisited The physical model is almost self-explanatory down to the unit level. Below the unit are two levels for the subdivisions of process control for a unit. These two levels control but do not transform. The names have caused confusion and distress, so we will look at the functions instead of the names. The lowest level performs the function of interfacing automatic control and indicating control to the process. It consists of sensors, actuators, and control functions that regulate the equipment attached to the sensors and actuators. An indicating function only has a sensor. An actuator is almost anything that manipulates the process and

batch chap 14.qxd

222

4/25/2006

3:16 PM

Page 222

Chapter 14

has two or more states. If it only has one state then it can’t be controlled. Analog actuators have as many states as the resolution of the device, certainly over 100 states and more likely in the thousands. Fully open and fully closed are also states of an analog valve. Different names are used for a variable speed drive. The lowest level isolates the user from the details of how the item performs its function or which control equipment it uses. This level accepts commands to change the state of something related to the process, like a flow, pressure, temperature, level, piping configuration, or agitator speed. Of course, an indicator does not accept a control setpoint, unless you consider an alarm trip point to be a control parameter. In other words, the function of the lowest level is to provide a sensor reading and/or to accept a setpoint for exactly one process condition. The control functions in the lowest level come from the 88 list of basic control functions. Coordination control for the server end of an acquire/release transaction may also be used. The lowest level is basic control and indication, because there is no lower level. That leaves everything else that does not meet the requirements for a unit in the layer above it, because there aren’t any other layers in a seven layer model. The solution seems obvious, but SP88 resisted the idea of an eight-layer model. The level below the unit and above the lowest level performs a process function, which is usually a process action from the 88 process model. The unit may also perform process functions by interacting directly with the lowest level, but it may be useful to isolate the unit from the details of how the function is performed. Items from the lower level that are included in an item at this middle level are isolated from commands from anywhere else. This can simplify the design effort. Process actions are mostly transfers of material or energy to or from a process. Turning on the agitator transfers energy to the process, but the only control required is a switch. The transfers performed at the middle level must require a procedure. A typical procedure checks the readiness of the unit for the transfer, configures the piping, starts the transfer, detects the end of the transfer, and shuts down. The control functions in the middle level include procedural control. The only level of procedural control allowed at this level is the phase. In fact, phase execution is required. That requirement means that this level cannot collect items from the lowest level into a logical group and coordinate them using basic control. Please understand that SP88 was dealing with a paper model and the need for consensus. We called the lower level the Control Module (CM) and the middle layer the Equipment Module (EM) because we couldn’t go on calling them lower and middle layer. We knew that this was not enough layers, but we also wanted to keep the model simple so that we could come to consensus.

batch chap 14.qxd

4/25/2006

3:16 PM

Page 223

Further 88 Clarifications

223

The reasons for using the word module were discussed in Chapter 2. They encapsulate behavior and they can be replicated. The module interface remains the same no matter how the function of the module is performed. The entity-relationship diagram was introduced early in the deliberations of SP88 in order to get more of this apparent simplicity. Entity-relationship diagrams allow recursion. That is to say, an item (instance) at a particular level may consist of other items from the same level. Bingo! Now we can have an infinite variety of items within one level as long as they have the properties of that level. And so it came to pass that anything that accepted setpoint commands and tried to hold the process at the setpoint was a Control Module. A piping configuration can be described with a single setpoint, so the module that consists of piping and block valve control modules is also a control module. This is true even though operators look at a transfer header and see an assembly of pipes and valves that is considerably more complex than a block valve control module. Many practical people, not versed in the intricacies of entity-relationship models, look at the transfer header as an equipment assembly that is less than a unit and more than a controlled actuator. It can’t possibly be a control module (if we’ve got to call them modules), so it has to be an equipment module. Such is the power of names. Note that a transfer header really is an equipment module if it has a procedure for cleaning up after a transfer. Why would anyone care what a process design team called an equipment assembly? Perhaps the plant already has names for its equipment assemblies. It really doesn’t matter, except that your control vendor doesn’t know what you called things. 88 said there were control and equipment modules. If you call it a control module then you get a setpoint command interface. If you call it an equipment module then you get to write phase logic. Either way, you get recursion of those two choices because that’s the way it is in 88. Ideally, the process designers are the only people who have to deal with modules as such. The assembly and function that are represented by a module are configured by the user, or at least specified by the user. The vendor should have provided fields for the identification tag name and descriptor for each module. Once the name and description are assigned, the module class is no longer visible. The only people that are confused are the newbie designers. SP88 named the layers. Deal with it. The user base is more than ten years old. There is no chance that the names will be changed to something reasonable like “basic control module” and “phase control module.” Looking back, the source of all the confusion was that SP88 put layers in the physical model that were really defined by their control functionality. There is also confusion

batch chap 14.qxd

4/25/2006

3:16 PM

Page 224

224

Chapter 14

regarding batch units because people look at the equipment and forget that a batch unit does not discharge its primary product while processing is going on. The inlet valves won’t open if the discharge valve is open, and the discharge valve won’t open while any inlet valve is open. If that’s not true then you have, at best, a discontinuous process unit like a pasteurizer. Speaking of units, there are people who think that the unit is the reactor, instead of a boundary around the reactor and its auxiliary equipment entities. The illusion could be dispelled by referring to the reactor as an equipment module. No, wait, the reactor doesn’t carry out any procedures on its own. The reactor is just a tank with some control modules, by the 88 definitions.

Batch Control Concepts Modules and Phases The definition of phase needs to be clarified. “The lowest level of procedural element in the procedural control model” defines where it is, not what it is. Many years ago, an elderly woman confronted a lecturer in astronomy with the assertion that the world was flat and supported on the back of a very large turtle. The lecturer asked the lady what the turtle was standing on. “Oh no,” she said. “You can’t fool me. It’s turtles all the way down.” And so it is with the humble sequential function chart (SFC). An SFC may express a procedure from the top level all the way on down to the smallest sequence in basic control. The difference between an SFC in a control module and one in an equipment module is the method of execution. A control module uses sequential control, which is one of the many methods of basic control. Sequential control requires that the end of the sequence wrap around and return to the initial step. An equipment module uses procedural control, which executes an SFC from beginning to end but does not wrap around. It just stops, until the next time that procedural control runs the SFC again. Both the control and equipment modules may run sequences. A sequence is a phase if it is executed by a procedural controller and it simply ends when it is done. The difference between a control and an equipment module hangs by that slender thread. That’s the way it is, for reasons explained above. One way to deal with this as a user is to use your own module hierarchy but to classify them as control or equipment. Perhaps you can use loop and device modules and assemblies. Vendors can only provide frameworks for the nested control and equipment modules defined in 88. The phase that is used in an equipment module should not be confused with an equipment phase. An equipment phase matches a recipe phase. The recipe procedural controller may start equipment phases with no intervening activity. Equipment module phases are initiated by unit equipment phases, which may require that the equipment module be acquired before it can be used.

batch chap 14.qxd

4/25/2006

3:16 PM

Page 225

Further 88 Clarifications

225

Equipment Entities and the Purdue Reference Model The Purdue Reference Model (PRM) has numbered levels in its control model. The SP95 effort used these levels to define the scope of their work, which is the business functionality described in levels 3 and 4. The interface to batch control and 88 is between levels 2 and 3. Ah, if only it were that simple. See the section on “Area” under Figure 14-1 in this chapter and Chapter 16 for a discussion of the interface. SP88 felt that the need to have equipment entities outweighed the existing work in the PRM. An equipment entity represents an identifiable combination of equipment and the control that is required to animate the equipment. Equipment entities can then be related to bits of process functionality that are required to make a product. From this we get the concept of separating the procedure into recipe and equipment, which allows recipe authors to build recipes without the services of control engineers. The PRM seems to be directed at continuous processing and supervisory control. The equipment is relegated to level zero as something to be controlled. Level 1 consists of what 88 calls basic control. Level 2 consists of control that supervises level 1 and is clearly a part of production control. There is no mention of product recipes. Procedural control is not discussed. Coordination control appears in level 3. Batch control requires both procedural and coordination control, so they must be in level 2. See Figure 14-2.

Figure 14-2 The Physical Model and the Purdue Reference Model

batch chap 14.qxd

4/25/2006

3:16 PM

Page 226

226

Chapter 14

Level 2 in the PRM is not a good interface to batch process control because it has no home for procedural control. SP88 and SP95 are still discussing the definition of the interface between the standards. At one time it was suggested that the 88 Process Management control activity belonged in 95 because it was clearly a level 3 function. There is a process management bubble in level 3, but it performs the business management side of Operations. SP88 would have done well to avoid the use of the term management if they had known what was coming. Perhaps the issue could be clarified by emphasizing “real-time control” and process safety factors as the keys to what belongs below the management activities described and defined in 95. The PRM is discussed further in Chapter 10.

Exception Handling Some form of prevention is required to stop an abnormal chain of events before a process gets into a state that cannot be controlled. Control can be lost if the state becomes unknown or a reaction becomes self-sustaining, possibly like the contents of a stick of dynamite. There may be a “tipping point” past which no control is possible. Reaction time may be very important. “If something can go wrong, it will.” That’s a nice saying, but it is not quantitative. What needs to be known (or estimated) is what can happen, how often it can happen, and how much it will cost when it does happen. Then you can decide if the “what” is worth considering. You need to know what methods are available to reduce the trouble caused by an exception in order to estimate the cost. The following are some abnormal events that will need to be considered: • Lack of resources—no material, no unit, no steam, no operator • Moving toward a constraint—something will have to give • Not moving when it should—generally a sign of dead equipment • Control equipment or communications failure—anything can happen, but rarely • Environmental problem—wind, rain, lightning, fire, flood, armed attack There are at least six methods for preventing abnormal chains of events, also known as accidents: • Careful design of equipment and control schemes • Operator training • Equipment maintenance • Exception handling

batch chap 14.qxd

4/25/2006

3:16 PM

Page 227

Further 88 Clarifications

227

• Interlocks • Safety shutdown system Careful design of equipment and control schemes is fundamental. Training and maintenance can not overcome poor design. Operator training is essential to help the operator stay out of trouble or to recognize trouble when it appears and deal with it quickly. Maintenance is essential because nothing lasts forever. The probability of an accident rises as wear and fatigue cracks accumulate. Exception handling is a set of procedures to be followed for various exceptions that may be identified. Some of the procedures may be automated. Exception handling requires equipment procedures. Writing these down, as pages of text or computer code, may be one to five times as much work as writing the normal procedures. A continuous plant has one steady state that is normal. Batch processing requires that the processing equipment have a series of states. There may also be regimes of reaction in a reactor during normal operation. Each state or regime must be considered for exceptions. Exceptions may also be found that are always exceptions, regardless of state, such as exceeding the physical limits of a piece of equipment. In general, if prevention can be handled by basic control then the interlock method is used. If procedural control is involved then the exception handling method is used. An interlock is a simple prevention method that can be hard or soft wired into basic control. If a specific thing happens then a specific action is taken. Interlocks work in all control modes, particularly Manual. They reduce the probability of an accident by requiring two things to go wrong before something gets damaged. See the discussion of interlocks in Chapter 3. Usually, an interlock stops the flow of something to prevent a physical problem like high pressure, temperature, or level. An interlock may also be a permissive, which prevents something from being started but has no effect after the start. For example, a large motor may not have bearing clearance unless it is rotating. It needs to have oil pumped into the bearings before it can start. Operation of the auxiliary oil pump is a permissive for starting the motor. Once the motor is running, the oil pump can be shut off. Interlocks are not difficult to design, but beware of the deadly embrace. A combination of interlocks may make it impossible to resume operation unless some of them are bypassed. A great deal of harm has been done by bypassed interlocks that were not restored to normal. Operator training should not include bypassing interlocks. Enough trouble will be caused by maintenance bypassing interlocks.

batch chap 14.qxd

4/25/2006

3:16 PM

228

Page 228

Chapter 14

Safety shutdown systems act like interlocks by stopping flows of energy and material when trouble is detected. The logic used to detect trouble is more complex than interlock logic. A system may be hard wired, but is more likely to be some form of computer that is either redundant or uses triple systems and voting. Safety systems are independent and different from the control systems. They do their prevention job no matter what the control system is doing. When a safety system does act, it almost always causes an uncontrolled shutdown, which will mean lost production and may require expensive cleaning and maintenance. Plants are insured against accidents. The insurance company balances the price of insurance against the risk of paying for an accident. A plant can reduce its insurance payments by using a certified safety system to reduce risk. There is no direct relationship between insurance costs and any of the other four methods. Safety shutdown systems tend to be designed to prevent major accidents and leave the minor accidents to chance. Training, exception handling, and interlocks prevent minor accidents and anticipate the safety system so that it doesn’t shut everything down. The exception handling and interlocking done in batch control are a first line of defense. The safety system is the last line of defense.

Product Exceptions Most exceptions involve the equipment regardless of the recipe being made. It is possible to have an event that is an exception only for one recipe or for many recipes. If the equipment does not handle the exception then it must be handled in each master recipe. It may be possible to create a phase or operation recipe building block that handles the exception. This moves the exception handling into the equipment, but the exception must always be detected in each recipe. Suppose a recipe execution comes to an analysis phase that is followed by a wait for results. The result may choose to add X more base and test again, add X more acid and test again or move on, adding nothing. An equipment phase could be constructed that captured the results and added X acid or base, if necessary. The phase could return a number (or words) that direct procedural control to re-test or continue.

Time Exceptions As in the example above, there may be places in the procedure where it is necessary to wait, but not forever. It may be useful to have a watchdog timer that can be set by a recipe formula parameter. This type of timer has been called a watchdog since the early days of batch control, possibly because if it barks (times out) then that event is a warning. The location of the watchdog timer becomes important if your batch control is distributed. If all procedural control is done by one machine then the dog will die when the machine fails. Your operators will be aware that the single machine has died and left them in charge, but they will have no way of viewing the status of procedures. It is

batch chap 14.qxd

4/25/2006

3:16 PM

Page 229

Further 88 Clarifications

229

a good idea to distribute procedural control to each unit and equipment module so that you do not have to deal with catastrophes when you design exception handling. The watchdog timer is used anytime that an action is started that will not generate an error event if it fails. The normal communication of commands from procedural control to equipment entities uses a confirmed service. An error will be returned if the communication failed, unless it isn’t. The watchdog timer has to be at the sender’s end to detect communication problems. This means that it must be built into a procedural controller and set by a standard parameter that is associated with each recipe phase. An equipment phase may use a watchdog timer if it starts a totalized flow and waits for a field device to detect that the total has been reached. You may find that the watchdog is useful in every equipment phase except those that do a timed wait. Many discrete control devices have watchdog timers that start when a command is received and bark if the physical device is not confirmed in position after waiting for physical travel. Still, the device may die between the acknowledged command and the time for the watchdog to bark, but this possibility is remote. If timing is important to you then your system should allow recipe watchdog timers that are operated by the procedural control that is executing the recipe. It is better to know that something has failed than to find out from some more drastic event like a tank overflowing or a safety valve release. The rest of this section is written for procedural exception handling in equipment, although some of it can be applied to interlocks.

Planning Planning begins by going over the process chemistry and equipment. Make a list of things that can go wrong, then estimate the cost of preventing each issue and how often it might happen. Decide if the risk is acceptably low enough to ignore or if prevention is necessary. If it has to be prevented, decide how to detect it and what has to be done if it is detected. Estimate the cost of doing something and revise the risk decision. More information on planning may be found in books on safety systems. Develop a toolkit of ways to handle exceptions, because many different exceptions can only be handled in one of a few ways. If the exception can’t be handled automatically but an operator could probably fix it, then the exception is handled by putting the procedural control state into Hold. This happens a lot. For example, if a valve will not confirm that it is in position then the central operator calls a field operator to go look at the valve and report what happens when the valve is cycled. If the position switch is bad then the central operator tells the valve device that the valve really is in position, and the batch continues on the normal path.

batch chap 14.qxd

4/25/2006

230

3:16 PM

Page 230

Chapter 14

Go back through the list of things that can go wrong looking for things that are conditional exceptions. Define the conditions in terms of equipment configurations and reaction regimes. An empty reactor is part of an equipment configuration. A polymerization reactor receiving the first quantity of monomer is in the “setup” regime. After catalyst is introduced it is in the “ignition” regime and is no longer relatively harmless. When procedural control is in Automatic mode and the state is Running then the operator should be unable to do anything but watch and respond to prompts. Allowing operator access during automatic procedural control will compound the design work for exception handling. In regulated industries, operator intervention may turn the batch into waste. If recipes are automated and you allow operators to change the mode or settings of basic control devices while the recipe is running, then you need to take a hard look at why you are doing that. Perhaps it is because you don’t have enough exception handling.

Detection You must detect an exception before you can take action. Basic control has built-in detectors called alarms and events. If your control system allows you to detect and identify alarm messages that come from basic control, then it is possible to write a monitor program that will select the handling to be done based on the alarm or event. Perhaps a combination of alarms detects an exception, but it is best to avoid that requirement in order to keep things simple. Try to do combination logic in basic control, so that the alarm is very specific. Detection is done on a unit basis, mostly with alarms on the normal process sensors or analyzers. It may also be done with dedicated switch sensors for flow, pressure, temperature or level. The detection for an agitator or pump may be done by measuring and alarming power, speed, or vibration. Other detectors may have to calculate something, like rate of rise or energy balance. A watchdog timer may be set to cause an exception event when a certain time elapses. You should never allow anything to wait forever, like filling a tank or raising a temperature. The monitoring program runs continuously. Some alarms are always exceptions, but some only matter within a reaction regime or equipment configuration or during a phase of an operation. Most of the conditional alarm detection can be made continuous if the phases change alarm limits to appropriate values as they run. For instance, a watchdog timer alarm is always a problem because the phase sets the maximum time to wait and clears the timer when the wait is over. A monitoring program for a unit probably can’t detect all exceptions, because basic control may not be able to detect all of them. Some detection must be included in the normal phase program. Detection should be done in the phase if it is possible to bring things back to normal from within the phase. If it is not possible to have an exception monitor then each phase must detect exceptions by polling basic control. This could cause a heavy load on communication

batch chap 14.qxd

4/25/2006

3:16 PM

Page 231

Further 88 Clarifications

231

bandwidth if the modules are distributed. Combination logic may be used in basic control to reduce the number of things that have to be polled. For example, each block valve should be confirmed in position (unless you have very obedient valves). If your system provides confirmed signals from device controllers then these can be “anded” to provide a master confirmed signal that can be polled.

Handling If possible, exception handling should restore normal control. If that’s not possible then bring the process to a less unstable operational state, usually Hold, so that an operator can untangle things. If that’s not possible then initiate the Stop or Abort state, depending on the urgency required. The exception monitor described above is always active. Each alarm or event message that is related to the unit is checked against a table of things that require handling. Handling from the monitor consists entirely of setting the state of the unit procedural controller to Hold, Stop, or Abort. Handling exceptions caused by physical extremes is simple compared to handling conditional exceptions. Consider a reactor that has a level switch for detecting absolute high level shortly before the safety valve has to open. The alarm or signal from this switch is always handled by going to the Hold state, so that inflows will stop. Add another limit switch about 30% of the way up that marks the high limit for the first ingredient charge. The absolute high level switch is connected so that it cuts off all ingredient valves no matter what. The 30% level switch only detects an exception during the first charge. After that, it is on until the reactor is emptied. The first charge exception has been elevated from an interlock to programmed exception handling by the fact that it is conditional upon the reactor regime. Perhaps your monitor understands reactor regimes. If not, the first charge phase should set the high level alarm to 30%. The second charge phase should raise the alarm setpoint. If there’s no monitor then each charge phase must poll the level—and set the alarm limit in case the procedural controller dies. Then again, the 30% level switch may act as a permissive for the next process action. If the first charge did not exceed 30% level then don’t do the second charge. This could be handled by one “if” test at the beginning of the second charge phase. A level alarm is not required. Monomer and catalyst are added together in the main reaction regime of a polymerization reaction. There is a possibility of accumulating excess monomer that could suddenly react. This sudden reaction could exceed the energy transport and pressure rating of the reactor vessel faster than anything but a safety valve could relieve. Detection may be calculated from total weight of monomer and total weight of catalyst. Detection may also be calculated from the expected generation of heat for the present flow rates.

batch chap 14.qxd

4/25/2006

3:16 PM

232

Page 232

Chapter 14

The detection is best done in the phase if it can’t be done in basic control because of the calculations. Phase logic can handle the situation directly by slowing or stopping monomer flow and waiting for the reaction to catch up. If it doesn’t catch up after a reasonable time, the phase commands the procedural controller state to go to Hold so that the operator can handle the exception. Exception handling can be initiated by the event that is generated by the operation of an interlock. This was called propagation of an interlock in 88.01. Propagation is treated as a separate activity (pardon me, function) in 88. It seems closer to the truth to say that any monitor, phase, or other control function must actively look for a message or value that indicates the state of the interlock. True propagation requires a program that knows how to send the interlock event to all interested parties, and the parties must somehow have an open receptor for the event. This seems to be overly complicated and requires more configuration. At some point, an operator may be called, if an alarm has not already done so. Hopefully, the operator will have time to determine the specific exception, find its entry in the Standard Operating Procedures manual, and do what the manual says to do before the exception predicted by the alarm actually happens. How do you handle an exception? No problem. You figured that out back in the planning stage. Otherwise, the answer has to be “That depends on the exception.”

Modes and States Almost all machines have modes and states. Assuming there is no perpetual motion, every machine has at least two states: active (on) and inactive (off). Almost every controlled machine has at least an automatic and a manual mode. For example, your car has a mode selector in the form of a gearshift. The state selector is the ignition key switch—Accessory, Off, Run, Start. The modes of travel are reverse and forward in various gears, or Park. Batch processes, particularly those that are automated, also have modes and states. SP88 described modes and states in the hope that vendors would use those terms to describe the same control behaviors no matter how they were implemented. The goal was a common operator interface. Imagine the mistakes that could be made by an operator working on two different systems or transferring to a different system in another part of the plant. Equipment entity modes and states are described in Chapter 3 of this book. Batch process modes and states are described in Chapter 9. Not much was said in 88 about what parts of a batch process have modes and states, except that equipment entities and procedural elements have them. Controlled equipment constitutes a machine, so it has modes and states. Procedural elements are not machines, so that abstraction goes too far.

batch chap 14.qxd

4/25/2006

3:16 PM

Page 233

Further 88 Clarifications

233

There is a “machine” called a procedural controller that executes procedural elements. Without a procedural controller, the procedural elements are just plans waiting to be executed. There is also a “machine” called a state machine that determines the state of a procedural controller, according to the state transition diagram in Figure 18 of 88.01 (Figure 9-3 in this book). A state machine is a mathematical abstraction, not a specific implementation. 88 does not discuss these machines because they are implemented in various ways by various vendors. The details are needed here to explain what is going on. SP88 decided that they could live with definitions for three modes: automatic, semiautomatic, and manual. The procedural controller has more states than active and inactive because exceptions have to be handled.

Modes This section offers recommendations that you should consider even if you have always done batch control another way. Some of them couldn’t be done ten years ago. An automated system is a deterministic system when it is in automatic mode. Deterministic means that it is only capable of behaving in ways that were planned by the designers. It is not reasonable or possible to plan for every conceivable exception. There are times when human abilities are needed to find the problem and fix it. The mode of procedural control belongs to the operator. An automated procedure will never change the mode. What, never? Well, hardly ever. This is a comfort to the operator, who knows that computers are not to be trusted. Actually, the first brass and steel pneumatic controllers had no mode switch. Operators demanded a manual mode so they could do things that the automatic controller couldn’t do, like shut a valve tight because the zero flow setpoint let it bounce. Automatic mode allows controllers to do what their designers intended them to do. The operator is denied access to the modes of the equipment entities and possibly to subordinate procedural controllers while the batch procedural controller is in automatic mode. This ensures deterministic batch process control. The plan can include requests and responses from operators, using the alarm system to attract their attention. Semi-automatic mode allows an operator to change the plan by altering the sequence of phases, perhaps by inserting new phases or deleting others in addition to moving phases around. There’s no excuse for failing to plan to adjust the batch if adjustment can fix a bad analysis, though. Perhaps a batch can be bumped for a higher priority batch, on rare occasions. An operator could add a sequence of phases in order to move a bumped batch to storage or waste, depending on a variety of factors that were too numerous for the planners to handle. An operator may want to prevent something bad from happening by marking certain paths between phases as blocked. The mode is returned to automatic, and execution resumes until the path to the next phase is blocked. The mode changes to semi-automatic and sounds an alarm. An alarm is required whenever the system changes a

batch chap 14.qxd

4/25/2006

234

3:16 PM

Page 234

Chapter 14

mode. Perhaps paths can be blocked while in automatic mode, if there is no possible way to harm anything. The equipment entities remain locked in automatic mode while the process is in semiautomatic mode, which means that operators can’t directly manipulate equipment control. This makes it relatively easy to go from semi-automatic to automatic mode without a lot of checking and setting to get the equipment back to planned states. Manual mode allows an operator to have complete control of the equipment entities, as required. Modules that contain modules may make the contained modules visible and individually operable. The operator changed the process mode to manual because something unplanned happened, and there is no way to predict what will need to be done. When the operator is ready to leave manual mode, the process is not in its planned state. One way to handle the return from manual mode is to use exception handling in each equipment phase. The procedure for transferring from manual mode must compare the state of the equipment now to the state of the equipment when the mode changed to manual. The previous state must be restored, if conditions permit and if the procedural controller stores the previous status. This is similar to computer interrupt handling, with the addition of checks to see if the previous status can be restored. An operator may manually complete a phase, which means that the phase should not be restored to its previous state. Either the phase detects that it is done and starts the next one or the operator has to manually signal the procedural controller that the phase is done (or should send its report). This might be possible, but there are so many things that an operator can do in manual that it may be best to require that the operator get everything lined up again. Each active phase would still have to verify that the equipment is in the proper state for automatic control to resume. The procedures for switching between automatic and manual mode are much the same as for switching between redundant controllers. The operator must transmit the current state of the process to procedural control before procedural control can resume deterministic execution. If the transmission can’t be automated then procedural control must be able to verify that the transmitted state of the process really is the current state of the process. State has been used here to mean all of the individual states of procedural control and the equipment entities, not just states of the procedural state machines.

States The process has states in which it exists. These states tend to have the same names as recipe operations, like initialize, charge, and react. Procedural Control has states in which it operates, like Idle, Running, Hold, Stop, and Abort. Running is the normal state, unless the product isn’t selling, in which case the normal state is Idle. All other states are exceptions. Both process and procedural control states are described

batch chap 14.qxd

4/25/2006

3:16 PM

Page 235

Further 88 Clarifications

235

relative to a specific batch. One batch may be initializing and another may be reacting. Either batch may be running normally or holding. The execution of any recipe or procedural element is controlled by the same state machine that is described in Section 5.7.2 of 88, regardless of the procedure. That is, the states are not related to specific products. The effect of the active state appears in the controlled equipment, again, independently of the product being made. There is at least one state machine for each active batch recipe in Process Management. There may be a state machine for each unit, because a unit can only run one unit recipe at a time. The effects of having units in different states will have to be evaluated to see if unit states should be allowed to be independent of the batch state. Can a process have multiple states in one batch? Yes, it can have as many as the number of equipment entities that process the batch. Can procedural control have multiple states in one batch? Possibly. The maximum is the number of relatively independent entities that have procedural control. The actual number depends on how independent they really are in a particular process. Equipment entity states are not procedural control states. A block valve may be open, traveling, or closed. A regulating controller is within tolerance of zero deviation between measurement and setpoint, or it is not. Procedural control has states because the process is deterministic only while control is automatic. There should be a good reason for making process control non-deterministic. If that reason occurs with annoying frequency then the plans should be altered to take care of it without leaving automatic mode. Things are not that simple. Procedural control can not adjust a valve position switch or fix a stuck valve, to name a few examples. The plans must allow for human intervention in a deterministic manner, and so we have the Hold state. The mode remains automatic, but the process is suspended to give humans the time needed to find, diagnose, and fix the problem. If a part of a phase must not be interrupted by Hold then it must be possible to state that in the procedure. The Resume command causes control to resume from a known state because the plans can’t be altered in automatic mode. Pause allows the present phases of the plan to reach relatively harmless states before the process is suspended. Hold is supposed to act quickly, while Pause allows the active phases to come to break points. Both states require code in a phase to provide the desired function. There is no Restart from Pause because the phase is supposed to pick up where it left off. Most people find that Hold is all that is required. Humans and sometimes exception handling may detect a problem that calls for discarding the batch before it is complete. This is because whatever went wrong can’t be fixed before the batch goes bad. For example, an overbalanced crane with a heavy

batch chap 14.qxd

4/25/2006

3:16 PM

Page 236

236

Chapter 14

load falls over and drops the load on the steam and cooling headers from utilities. This is not something that happens frequently. The Stop command can be used to bring the process to a low energy state in a deterministic and orderly manner. Perhaps a polymerization reaction has to be poisoned before it becomes uncontrollable. Another example is a cracked weld that is spraying process material that could really harm a human or just needs ignition to start a roaring fire. The Abort command is used to deterministically remove energy from the process and to stop flows by closing valves as quickly as possible. This would be the correct response to an immediate hazard like a cracked weld. There is another interpretation of Stop. It assumes that people will construct phases that will not shut down if something goes wrong. Perhaps that’s a valid assumption, but there are several ways of avoiding open-ended phases. It also assumes that modes and states are assigned to every phase. This allows an operator to go to any phase and select the Stop state to make the phase execute its stopping logic, in order to end a phase that has become immortal. Many people would say that the phase code is improperly constructed. Suppose that a phase is written to adjust the pH analysis of a product. If it is too low, add reagent A and wait, and then test again. Else, if the pH is too high, add reagent B and wait, then test again. You can see that the possibility for endless repetition has been set up. If you have to write such a phase, add an iteration counter that will stop at some point and ask the operator what to do. The pH control really belongs in a control module. Hold, Stop, and Abort are ways to handle exceptions while in the automatic mode. Sadly, there are times when the plans did not allow for some process exception, and so deterministic execution can not fix a problem. The semi-automatic mode allows an operator to prevent the process from executing the next phases of the plan, by suspending the process at a well-defined point. Unlike Hold, this does not work well if an executing phase will take a long time to complete. If semi-automatic is used and such phases exist, it must be possible to plan to terminate the phase if the mode is not automatic. The operator can set the Hold state first and then change the mode to manual if access to modules is required. Semi-automatic mode will not be allowed while the procedural control state is not Running, because each phase must run to completion before the operator can make changes to the sequence of phases.

Propagation of Modes and States If you accept the policy that says that the operator can only watch (and respond to requests) while the procedural control mode is automatic, then you need a way to propagate the mode of the batch procedural controller to all subordinate procedural controllers and equipment entities. This is not a simple copy to all modes. It is a condition that allows an operator to change modes or not.

batch chap 14.qxd

4/25/2006

3:16 PM

Page 237

Further 88 Clarifications

237

Allowing parts of the process to become non-deterministic is not good policy, unless such actions are part of the plan and the operator is restricted to a few possible actions. Sometimes it is possible to allow manual operation of equipment that is not currently in use and so does not affect the plan. Determining that the equipment is not in use can not be done by a simple propagation of modes. Perhaps acquire and release could be extended to modules that are owned by the unit. The operator would acquire a module for manual control, blocking a phase from using the module until it is released. If a phase acquired a module then the operator could not acquire that module. Procedural control states must propagate from the batch level controller to any subordinates. These states have no effect on equipment entities without procedural control. States might propagate upward from subordinate controllers, depending on your tolerance for mixed states in process control. Perhaps now you see why 88 is vague about the application of modes and states, and especially about propagation. Different vendors do things in different ways. It is not possible to standardize something that changes the way the user base will use a vendor’s offering, and so consensus can’t be obtained on adding details to a standard. Normally, the user base does not want change because new training will be expensive. There are cases where large users have been able to get a vendor to change something that has caused too many mistakes. It would take a very large user of diverse systems to unify the operator interface to batch control. Once that unification had been accomplished, then it could be standardized.

Recipe Operations If the procedure for making a product were written as a single procedure, it would consist of groups of conditional code that issued commands to basic control. There would be no building blocks and no separation of recipe and equipment procedures, just as it was not long after the last dinosaur died. How can a single procedure be made into an 88 recipe? First take each command and its conditional code and call it a step. Require that the steps be executed in the equipment because at that level they remain the same for any product recipe procedure. Then group the steps into phases according to their process actions. Require that phases be executed in the equipment because they are still specific to the equipment and not to any product. Also require that the phase have steps to support the running, holding, resuming, stopping, and aborting states of procedural control. Now group the phases into operations and the operations into unit procedures. Require that each operation and unit procedure begin with a phase that checks to see if it is OK to proceed. Also require that each phase check conditions before setting up, running, and ending the phase. Do this because semi-automatic and manual modes for procedural control exist, which allow procedural elements to be moved around. Unit procedures, operations, and phases become building blocks for recipes. Steps

batch chap 14.qxd

4/25/2006

3:16 PM

Page 238

238

Chapter 14

remain hidden in the equipment. A recipe author may arrange the blocks to apply any reasonable order of process functions to a product. A unit procedure recipe block contains operations and nothing else. No phases are required to do something across operation boundaries if the phases are properly designed. See “The Agitator Problem” below. At first, SP88 struggled with the concept of requiring that only one operation be active in a unit at a time. This requirement has the advantage of reducing the opportunities for a recipe author to make mistakes, reduces the testing time for inter-operation dependencies, and reduces the amount of exception handling code. But the users, who may not have understood these advantages, wanted to go on doing what they were doing, as they do. The vendors either didn’t understand the advantages or didn’t understand that customer management is required when selling systems. The customer is always right, eventually, but first you have to try to persuade them that they might be wrong and that your system is best for them. Operations are, after all, just ways of organizing phases and the process functions that they represent. If a user feels that recipe authors must be able to parallel operations, why, it’s their plant and their budget. That doesn’t change the fact that it is good practice to design each operation so that it fully occupies the unit and can’t be shared with another operation. There is no question that there is only one unit procedure in a unit at a time. That’s what makes it a unit procedure.

Alternative to Unit Procedures There is another style for subdividing procedures that does not use unit procedures. The recipe procedure, for example, is a series of operations. None of the operations perform transfers and there are no parallel operations. The process cell does all recipe procedure processing. Processing begins by selecting a suitable unit to perform the first operation. The first operation is given to the unit for execution of its phases. The unit continues processing operations until process cell procedural control comes to an operation that the unit will not be able to process. The process cell finds a unit that can do the next operation and performs the transfer of the batch from the previous unit to the next. There are no transfer procedural elements in the recipe. Something in the previous unit has to clean up after the transfer. Operations continue in the selected unit until an operation will not run in the unit and a transfer is required. When the last operation in the recipe procedure ends then the batch is transferred to product storage. This method is suitable for processes that require no unit preparation before a transfer. If the unit must be prepared then a unit recipe is required that is scheduled to start at a specified time or at the request of the source unit. Preparation may

batch chap 14.qxd

4/25/2006

3:16 PM

Page 239

Further 88 Clarifications

239

include cleaning, sterilization, charging solvent, and/or adjusting the jacket temperature. The next unit must be able to tell the source unit that it is ready for the transfer.

The Agitator Problem An agitator, cooling system, or similar function generally has to stay running from one phase or operation to the next. Some people dedicate a phase or even an operation to the task on the grounds that an active procedural element must be running to monitor the equipment. It all depends on how you design the equipment. Things like agitators can be provided with on/off switches and alarms. The switch accepts commands to change state just like any basic control module. You wouldn’t ask an operator to hold the switch on, and you wouldn’t dedicate an operator to checking the status while it was on. That’s what alarms are for, to enable operation by exception. You could have an interlock to stop the agitator if the blades are not sufficiently covered, if that matters. Then you can turn the agitator on at the start of the initial charge phase, knowing that it won’t actually start until there is enough level. An exception monitor will see any event or alarm and change the procedural controller state to Hold. If there’s no monitor then each phase that requires the agitator should check it, if the alarm is not enough to get the operator’s attention. If you use a pause state or semi-automatic mode then you don’t have to do something special because the agitator phase won’t end. In fact, the process usually requires that the agitator keep running if it was running.

The Common Valve Problem A common valve is one that has an inlet that belongs to one unit and an outlet that belongs to another unit. Typically, a common valve is the dump valve of one unit and an inlet valve for another unit. Two units can not own one valve. There are as many solutions to the problem as there are designers that work in isolation. 88.01 might lead you in the direction of calling the valve “common equipment.” This would mean that the control module that contains the valve has two instances of the same routines that are used by common material sources and the like to handle requests for acquisition. The units on either side of the valve would have to acquire it, but nothing else can acquire the valve. This seems to be unnecessary complication for a single valve. Modern control systems allow the discrete state (device) control function to have an interlock input. This allows two different sources of commands to control the valve. Let the source unit own the valve and the open/close command for the valve. Let the receiving unit own the interlock. The source can command the valve to open at any time, but the valve will not open unless the receiver has enabled the interlock. See Figure 14-3.

batch chap 14.qxd

240

4/25/2006

3:16 PM

Page 240

Chapter 14

Figure 14-3 The Common Valve Problem–Two Units The left side of Figure 14-3 shows the common valve between the upper and lower unit. The unit borders split the valve, which is not possible because the valve has only one point of control at its control module. The right side of the figure shows the common valve completely inside the border of the upper unit. The control module for the interlock switch is completely inside the border of the lower unit. A logical or real wire connects the interlock switch to the valve. This configuration lets either unit close the valve and stop the transfer, but only the source can open the valve. If your design philosophy says that a unit owns all of its inlet valves then you can turn the configuration around. Let the source control the interlock and the receiver control the valve. Either way, both units will want to know the actual valve position. The situation is different if more than two units are involved. See Figure 14-4. Configuration A shows that the upper unit is a single source to two or more receivers. The upper unit owns the valves and makes the selection. The lower units can prevent flow with their interlock switches. Valves and interlocks could be swapped vertically if that better suits your purpose. Configuration B shows the case for a common receiver. Configuration C shows multiple sources and receivers. Now you need a separate header control module that can be acquired. One of the source units acquires the header module and selects a destination. Each source and destination may still want to have an interlock on their valve from the header. It is not practical to have the destination own the header valve because the acquirer will set the path. The final complication is a multiple simultaneous transfer situation, requiring many valves. Imagine the holding tank facility in a large brewery with 100 tanks. About 1000

batch chap 14.qxd

4/25/2006

3:16 PM

Page 241

Further 88 Clarifications

241

Figure 14-4 The Common Valve Problem–More Than Two Units valves are required to do simultaneous transfers and separate the product from the cleaning solution. Each source must ask for a route and acquire it, up to the capacity of the header network. The algorithm for creating routes through the maze can be quite interesting, especially if each route requires a pump. You may want to use bit masks to control groups of valves with selected bit patterns. Where there is a choice of methods for handling transfer valves, pick one and apply it consistently. People make mistakes when different methods are used, like reaching for the turn signal to shift gears when the gearshift is on the floor (as in a rented car). If you are the type that enjoys negotiation, then you can forget the interlocks and let every vessel own its drain valve. The downstream unit then has to negotiate with the upstream unit to get it to open its drain valve. The downstream unit must trust the upstream unit not to open the drain valve on its own. Perhaps your exception handling group will require the interlock anyway.

Batch Control Activities Recipe Translation The amount of effort that is required to translate a general or site recipe into a master recipe depends on the degree of matching between the general and master procedural elements. 88.00.03 contains a thorough explanation of general recipes and the translation process. 88.01 recommends that you keep everything on a process function basis until you get to the equipment phases. This makes it very likely that a process function that is required by a general recipe will have a counterpart in the set of master recipe procedural

batch chap 14.qxd

4/25/2006

3:16 PM

Page 242

242

Chapter 14

elements. Further, it is very likely that some equipment entity has an equipment phase with the same name that performs the process function, no matter what kind of equipment actually does the processing. When you are faced with an operating process that does not have an 88 recipe structure then it is best to start with the equipment and not the recipes. Identify the process functions of each piece of equipment, perhaps finding other functions that the equipment could perform. Combine as many similar functions as possible into one equipment phase. Then build a set of equipment phases and write descriptions of their behavior. Give the descriptions to the recipe authors. Ask them if this is an adequate set or if they need other process functions. Additional functions should be rare, given that this is an operating plant. Give the final descriptions to the control engineers. Ask them to upgrade the equipment control systems so that they will do what is described. If that is not possible, call a meeting with the authors and the engineers and find compromises. Again, this is an operating plant so there should be few problems. Now the recipe authors can use the final descriptions of equipment capabilities to create operations and unit procedures that will be used in recipe building. Then all of the existing recipes can be translated into 88 recipes that can be handled by new Recipe Management, Process Management, and Unit Supervision control activities.

Executing Procedural Elements 88.01 does not suggest how procedural elements may be executed because that seemed too much like implementation. And yet, some model implementation would have made the process of executing a recipe procedure by passing control to equipment procedures much clearer. The following is an attempt to provide a model. Procedural control elements are executed by procedural controllers that can scan procedures and follow paths, as well as communicate with other procedural controllers. Each active batch needs at least one procedural controller. The top-level procedural controller for a batch is created (or assigned from a fixed set) in the Manage Batches function of Process Management. If unit procedures are used then there is a procedural controller for each unit. The unit recipe procedural controllers can communicate with procedural controllers in equipment entities. An equipment procedural controller may be quite different from a recipe procedural controller. Manage Batches creates unit recipes from the control recipe and sends them to the units at scheduled times or when requested by a running unit recipe. Following a chain of recipe procedural elements must eventually end in elements that are implemented by equipment procedural elements. If all of the equipment procedural elements are phases (the usual case) then the following takes place after Manage Batches has found a unit recipe and selected a unit:

batch chap 14.qxd

4/25/2006

3:16 PM

Page 243

Further 88 Clarifications

243

Manage Batches gives a unit recipe to the Unit Supervision recipe procedural controller. The procedural controller scans the unit recipe to find the first operation. The procedural controller scans the operation to find the first phase. The procedural controller establishes a connection with the corresponding equipment phase. (Failure to connect or the receipt of a negative response will invoke exception handling.) The procedural controller sends a message that contains parameter values and gets a positive response. The procedural controller sends a message that is a request to start and gets a positive response. The equipment entity performs the steps associated with the equipment phase. At the same time, the procedural controller waits to hear completion status messages from as many phases as it has started. The equipment phase ends and the equipment entity returns a successful completion status message. The procedural controller closes the connection and scans the operation procedure along the path described by the recipe operation to find the next phase to do. Eventually, the procedural controller finds no more phases left to do, so it scans the unit procedure to find the next operation. … And so on until there is nothing left to do in the unit procedure. The procedural controller then notifies the Manage Batches procedural controller that it is done and goes to sleep, unless it runs a procedure that monitors the idle unit. When the Manage Batches procedural controller has completed the control recipe it is either destroyed (if created) or becomes idle while waiting for the next control recipe. Note that there is nothing in the above procedure about doing any calculations.

Recipe Computations 88.01 describes three kinds of process control: coordination, procedural, and basic. They are all required in order to cause process functions to happen at the correct time and place. Process functions also need parameters, which 88.01 has put in the formula category of recipe information. Unfortunately, the standard did not discuss the need to compute parameter values during execution of the recipe. Some recipe parameters may need to be computed in order to compensate for analysis of raw materials and/or the heel left in the unit by the previous batch, if any.

batch chap 14.qxd

244

4/25/2006

3:16 PM

Page 244

Chapter 14

Repeated computations may be made to predict the endpoint of a reaction or to change the gain of a reactant flow controller. Temperature-versus-time curves may be required for different crystal sizes in different products, corrected by current conditions. There is also Statistical Process Control. Computations are required to scale the inputs to a recipe when the control recipe is created, but these may be built into the application that creates the control recipe. Computations that have fixed algorithms may be built into equipment. They should be built in if they compute equipment properties or derived measurements, like the bulk temperature of a batch of polymer as it polymerizes. Equations for calculating values could be written directly into each master recipe, but that creates other problems. There is no standard language for writing expressions or referring to remote or historic values. You will have to convert every recipe to the new way of doing things when your system vendor becomes unsuitable or brings out a new system because computing technology has changed. SP88 made a major contribution to the art when it separated the tools that are required to make products (equipment entities) from the description of how to use those tools to make a product (recipe). The separation is done with recipe building blocks that are jointly created by recipe authors and the control engineers that design equipment entities. It seems natural to separate computations from recipes by using the same concept. A recipe author, as a chemist, probably can’t write programs to control process equipment, but a recipe author needs to create computations. Building blocks allow computation to occur as part of a recipe procedure. The concept only works if a control engineer is not required to change the computation. Also, building blocks are impractical if every master recipe needs a different equation, because each computation block will require a unique name, within a cell. Usually an equation or algorithm is a tool for solving many problems with different parameters, so this is not a problem. It is possible for a control engineer to build a general-purpose calculator that takes math operators and parameters as text strings. This may not be useful for arrays because there is no loop capability. Programmers and recipe authors could create a set of computational functions for the kinds of computations that the author will need. A calculator with functions should be able to solve many problems with simple programming. A recipe author could be taught to construct equations from some language learned in college, like BASIC or PASCAL or C. The application that processes the language will need very robust defenses against a recipe author’s mistakes, more robust than any programmer would like. The math operators and their order of precedence are very similar among popular calculators or programming languages. The big problem lies in the methods for obtaining data for the operands. Values must be obtained from the recipe, from the equipment,

batch chap 14.qxd

4/25/2006

3:16 PM

Page 245

Further 88 Clarifications

245

and from the history of this and previous batches. Results must be stored in recipe parameters, equipment parameters, and history files. The methods and naming rules have not been standardized for recipe parameters and history file access. There are many data types, such as integer, float, double, character, and string, all in various sizes. The data values may be simple variables or organized into arrays or structures. Declaration statements are required to specify the type and organization of the data, but these have not been standardized. The data issues may force you to convert the contents of computational building blocks when you change batch control systems, even though the symbols and their precedence in the equations are identical. This suggests that the recipe author should write all of the statements in the building block. The recipe procedure should contain a recipe computation block that invokes the computation in the equipment computation block. The recipe block can pass recipe parameters to the equipment computation block, just as it does for process function blocks. Note that an equipment computation block does not have to be part of a unit. The application program that executes computation blocks may live in each unit or process cell, or anywhere that computation and communication resources are adequate for the task. Complex computations may be done in a separate computer to avoid overloading the real-time processors. There may be a problem with naming computation blocks if they are not independent of the equipment.

Operator Interaction Automated batch control systems need to be able to interact with people when there are manual process functions to be performed, sample data to be entered, or signatures required at various places in the procedure. 88 mentions this in discussing the process control activity but provides no details. The following discussion is for those who create control systems, either as vendors or as users modifying a system. The first consideration is that the operator is probably not sitting there waiting for your message to appear. The alarm system should be used to direct the operator’s attention to a human interface. It should be easy to get from acknowledging the alarm to the dialog window. It is a really bad idea to pop up dialog boxes when the operator is not ready to deal with them. Distracted operators make mistakes. If the dialog is initiated by a recipe phase then it makes sense to have an equipment phase that handles the dialog. Dialog phases could be configured for each dialog, or one dialog phase could provide the alarm and screen access using the words defined by parameters. The dialog will have at least one request and one response by an operator. The response may be keyboard input or it may come from a card or barcode reader, or even an RFID tag. The usual means are required to decode and check keyboard entries, and

batch chap 14.qxd

4/25/2006

3:16 PM

Page 246

246

Chapter 14

to display an error message somewhere between “Illegal entry, OK?” and “Huh?” Checking entries requires parameters that contain the entry data type and limits.

Procedure Function Charts This subject is presented as a Guideline for Languages in Section 6 of 88.00.02. The graphic display of procedural control as presented in IEC 60848 (circa 1985) is popular. It seemed to be a good fit for displaying procedural elements and their order of execution. So, SP88 proceeded to see what needed modifying, but any committee starts thinking about the worst case and loses the simplicity. IEC 60848 describes a simple structure in which each step is followed by a transition condition. If the transition condition expression below an active step becomes true then the active step turns off and the following step becomes active. There are rules for choosing paths or splitting into parallel paths and later rejoining to one path. Any path through a set of procedural elements can be described. The rules are easily learned. The result is called a sequential function chart (SFC), which is one of the languages of IEC 61131-3. The first problem is that procedural elements don’t have transition conditions until you get down to the steps below a phase. The procedural element simply does what its procedure tells it to do until it is done. The procedural function chart (PFC) could have used transition conditions labeled Done. They aren’t needed at all on simple paths, but they are needed for parallel splits and choices. You might think you want to see the names of the choices by the transition conditions when there is a choice, but the names of the following phases make that unnecessary. Perhaps the need for transition expressions on the execution path display arises from vendors talking to managers that have had no training in operating the process. A trained operator knows exactly where to find out what will make the phase end, should something happen to his or her memory. The endpoint value is in the list of parameters that are passed to the phase from the recipe. The committee came up with two kinds of transition conditions. The implicit version showed no bar across the path. The explicit version showed two bars across the path. When the recipe phase becomes active it starts an equipment phase that has no end. The recipe author writes an expression beside the split transition condition. When that expression is true then a message is sent to the equipment phase to stop what it is doing, and the top bar becomes lighted or otherwise indicates that it is active. Eventually, the equipment phase ends and sends a message back to the recipe procedural controller. The second bar lights up, but only briefly. The recipe phase immediately becomes inactive, and the next recipe phase becomes active. There are methods for specifying choices and to execute phases in parallel.

batch chap 14.qxd

4/25/2006

3:16 PM

Page 247

Further 88 Clarifications

247

There are three things wrong with explicit transitions. First, an equipment phase that will not end without a message from possibly another computer is insecure. Messages should be used to start equipment phases and receive notification when their process function is complete. Phases should be written to run autonomously until they meet criteria in the phase for being done, or exceed their allotted time. The criteria come from the formula, but the phase logic makes the comparison. Second, the recipe has to have a standard language for writing transition expressions. There is no standard expression language, so there would be no transportability of recipes from one machine to another. Third, the recipe procedural controller has to read process values and solve expressions. Neither of these is necessary if there is only communication between recipe and equipment procedural elements. The operator should be able to select the recipe element to get a detailed view of the equipment procedure, where the transition condition should be obvious. As the concept of recipe transition conditions began to sink in, one vendor objected because their system allowed one transition condition to follow another, with no intervening step. Another vendor objected to the use of “dummy” steps in order to make certain choices. Section 6 of 88.00.02 gives the details, but they are too cumbersome to use in practice. The whole thing fell apart under its own weight, taking the decorated boxes for procedural elements and Gantt chart box heights with it. There is still value in having a standard operating interface for recipes. The problem is that the vendors believe that a clever operating interface is a differentiating feature. Perhaps a simple procedural function chart could serve as a base for vendor embellishment. It isn’t a sequential function chart and users should not show transition conditions on it. The operator knows the behavior of phases, but not how the recipe author put them together this time.

A Word about Control Systems A wide variety of batch control systems is available, but only half as many as there were ten years ago. This section discusses a few of the differences among systems that may matter to you.

Data Owner Data may be owned by a big database in redundant servers. Independent sales reps that sell services benefit from this because they can configure in the database without requiring hardware to be present. The disadvantage is the inability to respond rapidly to the need for change. A new instrument that measures new properties may be unusable while the vendor takes more than a year to design, recompile, and test the big database and all the applications that use it.

batch chap 14.qxd

4/25/2006

3:16 PM

248

Page 248

Chapter 14

Data can be owned by field devices or by distributed controllers. Some advantages are on-line configuration, no extra work required to maintain the database, and no possible difference between what’s in the device or controller and what’s in the database. The new instrument goes on-line immediately. The disadvantage is the need for hardware or simulators for initial configuration. It is possible to have an initial configuration database that is loaded into the equipment, when that is possible, and then discarded. Backup copies of the distributed data allow spares to be loaded with a copy of their part of the current control configuration.

Programming Languages Writing code for a PLC is like writing assembly language code. There are lots of cryptic symbols and numbers. You can simulate PLC coding by putting pebbles in your shoes and then walking a mile to get to a goal that is 100 yards away. At least, that’s what it feels like if you have written scripts before. Things may have improved in the past ten years, but there are user base issues. A script is much closer to a modern language. You can read it without having to look up symbols and numeric memory locations. A script language is more concise and reduces the number of errors caused by keeping track of numbers instead of names. The difference between a script and a program is that the script does not need to be compiled. Table-driven software is still out there thirty years after its introduction, which is a tribute to the power of its user base.

Displays Continuous control may be monitored by a single graphic display of the equipment. Batch control needs two displays, one showing the equipment and another showing the recipe in the context of its recent past and immediate future. All displays should support selection of something to show in more detail. Top level displays for a process cell include an overview of equipment, an overview of batch processing and an overview of critical alarms. Similar overviews may be needed for groups of cells. The equipment overview should show just the status of all units, utilities, and storage facilities. Selecting any status brings up a detail display for that equipment. This display has a selectable field that identifies the recipe that is using the equipment, if any. Unit details allow selection of lower equipment entities, which also identify the recipe in a selectable field. Acquired modules should be shown with the unit or be easily selected. The batch processing overview should show the recipes that are in process, pending, and recently completed. The display is usually a table that identifies the batch, recipe, unit(s), and timing. Selecting a recipe gets the recipe detail display, which also identifies the equipment being used. Selecting a unit gets the unit detail display, which also

batch chap 14.qxd

4/25/2006

3:16 PM

Page 249

Further 88 Clarifications

249

identifies the recipe being used. An operator should be able to select either equipment or recipe details from any display. The alarm overview is like the continuous process alarm overview, but there are two kinds of alarms, either in one list or two sorted by equipment and recipe alarms. Only active alarms are shown on the display. The operator should be able to choose the minimum priority of the alarms shown. Selecting a recipe alarm gets the recipe detail, centered on the alarm. Selecting an equipment alarm gets the equipment detail at a level appropriate for the equipment. A display is required for messages to the operator that require response. Do not disturb whatever the operator is doing. Generate a message alarm that will call the operator’s attention to the automated request. Let the operator decide if it is safe to drop the present activity and go to the message screen. Always generate an alarm, even if the message screen is already displayed, because you don’t know what the operator is doing. Nuisance alarms could be reduced by delaying the alarm for a few seconds if the message screen is displayed. Don’t generate an alarm if the operator enters something. A recipe detail only shows part of the procedure because an 88 system has both recipe and equipment procedural elements. Selecting a recipe procedural element on a recipe detail display should bring up a display of the equipment procedure, if possible. The format may be different from the recipe procedure display. Selection should provide additional detail if that is available. All except the top level displays should have a way to go up a level in detail, so that the operator can get back to the big picture after examining some detail. Equipment displays should recognize that modules are containers that conceal their components while the module is in automatic mode. Only the interface is visible. If the module is in manual mode then contained modules should be shown for manual operation. This could be done by allowing access to another level of detail when the module mode is in manual mode. Operators should build their own displays, if at all possible. There is no better way to train the operators in the use of the displays. The displays will not contain things that the operators consider to be distractions, nor can the operators complain about missing details. Engineers need configuration displays that allow configuration to occur in context with other values. System managers need displays for network and processor loading, as well as the very occasional software upgrade. If you need hourly virus updates, then IT is not doing its job, and you are not isolated from the business network.

batch chap 14.qxd

4/25/2006

250

3:16 PM

Page 250

Chapter 14

All of these displays should be designed by people who have operated, configured, and managed systems. Too often they are designed by software engineers that do not know the meaning of the parameters, and so you get alphabetized lists instead of meaningful groups. Bill Watterson’s Calvin, as Spaceman Spiff, needed to prepare his ship’s blaster from a menu-driven display. His frustration mounts over the course of six panels in the Sunday comic strip, an all-time favorite of computer users. In the sixth panel he says, “Oh wait, I didn’t enter the number of volts! That’s it! Type in ‘gazillion,’ hit OK! What?! ‘Invalid setting.’ DARN! Go back to ‘volts,’ highlight ‘gazillion,’ press ‘delete.’ Type in ...” At that point the enemy spaceship closes with him and he is blasted out of the sky. Clearly, Watterson was commenting on early Windows™, but he could have been talking about some batch control vendors’ displays today. Note that the reliability of display stations almost always depends on someone beside the control vendor. Control vendors don’t own much of their technology now that computers are everywhere. A backup display station is always a good idea.

Summary This chapter discussed unfinished concepts in 88.01. The definitions in Section 3 of the standard could be made normative with some work, after being proven by ten years of use. The Physical Model needs at least two more layers and needs clearer explanation of some layers, particularly the abstract modules that are not really physical. 88 Batch Control Concepts needs a section on “Equipment entities and the Purdue Reference Model” to prevent some misunderstandings with SP95. The section on Exception Handling could be made substantive with a discussion of the various ways that are available to handle exceptions. Such a discussion was included in this chapter. Modes and states were discussed. That discussion could clarify 88.01. The recipe procedural element called an operation was discussed, with some reasons why operations should not be run in parallel. An alternative to the use of unit procedures was described. The agitator phase problem was discussed as a possible reason for unnecessary parallel operations. The ownership of a common valve between two units was covered and a solution proposed. Batch Control Activities could benefit from more discussion of the translation problem, especially in regard to translating non-88 recipes into the standard formats. A discussion of the execution of procedural elements is in this chapter, which might be an aid to understanding procedural control in 88.01. 88.01 has no discussion of recipe calculations, so that subject was also covered in this chapter. Procedure function charts were discussed because they have not caught on as they appear in 88.00.02, with a recommendation to remove much of the complexity. 88.00.02 data structures were not discussed because they have matured from those early sketches.

batch chap 14.qxd

4/25/2006

3:16 PM

Page 251

Further 88 Clarifications

251

Sections 4 and 5 of 88.00.02 do not use the same data model. New work is needed. Batch Control System issues were briefly discussed, although they are not directly related to 88.

batch chap 15.qxd

4/25/2006

3:19 PM

Page 253

Chapter 15

Generic 88 Implementation Introduction ANSI/ISA-88.01 defines models and terminology in abstract terms that both users and vendors can live with. You’ll notice that the word “satisfied” was not used in the last sentence. The people who are satisfied are the people that have read their own meanings into the text. A concrete example is needed, which covers many of the abstractions from previous chapters. This chapter describes a batch control project mostly from a control engineer’s viewpoint. The batch control project is covered from process flow diagram to exception handling to its release to Operations. The project is divided into six sections. Each section begins with the knowledge required to do the section, followed by three things to be created and ending with a review of the work done. The review allows other people to either agree with you or question your mental capacity and parentage. Go no further until you can get through a review unchallenged. What you will end up doing is teaching operators how to make a product. The operators know basic control, or can learn it from another class. If batch control is automated then you have to teach the machines, too. Machines take you literally and do not innovate work-arounds, so you have to be very careful and accurate, leaving nothing out. That last thing is the hardest part. You don’t really teach the operator how to make a product. The recipe does that. You have to teach operators how to read a recipe (and authors how to write them). You also have to teach operators how to carry out the process functions specified by the recipe. Finally, you have to teach operators what to do when something goes wrong, to reduce the risk of doing any harm. As every good teacher knows, you must understand before you can teach. Bad things happen when there are gaps in your knowledge. That is why the project procedure in this chapter has you review your knowledge with experienced people each time that you make some progress in the project. Fewer reviews are required as you gain experience.

batch chap 15.qxd

254

4/25/2006

3:19 PM

Page 254

Chapter 15

This chapter will discuss teaching, operators, process functions, machines, and specific exception handling. Generic examples must be used because batch control is used in so many very different processes. This chapter will not discuss recipes. They have been covered in detail in Chapters 5, 8, and 11. The design of recipe building blocks is tied to batch process control and so that will be discussed here. We begin with equipment process control because we need to know the equipment capabilities in order to learn how to run the process. Then we can create process functions, and then we can create recipe building blocks. Some kind of recipe procedure is needed to get started, because that procedure implies the functions. If there is no recipe procedure, then a list of process functions and their descriptions is required.

Designing Batch Process Control Before there is the project there is the batch procedure. Before there is the procedure there is the plan, or a “What the heck is this material?” experience. From simple beginnings come complex projects. They start small because the human brain only weighs three pounds. Complexity must be reduced by dividing the project into smaller pieces for the same reason. Equipment layouts and procedures gain complexity as people add things to them. Modular design is the result of experience with ever more complex arrangements and procedures. 88.01 offers you a physical hierarchy from largest to small (but not smallest). There are also the process, control, procedure, and activity hierarchies, which are designed to give standard names to subdivisions of a batch process. Someone, maybe you, must understand the purpose and probable requirements of the batch control project. A small design team, six or less, may be required if one person doesn’t have the depth of knowledge and experience necessary to gain full understanding. The team’s initial job is to learn facts and educate each other to build a common understanding. The depth of understanding will vary from person to person, but that’s why we have teams. First, understand the business requirements: • Learn the motives behind the project. Understanding the reasons for the project should help you to avoid over- or under-design. • Ask for the estimated limits on project cost and the delivery date. The initial cost and schedule are moving targets, subject to negotiation (unless they aren’t). • Ask about sensitive things to avoid, such as environmental concerns. A project was started at a plant downstream from a paper mill on a polluted river. Dumping anything in the river would make the plant share the pollution problem with the paper mill.

batch chap 15.qxd

4/25/2006

3:19 PM

Page 255

Generic 88 Implementation

255

• Ask for a person in management to follow the project and be its champion when trouble arises. Try not to get involved in a project that has no management champion. Yes, there are stealth projects, but you could get a bad reputation by doing one. Work within the system, if one exists. Second, understand what there is to know about the process. Perhaps there is a process design group that has designed the process equipment and provided a flow sheet with instrument requirements and a process procedure. If not, then you have to start with a description of the process provided by a research lab or a pilot plant. The scientist’s description will give you an idea of the equipment needed and the basic procedure. You may need to understand some new technologies in order to select and combine equipment. When you have the equipment decisions then you can do the process flow chart and make the procedure more specific. You may be asked to design a process from a set of recipes. Find out all that you can about how the products are made from the existing recipes. At least you have a procedure. All you have to do is the process flow sheet, and maybe someone else can do that. If the project is a retrofit to an existing process then get your information from the people running that process. The process flow sheet for the process is established, as is the procedure. You may see some innovations that will save time or otherwise reduce costs. In any event, you will need to review your version of the process flow sheet and procedure with the scientists, engineers, operators, and business people. Discuss and sell your ideas for improvements before you invest too much effort in designing them. If Operations can’t or won’t operate what you designed and built then a lot of money has been wasted, and it’s your fault. Learn about the tricky parts of the process—don’t add water to concentrated acid, the batch turns to concrete in the presence of any iron, temperature overshoot will start an exothermic runaway, these cells are hard to kill, and so on. The process flow sheet should apply to one product or a class of similar products. It may show several of the same kinds of vessel if multiple units are used to reach the design production rate. Simplify the flow sheet down to the equipment that is required to make one batch. Choose the product procedure for the worst-case product, in terms of equipment used. If multiple product classes are specified, start with the most difficult procedure.

Know Process Design Now that you have an initial understanding of what you are supposed to do, it is time for the team to start thinking about how to do it. See Figure 15-1, which outlines a procedure for designing a batch process control system.

batch chap 15.qxd

256

4/25/2006 3:19 PM Page 256

Chapter 15

Figure 15-1 Procedure for Designing a Batch Process Control System

batch chap 15.qxd

4/25/2006

3:19 PM

Page 257

Generic 88 Implementation

257

Of course, you don’t really know the process yet because you haven’t designed it, but you’ve got to know something about it. The design procedure in Figure 15-1 contains stops so you can review your understanding with other people involved. The review may cause previous steps to be repeated, but it is best to build on sound foundations. Informal reviews should be held once each step has been started to ensure that you are heading in the right direction.

Find Process Operations This is the first step in dividing the design problem into manageable parts. Your head may be quite full with your understanding of the process, but now it is necessary to add many more details. Discover the details one process stage and operation at a time. You will need a structure for dividing the process into smaller sections of information. At this point, 88.01 offers the Process Model shown in 88.01 Figure 1 and described in Section 4.1.3, “Batch Processes,” or in Chapter 6 of this book. Begin by listing and describing the process stages based on your understanding of the procedure. At the same time, identify the vessel or vessels that will hold the batch while the stage is processed. These vessels and their associated equipment will probably become units. Some of the associated equipment may become common equipment, if it can be shared. If your stage requires more than one vessel in a serial fashion then your stage is probably too big. Consider reducing its scope. You are looking for what there is to know, not how to make it work. You will get lost if you are distracted by trying to find solutions at this early stage. Normally, the process is still too complicated at the stage level. 88.01 offers process operations as subdivisions of a stage. You will probably need to create a preliminary list of named and described process operations. Repeat until the procedure has been divided into stages and the stages into process operations. See Figure 15-2, where the procedure is split into three process stages. Each stage is split into three process operations. Your process may not be that symmetrical.

Find Process Actions Look at the procedure that is associated with a process operation. Find parts of the procedure that will cause process equipment to perform some process function on the batch, such as add material, add heat, agitate, or drain. These are probably process actions. A process action is too big if it does two or more things, like adding material and heating. It is probably too small if it just opens a valve or stops a pump. See Figure 15-3, which shows a process stage, its process operations, and the process actions for each operation. Identify the items of control equipment that touch the process and that are associated with the action, such as a sensor and a valve. If sensors, valves, or motors are missing from the process flow sheet then add them. Notify the process design team or whoever is doing the piping and instrumentation drawings, because other people need to know the mechanical details.

batch chap 15.qxd

258

4/25/2006

3:19 PM

Page 258

Chapter 15

Figure 15-2 Procedure in Three Stages and Three Operations

Figure 15-3 Process Stage in Three Operations and Three Actions

batch chap 15.qxd

4/25/2006

3:19 PM

Page 259

Generic 88 Implementation

259

Use a separate piece of paper or document for each process action. Give each action a name and add the names of the process operation and process stage that are parents of the action. Add the control and process equipment used. If you do this on a computer, use a table or a database so that you can sort the list by any of the items. This is handy for finding relationships between actions and equipment, and for checking duplicates. Simple control equipment does not need a drawing. Some process actions may involve enough equipment that a drawing is necessary for understanding. The drawing will be the basis for more detailed explanations. Your review audience will be grateful that you have drawings. Describe a procedure for the action, as if you were teaching an operator to perform the action. Very soon you will have a sense of deja vu about the procedures. Plan on developing a separate list of bits of procedure (call them methods) that can be described once and referred to in the individual procedures. For example, the method for operating a PID control loop is determined by the controller. If the controllers are the same then so are the methods for operating them. It is still necessary to uniquely identify each controller. Repeat until all of the process operations have been divided into actions. Look at the separate list of methods. See if the list can be reduced by combining similar methods. Doing this now saves work in the future.

Describe Basic Control You need to describe the Basic control (see 88.01 Section 5.1.1 or Chapter 7 in this book) associated with each actuator. You don’t want a detailed specification, yet. The description should be enough to tell an operator what to expect when setpoints and modes (other than manual/auto) are changed. Chapters 3 and 4 discuss basic control, but don’t call it that because 88 had not been introduced at that point in the book. Look at each set of control equipment that is used by each process action. Describe the basic control functions (regulatory, discrete, sequential) that go with each valve or motor. Describe any sensors that are not involved in a control function that has a valve or motor. Again, plan on duplicate control functions. Describe each control function once, and refer to it in each basic control description. Repeat until all of the basic control required by each action has been described. There are no duplicates because each piece of control equipment has a unique identifier. There are many duplicate control functions. Look for control equipment on the process flow sheet that wasn’t used by any process action. Find out why it was shown. Ignore any valves that are not controlled by a procedure, like steam line or process drains, and instrument block and zero valves. All of these should be manual valves. If not, check your understanding of the purpose of the valve.

batch chap 15.qxd

4/25/2006

3:19 PM

260

Page 260

Chapter 15

Review Understanding You should know how to operate the process, in terms of following the procedure of each action by manually operating the basic controls. Verify your understanding by describing your knowledge to people that should be interested and that can offer comments. It is better to have too many people than to leave anyone out. Anyone outside your field (well, practically everybody) may not know your jargon (shorthand) so expand such compressions. You really don’t want anyone to miss something that they should have noticed. There are charts that express the cost of fixing an error versus when the error was found during the life of the project. It is much less expensive to fix an error now than after the design is complete, and cheaper then than after the process is operating. You can’t prevent all errors, but you’ve got to try. In the terephthalic acid (TPA) example in Chapter 2, fine crystals plugged the instrument impulse lines and made flow measurements useless. Some scientist knew that the process would make fine crystals, but he wasn’t asked. Repeat this section until no one can find anything wrong with your preliminary design. Be sure that you have talked to all of the right people, including your management champion. Then you can be confident that you understand how to operate the process and that you have the support of the people that control the budget and schedule. Discourage change requests at every review. Present the cost-versus-time graph as the cost of making changes instead of the cost of fixing errors.

Know How to Operate This section of the design procedure will create small control modules and the phases to operate them. “Operate” means issuing commands to a module or person that will perform process functions. It does not mean direct control of valves and motors, as you did in the preceding section. The phases are described to the point that an operator would have few questions on how to use them. Here you will make the transition from a general procedure to one specific to the equipment. This is not difficult if you have done the previous work. The previous work did not require any reference to unique equipment identifiers called tag names. See Chapter 2 for a discussion of tag names. Now it is necessary to use unique tag names to locate pieces of controlled equipment. Unique tags come from the earliest days of control, when they identified unique items on a purchase order, in the plant, on the control panel, and on the loop sheets. Batch control systems are hierarchical. A unit owns its modules, and no one else can control them. Unique tags compound the problem of finding the same function in different units. Tags used in phases are already in the context of a specific unit—the one that is executing the unit procedure. Similar units could use the same tag names for modules and function blocks, except that today’s systems won’t let you do that.

batch chap 15.qxd

4/25/2006

3:19 PM

Page 261

Generic 88 Implementation

261

But you can use hierarchical tag names because modern systems allow 32 characters in a tag name. Let each tag name begin with a process cell name, then append a unit name, and then append the name of the module to the name of the sensor, function block, or actuator. As far as the DCS is concerned the combined names form a unique tag name. You may be able to make some rules about the fields in a tag name that will allow phases to refer to modules and control equipment by their short names, without the process cell and unit fields. Future systems may identify the naming problem and fix it, but don’t count on it. Current users will resist change. Look up the story of the Dvorak keyboard.

Create Small Modules The 88 Physical Model shows Control Modules and Equipment Modules. See Chapters 6 and 14. Both can contain modules of smaller scope. You need to convert the sets of basic control found previously to small Control Modules first. The larger ones will be created later. At this point, you must describe each module and its contents. You must also design the preliminary module interface for commands, status, and data. Begin with the descriptions of basic control that were the result of work outlined in the section “Describe Basic Control.” Copy each one and give it a simple module name. The unique tag names will be built later. You will need one module for each analog actuator or indicator. Discrete actuators and indicators may be combined into one module where that makes sense, like the three valves in a double block and bleed assembly. You will need to identify the modules within a unit that the operator or phase must use to do a process function. Name and describe the commands that the module can execute, usually setpoint and mode changes. Name and describe the status and data items that the module can make available, usually mode, process value, setpoint, and perhaps output and alarms. These items are called “module interface parameters.” The meanings of command, status, and data items will be repeated often as you build more modules. There is no reason to make the names unique because they will be qualified by the module name, as in “tag.parameter.” Assign a name and describe the behavior associated with the name. A high alarm is a high alarm in every module that has a high alarm. So are actual mode, process value, and so on. You can build a master list of names and descriptions for interface parameters. You may have modules that provide the same data by different methods. Reactor level can be a very difficult measurement because the contents are agitated. Many methods have been developed, including the use of a mass balance model that is calculated from integrated inflows and outflows. The parameter “reactor level” is the same for any module that provides it, no matter how the measurement was obtained.

batch chap 15.qxd

262

4/25/2006

3:19 PM

Page 262

Chapter 15

If you are designing for automated operation with some manual process actions, you will have to be able to talk to the operator from the recipe. You can do that from a phase or you can create a module that accepts commands from the phase and puts them up as requests on an HMI, with an alarm to attract the operator. The operator will have to confirm that the action was completed and may have to enter other data. The module converts status and other data into parameters that the phase can read. If it becomes necessary to automate the action, the module can be changed without changing the phase code. Not everything that can be requested by a product recipe is a process action in the sense that an actuator is involved. Sometimes it is necessary to do calculations. If the calculation is known and the method does not change then a module may be used to make the calculation and return the data. You can even build a general-purpose calculator module by providing commands for math operators and parameters to load and retrieve data. See the section in Chapter 14 on computations. You could make a drawing for each module that shows the control and process equipment. These drawings will be used later to produce the loop sheets required by Maintenance, as described in Chapter 2. Again, you will see patterns emerge as well as unique drawings. You can create a pattern drawing for each type of control loop and indicator, with generic equipment identifiers. Then make a table for each module pattern that lists the actual equipment associated with each generic identifier. Add the drawing reference and table to each module description. See Figure 15-4.

Figure 15-4 Control Module Pattern Drawing

batch chap 15.qxd

4/25/2006

3:19 PM

Page 263

Generic 88 Implementation

263

The table for Figure 15-4 looks like this: Table 15-1 Table for CM PID Pattern Drawing CM PID

Module 01 in A01

Module 06 in A01

Module 01 in A02

XXTTAG

A01M01 FT01

A01M06 PT01

A02M01 FT01

AINTAG

A01M01 AI01

A01M06 AI12

A02M01 AI01

PIDTAG

A01M01 FC01

A01M06 PC03

A02M01 FC01

ACTTAG

A01M01 AO01

A01M06 AO05

A02M01 AO01

XXVTAG

A01M01 CV01

A01M06 CV05

A02M01 CV01

The same module in each unit has the same block tags. Different modules in the same unit have block tags that are numbered by the order in which they are used so that modules can use varying numbers of blocks. If you are absolutely certain that operators will not be confused, you could start numbering from 1 in each module. If you like to organize data into tables, the following is a way to describe the PID pattern using a table: Table 15-2 Description of PID Pattern General

Name

PID Pattern

Type

Flow control

Class

Control (or Equipment) Module

Level

1 (lowest, 2 contains 1s, 3 contains 2s that contain 1s, etc.)

Control

Regulatory (or Indicator, Alarm, Interlock, Discrete, Sequential, Phase)

Acquisition No (or yes if module supports being acquired) Devices

Blocks

Sensors

Flow transmitter

Actuators

Valve, air to open

AI

(describe anything common to all PID modules here)

PID AO Parameters status value

Read only (read only is just a reminder when writing phases) Read only

setpoint output mode alarms

Add text here if the function is not obvious from the name

position

Read only

batch chap 15.qxd

4/25/2006

3:19 PM

Page 264

264

Chapter 15

The table for a specific module within a unit may look like this: Table 15-3 Table for Specific Module Identification

Devices

Blocks

Tag Name

M01

Description

Inert Gas Flow (named for what it does, not the S88 module class)

Type

Flow control

Pattern

PID

Sensors

Orifice plate flow transmitter, 0-20 SCFM

Actuators

Equal percentage globe valve, air to open

AI

Square root correction, 0-20 SCFM

PID

Disable derivative

AO

Fail closed

The table of common parameter names might look like this: Table 15-4 Table of Common Parameter Names Parameters status

Read only, common to all modules, not shown on drawings

value

Read only, primary process variable

setpoint

Regulatory setpoint

output

Regulatory output to AO block or device

mode

Controller mode

alarms

Array of alarm trip points, can use individual names

position

Read only, actuator position

switch

Two state discrete setpoint

select

Multiple state discrete setpoint

confirm

Read only, discrete state equals setpoint

Repeat this process until you have modules for every basic control loop and indicator. You should not have any process control equipment left over. If you do, then find out why.

Assign Modules to Units Now you must assign modules to units or common equipment because a module must only be controlled from one such piece of equipment. Imagine that you are designing a control panel or graphic display for all of the modules. You can’t put them on randomly because the operator will spend too much time looking for a module that belongs to a unit that is causing trouble.

batch chap 15.qxd

4/25/2006

3:19 PM

Page 265

Generic 88 Implementation

265

First, you assign sections of the panel to major pieces of equipment, like units and common equipment. Then you group the individual controls for the major equipment within its panel section. If you automate, then each piece of major equipment will execute phases that can directly control only the modules assigned to the equipment. See Figure 15-5, where Process Cell A contains Unit A01, Unit A02, and Common Equipment A07. Each of these three contains modules, with fewer modules in the common equipment.

Figure 15-5 Example of Module Grouping Batch units can be identified from descriptions in 88.01 Section 4.2.5 “Unit Level” or Chapter 6. You also need to identify common resource equipment that is discussed in 88.01 Section 5.6 “Allocation and Arbitration” or in Chapter 9. The key characteristic of a unit is that it may contain all or part of a batch while it carries out independent process actions on the batch, except transfers. The process actions must be directed by a recipe. The key characteristic of a common resource is that it is a control or equipment module. 88.01 does not exactly say that common equipment can not be a unit. It does say that one unit must coordinate with another unit, rather than just acquiring it. The implication is strong that common equipment must be a module. Name the units and common resources. You will need these names for yet more documents. List the functions and services that each unit and common resource performs. List the actuators used by each unit or resource and note any uses of one actuator by more than one unit. List the sensors that measure something associated with each unit or resource, even though the sensor value may be used elsewhere. Next, identify transfer valves that have a unit attached to each side. Assign two small modules to each such valve. One of the modules contains the valve. The other contains a switch that is connected to the interlock function of the valve module by either a real wire or the software equivalent of a wire in basic control. Assign the valve module

batch chap 15.qxd

4/25/2006

3:19 PM

Page 266

266

Chapter 15

to either unit, as you please, but please be consistent. Assign the interlock switch module to the other unit. The Common Valve Problem is discussed in Chapter 14. If one end of a transfer valve goes to a common resource then look for other such valves connected to the same resource. Perhaps you have a header, in which the set of valves belongs to a larger module and not to either piece of major equipment. A header module may belong to a single source or destination, which selects the valve(s) to use based on the request that acquired the source or destination. You may want an interlock switch module for each selectable destination unit inlet valve or selectable source drain valve. See Figure 14-4 in Chapter 14. The header may be a common resource for transportation if it allows you to select both source and destination. You will need a module for each selection, so that one module may be acquired by a source and the other by a destination. Things become complicated if the header can do more than one transfer at a time. The header is a common resource if it can independently clean and perhaps sterilize its transfer paths. Cleaning is done relatively independently if the header has to select a source or return for the cleaning or sterilizing agent and the return or source is a unit. Maybe the header is a common resource, and maybe it is a large module. The header is a large module if cleaning starts in one unit and cleans the header by transferring the cleaning batch to another unit. A header is never a unit because it does not process a batch of product, and there is outflow while the processing is in progress. You should now have small modules for each valve or motor and each sensor that is not used by another module. Each module should be assigned to a major piece of equipment or a header. Each module must be used by at least one process action. If there are unused modules for some good reason, set them outside the scope of batch control. A module is not interesting if it is not used by a process action.

Convert Actions to Phases The generic actions must be converted to equipment phases that will operate modules to perform the action on specific equipment. There are two ways to design a phase. One is to use the recipe as SFC method, in which the phase logic sets the action in motion and a separate, external transition condition expression in the recipe determines the end of the phase. The other is to design the phase to begin the action on a command from the recipe and to end when it is done, without further communication from recipe procedural control. The self-completing method allows phases to be distributed closer to the controlled equipment, where communication or processing problems may prevent the satisfied transition condition from getting to the phase and stopping it. You may not think that phases will be distributed after years of using single cylinder batch engines, but the technology to do it exists today. With that technology comes the benefits of distributed control.

batch chap 15.qxd

4/25/2006

3:19 PM

Page 267

Generic 88 Implementation

267

There are cases where the phase is supposed to simply start an action that will be ended later by another phase. This may be done from within a phase that does other things if the action is sufficiently simple, like turn a motor on. Do not skip this step in the design procedure because your control vendor offers a Phase Library. This situation is similar to the big computer companies that offered accounting packages to prospective buyers. The generic accounting package never matched the customer’s business processes, so it required extensive, expensive customization. Sure, we all do the same things in batch control, but we don’t all have the same processes, operators, and environments. Worst case scenarios include the following: The Phase Library is too simple, probably created by Marketing from their martini process. The Phase Library is too complex, representing extremes from a hundred different jobs. The Phase Library is just right, for someone else’s process. Even if you did buy a Phase Library, you should go through this design process in order to discover the details that you will need to customize the vendor’s package. Either way, you will end up with your own Phase Library that can control the equipment entities in your process. Note that you cannot have a Phase Library without also having a standard set of module interfaces each having the parameters used by the phases. The descriptions of process actions done in the previous section did not have to refer to specific equipment or modules. That’s why they could be described before the modules were created. Now it is time to convert the actions into phases that will operate the modules. This should not be difficult because the process actions from the preliminary procedure were used to define small groups of basic control. Those groups were used to create modules. Difficulties arise from the general nature of process actions and the specific details of systems and equipment. The process action description could say, “Open the steam valve” or “Check the reactor level.” You will have to specify the module and the parameter that accepts the command to open the steam valve or provides the current reactor level. 88.01 offers a structure for this work, which is described in 88.01 Section 5.1.2, “Procedural Control,” or in Chapter 7 of this book. You will be working with phases at this point. You have worked down from process stages to process actions. Now you will work upwards from phases to procedures. You must name the phases, perhaps as the title of each phase document. Phase names can not be specific to units or other equipment because they are used in

batch chap 15.qxd

268

4/25/2006

3:19 PM

Page 268

Chapter 15

master recipes that are specific to a process cell but not specific to units. Remember that the name of an equipment phase must match the name of the corresponding recipe phase. The name should specify a process function or action. If an equipment phase performs the same function differently in different units, then the phase must be written for and associated with each unit, using the same phase name. If you have a procedural controller for equipment phases that is associated with each unit then you have no problem. If the recipe phase is Add Solvent, then it should find an equipment phase named Add Solvent in whatever unit is chosen by Manage Batches. Start with one phase per action. Do not worry about recipe or equipment phase divisions at this time. Just describe how the given equipment would perform the function. The description should be mostly procedure, using module interface names to cause equipment to move. If you described your process actions properly in the first section of the design procedure, then you should have no trouble with multiple phases per process action. If you must have multiple phases to perform a process action, be sure that the action isn’t really a process operation. The number of phases should be minimized eventually, but don’t lose the benefits of modularity. Group the phase descriptions by unit or common resource. Set aside the phases that operate any modules in other units or common resources. The remaining list should define unique phases for each piece of major processing equipment. Now go back to the list of phases that violate the principle of integrity of a unit by referring to other units. You solved the common valve problem during module design. The rest should be resolved by acquiring the services of a module or common resource, or by coordination with another unit (mostly for transfers). Modify the phase descriptions to include coordination. List and describe acquisition and coordination, but don’t worry about how that is done just yet. At this point, all of the phases should direct controlled equipment to perform all of the process functions that may be done in each unit or common equipment. If there are any phases left over, check your understanding and ask for help. Don’t worry if the phases look too small at this point. You are working with small modules. Ways of combining phases and modules will become evident once you have methods for doing everything that must be done. As an aside on the subject of starting small, consider the sad case of Charles Babbage. He designed an automatic difference engine because he was frustrated with the errors he found in computing and printing books of tables used for mathematical and navigation applications. It wasn’t just the first such engine; it was huge, with fifty-digit decimal numbers. He got government money to build it in 1822 and told them that it would take three years.

batch chap 15.qxd

4/25/2006

3:19 PM

Page 269

Generic 88 Implementation

269

Ten years later, his master machinist got greedy, so Babbage terminated the relationship. A six-digit working model and thousands of parts were returned to Babbage. It took the government two years to decide to scrap the project. During that time, Babbage designed a better machine, the analytical engine. It had many of the major functions found in today’s computers, like separate arithmetic and storage units. It could automatically multiply and divide, unlike any of the hand calculators available then. The debacle of the difference engine prevented him from finding funding to build the analytical engine. (Nobody else could get funding, either. Look up Thomas Fowler and his ternary machine.) It was one hundred years before circumstances enabled an automatic calculator to be built from IBM Hollerith card tabulators. That’s quite a setback. Imagine the effects of a Victorian Microsoft. It really is best to start small and build on successes. Your backers should not expect home runs until you have demonstrated a capability to hit them regularly. Your first goal should be first base.

Review Understanding You should know how to operate the process by executing phases that interact with modules in order to perform process actions. You don’t have all of the phase details yet, but you do know what modules you will need and how to build them. You have a module for each control equipment entity, and you have a library of module patterns that will greatly reduce the number of drawings needed to build modules. There are many two-state valves but only one pattern for building a two-state valve module. Test your understanding with process designers and people from Operations. Repeat until all of the questions are resolved. Let your management champion know that you are at this stage in the procedure, and ask how much of this technical stuff would be of interest. Sometimes, managers demand status reports because engineers never have time to talk to them. Make it clear that you will talk to management, using words that they can understand, and the issue of status reports may never come up. When your understanding of the functions of modules and phases is complete, then you can write phase procedures that can instruct operators or be the basis for software development.

Know Modules, Phases You have defined the small control modules that a phase can use to affect the process. You began the specification of the phase/module interface by naming some obvious parameters. You also described phases by referring to some of those parameters. This is not enough detail. Begin by writing precise phase procedure descriptions. Look for ways to combine phases to do unique process functions, but remember the value of modularity. Continue by creating larger modules that reduce the number of modules

batch chap 15.qxd

4/25/2006

3:19 PM

270

Page 270

Chapter 15

that a phase has to use, where possible. End by assuring that normal operation is possible, with nothing left over or unbuilt.

Write Phase Procedures In this step of the design procedure, you will describe exactly what has to be done and exactly what module parameters are used to do it. You will also need formula parameters in the recipe and perhaps configuration or dynamic parameters, which are stored in the unit. No code will be written. Examples of modules and phases will be shown in the section “Know Normal Operations” later in this chapter. Be specific about the data required to perform each function. Give each item of data a name and describe its properties. Use the same name only for exactly the same item of data. Identify data items that do not change with products and so are owned by the unit. Identify data items that depend on the product and so come from each recipe. These names will generate a list of formula data requirements. Phases only have temporary memory. If something needs to be stored for the next time that the phase is executed then it needs to be stored in the unit. Storing it in the recipe is not useful because a control recipe is only executed once. The set of unit data should be segregated into static and dynamic values. The static values are stored elsewhere as part of unit configuration, consisting mostly of sizes and ratings of unit equipment. This allows the same phase to run in different similar units. Dynamic data is updated by phase execution. It must be non-volatile and backed up. For each phase, do the following: • Classify the function that is directed by the phase, such as add, adjust, agitate, cool, heat, wait, and so on. • Name the class of equipment that can execute this phase, if necessary. • Describe the normal purpose of the phase. • Describe any special event messages generated by the phase. • Describe the known concerns for equipment and personnel faults associated with this phase. • List the names of modules used (this provides references to the lists of interface parameters). • List the acquisition and coordination activities required. • List the parameter names of required recipe data. • List any parameter names of returned recipe data. • List the parameter names of required unit data. • List any parameter names of returned unit data. • Describe the normal procedure in sections, as described below

batch chap 15.qxd

4/25/2006

3:19 PM

Page 271

Generic 88 Implementation

271

Use parameters for numbers that are required by a procedure. Once the phase is validated, it may be very difficult to change a number that is written into the procedure. Parameters may be kept in the unit’s static data and altered as conditions change. For example, a reactor temperature control phase should stop circulation when the level of the contents falls below the level of the heat transfer jacket coils. That level could be different in different reactors, but otherwise the phase remains the same. If the phase can read the minimum level for the unit then the phase is the same for all units. It is too soon to discuss exception handling. At this point, the description of concerns is based on information gained from Process Design people and others. A detailed review of concerns will be done once the normal procedure is defined, which will add to the documentation for the phase. The procedure should include the following sections: • Restart—Run checklist, go to Setup. • Initialize—Run checklist; do things you wouldn’t do on Restart, like reset totalizers. • Setup—Change equipment configuration using valves, turn on trends, send setpoints and other setup commands, get confirmations that all is ready. • Start—Send start commands to modules and get confirmations. • Run—Perform a repetitive procedure and/or wait for the started action to be completed. • Shutdown—Close valves, stop trends, restore configuration, release acquired equipment. • Report—Manipulate data as required, send report messages. • Exit—Return to Procedural Control. • Checklist: Assure that conditions that effect this phase, such as measurements or reaction regimes, are correct or meet minimum requirements. Do not fill a cold vessel with hot material, for example. Check instrument modes. Acquire or coordinate equipment if it is not already acquired. Restart is an entry point that is used after the procedural controller mode has changed from manual to automatic, if the phase was active when the mode left automatic and will be active again. The checklist is run but counters and timers are not initialized. Initialization is the entry point used by the procedural controller when the recipe transitions from one phase to another. The checklist is run and counters and timers are initialized. The Setup section does things that it wouldn’t hurt to do again on a restart. It is separate from Start in case the phase has to be restarted or picked up by a redundant

batch chap 15.qxd

272

4/25/2006

3:19 PM

Page 272

Chapter 15

processor. If the last known good state of the phase was Setup, then Setup can be repeated from the beginning with no ill effects. Similarly, Start is separate from Run so that the Start commands will not be repeated if the last good state was Run. Even if your system doesn’t handle phase restart gracefully, this is a good way to organize your procedure. The Start section sets the process function in motion. It is intended to be very brief, so that a resume into Start will not harm anything. The Run section monitors the progress of the function towards its goal, while detecting exceptions and the endpoint. The Shutdown section is useful if the phase should end with nothing new going on. Material additions would normally end with a Shutdown section to stop and close the equipment associated with the addition. Some phases are intended to start an ongoing activity, like inert gas pressurization or agitation. Another phase is required to change or stop the ongoing activity. The equipment associated with the activity must be able to check itself and send alarm or exception event messages from basic control, so that it may be monitored without having an active phase running. The Report section may be needed in order to process data, or all data requirements may be satisfied by normal event messages, such as a change of state of the phase. Report data may come from acquired equipment. Calculated data may be sent somewhere in a message, depending on the capabilities of the control system. The Exit section marks the definite end of the phase procedure and initiates return of control to Procedural Control, perhaps by asserting the “Done” status. The Checklist section is like a subroutine within the phase. It should be thorough because a phase can not count on normal operation. If something could cause trouble during the phase, make sure that it wasn’t there when the phase started or restarted. If the checklist fails then hand control back to the procedural controller, sound an alarm, and set the Hold state. It may be necessary to acquire or coordinate an equipment entity before all of the checks can be performed. When you have a collection of documented phases, sort them by classification. Look for phases that are nearly identical, such as “add material” and “add material at a defined rate.” Make them one phase by adding a few parameters to the less detailed phases. The recipe author will have to fill in the extra values because they are there, so don’t overdo it. Each phase has to be tested and perhaps validated, so you want to reduce the number of phases. Be sure to review each consolidation of phases with Operations. You may run into module and procedural differences between units that have the same process action, especially if the process has been expanded with new equipment. The name of the phase and the names of the recipe data items must not change, so that the recipe author can use the same phase name for a process action

batch chap 15.qxd

4/25/2006

3:19 PM

Page 273

Generic 88 Implementation

273

regardless of the target equipment. The document for each phase includes the name or class of the equipment that will run the phase. The class is used when units are identical, at least for this phase. The name is required if there are differences. For each different unit, first try to modify modules so that the phase can stay the same. If not, copy the original phase document and modify anything except the phase name and the parameters. Perhaps there is an additional valve. Modify the phase description to include the purpose of the valve. Add the name of the module that contains the valve and the names of any new commands or status items. Modify the procedure for operating the new valve and you are done, but you have added another phase to test. Decide on a standard set of reference names for commands and status items. Each short module name will be unique within the unit, so the reference names don’t have to be different for every module. Using standard reference names with known behavior will save time when you write procedures. Equipment that can be acquired may need to have module names that are unique within a unit after the acquisition makes the equipment part of the unit.

Create Modules for Phases Now you know exactly what phases and controlled equipment will be needed to make products from recipes. Well, almost exactly. You still have to interact with recipe authors to see if they think that you’ve got everything. You could do that now, according to the principles of 88.01 Section 6.1.3, “Process and Control Engineering,” and also Chapter 11. If recipe authors are not available, press on. You should have phases for everything that the equipment can do, so a new phase or module is unlikely. You do have many little modules. Start with a unit and look at the list of phases that the unit can execute. For each phase that has more than one module, make a list of the small modules that are not used by any other phase. These tend to gather around pieces of process equipment that are less capable than a unit, like heat exchangers and transfer headers. Group these dedicated modules into a larger module where that makes sense. The new, larger module may have “glue” logic so that the phase doesn’t have to talk to each small module. Circuit board designers use logic to “glue” major functions together on a circuit board. The larger modules might well be called equipment modules, but an equipment module must run a phase. See the “Modules Revisited” section in Chapter 14. Use descriptive names for modules rather than teaching the classification of modules. You will have to rewrite the phase procedure in order to use the larger module. This should simplify the phase procedure and the module interface because some of the work has been given to the glue logic in the larger module.

batch chap 15.qxd

4/25/2006

3:19 PM

Page 274

274

Chapter 15

Find Orphan Modules There will be small modules that do not belong in larger modules, such as the dump valve. Ensure that every one of the remaining small modules in the unit is used by a phase that can be executed by the unit. Any that are left over are orphans. For each orphan module, determine likely phases that may use it by its use in the unit. Check the phase procedure to see if something was left out. If no phase will use the module, find out why it is there. Perhaps another unit is supposed to operate the module. If a phase in another unit just reaches in and operates the module then that breaks the law of independent units. Ignorance of the law is no excuse, as law enforcers like to say. The module does not belong in the unit if the unit does not operate it exclusively. The module may be common equipment or belong to common equipment, or it may be assigned to the wrong unit. You need to sort out the problem so that the law is obeyed. Perhaps it would help to read about the common valve problem in Chapter 14. If the orphan module is not used by any phase anywhere, start asking process designers and Operations people why it is there. Your business contacts will tell you that they’re not running an orphanage.

Review Understanding You should now understand exactly what happens when a recipe procedure initiates a recipe phase that initiates an equipment phase. Do not proceed beyond this point without testing that understanding and possibly improving it. This would be a good place to get sign-offs for the phase and module documentation, certifying that the documentation describes normal operation of the process. Ask people to list the possible exceptions to normal operation as they review the documents. This will give you a preliminary list for the next section of the design procedure.

Know Normal Operations Now you know how to operate the process from phases, in detail. This section of the design procedure is the beginning of the other half of the work (your mileage may vary). Read the section on exception handling in Chapter 14, if you haven’t already done that. This section will identify exceptions, define detectors for the exceptions, and do the first pass at designing exception handling in the phases or in a unit process monitor, as described in Chapter 14. An example is used to show exception handling for reactor temperature control. The example consists of a process flow diagram, control modules, and a phase called “Transfer Heat” that handles either heating or cooling. Figure 15-6 shows the relevant part of a process flow diagram.

batch chap 15.qxd

4/25/2006

3:19 PM

Page 275

Generic 88 Implementation

275

Figure 15-6 Reactor Temperature Control

batch chap 15.qxd

276

4/25/2006

3:19 PM

Page 276

Chapter 15

The reactor is jacketed and agitated. There is a requirement for fine control near ambient conditions as well as rapid heating and cooling. Two heat exchangers are used so that there is no delay for switching when the heat demand swings from heating through zero to cooling. Besides, the heating and cooling heat transfer fluids are incompatible. The jacket circulation loop uses a wide-range heat transfer fluid that is too expensive to use in utility circulation. The jacket loop is instrumented to measure heat flow. A pump provides circulation. Four block valves are used to direct circulation through one or both heat exchangers, or neither. (Yes, most people would simply place the heat exchangers in series, but this is an example, not reality.) Two control valves regulate the flow of heat transfer fluid from hot and cold utility sources. They are configured for split-range operation with some overlap, for fine control near zero demand. The reactor dump valve is not used. The agitator and level are only monitored, not controlled. Figure 15-7 shows the control modules required for interfacing with phase logic. The module names start with the unit name (if necessary), then the module identifier Cm, followed by a two-letter abbreviation for the purpose of the module and an instance number. At least, that is how modules are identified in this example. The interface parameters are shown on the left side of each module drawing. Module CmBV01 controls the four block valves. The prefix “Cm” means any module, control or equipment. FC01.OUT represents a link to the heat flow controller output that is made in basic control, not to a module interface parameter. The “select” parameter can select the configuration when FC01.OUT is near zero, or it can close all valves. The “confirm” parameter is true when all four block valves are confirmed in their selected positions. The logic function block is configured to command the four valves. The logic configuration would be described on a second page of the module drawing. Here, it is described in general in the following paragraph. Normally, the valve configuration is determined by the value of FC01.OUT. Heat is selected when the output value is above +7%. Both are selected when the output falls below +7%, with a deadband to allow compensation for the addition of another circulation path. The additional cool fluid will raise the demand for heat, but a 3% deadband prevents a switch back to heating until demand reaches 10%. All block valves are open between +7% and -7% output. The heat path is closed below -7%. This is similar to the mixing that occurs as you rotate the mixing valve for a shower. Your numbers may vary depending on your equipment. There should be an interlock to stop the pump when all valves are closed, but there is only so much room in the book and time left to write. This module could be combined with CmTC01 but it wasn’t, because then we would have to discuss larger modules. Similarly, CmPM01 could be combined with this module.

batch chap 15.qxd 4/25/2006 3:19 PM Page 277

Generic 88 Implementation 277

Figure 15-7 Control Modules Required for Interfacing with Phase Logic

batch chap 15.qxd

278

4/25/2006

3:19 PM

Page 278

Chapter 15

Module CmLI01 is the source of the reactor level and alarms for several phases. The control scheme is simple, so the field transmitter and analog input function block are shown in one drawing. Values for this module are read-only for the heat transfer phase. An additional module is required for the low alarm that is used by the heat transfer phases. Module CmLI02 contains an alarm block that is linked through basic control to the level measurement from the AI block in CmLI01. This isolates the alarm settings made by the heat transfer phase. Module CmPM01 controls the circulation pump with a simple on/off switch. The Motor Control Center confirms that the motor has power applied to it. A “tripped” alarm occurs when the motor stops without an “off” command. Module CmAG01 controls the agitator motor. It is read-only for the heat transfer phase. The logic function block provides the correct command to the Motor Control Center and receives confirmation that the command worked. A “tripped” alarm occurs when the motor stops without an “off” command. If the motor is running then an integrator provides the amount of time that the motor has run. An analog input receives the signal from the power transducer in the MCC so that a phase can test to see if power is normal for conditions. That’s a procedural phase, not an electrical phase. Module CmTC01 controls the reactor temperature. Eleven function blocks are used, so they are shown separately. This drawing just shows the list of interface parameters and the tag-dot-parameters that they represent. The list of field equipment tag names shows the instruments included by the module. Each could have its own module or not, depending on how you do the design. You might want to add a setpoint ramp generator and an enhanced deviation alarm. Figure 15-8 shows the control function block configuration for reactor temperature control. The reactor temperature is controlled by TC01. A phase sets the setpoint from the recipe, and may set tuning parameters or select other control configurations. The output of TC01 is the heat demand required to heat or cool the jacket. The heat demand is the setpoint for FC01, which sets the control valve positions with the aid of output splitter block OS01. The range of the output is -100% to +100%. The splitter is configured to allow some overlap so that the controller is always active, with no dead time introduced by integrating through a deadband. Valve position versus output may be very nonlinear near zero unless a precision positioner is used. If you save energy by eliminating the overlap then you will lose tight control because of the deadband.

batch chap 15.qxd

4/25/2006

3:19 PM

Page 279

Generic 88 Implementation

279

Figure 15-8 Control Block Configuration for Reactor Temperature Control The heat flow measurement is provided by computational block CP01, which performs the heat flow calculation based on jacket inlet and outlet temperatures and jacket flow. It is followed by an integrator TG01, which provides the total heat supplied or removed during a reaction. All function blocks are normally locked in automatic mode except the controllers TC01 and FC01. Normally, TC01 is in automatic mode and FC01 is in cascade mode. A phase could set both modes to manual to stop control action, or some module logic could be used to operate both modes from a common mode parameter in the module interface. Perhaps you don’t have a DCS or support for process control function blocks. All of this configuration (an application) can be distributed among field devices that support FOUNDATION™ Fieldbus. This is the only fieldbus protocol that supports the concepts of the SP50 User Layer (as of 2005 and since 1995). Many vendors offer this protocol. The beauty of it is that the function blocks are based on standards for parameters and behavior, so you may choose a vendor based on other considerations. See Chapter 16 for a discussion of Fieldbus.

batch chap 15.qxd

280

4/25/2006

3:19 PM

Page 280

Chapter 15

The Transfer Heat phases have been developed for normal operation. Two phases are required: heat transfer and stop heat transfer. The heat transfer phase changes the temperature setpoint and stays active until the temperature is stable at the new setpoint. It will start heat transfer from the shut down condition, if necessary. A reaction usually goes through several temperature changes before the heat transfer system is shut off, later in the recipe. This phase will start heat transfer and ensure that the transfer is working, then exit and let the monitor detect exceptions. The heat transfer phase or the module CmTC01 should calculate tuning constants for TC01 based on the changing level, because the mass of material affects the rate of change of temperature. That is an unnecessary complication in this example. So is an override controller to limit the difference between jacket inlet and reactor temperature. In the procedure sections that follow, to fail means to generate an explanatory alarm and tell the procedural controller to set its Hold state.

batch chap 15.qxd

4/25/2006

3:19 PM

Page 281

Generic 88 Implementation

281

Table 15-5 Generic 88 Implementation for Heat Transfer Identification

Description

Modules

Parameters

Procedure

Phase Name

Heat Transfer

Phase Type

Reactor Temperature

Equip Name

Reactor Type A

Purpose

Control the reactor temperature for heating or cooling

Concerns

Low flow, pump failure, low level, agitator stops, control valve stuck, block valves not confirmed in position, transfer too slow, transfer in the wrong direction, module failure

CmBV01

Control block valves for heating or cooling

CmTC01

Control reactor temperature by regulating heat transfer rate

CmLI02

Monitor reactor level and alarm for low level

CmPM01

Control jacket circulation pump

CmAG01

Monitor agitator

Acquisition

None

Get Recipe

Reactor Temp SP, Reactor Temp Time

Set Recipe

None

Get Unit

Min Jacket Level

Set Unit

None

Restart

Run Checklist. Go to Setup.

Initialization

Run Checklist. Set CmTC01.reset to true until CmTC01.heatTotal is zero.

Setup

Report total heat from CmTC01.heatTotal. Set CmTC01.mode to manual. Set CmTC01.heatControl to 0%. Set CmTC01 block OS01 to automatic. If CmTC01.jacketFlow is below 50% then Set CmPM01.switch to run. Wait for CmTC01.jacketFlow above 50%. Fail if CmTC01.jacketFlow below 50% after 30 seconds. Set CmTC01 block FT01 low alarm to 40%. Set CmLI02 low alarm to Min Jacket Level. Set operator alarms as required. Set phase watchdog timer to Reactor Temp Time.

Start

Set CmTC01.reactTempSet to Reactor Temp SP. Set CmTC01.mode to cascade. Start watchdog.

Run

Confirm that CmTC01.reactTempSet equals Reactor Temp SP within 10 seconds. Fail if temperature is not set. While watchdog not timed out If CmTC01.reactTemp approaching Reactor Temp SP then continue. If CmTC01.reactTemp overshooting Reactor Temp SP then continue. If CmTC01.reactTemp very near Reactor Temp SP then break.

batch chap 15.qxd

4/25/2006

3:19 PM

Page 282

282

Chapter 15

Table 15-5 Cont.

Subroutine

Report

Success or failure, with CmTC01.heatTotal

Exit

Report done to recipe execution

Checklist

Status of all modules is Good. CmAG01.confirm is true. CmLI02.value is above Min Jacket Level.

The other phase shuts down the heat transfer system: Table 15-6 Generic 88 Implementation for Heat Transfer Shut Down Identification

Phase Name

Stop Heat Transfer

Phase Type

Reactor Temperature

Equip Name

Reactor Type A

Purpose

Shut down jacket circulation and heat transfer

Concerns

None

CmBV01

Control block valves for heating or cooling

CmTC01

Control reactor temperature by regulating heat transfer rate

CmLI02

Monitor and alarm for low reactor level

CmPM01

Control jacket circulation pump

Parameters

Get Recipe

None

Procedure

Restart

(do nothing, fall through to Initialize)

Initialize

Check that status of modules is Good. Fail if not.

Setup

Set CmLI02 low alarm to -5%. Report total heat from CmTC01.heatTotal.

Start

Set CmTC01.mode to automatic. Set CmTC01.heatDemand to zero. Start a phase timer.

Run

While phase timer is less than 10 minutes If CmTC01.heatControl is near 0% then break. If CmLI02.value is below Min Jacket Level then break.

Shutdown

Set CmTC01.mode to manual. Set CmTC01.heatControl to 0%. Set CmTC01 block OS01 to manual, outputs to -5%. Set CmTC01 block FT01 low alarm to -5%. Set operator alarms as required. If CmTC01.jacketFlow is above 50% then Set CmPM01.switch to off. Wait for CmTC01.jacketFlow below 10%. Fail if CmTC01.jacketFlow above 10% after 30 seconds. Set CmBV01.switch to off. Wait up to 30 seconds for confirmation.

Report

Success or failure, with value of phase timer

Exit

Report done to recipe execution

Description

Modules

.

batch chap 15.qxd

4/25/2006

3:19 PM

Page 283

Generic 88 Implementation

283

At this point you have the phase descriptions for normal operation, including Restart for the return from manual mode of the procedural controller. Note that the Run procedures contain “while” loops. The indented lines under the “while ” statement are repeated while the condition is true or until an “if” test results in a “break” statement. This breaks the loop so that the next non-indented line will be executed or the Run procedure ends and falls into the next procedure, usually Shutdown or Report.

Identify Exceptions You have identified some concerns during the first pass at describing phases. Now it is necessary to identify all of the exceptions that can be controlled by man or machine. This usually requires a review of hazards by a committee of people specializing in finding hazards. For this example, the committee has found the following concerns: • Low flow—block FT01 in CmTC01 indicates low or no flow in the circulation loop. • Pump failure—confirm contact from MCC in CmPM01 opens. • Low level—CmLI02 indicates that the reactor level is below the jacket coils. • Agitator stops—confirm contact from MCC in CmAG01 opens. • Control valve stuck—output of block FC01 in CmTC01 goes to a high or low limit. • Block valves not confirmed in position—causes a module failure in CmBV01. • Transfer in wrong direction—abnormal initial heat transfer condition. • Low heat flow—abnormal heat transfer condition, actually inadequate heat flow. • Module failure—modules declare failure if they cannot hold their setpoints.

Design Detectors The detectors for eight of the nine exceptions are the alarms from basic control function blocks: • Low flow—alarm from block FT01 in CmTC01. • Pump failure—motor tripped alarm from MCC in CmPM01. • Low level—alarm from CmLI02 when reactor level goes below jacket coils. • Agitator stops—motor tripped alarm from MCC in CmAG01. • Control valve stuck—high- or low-output alarm from block FC01 in CmTC01. • Block valves not confirmed in position—covered by module failure alarm from CmBV01. • Low heat flow—deviation alarm from block FC01 in CmTC01. • Module failure—failure alarm from any module.

batch chap 15.qxd

4/25/2006

3:19 PM

284

Page 284

Chapter 15

The low flow and low level alarms must be set by heat transfer and disabled (set to -5%) by stop heat transfer. The ninth exception needs to be handled by a phase: • Transfer in wrong direction—detected by an operating phase.

Define Handling All of the alarm conditions can be detected by the exception monitor. The response to all of them is to set the Hold state. Hold does not stop jacket circulation, but it does close the heating valve (or whatever you decide to do). The operator may decide to apply full cooling or restore temperature control. A human must determine the cause of the alarm and act appropriately. Hold stops all inflows of material and energy in order to allow time for human responses. Transferring heat too slowly may cause the heating or cooling valve to open fully. Before that happens the heat flow can be checked for some normal value as a function of time or reactor temperature. Low heat flow is an exception, but a phase cannot correct it. The Hold state must be set to allow the problem to be investigated. Transferring heat in the wrong direction means that something is wrong. The jacket inlet temperature should be hotter than the reactor contents if heating is required and cooler if cooling is required, at least initially. The correct response is Hold, after a short delay for heat flow stabilization. Addressing the concerns is not the end of exception handling. The state of the procedural controller determines whether the normal (running) phase procedure will be followed or one of the following will occur: • Holding—close the heat and cooling valves unless there is a temperature alarm, then fully open the correct valve. • Restarting—restore normal temperature control. • Stopping—set the temperature setpoint to ambient, and wait for the temperature to be near ambient, then shut down. • Aborting—close the heating and cooling valves, stop the pump, and close all four block valves in the circulation loop.

Review Understanding You now have descriptions of the way each exception will be detected and handled. Before you get into the details, review your work with the groups that determined the original concerns. Make sure that they agree that you are on the right path, so that you don’t have to throw work away later.

batch chap 15.qxd

4/25/2006

3:19 PM

Page 285

Generic 88 Implementation

285

Know Exceptions It is time to take care of the details of detection and handling, now that you have an approved path to take.

Refine Detectors Make sure that the required alarms are configured in the control modules. If all of the alarms in a block have been configured then create another block for the exception alarm(s). Provide module parameters for those alarms that have to be set to enable exception handling, as was done in CmLI02. The reactor temperature controller is set up to deliver (or remove) the heat that is needed to reach and hold the setpoint. The controller does not know whether it is supposed to heat or cool, so logic in the phase determines the direction of temperature movement with respect to the setpoint, after allowing time for initial transients to settle out. Low heat transfer could be detected by logic in CmTC01 that requires a certain heat flow if a deviation alarm exists at block FC01. The alarm should be higher than the advisory alarm to the operator. If better detection is required then the control module could have a curve for the expected heat flow-versus-temperature difference between jacket and reactor contents.

Write Monitor Handling The exception monitor must be configured with the identification of each alarm that will cause either the master or the unit procedural controller to go to the Hold state. If alarms are conveyed by unconfirmed occur and clear messages, it is a good idea to have the monitor slowly poll the function blocks for the presence of alarms. The polling rate is determined by the bandwidth of the communication system and by the free time of the application that executes function blocks. It may be possible to get active alarm information from the historian or the unit. It might not be possible to have a monitor. In that case, each phase must continually look for exception alarms, and the phase descriptions in this example will not work. In that case, configure the modules to have a single exception alarm parameter, since they all are handled the same way. This means that the heat transfer phase can not end when the temperature is reached. Instead, it ends when the setpoint is changed or stop heat transfer is started.

Write Phase Handling The following tables show the previous temperature control phases modified for exception handling:

batch chap 15.qxd

4/25/2006

3:19 PM

Page 286

286

Chapter 15

Table 15-7 Generic 88 Implementation for Heat Transfer-Modified Identification

Description

Modules

Parameters

Phase Name Heat Transfer Phase Type

Reactor Temperature

Equip Name

Reactor Type A

Purpose

Control the reactor temperature for heating or cooling

Concerns

Low flow, pump failure, low level, agitator stops, control valve stuck, block valves not confirmed in position, transfer too slow, transfer in the wrong direction, module failure

CmBV01

Control block valves for heating or cooling

CmTC01

Control reactor temperature by regulating heat transfer rate

CmLI02

Monitor and alarm for low reactor level

CmPM01

Control jacket circulation pump

CmAG01

Monitor agitator, low level alarm altered

Acquisition

None

Get Recipe

Reactor Temp SP, Reactor Temp Time

Set Recipe

None

Get Unit

Min Jacket Level

Set Unit

None

Running Procedure Restart

Run Checklist. Go to Setup.

Initialization

Run Checklist. Set CmTC01.reset to true until CmTC01.heatTotal is zero.

Setup

Report total heat from CmTC01.heatTotal. Set CmTC01.mode to manual. Set CmTC01.heatControl to 0%. Set CmTC01 block OS01 to automatic. If CmTC01.jacketFlow is below 50% then Set CmPM01.switch to run. Wait for CmTC01.jacketFlow above 50%. Fail if CmTC01.jacketFlow below 50% after 30 seconds. Set CmTC01 block FT01 low alarm to 40%. Set CmLI02 low alarm to Min Jacket Level. Set operator alarms as required. Set phase watchdog timer to Reactor Temp Time.

Start

Set CmTC01.reactTempSet to Reactor Temp SP. Set CmTC01.mode to cascade. Start watchdog. Start a phase timer.

batch chap 15.qxd

4/25/2006

3:19 PM

Page 287

Generic 88 Implementation

287

Table 15-7 con’t.

Run

Confirm that CmTC01.reactTempSet equals Reactor Temp SP within 10 seconds. Fail if temperature is not set. While watchdog not timed out If phase timer > 2 and < 5 minutes If CmTC01.reactTemp going wrong way then fail to Hold state. [You’ll need to figure out how to do this using temporary variables] If CmTC01.reactTemp approaching Reactor Temp SP then continue. If CmTC01.reactTemp overshooting Reactor Temp SP then continue. If CmTC01.reactTemp very near Reactor Temp SP then break. Disable Hold.

Report

Success or failure, with CmTC01.heatTotal

Exit

Report done to recipe execution

Checklist

Status of all modules is Good. CmAG01.confirm is true. CmLI02.value is above Min Jacket Level.

Holding Procedure

Run

Stop watchdog timer. Set low flow alarm on FT01 to -5%. Set low level alarm on CMLI02 to -5%. Set CmTC01.mode to manual. Set CmTC01.heatControl to 0%. [maybe you don’t want to stop control for a Hold] Set CmPM01.switch to off. Set CmBV01.switch to off. [maybe you don’t want to stop circulation for a Hold] Report holding done to procedural controller.

Restarting Procedure

Run

Run Checklist. Report restarting done to procedural controller. Go to Running Procedure Setup.

Run

Stop watchdog timer. Set CmTC01.mode to manual. Set CmTC01.heatControl to 0%. Set CmTC01 block OS01 to manual, outputs to -5%. Set CmTC01 block FT01 low alarm to -5%. Set low level alarm on CmLI02 to -5%. If CmTC01.jacketFlow is above 50% then Set CmPM01.switch to off. Wait for CmTC01.jacketFlow below 10%. Fail if CmTC01.jacketFlow above 10% after 30 seconds. Set CmBV01.switch to off. Report stopping done to procedural controller. Exit

Run

Stop watchdog timer. Set CmTC01 block FT01 low alarm to -5%. Set low level alarm on CmLI02 to -5%. Set CmTC01 block OS01 to manual, outputs to -5%. Set CmPM01.switch to off. Set CmBV01.switch to off. Report aborting done to procedural controller. Exit

Subroutine

Stopping Procedure

Aborting Procedure

batch chap 15.qxd

4/25/2006

3:19 PM

Page 288

288

Chapter 15

Table 15-8 Generic 88 Implementation for Heat Transfer Shut Down-Modified Identification Phase Name Stop Heat Transfer Phase Type

Reactor Temperature

Equip Name

Reactor Type A

Purpose

Shut down jacket circulation and heat transfer

Concerns

None

CmBV01

Control block valves for heating or cooling

CmTC01

Control reactor temperature by regulating heat transfer rate

CmLI02

Monitor and alarm for low reactor level

CmPM01

Control jacket circulation pump

Parameters

Get Recipe

None

Running Procedure

Restart

(do nothing, fall through to Initialize)

Initialize

Check that status of modules is Good. Fail if not.

Setup

Set CmLI02 low alarm to -5%. Report total heat from CmTC01.heatTotal.

Start

Set CmTC01.mode to automatic. Set CmTC01.heatDemand to zero. Start a phase timer.

Run

While phase timer is less than 10 minutes If CmTC01.heatControl is near 0% then break. If CmLI02.value is below Min Jacket Level then break.

Shutdown

Set CmTC01.mode to manual. Set CmTC01.heatControl to 0%. Set CmTC01 block OS01 to manual, outputs to -5%. Set CmTC01 block FT01 low alarm to -5%. Set operator alarms as required. If CmTC01.jacketFlow is above 50% then Set CmPM01.switch to off. Wait for CmTC01.jacketFlow below 10%. Fail if CmTC01.jacketFlow above 10% after 30 seconds. Set CmBV01.switch to off. Wait up to 30 seconds for confirmation. Disable Hold.

Report

Success or failure, with value of phase timer

Exit

Report done to recipe execution

Holding Procedure

Run

Stop watchdog timer. Set low flow alarm on FT01 to -5%. Set low level alarm on CMLI02 to -5%. Set CmTC01.mode to manual. Set CmTC01.heatControl to 0%. Set CmTC01 block OS01 to manual, outputs to -5%. Set CmPM01.switch to off. Set CmBV01.switch to off. Report holding done to procedural controller.

Restarting Procedure

Run

Check that status of modules is Good. Fail if not. Report restarting done to procedural controller. Go to Running Procedure Setup.

Description

Modules

batch chap 15.qxd

4/25/2006

3:19 PM

Page 289

Generic 88 Implementation

289

Table 15-8 con’t.

Stopping Run Procedure

Stop watchdog timer. If Running Procedure was before Run then Set CmTC01.mode to automatic. Set CmTC01.heatDemand to zero. Start a phase timer. While phase timer is less than 10 minutes If CmTC01.heatControl is near 0% then break If CmLI02.value is below Min Jacket Level then break. Set CmTC01 block FT01 low alarm to -5%. Set CmTC01.mode to manual. Set CmTC01.heatControl to 0%. Set CmTC01 block OS01 to manual, outputs to -5%. Set CmPM01.switch to off. Set CmBV01.switch to off. Report stopping done to procedural controller. Exit

Aborting Run Procedure

Stop watchdog timer. Set CmTC01 block FT01 low alarm to -5%. Set low level alarm on CmLI02 to -5%. Set CmTC01 block OS01 to manual, outputs to -5%. Set CmPM01.switch to off. Set CmBV01.switch to off. Report aborting done to procedural controller. Exit

The phase code is not shown in these tables because these phases are at the specification level of the code requirements. Operators could directly implement these phases if there was no automation. The actual code will depend on the automation system.

Review Understanding At this point, it would be best to test your modules and phases. Use a test recipe to invoke each equipment phase. Check each phase to see that it detects exceptions and handles them as you expected. Check each of the process control states. Check the process control modes for proper mode transfers. Make sure that you test going back to auto mode after the operator has set the procedural controller mode to manual and set some controllers to manual mode. Report your status to interested parties. Make sure that the business, process, and operations representatives are happy, so that you won’t be approached with as many changes during process startup. Again, make sure that people wanting changes are aware of the cost of the change at this point. In other words, push back and resist the request. It’s your budget that they are trying to use. “Pushing back” is unknown to many engineers, especially when the engineering gland is pumping out perfection hormones.

Know All There Is to Know Write SOP Manual Now that you have accumulated all of the control system knowledge, you are the logical person to write down what the operator must do for each normal and exception procedure. You may have the option of teaching what you know to people from Operations that will write the manual. If that happens, allow time to review what they wrote, or you may get a call at any time during a 24-hour day, seven days a week. Try not to be the only person who knows how the system works.

batch chap 15.qxd

4/25/2006

3:19 PM

290

Page 290

Chapter 15

Teach Operators and Test You will have to prepare materials to either teach operators how to run the control system or teach a few people from Operations that will do the operator training. Be sure to obtain basic control system operator training for your operators from your vendor to take care of screen navigation and other basic things. If you don’t teach, allow time to sit in the operator classes, where you can catch presentation errors and operators’ questions. You really do want to correct misconceptions before they become entrenched. Pay special attention to those parts of process operation that are not like the experiences of everyday life. An operator may think, “When my car slows down, I just give it more gas.” Explain why feeding more monomer is not the right thing to do to a polymerization reaction that is abnormally cool. If at all possible, let the operators find out how the process works by a simulation or by running water through the real process. If you do water runs, make sure the operators understand how the density and viscosity of the real materials will affect measurements and operation. This should also provide a thorough test of your design work. Find ways to exercise all of the exception handling during the training.

Release to Operations You may think that you are done when the training is over, but Operations may have developed a list of things that need to be fixed or improved while the operators were training. Allow time to fix things and modify the SOP. Resist making any improvements that use your project’s budget. Your resistance should not surprise anybody because you warned them about that. Operations signed off on the design at several sections of the design procedure. Now it is time for them to think about starting new projects. The difficulties associated with starting a new project explain why people want improvements done on your budget. The list of things left to do near the end of a project has been called a “punch list.” Once you have negotiated the size of the punch list and perhaps the titles of new projects, finish the punch list by fixing things and declaring other things to be improvements. Operations should accept your project as complete when the punch list is done. You may have to call on friends in high places to resolve Operations’ remaining problems.

Done This project is finished. Now you have built a library of modules and phases that will be useful to your next project. Estimate the time that you will save by having these modules and phases. If you are an engineer, divide the estimate by two because engineers are optimistic. If the next project is on a different control system platform then be pessimistic. In any event, your next project will not cost as much for development per phase and module as the first one did.

batch chap 15.qxd

4/25/2006

3:19 PM

Page 291

Generic 88 Implementation

291

Summary This chapter has discussed almost every aspect of the process of designing an 88 batch control system, from beginning to end. It is probably more than anyone can absorb in one reading. Hopefully, it has pointed you in the right direction so that you can get started, and will provide some answers when you discover the questions. You may do things differently because your circumstances are different, but this chapter should still serve as a useful guide to the art of building modules, phases, and exception handling. Some practical aspects of running a project were also given, from experience. Technology and organizations may change at a challenging rate, but people still have the same motives, somewhat modified by their environment.

batch chap 16.qxd

4/25/2006

3:20 PM

Page 293

Chapter 16

Role of 95 and Other Things ISA SP95 was chartered in 1995 to define the interface between business and manufacturing systems. The original idea was to define a firewall that would prevent business systems from sending arbitrary commands to manufacturing equipment. Some vendors were pushing the idea of integrated control from the boardroom to the factory floor. The people in the boardroom have high control needs, so they thought the idea was excellent. A firewall isn’t popular with people who see the enterprise as a single information problem to be solved by computers all the way down. Manufacturing provides mission fulfillment for the enterprise by making the products that generate cash flow, so it ought to be tightly integrated into an enterprise-wide information system, right? Well, no, because manufacturing systems are actually fragile. There are things that business systems should not be able to do to manufacturing systems. Control networks tend to be bandwidth-limited. Using each piece of computing and communications equipment to its maximum capacity saves money on the control project. The result is that too many unsolicited queries from business systems can shut down real-time control. Every process is run to its fullest capability, which means pushing the equipment to its limits. There is no room for an error made by someone who was not trained in the consequences of their actions. In most processes, an error can destroy expensive machinery that cannot be readily replaced, or kill people by releasing very hot or poisonous material, or destroy expensive products. Operators require extensive safety training before they are allowed access to a process control system, in order to prevent expensive accidents. People on the business side have enough trouble learning their own trades, some of which encourage taking risks. There is no point in training them how to operate equipment safely or to know the meaning of every measurement in the process. Manufacturing is the group that is trained in those things, and they are very aware of the consequences of making mistakes. People who are good operators and engineers tend not to have good business sense, so there is no point in training them how to run

batch chap 16.qxd

4/25/2006

3:20 PM

294

Page 294

Chapter 16

a business. The people that create databases are another breed altogether. The only individuals that might understand process control have worked in continuous or batch manufacturing. Discrete manufacturing has machines that can kill a person, but not many. This training gap requires a boundary, so that untrained people do not make operating decisions. Further complicating the issues is the fact that SP95 caught the rising wave for enterprise information management. Rather than scaling down unexpected demands on the control systems, the emphasis was on getting even more information. Further, SP95 proposed models that drove business systems deeper into the heart of manufacturing, even into Unit Supervision. This provoked a joint effort to define the roles of manufacturing control systems and business systems.

Joining 95 and 88 There is no question that the work done by SP95 to define models, terminology, and data models has caught the interest of users and vendors. Ongoing work could actually eliminate the middleware that has to be created so that proprietary enterprise and manufacturing systems can exchange information. There is no question that the work done by SP88 to define models, terminology, and control activities has made a difference in the way users specify and vendors build batch control systems. Ongoing work will create useful data interchange standards for recipes, schedules, and production history. 88 may be extended to some discrete and continuous processes. One day there may even be a communication standard between recipe execution systems and equipment entities. And so, there is no question that SP88 and SP95 will resolve their differences. That resolution is not complete at the time of this writing, so the following discussion will suggest some solutions. But first, here is a review of the details of the problem. See Figure 16-1, which is taken from 95.00.03 Draft 16 (March 2004) as Figure 8, “Activity Model of Production Operations Management.” The dashed oval at the bottom, labeled “Level 0-1-2 Process Control,” is where the control of batch, continuous, and discrete processes takes place. The levels are defined in the Purdue Reference Model. The four labels directly above the dashed oval are the proposed communication paths. 95 ends at the dashed oval. Figure 16-2 reproduces the batch process control activities in Figure 11-1 from Chapter 11 of this book. The top three activities are mostly business functions that are required for batch process control. 88 ends at Personal and Environmental Protection, even though the modules do contain process-connected equipment. The Protection control activity is independently connected to sensors and actuators.

batch chap 16.qxd

4/25/2006

3:20 PM

Page 295

Role of 95 and Other Things

Figure 16-1 Activity Model of Production Operations Management

Figure 16-2 Control Activity Model

295

batch chap 16.qxd

4/25/2006

3:20 PM

296

Page 296

Chapter 16

Interfaces Figure 16-3 truncates the earlier figures in order to show where the problems lie. The ideas expressed in 88 and 95 have to be rewritten so that a defined border can be placed between the two standards.

Figure 16-3 Comparison of Ideas from 88 and 95

Recipe Management Most people agree that 88 Recipe Management is a business function because recipes are a major part of the intellectual property of an enterprise. It can easily be seen as being part of Product Definition Management. 88 Process Management needs to obtain master recipes quickly so that it can create control recipes to start batches on time. This will not be possible when the Product Definition Management server or database is being upgraded, especially if the upgrade has technical difficulties. The present Recipe Management activity in 88 should be renamed “Recipe Buffer.” The activity still provides Master Recipes to Process Management. It has three functions: 1. Look ahead in the schedule for recipes that are not in the buffer. Delete the recipe that has the oldest date of use and request a copy of the new recipe from Product Definition Management. 2. Translate communications with Product Definition Management to and from XML or SQL if the business system uses a relational database and the control system does not, or if the recipe formats are different. 3. Answer requests from Process Management for copies of master recipes. No translation is required here.

batch chap 16.qxd

4/25/2006

3:20 PM

Page 297

Role of 95 and Other Things

297

There is one problem, though. 95 defines Product Definition Management in general terms so that it will fit all processes. 88 has very specific requirements for creating recipes. 88 introduced the separation of recipe and equipment, where the recipe knows what to do and the equipment knows how to do it. 95 knows what to do, as stated in Product Definition Management, but it doesn’t know how to do it. 88 knows how to do it, but the names don’t match. This is also true for the other interfaces to manufacturing activities.

Production Information Management 88 Production Information Management would seem to belong entirely in 95 Product Data Collection. Again, a buffer is needed between manufacturing and business systems. You do not want the traffic caused by someone on the business side doing a wild-card search on every process transmitter’s materials of construction to appear on the control network. You do want to build an active alarm list in the buffer by capturing every single alarm message, even when there is a cascade of alarms. In general, this activity must maintain operational production information even if the business system becomes unavailable. The present Production Information Management activity in 88 should be renamed “Production Information Processing.” The activity still provides production information to Product Data Collection. It has nine functions: 1. Capture process equipment entity alarm and event messages, and maintain current alarm and event lists. 2. Capture report messages from process control activities and procedural controllers. 3. Capture dialogs for acquire and release, and maintain a list of current acquired equipment entities. 4. Maintain status information for units and the batches that they contain, if any. 5. Capture trend data, perhaps as instructed by a procedural element. Similarly, capture analyzer data. 6. Capture operator entries and maintain a list of recent entries. 7. Maintain a “mirror” of all available asset data by slowly polling devices and reading changes. 8. Provide data for various operator displays that are required to maintain control. 9. Construct messages for Product Data Collection. Isolate this activity so that it can be changed as business system technology changes, without bothering production. This list is not complete, but it does show the real-time nature of communication with the batch control activities. There are also processing activities such as maintaining

batch chap 16.qxd

298

4/25/2006

3:20 PM

Page 298

Chapter 16

lists and summary data for operator stations. The control recipe has to be re-created from some of the messages. Some production statistics may be generated. This activity is shown as one-way, passing information up the chain. In a cell, production information also includes quality, inventory, and maintenance information that pertain to the cell. S95 business systems contain the source of that knowledge, so the information must come from the business network. Operators require this information even if the business network goes down (or is taken down). Redundant computers may be necessary due to the ephemeral nature of the messages. The communication system should provide secure, confirmed delivery of messages, but the messages can’t be re-created if the computer dies before data is saved to the disk.

Production Planning and Scheduling Production Execution Management and Production Planning and Scheduling are on the path between Production Dispatching and Process Management. 95.03, draft 20 says that Production Execution Management is a “collection of activities that direct the performance of work, as specified by the contents of the production dispatch list elements.” This activity selects a process cell, gives it a dispatch list element, starts production and directs the movement of a product through units. Clearly, this activity should talk directly to Process Management. Note that scheduling can’t talk to execution unless they share a common understanding of the terms for things that need to be scheduled and a data model that describes the context of those things. Well, it can, but not with any flexibility to accommodate new ways of doing things. Context is required so that the effects of changing one number can be calculated for numbers associated with surrounding equipment. 88 provides the models and terms required to define the relationships for a particular process. 88.01 says that Production Planning and Scheduling has one defined control function—to develop batch schedules. 95 covers this area with the Detailed Production Scheduling and Production Dispatching activities that lie directly above Production Execution Management. 88 Production Planning and Scheduling is not required in the model because the functions are duplicated. 88.01 says, “Process Management is the collection of control functions that manages all batches and resources within a process cell.” There is some overlap here with Production Execution Management. Can either of the activities be called redundant? Here are the functions of 88 Process Management: • Manage Batches—create control recipes and distribute them to units, initiate batches. • Manage Process Cell Resources—handle the schedule, monitor resources, allocate and arbitrate assignments. • Collect Batch and Process Cell Information—produce information for the historian.

batch chap 16.qxd

4/25/2006

3:20 PM

Page 299

Role of 95 and Other Things

299

Manage Batches sounds a lot like “starts production and directs movement of a product through units” except for creating control recipes. The 95 description does not provide any details of the critical capabilities described in Section 6.5.1 of 88.01 and detailed in Chapter 11. Similarly, Manage Process Cell Resources contains far more detail than is dreamt of in the philosophy of Production Execution Management. This is not unexpected. 95 is all things to all processes, down to the bottom of PRM layer 3, so it can’t possibly address the details of batch Process Management. The situation is similar to the difference between recipe phases and equipment phases. Production Execution Management has the names of things to do. 88 Process Management contains the details of how to do what is required for a batch processing cell. The list of tasks for Production Execution Management in 95 Part 3 includes things that are not in the description of batch Process Management. These are as follows (again from draft 20): c) Confirming that the work is performed according to the accepted quality standards. This may involve receiving information from quality assurance that indicates an unanticipated condition. d) Ensuring that equipment certifications, personnel certifications, and materials statuses are valid for the assigned tasks. f) Informing other activities when unanticipated events result in the inability to meet the work requirements. g) Receiving information from production resource management about unanticipated future availability of resources. h) Providing production information and events about production execution management, such as timing, yields, labor and material used, start of runs, and completion of runs. Clearly, both activities—Production Execution Management and Process Management—are required. The main job of Production Execution Management in a batch process environment is to send documents to Process Management that specify what is to be made and how much. This could be done as a series of work orders that specify the master recipe and the quantity. These work orders may include more detail on units to use, times to start, and even qualified personnel. Production Execution Management also receives feedback about the schedule from Process Management, and distributes that information on the business side. Process Management receives (and possibly translates) the work orders, which are all that it needs to begin producing batches. It informs Production Execution Management when things do not go as planned, and provides any information to task “h” that does not go through 88 Production Information Management. Process Management, or whatever it is called, is essential to flexible batch processing. Where continuous processes have their units in a fixed order, batch processes do not. Something has to select units on the fly and allocate them to production of a specific

batch chap 16.qxd

4/25/2006

3:20 PM

300

Page 300

Chapter 16

batch, then allocate units to new batches as they become available. Process Management does its job with real-time response, away from the business systems network. Process Management should be renamed “Process Supervision,” so that it does not appear to aspire to the heights of level 3. Production Execution Management should be redefined so that processes are allowed some autonomy in performing their work. If a process needs only a work order then that is all the direction that it needs. A continuous process has supervisory control that requires specific targets. In that case, Production Execution Management should expand its role to provide those targets. This concludes the discussion of 88-95 overlaps. If most of this were acceptable to SP88 and SP95 then the interface drawing could look like Figure 16-4. The dashed border represents the border of real-time control between control systems and business systems.

Figure 16-4 Possible Interface of 88 and 95

Missing Interfaces Storage 95 has an activity called Inventory Control, which is organized like Figure 16-1. 88 did not address the storage problem at all. We were having enough trouble with Production. Storage was something that happened in a tank farm outside of the process cell. Materials appeared and disappeared as if by magic. However, there are process cells that need a place to store intermediate products. The intermediates were made by the same units that will need them in order to make finished products.

batch chap 16.qxd

4/25/2006

3:20 PM

Page 301

Role of 95 and Other Things

301

Storing liquids or gasses requires tanks. Batch processing uses a tank as the central feature of a unit. This concept can be extended to storage units, where no active processing occurs. Storage units fit into the physical model at the side of processing units. They, too, have equipment modules for transfer equipment and control modules for hydrostatic tank gauging. Storage units generally don’t contain single batches, unless the business is so small that all batches are different. A storage unit is a resource for storing things. Solid storage looks more like a warehouse than a tank, unless the solid is a powder that can be fluidized. Either material or empty space in a storage unit needs to be allocated to various production activities. Storage units may be part of a process cell and use the cell’s transportation system. Storage units may also be gathered into storage cells (to pick a name) that serve as resources to many process cells. The storage cell probably has a complex network of distribution piping that allows simultaneous transfers within the cell. Paths in the network must be cleaned between transfers of incompatible fluids, or before any transfer of an edible or drinkable product. Large storage cells have network management that allows many transfers to take place. Setting up and cleaning up require procedures, which could be called transfer recipes. The cell could have a storage management activity that is very similar to the 88 process management activity. Transfer requests come from a scheduling activity. The manage storage cell resources function receives the request, checks its resources (storage units and transfer network), and sends a request to the manage transfers function to do the transfer. The manage transfers function may request a transfer recipe. Status information is sent back to Inventory Management. Manage transfers selects a transfer recipe with cleaning as required, and then hands it off to an instance of transfer supervision, which handles the details of the transfer by executing the recipe. Exception handling could be interesting. Storage management also handles requests for allocations of material or space in specific storage units and collects information for inventory management and storage information processing. Coordination control is required to handle transfers, just like process unit transfers. 88 has tools that can handle all of these things, even solid storage.

The Role of STEP The Standard for the Exchange of Product Model Data (STEP) is an ISO standard (ISO 10303) that describes how to represent and exchange digital product information. STEP was born in 1983, from existing international efforts. The first part of STEP

batch chap 16.qxd

4/25/2006

3:20 PM

Page 302

302

Chapter 16

describes a protocol for exchanging data that describes the geometry of a product. It became a standard in 1994. The goal of STEP is to have a set of standards that contain enough information to cover a product’s entire life cycle, including design, analysis, manufacturing, quality testing, inspection, and product support functions. STEP aims to digitize the “DNA” of a product, so that the product may be re-created from the set of digital data that is defined by STEP. Owners are interested in the idea of duplicating facilities that were destroyed by natural disasters. The military would like to be able to replicate plants that make war materials. Users would like to be able to make spare parts. The Saturn rocket technology would not be lost today if STEP had been completed in the early 1960s. STEP is a very ambitious project that is not moving fast enough to stay current with technology, if that is even possible. Unfortunately, STEP will do nothing to help us find the best practices of process control and build standards around them. STEP captures only what exists.

Expanding the Scope of 88 The discussion of all manufacturing processes in Chapter 1 shows that batch processing lies between discrete and continuous processing. Discontinuous processing lies between continuous and batch. In fact, there are many kinds of processing between continuous power generation and stamping discrete flat washers from sheet metal. All of these processes require control so that their products stay within specifications. Power generation must maintain voltage and frequency no matter what the load is doing. Samples of steel washers must be measured to ensure that the dimensions are within tolerances. Some industries have been around for a hundred years and some will start up next year. Some have time constants in hours and some in milliseconds. Some require many manual operations, some only have lights for the maintenance people. Some products are huge and some are microscopic or invisible, but all are measurable. In a word, processes are diverse. 95 seeks an interface with all of them or, at least, all that can afford that interface. All but the newest processes have evolved methods for process control. 88 showed that the diverse batch processes could be unified and rationalized by a standard, instead of drifting from one reinvented way of doing something to another.

Why Expand 88 SP88 has built a standard around the best practices of batch process control at the recipe and equipment entity level. There is nothing in 88 about best practices for basic control. However, 88 does have control activities that can interface with S95. Can the 88 principles be applied to all processes? To put the question another way, why spend resources on doing something like 88 for other processes? S95 has a onesize-fits-all set of models in S95.03, so what’s the problem?

batch chap 16.qxd

4/25/2006

3:20 PM

Page 303

Role of 95 and Other Things

303

The problem is that one-size-fits-all is the old “accounting package” approach to selling systems. Everybody knows that they need one, but vendors and users alike don’t know what those needs really are. The users only know what they developed, and the vendors don’t understand the user’s explanations. It takes a group of vendors and users to define and standardize models and terminology. Without standards, vendors sell systems any way that they can, and then the users pay for “maintenance” programmers to figure out what was really required. 88 goes a long way to clarify the needs of batch processing. Vendors have responded by building systems that meet those needs, to the best of their understanding. Users have made their batch processes more efficient and new projects less expensive. There are good economic reasons for standardizing the models and terminology of industrial processes. Competitive people worry about giving their competition ideas. There were users in SP88 that got what they wanted without revealing exactly why they wanted it. The main benefit of meetings with vendors and users is that each becomes aware of the needs and limitations of the other. One user may do that with one vendor, but that doesn’t stretch anybody. The vendor may decide not to develop some of the user’s needs because they see no economic return, when there are other users with similar needs that would make development pay off. The vendor has no doubt that development is necessary to meet the requirements of a standard. The point is that standards benefit everybody, and may even allow development breakthroughs. The answer to the “why spend resources” question is that there are economic returns, and the people that participated in the discussions have a head start on everyone else in finding those returns. 95 needs those standards in order to fulfill its purpose. Without them, 95 can only write guidelines for one side of the interface to manufacturing, in their own terminology.

Features of 88 88 is a good starting point for other process standards. The following discusses some of the features of 88 that may (or may not) fit the needs of other processes. 88 assumes that flexible processing is desired in order to change products rapidly, if no new equipment has to be built. Continuous processes are designed to maintain an operating state that is as close as possible to the economically optimum product purity. Most process changes are designed to increase production, up until new technology makes the process obsolete. Flexible manufacturing has been applied to the discrete processes, mostly those that make “batches” of parts. A man at a lathe is far more flexible than many numerically

batch chap 16.qxd

4/25/2006

304

3:20 PM

Page 304

Chapter 16

controlled machines, and less expensive to program. While computer-controlled machines are flexible, the economics have not been able to encourage flexible machining in general.

Process Model The first thing that 88 addresses is the process model, which decomposes a process into stages, operations, and actions. Certainly all processes have process actions, whether a hole is drilled, a batch is changed a little, or a distillation tray slightly separates fluids that Nature has joined together. Process operations should be universal because it takes a set of actions to perform a major transformation. Continuous processes have unit operations like distillation. Discrete processes are more likely to do machining operations. Process stages may be found in all kinds of processes, just as there are stages in a human life. Discrete products go through stages as they are assembled. Batch products go through stages as their chemistry is changed. Continuous process lines may be divided into stages like reaction, purification, crystallization, and separation.

Equipment All processes have processing equipment. The equipment can be classified in a hierarchy of units and modules, but other processes already have familiar names for their hierarchies. Units do not contain a batch in most non-batch industries, depending on how you stretch the 88 definition of batch. Equipment modules do not run phases in any non-batch process. The function of the module in other processes is to encapsulate controls and equipment that perform a complete operation on a product, such as a station at an assembly line. A station may perform a mechanical sequence driven by cams or their servo equivalent. The word phase would have to be badly deformed to cover that case, leaving it no different from sequence. Control modules should be no problem, at least for processes that have identifiable pieces of control equipment. A Quality Assurance person with tools and reports would be a very broad definition of a control module in an equipment hierarchy. The punch press for stamping out washers has no process control, unless you count the safety interlock on the finger-saving guard. The punch press may be called a unit if we broaden the definition of unit to mean a collection of equipment that processes a major transformation in the product. Creating a round washer with a hole in it from a flat sheet of steel qualifies as a major transformation. Does drilling a hole in something make a major change? It depends on the number of holes that are required to make the product. Perhaps the punch press is a unit because its processing is relatively independent of other processing equipment.

batch chap 16.qxd

4/25/2006

3:20 PM

Page 305

Role of 95 and Other Things

305

An assembly machine surrounded by processing stations is clearly a unit, and the stations are clearly equipment modules that do not have to contain control modules. If the motions of an assembly station are not all determined by cams, then control modules consist of limit switches, timers, actuators, and servos. Is the long conveyor system for automobiles one unit? It could be called a transportation system, with stationary units that do relatively independent processing, but the units are not independent of the transport system. This sounds like a pipeless batch process with a fixed route. Continuous processes have units that maintain continuous flow through each unit. They do relatively independent processing except that they depend on the continuous flow of materiel to bring in raw materials and take away products. This is not unlike the automobile assembly line, except that the materials are fluids or fluidized solids. Continuous units have equipment modules, mostly in the form of heat exchangers or pumping systems. Some heat exchangers function as condensers for process vapors. Almost all equipment modules have control modules, if only for temperature or level. Is a multi-stream analyzer a control or an equipment module? Even if it does have its own building and operates independently of the process, it is a control module because its primary function is to provide process measurements. Is a heat exchanger a unit if the process fluid flows through it? That depends on whether the energy exchange makes a major transformation of the product. Is a phase change a major transformation? A condenser is probably not a unit. On the other hand, a boiler is obviously a unit, but its main purpose is to transform water into steam. A cooling tower is a unit because, like a boiler, it is relatively independent of the process. A condenser may be a unit if it stands alone. The condenser on a distillation column is a part of the column. 88 considered boilers and cooling towers to be utilities, not units or modules. They are units in something called Utilities, if they serve other cells. Nobody would call them common resource equipment modules unless they are in only one process cell. That brings us to the level above units. The continuous processes call a collection of units that make one product a train or production line, like A Line and B Line or the Formaldehyde Train. The ISO CIM model for discrete processes calls a group of cells a section (and calls an equipment module a station). 88 doesn’t have a group of cells, unless Cell Group is added, as discussed in the Physical Model section of Chapter 14. Existing plant names for groups of process and control equipment will cause trouble unless the control and equipment modules are given more abstract names or redefined. The modules should be differentiated by purpose, not by allowed types of control.

Recipes All processes have some form of product definition, but only batch processing calls that definition a recipe. Continuous processes define products in terms of properties of the product, like chemical analysis. The power industries have no recipe at all, but run at rated voltage and frequency, within the limits of rated power.

batch chap 16.qxd

4/25/2006

306

3:20 PM

Page 306

Chapter 16

Batch processes are based on recipes. Flexible batch can handle recipes that haven’t been created yet, within the limits of the process actions that can be done by the equipment. Discrete processes may have a Bill of Material that specifies machines to use as well as the properties of materials. Otherwise, product definition consists of a mechanical drawing and its notes. It seems likely that the other process industries would choose a different term than recipe to describe what they do. Recipes contain equipment requirements, and all processes can use this feature. The formula contains numeric and other data that is related to the process. All processes have such data, from column temperature setpoints to the dimensions of a stamped washer.

Procedures All processes have procedures for making products. Continuous and discrete processes have most of the procedure built into the processing equipment. Continuous processes are built to supply one product in large quantities, perhaps with some seasonal variations. Discontinuous processes are more like job shops that accept orders for large but finite quantities of product, such as paper mills, steel mills, and specialty chemicals. There may be procedures for starting and stopping a production run, but the run uses basic regulatory control to maintain the product within tolerances. Supervisory control of basic control may also be used. A batch process would be just a set of process actions if there were no procedure to direct those actions. This is true of the other processes as well. The procedure for a continuous plant is defined by the order in which material flows through the unit operations. Some piping configuration changes may effect changes in the procedure, but otherwise the “recipe” formula is all that is required to contain the data that define the product. Processes that change the chemistry of materials do so by mixing ingredients at certain conditions of pressure and temperature, perhaps with catalyst material or laser light to drive the reaction. The discrete processes change the shape of solids. Much of the auxiliary control is motion control, to place a shaping device in the right place at the right time and retract it. Moving devices in steps requires repeated acceleration and deceleration, which wears out the mechanical joints, so phases with steps are not used. A discrete process control module is far more likely to contain a cam (or servo equivalent), a four-bar linkage, and an effector device than a sensor and actuator. Pneumatic or hydraulic actuators and position sensing switches with a sequencer may be used instead of cams. Discrete process control modules become an equipment module when their actions are synchronized. Like continuous processes, discrete process equipment modules do not need a procedure, in the sense of ordered sets of instructions, in order to perform their process

batch chap 16.qxd

4/25/2006

3:20 PM

Page 307

Role of 95 and Other Things

307

functions. There is a manual called Standard Operating Procedures for the continuous processes, but it is almost entirely about exception handling. Its subtitle could be “What to Do When an Alarm Occurs.” True, discrete and continuous processes need some kind of startup and shutdown procedures, and perhaps other exception handling procedures. There has been no economic incentive to automate those procedures, so far. Falling prices and easier configuration (due to 88) of procedural control may change that. Batch processes get their flexibility from a set of separate process actions that may be ordered by a procedure. The other processes would be interested in 88 procedural control to the degree that they have separable process actions that are required to make products.

Control Structure 88 describes basic, procedural, and coordination control. Continuous processes would add supervisory control. Supervisory control solves mathematical models as it searches for the optimum processing conditions to make a specific product. The optimum settings change as feedstock composition changes. Supervisory control directs basic control by changing controller setpoints every time that it finds new optimal conditions. A “hill-climbing” algorithm never stops changing setpoints because it is always looking for a better solution. Discrete processes would add motion control either to basic control or as another item in the hierarchy. There are discrete processes that have no regulatory control. This fact drove the separate development of PLCs and DCSs when computers were limited by memory and execution rate. The DCS is for continuous control, while the PLC is for discrete control. Batch took what it could get. Computers no longer have those constraints, but ways of thinking about things change slowly. Coordination control mostly concerns equipment allocation. This is not a problem for continuous processes. Batch processes need to allocate units and transfer fluids among them. Discrete processes may be arranged as production lines so that the material naturally comes to the next processing function. Expensive machine tools may be allocated that require the coordination of transportation by robots or cars that run on real or virtual tracks. The allocation and transport required for fixed machine tools may represent a worse case than batch processing.

Equipment Entities These were covered above in Equipment. The discussion shows that defining physical entities by the kind of control that they use causes new definitions to be required. 88 does not describe the worst case. Perhaps equipment entities should be classed by function, without regard to the kind of control required to perform that function. It is

batch chap 16.qxd

4/25/2006

3:20 PM

308

Page 308

Chapter 16

enough to say that a unit processes material in a manner that is relatively independent of other units. A unit is a batch unit if it can do procedural control and hold all or part of the batch while it does it. A continuous unit operation is a wide spot in a pipeline where some form of processing occurs (unless it is a pipe reactor—then it’s not wide). A discrete unit might only use motion control. Mobile units are not discussed in 88. A “pipeless” batch process has stationary equipment modules that provide process functions to roaming reactors. This is expensive but very flexible. A complete batch is processed from beginning to end in one reactor, so recipe procedural control has to follow the reactor that contains the batch that it is controlling. A similar thing happens to pans on a conveyor belt where each product is identified and some assembly is required. If a container contains an identifiable batch of product and requires procedural control, then it is a batch unit. Equipment modules can serve the purpose of defining a group of controlled equipment, if the control that they use to coordinate a group is not specified. Control modules seem to be useful in all processes if you are not picky about how they get the job done. They can be defined as modules that contain equipment that touches the process and the least amount of control required to do their function. The things that touch the process are sensors, actuators, and effectors. Effectors make changes in the shape of products. Perhaps the discrete industries have a better word for the general case of cutting tools, hot wires, extruders, and so on.

Modes and States 88 defined a set of modes and states that apply to procedural control, but they do not represent the worst case. Discrete processes that have a flow of objects from one unit to the next handle exceptions in single units with buffer storage. When a unit is taken out of service, perhaps to clear a jam, units ahead of it continue processing until the incoming buffer for the affected unit is full. The unit that has no more outlet storage stops, and the full buffers propagate up the line. Downstream units keep running until their incoming buffers are empty. The units do not stop, but enter a standby state, ready to go when the jam is cleared and processing resumes. Buffer storage is not always used, but standby exists as an alternative to the running state that requires no procedural control in order to change between states. It does require simple interlocking, so that the motion control cam will not begin a new cycle if there is no product to process or no place to put it. A similar thing happens in continuous control, where buffer tanks are used between unit operations. Override controllers continuously reduce flows if the buffer tank level gets too high or too low. There is no standby state, but you very seldom get jams

batch chap 16.qxd

4/25/2006

3:20 PM

Page 309

Role of 95 and Other Things

309

within the units. When trouble does happen, a crane may be needed to disassemble the unit before it can be repaired. The line might be shut down for days. The sizes of buffer tanks are determined by risk analysis.

Back to 95 The purpose of the discussion in this chapter has been to see if 88 could be used to represent all processes to 95. It turns out that many 88 definitions would have to be broadened (and weakened) to accomplish that goal. The problem is that there are no comparable standards for discrete and continuous processes. 95 needs model and terminology standards to be able to ask for and interpret process data. The OPC standards allow business systems to query and receive responses from most process control systems. 88 provides a structure for storing the data and generating reports from it. Other processes continue to be structured by the way that the structure evolved at a particular site or enterprise. This is what keeps vendors in the services business. You are paying extra because you don’t have a standard structure. Perhaps you should talk to ISA about forming a standards group that will standardize 80% or more of the things that your industry wants to store and report. 88 may provide a template for your standard, which will save time by avoiding reinvention. You will need a group of experts from your process or industry and an effective leader. The preceding discussion has focused on the production information interface to 95. Product definitions and schedules must be sent to manufacturing, perhaps as commands. OPC has started a working group to do this. The amount of data requires structures that enable messages to be understood on both sides. Again, 88 defines structures for the purpose. These structures go a long way towards defining individual industry structures, which reduces the cost of custom work. Perhaps the reason that other industries have not standardized is that neither the business nor the manufacturing side have automated the definition and scheduling processes, perhaps because there is no significant cost driver.

Fieldbus Originally, this section of the book was going to be about future technologies for batch process control. The fact is that control vendors don’t have much control over the technology, and haven’t since microprocessors were introduced. Software engineers write the code that gives the hardware its control functionality, but they don’t write their own tools and operating systems anymore. Business practices require commercial, off-the-shelf technology whenever possible. Technology innovations can be found in magazines read by computer and communication scientists, far outside the scope of this book. There are not many new sensor or

batch chap 16.qxd

4/25/2006

310

3:20 PM

Page 310

Chapter 16

actuator technologies left to discover after a century of developing process control systems, except for analyzers. The microprocessor has made temperature compensation more exact, providing more accurate measurements. It has also enabled digital communication with a field device.

History One of the last major vendor developments in the control field began with the addition of microprocessors to pressure sensors, led by Honeywell Smart transmitters and then Rosemount HART devices in the early 1980s. This led to a call for ISA to reopen the SP50 committee in 1985 in order to develop a standard digital field signal in addition to existing 4-20 mA DC and 3-15 PSI signals. As it turned out, many communication scientists were ready to develop something new, and many vendors were concerned that they would be left behind if some other vendor’s technology became standard. The political stuff died down about five years later, after it became apparent that no existing scheme was going to win. As so often happens, an innovation was driven by a user’s bad experience. It seems that the stainless steel bodies of flow transmitters in a refinery actually had aluminum plugs in small drain holes in the body. One day a fire near a column heated the body of a transmitter to the point that the aluminum softened and pressure blew a plug out. The hole then sprayed fuel on the fire, making it much worse. Naturally, no one was watching this when it happened so the damage was not negligible. The user had a brilliant Ph.D. in its central research center (now closed) that understood that the faulty transmitters could be quickly replaced if vendors made interchangeable smart transmitters. A standard digital fieldbus was the perfect way to enforce interchangeability. It would also allow body temperature as well as flow to be read from the device. At the same time, the good doctor was vexed by the ever more complicated and untestable software being put into digital controllers (in 1985). He joined SP50 with the goal of standardizing control functions in field devices, so that a PID could go on controlling to its last setpoint as long as there was field power to open the valve. He also expected better testing and fewer revisions to software used in field devices. The idea caught on with users and then vendors joined to defend their interests. The communication people were entranced by a seven-layer protocol that worked by defining the interface signals between layers. This model was implemented as MAP/TOP under the sponsorship of automotive manufacturers, who were also looking for standard factory communication. Naturally, SP50 adopted the model but cut out the unnecessary layers that slowed it down. Control in the field was added as the User Layer at level 8. Most of us on the User Layer committee thought that it was an idea whose time had come. The eighth layer turned out to be essential to making sure that the work of the communication scientists was suitable for its intended purpose.

batch chap 16.qxd

4/25/2006

3:20 PM

Page 311

Role of 95 and Other Things

311

Sadly, a hundred experts proved to be as unmanageable as a herd of cats. A group of vendors, no longer afraid of having a standard but of not having one, formed a consortium called the Fieldbus™ Foundation (FF). A small group of experts was sent to a hotel in the Black Forest in November 1993, and told to stay there until we had something worked out. Interchangeability was replaced by interoperability. After specifications for the layers were written, vendors built prototypes while interoperability tests were written. Tested devices were demonstrated at the 1996 ISA Show. Early adopters proved the concept, and the word spread. Now there are about 200 different registered FF devices from many vendors. Over 500,000 FF devices and 8000 systems had been shipped by the end of 2004. Vendor production of analog field devices is now more FF than the previous 4-20 mA standard. The people that run plants are reluctant to change something that works, so some still replace equipment with 4-20 mA devices. Others tried FF and now do replacement projects as well as new projects with FF devices.

Future for Batch Control The FF devices being sold now are largely for continuous processes. The control functions that are implemented are for continuous control because that’s a great way to get a return on the development effort. There are PLCs that take FF wiring, possibly with intrinsic safety barriers. There has been no effort to move batch control functionality into field devices because there are no specifications for such devices. The users have not discovered the benefits of control in the field, possibly because reliability is not the problem in batch plants that it is in continuous processes. This will change as batch users discover that control in the field will standardize the way control modules are built from field devices, which in turn will standardize the way equipment modules are built. Finally, standard module interfaces will standardize the way equipment phases and exception handling are written so that the phases can control the modules. Going any higher will get you into the world of databases and XML messages, which are already being standardized as the enterprise seeks to extend its tendrils into the manufacturing area.

Control in the Field The advantages of distributed control should be well known after thirty years of distributed control systems. At first, the DCS was not distributed at all but set up in racks along side of the marshalling panels that received all of the field wiring into one control house. The idea of a communication network took some time to become familiar. Some of you may remember Honeywell’s fire-axe demonstration, chopping one of the redundant paths without stopping control. Control in the field extends the concept of distributed control into the field devices. Again, people waited to see if there would be communication issues, and this time the wire was not redundant. In fact, it was an advantage to be able to install another transmitter and use the same pair of wires that was already running a control loop.

batch chap 16.qxd

4/25/2006

3:20 PM

Page 312

312

Chapter 16

For a while it looked as if the wire and labor savings possible with fieldbus would be the major selling point. Now people have reported 50% savings in ongoing maintenance because you can ask the device about its health while it is doing its control function. An 85% reduction in control room space and a 90% reduction in the cost of commissioning loops are nice, but they are one-time savings. With today’s DCS your ability to maintain control of the process depends on field devices, wire, power, an interface card, and either a programmed computer or a PLC with a control configuration. With control in the field you can maintain control while you replace an interface card, computer, or PLC that has lost its ability to provide control functionality. Field devices have purpose-built computers, not Wintel machines, with no moving parts. Field device software is thoroughly tested because no one wants to replace thousands of devices because of a software problem. Control in the field allows modular equipment, perhaps mounted on a skid or wheels, to be plugged onto the FF network, all ready to perform its process function. All described functionality has been tested at the factory. Installing a skid of equipment is no different than hooking up a transmitter, except that more piping and power may be involved.

Higher Bandwidth The original FF products (H1) had a low transmission data rate of 32 KB, so that they could work with existing plant wiring. FF began offering High Speed Ethernet (HSE) interoperability test kits to developers in February 2005. Before that, specs were written in 2000, prototypes were built and tested with preliminary test software, problems were fixed, and the first approvals given to the prototype vendors in 2004. A pilot project was assembled at an operating plant and the test was successful in May 2005. HSE does not have the bandwidth or power limitations of H1, but it has the same (well, almost the same) User Layer. Some data sizes were expanded because the message size limit is no longer just 128 bytes. HSE can handle large amounts of discrete data, which was a bandwidth problem for H1 and low power processors. Multipoint process analyzers were a problem given the limitations of H1, but not with HSE.

User-Defined Function Blocks FF standardized and has interoperability tests for about thirty control function blocks. A project to specify a Flexible Function Block (FFB) was started in 1999, but it moved slowly because people didn’t quite know what to do with it. The HSE demonstration in May 2005 used several FFB as wrappers around sequential function chart configurations that opened 8-inch butterfly valves in 100 PSI nitrogen lines and then closed them 800 milliseconds later. All FF devices have time synchronized to a time master, so a wave of timed pulses could be distributed among several devices. The FFB developed into an interface between either proprietary code or user-configured programs and other FF devices. Standard function blocks have names for their parameters that are known to host systems because they are standard. The FFB lets

batch chap 16.qxd

4/25/2006

3:20 PM

Page 313

Role of 95 and Other Things

313

users configure their own names for parameters if their configuration device supports Device Description Language (DDL). DDL has been used to allow vendors to add extensions to standard blocks in such a way that any host with DD Services can display the nonstandard names and data types. HSE and the FFB are too new to have any mainstream support, but support will grow as surely as the support for H1 grew. Eventually, the batch control community will realize that FF has made it possible to distribute equipment procedural control to field devices. The FFB is a natural application for module interfaces. The module interfaces will have to be tested for interoperability, which will effectively make them standard. Standard module interfaces will encourage and enable the development of standards for designing and coding procedural elements like phases. When those standards are accepted, it will be possible to sell standard modules and standard phase libraries that are more than a Java compiler and a cheery “Good luck!” Development costs will drop to very low levels once the module and phase libraries have been developed. Look for vigorous opposition from the vested interests who sell batch application development. Or maybe not—the market is supposed to be able to adjust to innovation. If you would like to see such standards then contact the Fieldbus Foundation, and ask them what they would need to get started.

Summary This final chapter has discussed some batch process control issues that were not resolved at the time of this book’s publication but will have a major influence on the evolution of 88. This chapter will only be interesting to historians after the issues are resolved, but perhaps these words will shed some light on the origins of the decisions. Joining 95 and 88 concerns the three interfaces between the two standards. It is not good practice to define one thing in two different standards, because they will eventually drift apart, if they were ever together. The discussion in this chapter suggested that 95 should define the names and properties of the interface activities, while 88 should describe the behavior and details of each interface activity. There should be companion standards similar to 88 for other processes. The missing interface called storage was also discussed. Expanding the Scope of 88 discussed why that was necessary and how seven concepts of 88 could be applied to continuous and discrete processes. If the fit was good then 88 could be used as a “template” for the companion standards needed by 95. The result was a firm “Probably.” Continuous processes need a model for supervisory control. Discrete processes need a model for motion control. All processes have procedures, but only batch requires procedural control in order to make a batch. Recipes are called other things in other industries, and have different emphases on the parts of a recipe. There really is a lot of common ground, if only we can agree on the names and definitions.

batch chap 16.qxd

314

4/25/2006

3:20 PM

Page 314

Chapter 16

Finally, the section on Fieldbus discussed the implications for change that control in the field will have on batch process control. If the Fieldbus Foundation could be persuaded to take up the work then standard modules and standard phases could become a reality. The technical stuff is there—all it takes is leadership and resources.

batch biblio pp315.qxd

4/25/2006

3:45 PM

Page 315

Bibliography

ANSI/ISA-88.01-1995 - Batch Control Part 1: Models and Terminology (Formerly ANSI/ISA-S88.01-1995). ANSI/ISA-88.00.02-2001 - Batch Control Part 2: Data Structures and Guidelines for Languages. ANSI/ISA-88.00.03-2003 - Batch Control Part 3: General and Site Recipe Models and Representation. ANSI/ISA-88-00-04-2006 - Batch Control Part 4: Batch Production Records. Automation, Systems, and Instrumentation Dictionary. Fourth edition. ISA, 2002. Bernard, John W. CIM in the Process Industries. Independent Learning Module Series. ISA, 1989. Fisher, Thomas G. Batch Control Systems. Resources for Measurement and Control Series. ISA, 1990. Lipták, Béla G., editor-in-chief. Instrument Engineers’ Handbook. Volume 1 – Process Measurement and Analysis. Fourth edition. CRC Press/ISA, 2003. Volume 2 – Process Control and Optimization. Fourth edition. CRC Press/ISA, 2006. Volume 3 – Process Software and Digital Networks. Third edition. CRC Press/ISA, 2002. McMillan, Gregory K. Tuning and Control Loop Performance. Third edition. ISA, 1994. Merriam-Webster’s Collegiate Dictionary. 10th edition. Merriam-Webster Inc., 1993. Nisenfeld, A. E., editor. Batch Control. Practical Guides for Measurement and Control Series. ISA, 1996. Parshall, Jim and Larry Lamb. Applying S88: Batch Control from a User’s Perspective. ISA, 1999. Shlaer, Sally and Stephen J. Mellor. Object-Oriented Systems Analysis: Modeling the World in Data. Yourdon Press Computing Series. Yourdon Press, 1988. Webster’s New Collegiate Dictionary. G. & C. Merriam Co., 1958.

315

batch front of book copy.qxd

4/24/2006

10:50 PM

Page iii

Batch Control Systems Design, Application, and Implementation, 2nd Edition William M. Hawkins and Thomas G. Fisher

batch front of book copy.qxd

4/27/2006

4:05 PM

Page iv

Notice The information presented in this publication is for the general education of the reader. Because neither the author nor the publisher have any control over the use of the information by the reader, both the author and the publisher disclaim any and all liability of any kind arising out of such use. The reader is expected to exercise sound professional judgment in using any of the information presented in a particular application. Additionally, neither the author nor the publisher have investigated or considered the affect of any patents on the ability of the reader to use any of the information in a particular application. The reader is responsible for reviewing any possible patents that may affect any particular use of the information presented. Any references to commercial products in the work are cited as examples only. Neither the author nor the publisher endorses any referenced commercial product. Any trademarks or trade names referenced belong to the respective owner of the mark or name. Neither the author nor the publisher makes any representation regarding the availability of any referenced commercial product at any time. The manufacturer’s instructions on use of any commercial product must be followed at all times, even if in conflict with the information in this publication. Copyright © 2006 ISA – The Instrumentation, Systems, and Automation Society All rights reserved. Printed in the United States of America. 10 9 8 7 6 5 4 3 2 ISBN-10: 1-55617-967-7 ISBN-13: 978-1-55617-967-9 No part of this work may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, electronic, mechanical, photocopying, recording or otherwise, without the prior written permission of the publisher. ISA 67 Alexander Drive P.O. Box 12277 Research Triangle Park, NC 27709 Library of Congress Cataloging-in-Publication Data Hawkins, William M., 1938Batch control systems : design, application, and implementation / William M. Hawkins and Thomas Fisher.-- 2nd ed. p. cm. Rev. ed. of: Batch control systems / Thomas G. Fisher ISBN 1-55617-967-7 1. Process control--Data processing. 2. Process control--Automation. I. Fisher, Thomas. II. Fisher, Thomas. Batch control systems. III. Title. TS156.8.F573 2005 660'.2815--dc22 2005029956

batch front of book copy.qxd

4/24/2006

10:50 PM

Page v

This book is dedicated to the memory of Thomas G. Fisher The following is extracted from Bill Wray’s obituary for Tom, written for the World Batch Forum: It is with profound sadness that we announce the loss of our friend and colleague, Tom Fisher. Tom passed away peacefully on December 6, 2001 after a long battle with cancer. He faced this struggle as he faced other challenges in his life, with dignity and courage. Tom had a long career with The Lubrizol Corporation, joining as a process engineer in 1967 and rising to become Operations Technology Manager. He had previously worked for DuPont and NASA. His vision led to the formation of the ISA SP88 committee in 1988 and to the subsequent development of the batch automation standards we benefit from today. He served as Chairman and Editor of this committee as well as a leader of the IEC SC65A Working Group 11 for batch control. Further, Tom served as ISA Publications Vice President, was active in the ISA SP84 committee, and a member of the Process Control Safety subcommittee of the Center for Chemical Process Safety. His many contributions were recognized by ISA when he was named a Fellow of the organization. Tom was also a Registered Professional Engineer and member of the AIChE. Without Tom’s leadership and vision, there would be no ANSI/ISA-S88.01-1995, Batch Control Part 1: Models and Terminology, he is therefore rightfully known as the Father of Batch Automation. Tom was a teacher and taught courses through the ISA, WBF, and other organizations on topics such as safety interlock systems, programmable controllers, and batch automation. Above all else, teaching was his passion. Further, he was an accomplished author, having written several books and articles on batch automation and safety interlock systems. If you ever met Tom, you know he was one of the truly nice guys in this world. Tom is survived by his wife Shirley, his children, Gary, Jeff, and Rebecca and several grandchildren. We will miss him greatly, not only as a mentor, but more importantly as a friend.

v

batch front of book copy.qxd

4/24/2006

10:50 PM

Page xv

Foreword As a general principle, manufacturing is nothing more than changing raw materials into something else that is, hopefully, of greater value than the raw materials themselves. In many types of manufacturing, machinery attacks raw materials directly. For example, machines are frequently used to shape chunks of metal to make parts that can then be assembled to create something like an automobile. The raw material is changed into another form because we do something physical and easy to understand directly to the raw materials. Process manufacturing is a little special and often different in approach. While some processing activities do make overt changes in the material with activities like mixing or heating, many other processing activities merely set the conditions and the environment to which the raw materials are exposed and then let nature take its course. Chemicals react because the conditions are right, not because we have a machine that does the job. Bacteria or cells or corn mash grow and ferment because the environment is conducive for such goings on. In those cases, all we can do directly to the raw materials is to get them to the conditions that will let them do what we would like for them to do. Process manufacturing has been around for a long time. Most societies since prehistoric times have found a way to make beer and/or wine. For both products, the process consisted of putting the right stuff in the pot and then keeping the pot just warm enough without letting it get too warm. What was going on there might have been ancient and it may have been manual rather than automatic, but it was process control. Without control, beer can happen, but don’t count on it. All modern process manufacturing requires control if it is to function with any reliability at all. It is an essential element of process manufacturing even though it is often looked on as “instrumentation” that is added on to a process to somehow make it work better. The reason for this slightly derogatory viewpoint is that manual control doesn’t show and doesn’t seem to count as control in the minds of many. The only type that gets credit as “real” control is the automatic version. Part of this view comes from the traditional approach to automatic control in continuous processes where “loops” and “devices” are applied to bits and pieces of a process so that a human operator can manipulate targets for controllers. The controllers (the perceived “real” control) then set small groups of equipment or process variables to a desired condition and twiddle valves and things to maintain that condition. A simple controller-based view of control may well be justified, or at least tolerated, in continuous processes where the whole intent of the technology is to maintain the same operating conditions indefinitely. The only times targets for control have to be adjusted are at startup, shutdown, and when things are not behaving well. That is hopefully much less than 5% of the time the process is running so the control exerted

xv

batch front of book copy.qxd

4/24/2006

10:50 PM

Page xvi

by the operator is often considered trivial and the “real” control looks like the little magic boxes or control room systems that keep massive processes from changing. That distorted view of control was one of the factors that hampered the development of more effective control of batch processes. The fool things would simply not stay in one state. They had to keep changing from one operating condition to another. Of course, the operator was making that happen so it was traditional to consider most batch processes as fundamentally manual in nature. However, it was obvious that the operator was doing control and was necessarily doing it almost 100% of the time the process was running. In that setting, the operator’s role in the control of the process couldn’t be ignored. In spite of that, it was difficult to figure out how to go about doing manual control tasks with more automatic control even after computer based technologies gave us the tools to effectively confront the problem. Traditional state oriented and regulatory control could solve part of the problem and sequences could be imposed but problems remained. Because people are very flexible, it was not immediately obvious that batch control had to also be flexible. Fixed sequences would work for a while, but often had to be redone as the process changed or other process requirements were added — changes and minor improvements that had seldom bothered the operator. In addition to that, the operator usually had to still do a lot of the control. Many approaches to the problem were proposed and tried, some quite inventive, but it took a while for a broadly accepted approach to batch control to emerge; a simple little standard produced by ISA called ANSI/ISA-88.01-1995 (aka ISA 88). To discuss control of batch process manufacturing without mentioning ISA 88 is a little like discussing a sandwich while avoiding the mention of bread. The standard defines an internally consistent approach for control of batch processes and the standard terminology that allows it to be described and understood. Because it addresses the entire scope of manufacturing activities, including procedure and coordination as well as more traditional single point control, it deals with essentially all of the functionality required in a batch processing plant. It also provides tools to help define the way the processing equipment should work with manual control, automatic control or some mixture of both. Whether the challenge is improvement to an existing process or a major new installation, the standard is a pretty reliable guide for automation. What, precisely, is ISA 88? Physically, it is a combination of five documents; some still in preparation as this is written. The first part entitled Models and Terminology is a document that defines most of the important concepts the standard contributes to manufacturing automation. The committee that wrote the standard realized that a common set of terms would be needed to even start work on a standard, so terminology was addressed first. However, names can only be applied to things or concepts that are understood. At the time that work on the standard began, much if not most accepted terminology was related in some way to commercial products, most of which differed significantly from supplier to supplier. In addition, functions common to multiple suppliers often were assigned unique proprietary names. Also, no name

xvi

batch front of book copy.qxd

4/24/2006

10:50 PM

Page xvii

existed for many important concepts. To deal with those problems, conceptual or functional models were created that could provide a uniform context for terminology. The models are general so that they can represent almost any batch manufacturing process and are valid no matter how control is actually implemented. Terms were then matched up with elements of the models. This may sound unacceptably abstract, but it actually works. Once the basis for the models is clear they are intuitive and the terminology can be applied to any physical process. The purpose of standard terminology was to provide a common language free of techno babble. Where words in common use could be applied, they were used. Where more than one word in common use meant the same thing in the context of the standard, either one of the conflicting words was chosen or the committee came up with a more appropriate term. Naming concepts that had never had a name was one of the more difficult tasks. The goal was to arrive at a common language that would allow people to communicate clearly and unambiguously with each other — engineers with other engineers and specialists, engineers with suppliers, managers with both, etc. The committee came pretty close. The terminology provides an adequate way to communicate concepts as well as references to tangible components of control, automation and process elements. The models provide a generalized view of the manufacturing process. To be useful, they have to be abstract enough and flexible enough to fit essentially any batch process and still be detailed enough to represent reality. The models that resulted serve their purpose well. They are able to establish a basis for modularization and allow unsynchronized activities in a manufacturing facility to be visualized and understood. They represent required functions in each part of the process and identify the relationship between the various parts. Defining models and terminology seemed fairly simple to begin with. Just draw up some models, plug in some terms, and go on to the important stuff. However, something funny happened on the way to the models. In order to create them, it was necessary to really understand and properly represent almost everything that goes on to make a product in a batch process. That ended up requiring five years in which up to 50 batch manufacturing experts met for several days every month or two to define a much more perceptive view of the organization of manufacturing equipment and the hierarchy of control functions needed to enliven that equipment. The result was a structured view of manufacturing function that is very complete. Concepts like modular grouping of equipment and control, the meaning of recipe, the importance of the schedule, the inherent layering of control functionality, etc., were fitted together to create an internally consistent and structured view of essentially any batch manufacturing process. It became the accepted road map for batch automation. It is important. ISA 88 is important for several reasons but is best known because it has been proven to deliver measurable benefits when properly applied to define and implement batch process automation. Those and many other benefits are the subject of this book. Naturally all benefits come with some cost and the use of ISA 88 is no exception.

xvii

batch front of book copy.qxd

4/24/2006

10:50 PM

Page xviii

The primary cost in the case of ISA 88 is the time that needs to be dedicated to learning what the standard teaches and how to use it. In the case of a production manager, the time required to start participating with a design team may be no more than few hours. Engineers, who must learn the technology as well as the principles, will spend more time. The time spent is definitely worth the effort, but it is absolutely necessary to invest that time in order to derive the benefits that are there for the taking. This book is a good start. The fundamental difference between traditional control and control as outlined in the standard is that ISA 88 adds control of procedure and a level of coordination control necessary to keep multiple procedures sorted out. The concepts that are spelled out in terms of a manufacturing environment are consistent regardless of whether the control is provided manually or automatically. It treats control as a function that causes equipment to do the things necessary to make a product - no matter how that control is achieved. There is nothing wrong with manual control. It has worked well for many years and is not to be taken lightly. However, there are usually benefits to be gained by automating at least some of the procedural control in a manufacturing facility. ISA 88 works with either case, or both. It is based on the premise that it is the function that is important. This is particularly important in modern manufacturing approaches where smooth integration of manual and automatic control activities is needed. Few processes actually run all night with the lights out and people are not yet obsolete so we will be mixing automatic control and people for some time to come. There is another signal principle that provides profound benefit. Products change; processes change and products are added. All of these changes require that the control of the process be modified in some way. Product related changes are much more frequent than changes to the way that process tasks and actions are implemented. ISA 88 leverages the infrequent changes to process-oriented tasks and separates them from product processing information. Process oriented tasks are defined, modularized and separated from product specific information. A recipe contains the information specific to a product. That recipe is used to orchestrate the sequence in which process-oriented tasks are executed, and to provide the values they will use for such things as amount, rate, pressure, etc. Most process changes can be made in recipes written by product experts who understand the process but are not necessarily expert in control. This allows control experts to design and execute the process-oriented tasks and for the equipment control to be effectively locked away in a controller while the robust and much less complex recipe can be executed in another part of the system. It is a powerful concept that definitely helps keep an automated plant running in automatic. The journey through the concepts and practicalities of batch control is a challenge, but a rewarding one. The following chapters should make that journey toward expertise more interesting and even more fun. Enjoy yourself along the way. Lynn Craig Medford, NJ July 2005

xviii

batch front of book copy.qxd

4/24/2006

10:50 PM

Page xxi

Acknowledgments The books that you read depend on many people to bring an idea to chapters to publication. This one is no exception. It is not possible to list the names of everyone who contributed, if only because of memory fade. If I tried, I'd leave out someone that would be less than happy or even offended by the omission. The following is a short list of people who made the book possible. Three individuals were key to the project, because the project would have failed without them. Lois Ferson of ISA acted as agent to get a book contract, motivator when the project looked impossible, and editor when there was something to edit. Lynn Craig read everything, and discussed it with me at great length, especially modules and control activities. Joellen Burns, my wife, made it possible by not leaving me when I got totally wrapped up in writing. She supported me through it all and helped me to understand databases. This book would be incomplete and not very interesting without the education and experience that I received from working with people in the batch control and fieldbus communications fields. Many thanks to Bill Wray and the people at the Channelview polyols plant for the most challenging startup. Not all of my education took place at startups, though. Most relevant is the time spent in SP88 meetings and discussions, as well as time with the people in IEC SC65A WG11 in Europe. Some of the people who made me think about batch control in different ways were Tom Fisher, Lynn Craig, Dennis Brandl, Bruce Braunstein, Edgar Bristol, Harry Burns, Guido Carlo-Stella, Dave Chappell, Leo Charpentier, Tom Crowl, Dave Emerson, Larry Falkenau, Ashish Ghosh, Niels Haxthausen, Tom Hollowell, Thomson McFarlane, Thomas Muller-Heinzerling, Albert Pampel, Lou Pillai, Michael Saucier, Keith Unger and Allen Weidenbach. WG11 had an unforgettable meeting with Reiner Uhlig. Time was also spent in SP95, but that's another long list with considerable overlap. John Vieille and Charlotta Johnsson are exceptional European members who have also worked in batch control. The World Batch Forum has been a source of new ideas and current practices since Michael Saucier started it in 1994. There are many people that I'd like to recognize, but the list got too long. See the wbf.org web site for the list of officers and board members. WBF also sells a CD of all of the papers presented from 1994 to the latest meeting. SP50 and later the Interoperable Systems Project and the Fieldbus Foundation provided an education in both control and communications. Richard Lasher of Exxon led the User Layer, teaching all of us about function blocks, cascade control, and block

xxi

batch front of book copy.qxd

4/24/2006

10:50 PM

Page xxii

initialization. Tom Phinney helped me to understand why so much work was going into the digital replacement for 4-20 mA DC signals. Terry Blevins led the function block work in ISP and FF, with Bill Hodson and Marcos Peluso as major contributors. Dave Glanzer managed the High Speed Ethernet project, and Lee Neitzel led the technical work. Richard Corles provided support and valuable insights. Marten Hinrichs provided a European viewpoint, and many more interesting people were involved with control communication. There is a really long list of people who provided me with process control experience and guided me through the tough parts, who worked for Hercules, Rosemount and Rosemount's customers around the world. Thank you all.

xxii

batch front of book copy.qxd

4/24/2006

10:50 PM

Page xxiii

About the Author William M. Hawkins has more than forty years in the field of process control as an engineer, twenty with Hercules as a chemical industry user and twenty with Rosemount as a control system vendor. He has been an engineering consultant for the last five years. He showed engineering talent early, and received a BSME from MIT in 1960. Bill started at his career at the Hercules Powder Company blasting cap plant, where he worked on assembly machines and invented special measurement equipment. He transferred to the Covington Fiber and Film plant, where he worked on electronic and instrumentation problems in fiber and blown film. He transferred to central engineering and established an instrument laboratory, where he designed and built Hercules’ first computer control system. He designed a batch control system for the TPA facility using a Foxboro 2/30 minicomputer and wired interlock logic mounted in the control panel. He also did a batch control project for polypropylene catalyst with a PLC. Things changed, and Bill took a job with Rosemount in 1980 as Systems Engineering Manager, but soon became the control architect for Rosemount’s next control system, RS3. He started up the first RS3 at a corn milling plant, with a transfer network of 165 valves and 22 pumps. No PLC was required because RS3 could do that logic. He developed ABC Batch with the help of the NAMUR recommendations in 1985. He started up the first ABC installation at a urethane polyols plant in Texas. Bill joined the SP50 fieldbus communication standard and its User Layer in 1988, where he contributed to the design of control function blocks and learned a lot about fieldbus communication. He joined SP88 in 1992, where he helped to develop the concept of separation of recipe and equipment. He served as secretary for several years with Lynn Craig as chairman and Tom Fisher as editor, through the final ballot on ISA-88.01. He also served on the matching IEC standards committees, where he learned about the European viewpoint. He left SP50 in 1992 when a commercial consortium split away to get the job done. He wrote half of the function block specifications. The World Batch Forum was started in 1994, and Bill was elected Treasurer, a post he held for eight years. He is still active in the Forum, currently involved with the conference technical program. Bill formed HLQ, Ltd. when Emerson closed the Minnesota RS3 plant in July,1999. He began by working for the Fieldbus Foundation on development and testing of the High Speed Ethernet fieldbus. Most of his time is now spent writing technical material.

xxiii

batch front of book copy.qxd

4/24/2006

10:50 PM

Page xxv

About the Book Scope This book is about process control as it is practiced in batch process industries. That means mostly recipe-driven procedural control and the equipment entities that make recipes relatively simple. The book does not include discussions of implementing most basic control, like temperature and pH control. There are many books on the subject of process control. The ISA 88 series calls it basic control relative to procedural control, which does not have a wide selection of books. It does not cover specific control systems or computer operating systems or database applications for batch control, but does talk about those things in general.

Purpose This book is intended to update ISA’s “Batch Process Control” book with the findings of SP88, both as discussion of 88.01 and as experience in applying 88.01, and to update the technology in the first edition.

Organization There are sixteen chapters, each building on details discussed in previous chapters (except Chapter 1, of course). The first three chapters introduce processes, projects, and basic control. Experienced engineers could skip this material, but it might be interesting to see how someone else views those topics. Chapters 4 and 5 introduce topics that are specific (but not unique) to batch control. Chapter 4 is about controlled equipment. Most people think of equipment and control as separate things. 88 combines them to build an entity that can perform a process function. Process functions are specified by product recipes, not separate equipment and control functions. Chapter 5 introduces recipes as a way to specify products that require assembly procedures that vary from product to product. Chapters 6 through 13 discuss the 88.01 standard from beginning to end. The standard is mostly described in different words in this book, rather than as quotes from the standard. The different words are intended to give you another viewpoint, not as criticism of what the standard should have said. This should help you to understand what 88.01 says by looking at it in another way. It is too late to criticize the standard. Chapter 6 begins the discussion of 88 with the physical model. At first, the model is intuitively obvious, as the professor used to say. All kinds of misunderstandings begin at the Unit and get worse as you go lower in the model. Alternative physical models are presented for perspective. A marketing person would say that this chapter clears everything up, but an engineer would be more restrained.

xxv

batch front of book copy.qxd

4/24/2006

10:50 PM

Page xxvi

Chapter 7 explains procedural elements and procedural control, and how they relate to the unit, equipment module, and control module. All of those items are then related to the process functions that are performed by equipment entities. Chapter 8 explains the recipe models for the four types of recipes and the five categories of recipe information. These two chapters contain much of what is new in 88. Try to understand these chapters before proceeding. If the material won’t come together, try reading Chapter 12, which discusses how these concepts are used. Chapter 10 might help because it reviews chapters 7 and 8, among other things. Chapter 9 discusses schedules and production information as a foundation for material in chapters 11 and 12. As a catchall chapter, it also discusses the 88 subjects of allocation and arbitration, modes and states, and exception handling. This finishes section 5 of 88.01. Chapter 10 summarizes Chapters 6 through 9 and discusses the changes that sections 4 and 5 of 88.01 have made to previous ways of doing batch control. It also presents work done at Purdue that preceded and influenced 88, and reviews the NAMUR work presented in Chapter 5. Chapters 11 and 12 cover section 6 of 88.01 on the subject of control activities. Sections 4 and 5 presented new concepts. Section 6 describes how those new concepts are used to make products. Chapter 11 discusses the three activities that require interfaces to the activities described in ANSI/ISA-95.00.03-2005. Recipe Management creates and maintains the recipes that are used to make products. Production Planning and Scheduling determines when what products will be made, and may specify the equipment, materials and personnel to be used. Production Information Management processes information generated by the batch control activities for use by plant operators and business functions. Chapter 12 describes the three activities that are essential to make batch products, as well as the activity that maintains personnel and environmental protection. Process Management coordinates the distribution of control recipes to process cell units in a timely manner. Unit Supervision executes that part of a recipe than can be done in that unit, and sends commands to the Process Control activity, which applies the commands to equipment procedural and basic control in the modules belonging to the unit. Chapter 13 presents the definitions in section 3 of 88.01. Some comments will help the reader and some are intended to improve the definitions in the next revision of 88.01. Chapter 14 attempts some further clarifications of 88.01 from the author’s viewpoint. They would probably not gain consensus in an SP88 meeting. You may find them helpful in understanding what 88.01 did not say. Chapter 15 presents a generic 88 implementation, as your author might have done it.

xxvi

batch front of book copy.qxd

4/24/2006

10:50 PM

Page xxvii

The chapter describes a step-by-step procedure to design modules and phases from process flow diagram to completed system. A reactor jacket heat exchanger system is the basis for the example. Hope you find it useful. Chapter 16 discusses the 88-95 interface problem, which is still being discussed by a joint working group that doesn’t have enough control engineers to balance the database fashion designers. A solution is proposed, but probably too late to be considered. 88 seems like it might be useful in areas other than batch control, so possibilities and pitfalls are discussed. Finally, it seems like the largest future impact on batch control could come from the FOUNDATION™ Fieldbus and their ability to do control in field devices. This could lead to standard module interfaces for standard process functions, which could lead to the holy grail of useful standard phase libraries. These projects lack leaders, resources, and qualified people at the present time. There is a lot of ground to cover in these 16 chapters. This book is not intended to be read in one evening. The plot is too tenuous and new characters keep appearing. There are passive voice statements that are intended to keep your excitement from becoming uncontrollable. There are some attempts at humor. Your mileage may vary. All learning is based on making people ask the questions so that they will retain the answers. It will be helpful to be familiar with the contents of 88.01. Read far enough to form some questions and then spend some time thinking about possible answers to those questions. Then plow into the book again to find out what a group of industry experts came up with when they asked those questions. Jumping into the middle of the book with a specific question is not recommended, unless you have gone through the book and understand all that is implicit in the answer to your question.

xxvii

batch front of book copy.qxd

4/24/2006

10:50 PM

Page xi

Figures and Tables Chapter 1 Figure 1-1 Cross-Section of a Blasting Cap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 Figure 1-2 Approximate Layout of Explosives Plant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 Figure 1-3 Sample Specialty Baking Plant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 Table 1-1 Process Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 Table 1-2 Three Unambiguous Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Table 1-3 Batch vs. Continuous Processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

Chapter 2 Figure 2-1 Example of a PFD (TPA Process) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 Figure 2-2 Rough Example of a P&ID. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 Figure 2-3 Example of a Loop Sheet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 Figure 2-4 Example of a Block Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 Table 2-1 Material Balance for One Reactor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 Table 2-2 Gantt Chart for Four Reactors/2-Hour Cycle. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 Table 2-3 Overall Material Balance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

Chapter 3 Figure 3-1 Pressure vs. Flow Curves . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 Figure 3-2 The Elements of a Regulatory Control Loop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 Figure 3-3 Discrete Control Loop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 Figure 3-4 Simple SFC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 Figure 3-5 Override Control by Value Position . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

Chapter 4 Figure 4-1 A Combination of Process Equipment and Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 Figure 4-2a Instrumented Reactor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 Figure 4-2b Bioreactor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 Figure 4-2c Mobile Reactor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 Figure 4-3 Shell and Tube Heat Exchanger. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 Figure 4-4 Heat Exchanger for Heating and Cooling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 Figure 4-5 Heat Exchangers for Jacketed Batch Reactor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

Chapter 5 Table 5-1 Condensation of NE 33-Figure 7.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

xi

batch front of book copy.qxd

4/24/2006

10:50 PM

Page xii

Chapter 6 Figure 6-1 Process Model (Entity-Relationship Diagram) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 Figure 6-2 Physical Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 Figure 6-3 ISO CIM Model Compared to 88.01 Model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 Figure 6-4 Comparison of Physical Structures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 Figure 6-5 Uppermost Levels of Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106 Figure 6-6 Process Control Levels of Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106

Chapter 7 Figure 7-1 Three-Level Hierarchy of Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109 Figure 7-2 Procedural Control Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 Figure 7-3 Procedural Control/Equipment Mapping to Achieve Functionality . . . . . . 116

Chapter 8 Figure 8-1 Recipe Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126 Figure 8-2 Relationship of General or Site Recipe and Master Recipe . . . . . . . . . . . . . . . . . . . 133 Figure 8-3 Linking of Control Recipe and Equipment Entity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137 Figure 8-4 Unit Procedure Built into Equipment Entity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138

Chapter 9 Figure 9-1a Simple Basic Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151 Figure 9-1b Transfer Header . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151 Figure 9-2 Sequence for Two Directions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152 Figure 9-3 State Transition Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154

Chapter 10 Table 10-1 Hierarchy for Recipes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160 Table 10-2 Generic Functions of a CIM System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162

Chapter 11 Figure 11-1 Control Activity Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171 Figure 11-2 Concurrent Definition/Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175 Figure 11-3 Recipe Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177

Chapter 12 Figure 12-1 Process Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188 Figure 12-2 Unit Supervision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194 Figure 12-3 Process Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199

xii

batch front of book copy.qxd

4/24/2006

10:50 PM

Page xiii

Chapter 13 - None Chapter 14 Figure 14-1 Complete Physical Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219 Figure 14-2 The Physical Model and the Purdue Reference Model. . . . . . . . . . . . . . . . . . . . . . . 225 Figure 14-3 The Common Valve Problem–Two Units . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240 Figure 14-4 The Common Valve Problem–More Than Two Units . . . . . . . . . . . . . . . . . . . . . . . . . 241

Chapter 15 Figure 15-1 Procedure for Designing a Batch Process Control System . . . . . . . . . . . . . . . . . . 256 Figure 15-2 Procedure in Three Stages and Three Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258 Figure 15-3 Process Stage in Three Operations and Three Actions . . . . . . . . . . . . . . . . . . . . . . . 258 Figure 15-4 Control Module Pattern Drawing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262 Figure 15-5 Example of Module Grouping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265 Figure 15-6 Reactor Temperature Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275 Figure 15-7 Control Modules Required for Interfacing with Phase Logic. . . . . . . . . . . . . . . 277 Figure 15-8 Control Block Configuration for Reactor Temperature Control . . . . . . . . . . . 279 Table 15-1 Table for CM PID Pattern Drawing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263 Table 15-2 Description of PID Pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263 Table 15-3 Table for Specific Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264 Table 15-4 Table of Common Parameter Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264 Table 15-5 Generic 88 Implementation for Heat Transfer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281 Table 15-6 Generic 88 Implementation for Heat Transfer Shut Down. . . . . . . . . . . . . . . . . . . 282 Table 15-7 Generic 88 Implementation for Heat Transfer-Modified . . . . . . . . . . . . . . . . . . . . . 286 Table 15-8 Generic 88 Implementation for Heat Transfer Shut Down-Modified . . . . . 288

Chapter 16 Figure 16-1 Activity Model of Production Operations Management. . . . . . . . . . . . . . . . . . . . . 295 Figure 16-2 Control Activity Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295 Figure 16-3 Comparison of Ideas from 88 and 95 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296 Figure 16-4 Possible Interface of 88 and 95 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300

xiii

317 Index Term A

Links

activity,

160

180

215

actuator,

41

46

69

97

104

66

68

139

230

48

52

57

60

143

200

230

146

190

203

193

197

203

218

120

201

164

185

259 agitator, problem, alarm,

excessive,

64 239

53

allocation,

145

alternative,

238

arbitration,

146

147

archive,

173

182

81

93

95

204

173

183

188

190

86

109

125

157

159

163

165

187

204

224

247

250

253

311

15

73

127

141

145

181

184

186

12

19

63

91

97

159

area, availability, B Babbage,

268

batch,

204

control,

distillation, golden, ID,

127 13 190

process,

1 205

schedule, semi, bill of material, Bristol,

205 15 78 159

C calculation,

185

centrifuge,

74

change management,

200

173

charge,

69

CIM,

93

161

165

305

command,

127

150

220

237

common valve problem,

239

318 Index Term communication,

87

106

114

134

139

143

161

183

199

310

158

159

161

163

activity,

176

187

194

201

basic,

110

121

149

151

200

204

259

118

120

146

196

205

151

165

171

193

196

134

165

200

205

223

continuous process,

60

Links 62

136

control

constraint,

51

coordination,

75

114

device,

48

86

discrete,

46

equipment,

59

206

function,

66

119

198

312

interface,

34

119

120

interlock,

55

56

227

modes,

45

module,

97

120

159

override,

54

280

PID,

40

43

158

110

116

149

152

195

198

209

233

246

166

247

206

294

procedural,

regulatory,

40

sequential,

49

D 105

247

database,

90

140

143

144

161

DCS,

26

46

61

158

311

deadtime,

45

143

220

device,

47

61

81

159

310

display,

199

246

248

250

data owner,

distillation column, dynamic,

73 174

270

E engineering,

174 93

94

103

129

common,

75

96

120

200

control,

59

206

enterprise, equipment

162

319 Index Term entity,

115

Links 117

195

206

81

operation,

121

136

138

165

96

119

165

206

223

138

195

206

phase,

135

138

198

206

procedure,

207

separation,

80

86

135

165

237

297

200

207

226

274

285

284

285

153

155

195

198

224

module,

unit procedure, exception handling,

175

207 156

detection,

230

handling,

231

interlock,

227

monitor,

230

planning,

229

exceptions product,

228

time,

228

execution,

118

233

246 F facility,

215

218

failure,

55

185

200

FDA,

33

134

142

fieldbus,

60

68

182

279

309

85

157

159

207

35

87

279

47

246

248

heat exchanger,

70

276

hierarchy,

85

90

111

139

160

162

79

144

166

181

183

190

IEC,

36

81

85

149

150

246

interface,

33

169

220

247

293

296

Fisher,

161

formula,

77

function,

215

function block, G graphic, H

historical data, history,

185 310

I

300

320 Index Term interoperability, ISA,

177

Links 180

182

184

311

312

52

117

211

217

95

161

163

301

305

128

134

140

158

244

143

174

184

26

46

60

104

159

220

7

13

96

141

144

160

174

186

208

120

142

148

149

153

208

148

232

236

308

89

161

222

26

27

309

310

93

language,

115

late entries,

185

logs, loop,

ISO,

293

L

lot,

248

M macros,

114

mixer,

69

mode,

45 233

and states, model, communication,

104

enterprise,

103

physical,

121

control,

218

104

plant,

101

relationship,

116 33

86

control,

97

120

165

200

205

223

equipment,

81

96

119

165

206

223

interface,

223

261

267

311

orphan,

274

parameter,

261

86

129

160

156

173

module,

Murphy,

221

304

270

142

N NAMUR,

79

NIST,

93

O operation,

85

112

159

209

operator,

60

84

143

153

234

200

321 Index Term interaction,

Links 245

P parameter,

135

136

path,

100

209

permissive,

227

231

84 209

phase,

phase library, physical model,

183

199

250

312

111

113

119

139

159

224

236

268

270

283

218

165

267 93

plant,

1

161

163

215

PLC,

46

61

158

248

139

175

178

195

preemption,

147

procedural element,

111

120

130

210

233

246

153

242

77

85

111

157

159

210

254

execute, procedure,

306 process,

210

action,

93

120

122

210

237

257

304

batch,

1

12

19

63

91

97

158

205

308

81

82

94

95

97

117

121

187

192

210

2

18

69

130

211

cell,

discrete, input, interlock, management,

163

56 187

211

93

138

130

211

parameter,

12

130

195

stage,

81

93

211

information,

142

166

181

198

201

297

schedule,

141

146

180

187

192

298

260

290

operation, output,

211

211

production

19

32

62

253

propagation,

118

199

232

236

protection,

201

209

93

159

161

225

project,

Purdue,

294

322 Index Term R reactor,

Links 64

224

biological,

67

112

control,

65

mobile,

68

100

2

10

77

80

83

160

166

175

212

305

80

127

133

136

187

130

136

166

formula,

79

128

130

136

207

general,

129

132

177

207

173

208

recipe,

basic,

80

basis,

80

computations, control, equipment requirements,

98

header,

129

hierarchy,

139

management,

176

177

212

296

master,

127

132

178

187

208

operation,

212

other information,

133

phase, procedure,

243

135

195

212

79

131

136

179

212

80

86

135

165

237

297

128

132

178

213

162

173

228

247

130

process outputs,

130

reference information,

172

site, source,

80

translation,

134

241

transportability,

139

166

types,

125

unit procedure,

212

redundancy,

57

regulatory,

173

requirement,

115

resource

205

98

process inputs,

separation,

158

243

grade,

parameter,

125

62

311

323 Index Term common, exclusive-use,

75

Links 146

184

205

147

207

75

147

213

safety,

57

133

172

201

218

sensor,

104 10

77

85

152

149

151

158

224

1

81

93

95

213

software,

61

162

250

SOP,

54

289

shared-use, S

sequence,

2

sequential,

48

SFC,

50

simulation, site,

228

246

290

Spaceman Spiff,

250

state,

148

150

213

235

and modes,

148

232

236

308

machine,

150

152

233

235

transition,

233

150

152

statistical,

13

79

step,

85

237

STEP,

226

301

T terminology, timing, Tower Bridge,

90

159

253

303

150

173

191

227

290

159

126 55

tracing,

183

tracking,

174

training,

60

transport header,

70

turtles,

115

224

U Uhlig,

79

86

unit,

81

95

118

122

131

138

214

238

224 procedure,

112

136

recipe,

189

214

storage,

221

300

supervision,

194

214

214

324 Index Term user,

35

Links 48

53

86

149

217

237

253

261

303

311

312

86

164

174

228

230

238

247

115

232

33

watchdog,

57

Williams,

161

interface, V validation, W

batch front of book copy.qxd

4/24/2006

10:50 PM

Page vii

Table of Contents Forward . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xix Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxi About the Author . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxiii About the Book . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxv Chapter 1

Introduction to Manufacturing Processes. . . . . . . . . . . . . . . . . . . . . . . . 1 Process Classification. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 Process Properties. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 Batch Process Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 Auxiliary Processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 Process Boundaries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

Chapter 2

Introduction to Process Design and Construction. . . . . . . . . . . . . . . 19 Process Flow Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 Piping & Instrument Diagram. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 Loop Sheets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 Example of Process Design and Construction . . . . . . . . . . . . . . . . . . . . 28 Process Flow Diagram. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 Batch Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 Construction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 Modular Design. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

Chapter 3

Introduction to Process Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 Types of Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 Regulatory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 Discrete Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 Sequential Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 Constraint Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 Alarms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 Overrides. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 Interlocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 Interlock Variations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

Chapter 4

Introduction to Controlled Equipment . . . . . . . . . . . . . . . . . . . . . . . . . 59 The Role of Humans in Process Control . . . . . . . . . . . . . . . . . . . . . . . 59 Process Equipment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 Controlled Process Equipment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 Examples of Controlled Equipment . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

vii

batch front of book copy.qxd

4/24/2006

10:50 PM

Page viii

Common Equipment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 Chapter 5

Recipes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 NAMUR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 Recipes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 Evolution of Recipes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 Changing from Drums to Digital Computers. . . . . . . . . . . . . . . . . . . 84 Modular Programming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 Separating Recipe and Equipment Programming . . . . . . . . . . . . . . 86 Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

Chapter 6

88 Physical Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 Modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 Models in 88.01 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 Batch Processes and Equipment in 88.01 . . . . . . . . . . . . . . . . . . . . . . . . 91 Batch Processes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 Physical Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 Process Cell Classification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 Other Physical Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 Control in the Physical Model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

Chapter 7

88 Batch Control Concepts, Part 1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109 Structure for Batch Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109 Basic Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110 Procedural Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110 Coordination Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114 Equipment Entities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115 Relationship Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116 Control in Equipment Entities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 Structuring Equipment Entities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121 Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123

Chapter 8

88 Batch Control Concepts, Part 2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125 Recipes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125 Recipe Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125 Recipe Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129 Recipe–Equipment Relationship . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134 Recipe Transportability. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139 Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140

Chapter 9

88 Batch Control Concepts, Part 3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141 Production Plans and Schedules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141 Production Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142 Allocation and Arbitration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145

viii

batch front of book copy.qxd

4/24/2006

10:50 PM

Page ix

Modes and States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148 Exception Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156 Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156 Chapter 10

88 Perspective and Review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157 Before SP-88 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157 Purdue Workshop WG4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159 NAMUR. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160 Batch Control Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161 Computer Integrated Manufacturing. . . . . . . . . . . . . . . . . . . . . . . . . 161 Purdue Reference Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161 During SP-88 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165 Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167

Chapter 11

88 Control Activities and Functions, Part 1 . . . . . . . . . . . . . . . . . . . . 169 Control Activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169 Control Activity Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170 Information Handling. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172 Process and Control Engineering . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174 Recipe Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176 Production Planning and Scheduling. . . . . . . . . . . . . . . . . . . . . . . . . . . 180 Production Information Management. . . . . . . . . . . . . . . . . . . . . . . . . . 181 Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186

Chapter 12

88 Control Activities and Functions, Part 2 . . . . . . . . . . . . . . . . . . . . 187 Process Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187 Unit Supervision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194 Process Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198 Personnel and Environmental Protection . . . . . . . . . . . . . . . . . . . . . . . 201 Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201

Chapter 13

88 Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203 Other Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215 Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215

Chapter 14

Further 88 Clarifications. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217 Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217 Physical Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218 Batch Control Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224 Modules and Phases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224 Equipment Entities and the Purdue Reference Model . . . . . . . . . 225 Exception Handling. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226 Modes and States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232 Recipe Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237 Alternative to Unit Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238 The Agitator Problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239 The Common Valve Problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239

ix

batch front of book copy.qxd

4/24/2006

10:50 PM

Page x

Batch Control Activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241 Recipe Translation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241 Executing Procedural Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242 Recipe Computations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243 Operator Interaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245 Procedure Function Charts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246 A Word about Control Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247 Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250 Chapter 15

Generic 88 Implementation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253 Designing Batch Process Control. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254 Know Process Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255 Know How to Operate. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260 Know Modules, Phases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269 Know Normal Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274 Know Exceptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285 Know All There Is to Know. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289 Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291

Chapter 16

Role of 95 and Other Things. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293 Joining 95 and 88 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294 Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296 Missing Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300 The Role of STEP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301 Expanding the Scope of 88. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302 Why Expand 88 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302 Features of 88 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303 Back to 95 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309 Fieldbus. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309 History. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 310 Future for Batch Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311 Control in the Field . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311 User-Defined Function Blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312 Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313

Bibliography Index

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317

x