News & Politics
APPLYING S88 BATCH CONTROL FROM A USER'S PERSPECTIVE JIM PARSHALL AND LARRY LAMB Notice The information presented in this publication is for the general education of the reader. Because neither the authors nor the publisher have any control over the use of the information by the reader, both the authors 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 authors nor the publisher have investigated or considered the effect 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 authors nor the publisher endorse any referenced commercial product. Any trademarks or tradenames referenced belong to the respective owner of the mark or name. Neither the authors nor the publisher make 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 © 2000 ISA - The Instrumentation, Systems, and Automation Society All rights reserved. Printed July 2006 ISBN-10:1-55617-703-8 ISBN-13: 978-1-55617-703-3 Printed in the United States of America. No part of this publication may be reproduced, stored in 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 North Carolina 27709 Library of Congress Cataloging-in-Publication Data is available. LC #99-42402 For our parents TABLE OF CONTENTS F OREWO RD VIII A CKNO W L EDGM EN TS IX I NTRO DU CTION X I C HAPTER 1 B ASIC C O NCEP T S 1 Batch Manufacturing 1 What Really Is S88? 2 E-R Diagrams 5 Sequential Function Charts 7 A Typical Mix-Making System 12 C HAPTER 2 A RE Y OU R EAD Y T O G O Y ET ? 16 Gathering Requirements 16 Selling the Concept (Getting Funding) 18 C HAPTER 3 S TA RT IN G (W HAT Y OU H OPE W IL L B E ) A S UC CESSFU L P ROJECT 21 Step One of a Successful Project 21 Moving Forward with a Successful Project 23 C HAPTER 4 T HE P HYSICAL M ODEL 25 Enterprise and Site Levels 25 Area Level 27 Unit Level 28 Process Cell Level 30 Control Module Level 33 Equipment Module Level 34 Designing the Physical Model 35 C HAPTER 5 R EC IP ES , P ART 1: P ROC E DU RES 37 Information in a Recipe 37 Types of Recipes 38 General and Site Recipe Procedures 41 Master and Control Recipe Procedures 44 Recipe Collapsibility 49 Converting Site Recipes into Master Recipes 49 Linking the Physical, Procedural Control, and Process Models 50 Process Control vi C HAPTER 6 R EC IP ES , P ART 2: A L L TH E O THER S T U FF 52 Information in a Recipe 52 C HAPTER 7 L INK I N G R EC IP ES TO E QUIP MENT 57 Types of Control 57 Linking Recipes and Equipment Control 60 C HAPTER 8 O THER I MPORTAN T B AT C H C ONTRO L I TEMS 65 Modes of Operation 65 States and Commands Associated with Batch Control 67 Exception Handling 71 Allocating and Arbitrating Equipment Use 72 C HAPTER 9 B ATCH A CTIV ITIES AND I NFORMATION M ANA GEM E N T (T HE C AC T U S M OD EL ) 75 The Control Activity Model 75 Presenting Information to the User 87 C HAPTER 10 S YSTEM S PECIF I C A TION AN D D ES IGN (S OME OF I T , A NYW AY ... ) 89 Creating a Control System Functional Specification 89 Documenting Equipment Control 90 A Sensitive Subject: Working with Your IS/IT Department 92 One Final Note 93 C HAPTER 11 S PECIF Y ING AND D ESIG NING E QUIPMENT P HAS E S 94 A Phase Review 94 Modes and States 100 Allocation and Arbitration 105 Unit-to-Unit Synchronization 105 Exception Handling 106 Data Collection 107 Important Design Notes 107 C HAPTER 12 W RITIN G P HASE L OGIC 109 Using Distributed Control Systems 109 Writing PLC Phase Logic 111 Writing Control Modules (Device Drivers) 117 A Design/Code Process 118 Tips 119 The PLI 120 Table of Contents vii C HAPTER 13 S TA RT IN G Y OUR S YSTEM R IGHT ... THE F IRS T T IM E 121 Validation 121 Start-up Tips 123 C HAPTER 14 F IN IS 125 What We Learned—The Big Picture 125 A Challenge to Think Beyond Manufacturing 127 For More Information 127 One Last Thing 128 A BO UT T H E A UT HOR S 129 FOREWORD To grossly paraphrase Nietzsche, serving on standards committees either kills you or makes you stronger. After six years of bimonthly international meetings involving hundreds of batch professionals, costing the sponsoring companies millions of dollars, accommodating thousands of end-user comments, boosting frequent flyer accounts to record highs, and leveling whole forests to produce the twelve intermediate drafts required to reach consensus, the ISA S88 Committee produced ANSI/ISA-S88.01-1995: Batch Control Systems, Part 1: Models and Terminology The standard promised to unify the world of flexible process manufacturing with a common framework, finally allowing engineering, operations, vendors, and customers to use a common language to describe, design, and deliver agile plants. While momentous, clear, and enlightening to the hard-core committee members, the standard proved in practice to be more of a reference than a guide to automation engineers. There were a few who vowed to write application guides to supplement the standard, but most approaches cover a superset of the S88.01 material, treating the many aspects of batch automation necessary to successfully architect and manage large teams. However, there is a need for strong examples and case studies that breathe life into the theory. That is where this book comes While attending the Rockwell Consumer Products Roundtable a few years ago, I ran into Jim Parshall for the first time. He was holding court on the finer points of making ice cream, waving his arms, and genuinely having a good time explaining the process to those around him. I was instantly struck by his outgoing and enthusiastic attitude about applying computers to flexible manufacturing. He moved throughout the crowd, challenging whomever he encountered to a discussion on segmenting a plant, architecting a PLC, or laying out a graphic display. His combination of technical expertise and dynamic, engaging style appealed to the attendees and helped them understand his message. This book is written in the same style, telling the story of Ben & Jerry's first foray into the world of agile manufacturing. Jim and Larry breathe life into the technical details of S88.01, and the result is both entertaining and informative. With the standard as a companion, this book serves as a cookbook for success, guiding the S88 "newbie" through the perilous terrain of justifying, specifying, designing, and deploying a truly flexible process manufacturing system. June 1999 Michael Saucier Chairman and Founder of Sequencia Corporation ACKNOWLEDGMENTS Many authors acknowledge the help of others and often state how important everyone's contribution was to the effort. After this project, we now completely understand how important this section is. A whole lot of people advised us, lent a hand, or otherwise cheered us on during our batch control project and while we wrote this book. Our names may be on the cover, but there was a much larger team involved. Most of the effort needed to write this was stolen from quality time with our families, and so it is only fitting that we first thank Georgianne and Evan Parshall (Evan was born just as we completed the first manuscript draft) and Deb, Erica, and Sarah Lamb. Their love, patience, and understanding gave us the time and ambition to accomplish this. This book wouldn't have much value if we didn't upgrade the mix-making batch control system at the Ben & Jerry's St. Albans plant. The lead mix maker, Althea Sherwood, believed in us all the way and was a driving force in making the system better. Chad Larivee and Mark Kimball, the other two mix makers, patiently worked with us and showed the same faith as Althea. Ellyn Ladd, Production Manager, and Janet Norcross, Process Supervisor, gave us the time and support necessary to enhance the operations. Dan Carver, Controller, and Scott Beaudin, Cost Accountant, were key customers; helped us assemble a successful proposal; and worked with us diligently to ensure that the system delivered as promised. Gary Epright, Engineering Manager; Wendy Yoder, Plant Manager; Drake Wallis, Corporate Director of Manufacturing; and Bruce Bowman, Senior Director of Operations, let us use technology to improve plant operations. Sue Ketcham taught us volumes about process manufacturing. We returned the favor by helping her understand the world of modular automation (and linear algebra and logarithms). She's now supporting the batch control system at St. Albans (among her other many duties). You may have heard it before, but Ben Cohen and Jerry Greenfield are two real guys. We both knew them, and on one occasion Ben and Jerry bought beers for us at a local microbrewery. Of course, we must acknowledge our good friend and fellow engineer Roland Wilhelm. (He's a mechanical engineer, but we don't hold that against him—most of the time.) The three of us made quite a trio at that plant. Roland's unrelenting insistence on perfect project management, starting with exceptional requirements gathering, kept us on our toes throughout our tenure in St. Albans. He's truly one of a kind, and we miss working with him. We had help from many people in industry as well. These next four people spent many hours reviewing our manuscript and suggested many great improvements. (So blame them for any mistakes ...) Michael Saucier, founder of Sequencia, guided us in the principles of S88, always honestly shared his views, and was kind enough to write the book's foreword. Tom Fisher, Technology Manager at Lubrizol and considered the "father" of S88, kept us from straying too far from the intent of the standard. Karen Tipp, Industry Specialist at Rockwell Automation, is always a great source of encouragement and enthusiasm. Her experience implementing OpenBatch helped us clarify issues. Finally, Rick Mergen, Senior Engineer at Lubrizol and the first Chairman of the S88 committee, also provided great insight. Lynn Craig of Manufacturing Automation Associates, and Chairman of the S88 committee when we wrote the book, is a wealth of information and phraseology He read the manuscript on his own time and provided great feedback. Wayne Cantrell from Siemens helped us with PCS 7 information. Steve Ryan, Dan Hartnett, John Clark, and Chuck Fortner from Rockwell; Bart Winters and Don Clark from Honeywell; Bob Nelson from Siemens; Joe Hancock from Eutech; Bruce Sanchez from AspenTech; Mike Kolba from Foster-Wheeler (and the Chairman of the World Batch Forum while we wrote this); Roddy Martin from AMR; Asish Ghosh from ARC; Paul Nowicki from Sequencia; and Niels Haxthausen from Novo Nordisk Engineering all lent us a hand in one important way or another. Lou Bendle from Sequencia showed us the light on OpenBatch and how we much we could benefit from it. John Parraga from Sequencia was the most-excellent consultant who introduced us to the world of phase logic. We also cannot forget the Sequencia product support team, as support can sometimes make or break a product. This group is first class. Thanks Barry, Tamara, Danny, Mark, and John. In the middle of writing this book, we both ended up leaving Ben & Jerry's to pursue other ambitions. We want to thank Jim Newton and Bill Derochers of Oakes Electric for their support and encouragement. There are many people we want to thank at Eli Lilly. Paul McKenzie and Rae Marie Crisel ensured that no issues held us back and supported us all the way. Dave Adler went above the call of duty by reading the entire manuscript during a flight to Singapore. Jeff Owen and Jim Wiesler helped us better understand the world of distributed control systems. Finally, we will not forget, nor can we emphasize enough, our appreciation to ISA for making this book possible. Kate Fern was the acquisitions editor who got us in the door and helped us refine the proposal. After Kate moved to get married, we had the fortune of working with Robert Rubin, a superb editor. Robert knew how to walk the fine line between ensuring that we told our story the best way and letting us keep our style and intent. He handled the role extremely well, and we sincerely appreciate all of his effort. Once the final manuscript was submitted, we had the pleasure of working with Shandra Botts, the production manager. Authors get really antsy about getting a book in print once the manuscript is finished. She did phenomenal work. We also want to thank Joice Blackson for all of her help in coordinating the proposal and manuscript reviews, as well as all of her efforts during the editing process. INTRODUCTION You probably remember reading a chapter from an engineering or math textbook and thinking to yourself, "I'm sure the author knows what he's talking about, but I'm just not getting it." So you read the chapter again. And you still didn't get it. You chugged or repeatedly sipped your favorite caffeinated beverage. Ah, but that didn't work either. So you highlighted the chapter with three or four different colors to outline what you thought were the important notes or equations. Your impending headache made you swallow a couple of aspirin with another jolt of caffeine. Maybe you just gave up and went to bed. Well, as embarrassing as this may sound, reading the S88.01 standard reminded us a little bit of our college days. We know the SP88 members certainly have the qualifications to write such a spec and worked long and hard producing it. In fact, during the past several years we have had the pleasure of meeting several of them. Unfortunately, the nature of any standard or regulation prevents its authors from providing lengthy examples and details for interpreting it. Since standards serve countless companies in many different industries, they must be written to cover the broadest ground or they would never be published. (We defy you to tell us that immediately after reading any section of the FDA's "Good Manufacturing Practices" you understood exactly what the PDA meant.) But hey, let's not make any excuses: S88 just wasn't sinking in. As we reviewed S88 and spoke with industry experts, including vendors, committee members, and other users, we took notes to strengthen our understanding of the standard. Our installation of RSBatch to control Ben & Jerry's mix-making operation in 1998 was a very strategic project for the company because RSBatch was a key component to improve manufacturing efficiencies and information handling. Integrating RSBatch with Ben & Jerry's existing process control system required a lot of planning, so we continued to take notes before and during the installation. From our notes during that project we wrote this book. (We didn't dare write it from memory.) It's about what we think S88 means and how we used our interpretation to redesign our existing batching system. Our hope is that you'll only need one highlighter to capture the important points. We didn't have the good fortune to serve on SP88, so we don't consider our solutions to be definitive. In other words, we may not have implemented S88 exactly like others, but what we did worked well for us. In fact, we're proud to say that the system, including the human-machine interface (HMI), was designed, developed, and retrofitted into existing hardware and software in fewer than five hundred person-hours and that the very first batch of mix created with the new system was successfully used in finished product. (For any reader without an automation background, HMI is a manufacturing term that refers to a graphical user interface or "GUI." Some people may use the term operator interface. Folks who want to give away their age use the terms operator interface terminal or ОIT.) By now, you may think that we're using the terms 588, S88.01, and S88 somewhat interchangeably. No, these aren't typos. (Hey, let's give our editor some credit, after all.) Each of these has a very distinct meaning: S88 is the overall standard name, S88.01 is part one of the standard (it has two parts), and SP88 is the name of the committee that authored the standard. These terms are explained in more detail early in Chapter 1. Applying S88 xii HOW WE CHOSE S88 AND RSBATCH The Ben & Jerry's plant in St. Albans, Vermont, started running its mix making system in the summer of 1995. All batching functions were controlled via relay ladder logic (RLL) in Allen-Bradley PLC-5s and PanelViews. (Personal computers were not part of the process control system in 1995.) Once we eliminated the initial bugs the system was quite stable, as long as ingredients and processing steps stayed the same. That first batch control system quickly helped turn the St. Albans plant into the company's volume leader. However, as a growing company committed to remaining competitive in the marketplace, Ben & Jerry's is constantly introducing new products and reformulating existing products. While many of these products used existing base mixes, some required new mixes. Well, you guessed it: many of these new mixes required new ingredients and new processing steps. After introducing several new mixes, we concluded that our existing PLC-only mix-making control logic wasn't flexible enough to handle all of our new products. In addition, our method for collecting data was fairly primitive. Operators were tired of writing all recipe ingredients out by hand, along with target quantities, actual quantities, and the raw ingredient tanks used in each batch. (It was rumored that Ben & Jerry's was the largest purchaser of stainless steel clipboards in northern New England.) St. Albans had significantly reduced mix-making manufacturing variances since its start-up, but we knew we could do better. However, without more automatic and accurate data collection, even trying to perform a simple analysis of our process became a chore. So, we set out to find a better way to run our mix-making system. We noticed something peculiar when reading batch control books: they didn't discuss using ladder logic to run and manage recipes. At first, we just figured the books were written from a perspective that favored distributed control systems (DCS), in which scripting-type languages are used for batch control. However, while reading Batch Control, edited by A. E. Nisenfeld and H. Leegwater (ISA, 1996), we noticed the S88 standard being mentioned prominently throughout the text. We also couldn't help noticing the popularity of S88 in various trade magazines, so we decided to do a little research on S88.01 and ordered the standard from ISA. While we couldn't grasp all the concepts initially, we both thought following a standard for batch control was at least worth some investigation. Meanwhile, while making a presentation at Allen-Bradley's Consumer Products Roundtable in March 1996, Jim met Michael Saucier, the founder of Sequencia (then known as PID). Sequencia created and is marketing OpenBatch, a PC-based batch control software package that follows the S88 standard. About that time, Rockwell Software announced that it had licensed OpenBatch and would be marketing it under the name "RSBatch." (Other companies, including Honeywell, Siemens, and AspenTech, have also since licensed OpenBatch and integrated it into their batch solutions.) There are several "S88-aware" solutions in industry today, including products from Sequencia, Rockwell, Wonderware, Intellution, Siemens, Honeywell, Fisher- Rosemount, Moore Products, ABB, Yokogawa, and GSE. After reviewing the alternatives, we concluded that OpenBatch was the best solution for us. Ben & Jerry's formed an alliance with Rockwell Automation in 1993 in which Rockwell would be Ben & Jerry's exclusive provider of critical control system components, such as PLCs, operator interfaces, discrete control panel components, frequency drives, and motor starters. Ben & Jerry's relationship with Rockwell Automation was very strong, and so Rockwell Software's decision to license OpenBatch strengthened our favorable opinion of the product. Introduction xiii OpenBatch can work with all kinds of different control systems, and Allen-Bradley PLCs can work with many S88 batch packages. Because of our commitment to our alliance with Rockwell Automation and our satisfaction with that relationship, we decided to purchase RSBatch. (It's also easier to justify projects that include products and services from alliance partners.) However, to appeal to a wider audience (in hopes of higher royalty income), we've written this book to educate users who are working with any S88-aware solution. Furthermore, we'll also use the term OpenBatch instead of RSBatch. Before we go any further, we do need to make one tiling clear: we're not saying batches can't be controlled exclusively using ladder logic or that they shouldn't be (after all, the St. Albans plant used ladder logic for three years and has left the original PLC code in place as a backup). We're just saying it ended up not being the best way for us. Besides retrofitting an existing control system with new software (versus installing an entirely new system), we did something else that was not common: we designed and implemented the system ourselves. Plenty of very qualified system integrators and consulting companies, including Rockwell and Sequencia, could have installed it for us. But we had the resources available and the personal interest to do it ourselves. What we're going to tell you—and what the examples we're going to use will show you—is not what we read, saw, or managed. They are what we did. WHAT YOU SHOULD READ DEPENDS ON WHO YOU ARE We believe this book can help educate just about anyone in an organization that uses batch control. In the following table we have listed suggested chapters to read based on your role at your company. We believe these apply if you work for a manufacturing company or if you're working at a vendor, an original equipment manufacturer (OEM), or a consulting firm. If you are: Think about reading: An automation or controls engineer The whole kit and caboodle A project engineer or project manager Almost the whole kit and caboodle: skip Chapter 12 An automation or controls technician Chapters 1 through 8 and 11 through 14 An operator Chapters 1 through 8 and 13 and 14 An information technology (IT) systems analyst in manufacturing Chapters 1 through 10 and 13 and 14 An engineering or IT supervisor Chapters 1 through 7 and 13 and 14 A mid-level manager and above (including a company executive) The first two parts of Chapter 1 and all of Chapter 14 Applying S88 xiv HOW WE CHOSE TO ORGANIZE THIS BOOK So this is the story of how we implemented an S88-aware batch control system. In the first chapter, we begin discussing batch manufacturing so that we'll all start on the same page, literally and figuratively Still in Chapter 1, we introduce S88 as a concept and a philosophy, throw entity-relationship (E-R) diagrams and sequential function charts at you, and describe our mix making process. Chapters 2 and 3 discuss critical project activities, like gathering customer requirements, selling the concept (getting money), managing the project, and scrounging dinners from vendors. Starting with Chapter 4, we dig into the meat (or tofu for you vegetarians out there) of S88.01. For those of you who have read the standard, please be patient with us. We do not follow its thought progression exactly. Well introduce S88 models in Chapter 4, talk about recipes in Chapters 5 and 6, discuss equipment control in Chapters 7 and 8, and review important aspects of information handling in Chapter 9. So that you get your money's worth, we're also going to discuss specifying a batch control system in Chapter 10, designing phase logic in Chapter 11, and writing phase logic in Chapter 12. Chapter 13 is about starting your new system, including dealing with validation activities. We wrap things up in Chapter 14. We didn't implement every detail of S88 in St. Albans because we didn't need to. But for this book we have also worked with industry experts to fill in the gaps. If you're not an OpenBatch (or RSBatch or Total Plant Batch) user, don't fear: you will learn and profit hugely from reading this book. We didn't write it to be a replacement user manual for OpenBatch, RSBatch, or Total Plant Batch. For those of you using batch solutions from Intellution or Fisher-Rosemount, this book will be more helpful to you than you may think. The core functionality of their products is very similar to OpenBatch. You just can't please everybody, so we know there will probably be at least three groups of people who aren't going to like this book. The first group will be S88 committee members, who'll be disappointed because we're not going to interpret the standard exactly the way they intended. The second group includes engineers who implemented S88 differently than we did but who at least think they implemented their solution "the right way." The third group includes people much smarter than us, who'll find our interpretation of S88 offensively simple. On the other hand, committee members who authored S88, engineers who have already implemented S88, and those who believe they truly understand the standard probably don't need this book. We hope you do—that you really have no idea what S88 is all about or at least you would like a guide to using it. After reading this, maybe you'll think we're both S88 geniuses and hire us as consultants for obscene fees. On with the show. 1 BASIC CONCEPTS No milling around in this book; we're jumping right in. So hang on tight and enjoy the ride. BATCH MANUFACTURING Manufacturing operations can be generally classified into one of three different processes: discrete, continuous, and batch. Discrete processes involve the production of things. A part or a specific quantity of parts in a group moves from one workstation to another, gaining value at each location as work is performed. In a discrete process, each thing or part maintains its unique identity. Often parts are combined to create products or other parts, but each new product or part maintains its unique identity. A great example of a discrete manufacturing process is the production of automobiles. Think conveyors, robots, nuts, bolts, and torque wrenches when considering discrete processes. Continuous processes involve the continuous flow of material through various processing equipment. Once a continuous process is operating in a steady state, the goal is to produce a consistent product no matter how long the operation may run. The production of gasoline is often thought of as a prime example of a continuous process. Once started, refineries do not want to shut down. When looking at a continuous process, you'll see pumps, valves, instrumentation, and larger processing equipment (such as a cracking tower). According to the S88 standard, a batch process is defined as follows: "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." So, instead of a continuous flow that can go on for days or weeks, batch processing involves limited quantities of material called—are you ready for this?—batches. By the nature of the process, batch manufacturing is discontinuous. That is, you start with some raw material, do something with it, send it on its way, and start all over again with some new raw material. Batch manufacturing is also not discrete. There are no things that you can easily separate or identify. Sure, you can place a portion of a batch into some specific container, like a bottle of soy sauce, but that doesn't make the process discrete. If you combine a whole bunch of uniquely stamped gas caps in a box and mix them up, you can still identify each one individually. You can individually mark bottles of soy sauce, but the sauce inside the bottle is still part of the same batch and cannot be distinguished from one bottle to the next. The distinguishing factor of a product like soy sauce is the batch or lot from which it was bottled. That's why you'll see some type of batch or lot identifier printed on the cap or label. We've dealt with batch processes throughout our lives. Our mothers made brownies in batches. We wash clothes in batches. (The clothing in the washing machine may be uniquely distinguishable, but washing is a batch process nonetheless.) The word batch is a noun, but it is also a verb. To "batch" is to apply a batch process. Applying S88 2 Producing a product consistently is always a top priority. Once a process is repeatable, you can then work on issues like reducing cost, waste, or both. Consistently producing products with batch manufacturing is especially tricky Unlike continuous processes, which may run for a long time, brand-new batches are created often. And unlike both discrete and continuous processes, it may not be possible to determine if the batch is being made correctly while it is being made. You may have to wait until the batch is complete before checking. If it's a bad batch, you can try to correct it (which costs time and money) or trash it (which really costs time and money). The point is to make a batch right the first time. So, the control of the batch process (or as we automation engineers like to call it, batch control) is a very important aspect of batch manufacturing. Wow, what a lead-in to S88! WHAT REALLY IS S88? First of all, for the purposes of our book, here's the golden rule regarding S88 and SP88, which also applies to all ISA standards and committees: • S88 is the standard (S stands for "Standard"). • SP88 is the committee that wrote it (SP stands for "Standards & Practices"). Now that you know this, don't embarrass your friends, your family, or your company by using S88 or SP88 in the wrong context. The S88 committee was formed to address batch control issues after companies grew sick and tired of four basic problems: 1. No universal model existed for batch control. 2. Users had a very difficult time communicating their batch processing requirements. 3. Engineers found it very hard to integrate solutions from different vendors. 4. Engineers and users had a difficult time configuring batch control solutions. All of these problems led to expensive batch control systems that often did not meet all of the needs of the users and were difficult to maintain. So the committee put together a road map that outlined a two-part standard. ANSI/ISA-S88.01- 1995 (the standard number) and Batch Control Part 1: Models and Terminology (the standard title) was released on October 23, 1995; S88.00.02, Batch Control Part 2: Data Structures and Guidelines for Languages had not yet been officially released by ISA or ANSI when we wrote this book. However, to gain valuable insight into S88.00.02, we activated the "mole" that we planted in the committee many years ago. Our source gave us important and accurate advance information about S88.00.02 that we have included in this book. Most of that information will be focused on data structures, which are discussed in Chapter 9. The portion of S88.00.02 that deals with language guidelines seems to be leaning more toward a vendor focus and is not quite as important to the user. We made a difficult decision not to include language guidelines in this book; however, we can always write another book. We will often shorten our reference to the standard to "S88" (not S88.01 or S88.00.02). We've already had more than one committee member kindly inform us that the official standard names are ANSI/ISA-S88.01-1995 and S88.00.02. Okay, okay, we agree; but we're trying to save some ink here! Ahem! Moving on ... Basic Concepts 3 S88 isn't just a standard for software, equipment, or procedures; it's a way of thinking, a design philosophy. Understanding S88 will help you better design your processes and manufacture your products. Leveraging the knowledge and experience contained in the standard will enable you and your customers to identify your needs better, make recipe development easier, and help reduce the time it takes to reach full production levels with a new system or for each new product. By following the concepts explained in S88, you could improve the reliability of your operations and reduce the automation life-cycle cost of your batch processes, including lowering the initial cost of automating your operations. How does S88 do this? • S88 isolates equipment from recipes—When the code to run equipment and the code that defines a product recipe are in the same device (such as a programmable logic controller [PLC] or a distributed control system), the two different sets of code eventually become indistinguishable and in some cases inseparable. Every additional ingredient and process improvement can require many person-hours to modify the software. Documenting such a system is also extremely tough. This makes recipes difficult, if not impossible, to maintain. (And let's not mention altering the process.) If recipes are kept at a higher level, as in S88-aware systems, they are more flexible. The person who knows what process changes are required—process engineers or lead operators—can make the changes directly Control systems experts are not needed. (Whoa! So much for job security. But who wants to do "maintenance" work like this anyway?) • S88 provides guidelines on how to recover from abnormal events—Recovering from abnormal events is one of the most difficult parts of batch control. In many non-S88 installations, automatic recovery is not implemented, and operators and/or engineers are needed to get equipment and the recipe back in sync. Since S88 uses a standard set of states, it provides engineers with an opportunity to consider how abnormal events should be handled when designing the system. Recovering from abnormal or unexpected events was one of our main considerations when we designed an S88 solution for Ben & Jerry's. • S88 helps you track historical data—When there is a problem with a product and someone has to go back through plant data to try to determine the cause, it can be difficult to understand what was being done in the process at a given time. S88-aware software tracks the state of the batch in a log. Some companies integrate this process log into "historian" software packages. • S88 makes gathering requirements from customers easier—S88's common terminology and models help you know what questions to ask. This will make it more likely that the system you install is the system your customers wanted. How a product is manufactured is often as important as the ingredients it is made of. S88 helps you better define the manufacturing process. • S88 makes conveying requirements to vendors easier—Again, common terminology and models will help reduce the number of surprises you and your vendor spring on each other. Working with more than one vendor is also easier. If everyone follows S88, you are much more likely to have better success integrating products from different vendors. In the long term, as vendors become more comfortable with S88, you should experience quicker turnaround time on systems and projects. • S88 modularity makes possible better return on investment—For those of you with large batching operations or several plants producing similar products, you can also benefit from the reusability of recipes and equipment phases that S88 makes possible. If your recipes are written properly, you can duplicate equipment functionality with minimal changes, which Applying S88 4 will significantly reduce the time you need to implement subsequent projects. With S88, recipes are also more transportable between sets of equipment or between plants. • S88 design concepts will make validation easier—A good S88 design will allow you to validate procedures and equipment independently. This simplifies the commissioning process, which typically translates into a faster start-up and faster ramp-up to full production capability. These seven points can translate into direct, tangible benefits. The following list shows possible improvements in terms of typical metrics that a batch manufacturing plant may capture. As you can see, some of these are directly related to others. 1. Reduced batch cycle time 2. Increased production run rate 3. Higher number of batches per year 4. Shorter changeover time 5. Lower cost to make a batch 6. Improved batch yield or consistency 7. Reduced raw material loss 8. Larger number of scheduled recipes 9. Reduced time to add new recipe 10. Reduced time to modify a recipe 11. Improved equipment utilization 12. Reduced downtime 13. Reduced number of manual operations 14. Lower engineering cost throughout the life cycle of your manufacturing process 15. Lower cost of capturing data, including less time to record batch data 16. Data availability is better: A larger quantity of higher-quality data is accessible for analysis Various papers and articles have described the improvements S88 has made possible for many of these metrics. For example, it's not uncommon to see companies experiencing a 20 percent improvement in process cell throughput, a 20 percent reduction in batch cycle time, a 10 percent increase in product yield, a 33 percent reduction in project start-up time, or a 30 percent reduction in implementation cost because they used modular batch automation with S88. In recent years, the annual ISA Expo or ISA Tech events have had presentations about successful S88 projects. Visit www.isa.org to purchase conference proceedings. The World Batch Forum is also a great source for papers describing the benefits that can be derived from S88 implementations (visit www.wbf.org). You'll learn more about leveraging the knowledge of ISA and the World Batch Forum in Chapter 14. Keep in mind that S88 was designed to handle all levels of automation. That is, S88 can be applied to a fully automated system or to a completely manual system ... or to anything in between. If you plan to use original equipment manufacturers (OEMs), system integrators, or other vendors, make sure you hire only the ones that buy you the nicest dinners. Seriously, the S88 standard enables these firms to supply the appropriate tools for implementing batch control. But don't just hire a vendor to implement your system. That's like putting a coin in a slot machine, Basic Concepts 5 pulling the lever, and walking away. Stick around; see what you can win. You must embrace the standard yourself in order to get the complete payout. To properly develop a successful batch control system, you need to define three important elements: • How to make the product (recipes) • What physical tools are needed to make the product (equipment) • How to run that equipment (control activities) You will read about each of these three elements in this book. We'll stop here for now to let this soak in and then move on to other basic concepts you should understand. E-R DIAGRAMS Let's talk about E-R diagrams. While they have nothing to do with Michael Crichton's TV show, understanding this documentation technique might help you prevent some future hemorrhaging in your projects. Many books will place discussions about entity-relationship diagrams or other similar subjects in an appendix. We believe that understanding E-R diagrams is just too important a topic to defer, so we're going to present them right now. E-R diagrams are a common way of describing objects in a system (entities) and how they correlate to one another (relationships). This type of documentation is very commonly used in the definition of data structures and flow, especially database architectures. Therefore, this technique has been very popular with IS/IT organizations. There are four basic associations between objects in a system. In Figure 1.1, for each occurrence of A there is one and only one occurrence of B. The example E-R diagram reads "A unicycle has one and only one wheel." Figure 1.1 One and Only One Association In Figure 1.2, for each occurrence of A there is zero or one occurrence of B. In this example, a car can have zero or one hatchbacks. Applying S88 6 Figure 1.2 Zero or One Association In Figure 1.3, for each occurrence of A there is one or more occurrences of Б. In this example, a house has one or more bathrooms. Figure 1.3 One or More Associations In Figure 1.4, for each occurrence of A there is zero, one, or more occurrences of B. A Ben & Jerry's employee gains zero, one, or more pounds during the first week on the job. Figure 1.4 Zero, One, or More Associations Okay, the example in Figure 1.4 is pushing it, but remember the phrase from college, "the freshman fifteen"? Well, at Ben & Jerry's they have "the Ben ten." It's hard enough to not gain weight by just working at an ice cream plant, but the company pushed us over the top with one of the best benefits around: three free pints a day, every day. Anyway, many E-R diagrams include labeled associations, as in Figure 1.5. In the example, the association would be read as "A surfer dude owns one or more surfboards," or (more succinctly) "Surfer dude owns surfboards." Basic Concepts 7 Figure 1.5 Labeled Association E-R diagrams need not focus on physical objects. In fact, many of the E-R diagrams we will be using in this book are more procedurally oriented. For example, in Figure 1.6, a procedure consists of an ordered set of operator instructions. Figure 1.6 Procedural Association Enough of E-R diagrams. SEQUENTIAL FUNCTION CHARTS The International Electrotechnical Commission standard IEC-61131-3 includes something called a sequential function chart (SFC) as a programming language. It is also common to use this nomenclature as a documentation framework. We've illustrated an SFC in Figure 1.7. Existing products, including PLC programming software and batch control packages, use SFCs to represent executable procedures. In this section, we're first going to introduce two common elements of an SFC: steps and transitions. A block containing either a step number or step name represents an SFC step. Vertical lines link the steps. The initial step of a sequence is drawn as a box with a double line. A step is either active or inactive at any given time. We'll see in a little bit how more than one step may be active at a time. A horizontal line represents a transition across the vertical link between two steps. It lists the condition for transferring control from the active step preceding the transition to the step following the transition. That is, when a transition is true, or ires, the active step immediately before the transition becomes inactive and the step immediately after the transition becomes active. We talk about an active step because a transition can be true anytime, but for a transition to activate the step following it the step preceding it must be active when the transition fires. Figure 1.7 shows the step and transition elements of a sequential function chart, as well as the sequence terminator. (Note that IEC-61131-3 does not define a sequence terminator. That standard requires that an SFC end with a step and not a transition. Some batch control software packages, including OpenBatch, use this terminator.) Applying S88 8 Fiqure 1.7 Elements of a Sequential Function Chart Figure 1.8 adds some real-world features to our example Figure 1.8 SFC Example: Mixing Milk and Cream Basic Concepts 9 Notice a couple things in Figure 1.8. First, the "initial step" is not labeled; it is just a double box. Second, a TRUE transition is allowed. Keep in mind that a TRUE transition will immediately pass control to the next step or steps in line. If a TRUE transition existed between Add Milk and Add Cream, Add Milk would stop and Add Cream would start right away, even though not all the milk had been added. Remember that as long as the preceding step is active and the transition is true, the preceding step stops—even if it is not yet complete—and the following step starts. To prevent this from happening, you'll find the most common type of transition is the "step complete," as shown in Figure 1.8. SFCs handle AND/OR branching pretty well also. An OR condition, or what IEC- 61131-3 calls a divergence of sequence selection, is shown in Figure 1.9. In the example in Figure 1.9, we only add one type of cocoa, high-fat or low-fat, depending on what the recipe calls out. Figure 1.10 builds on Figure 1.9 to show how the sequence converges. Note how only one alternate path is taken, but no matter which cocoa is used the sequence converges back to adding cream. When designing your control scheme, it's always convenient to construct mutually exclusive conditions in your transitions. Even if both transitions were to fire above (let's say we mixed both types of cocoa in a recipe), SFC rules only allow one path to run. Generally, we like to think the "left" path has the priority, but that of course depends on the SFC implementation of the product you're using. So, to be sure, check with the product support group to see how its rules work. Figure 1.9 Divergence of Sequence Selection (OR Condition) Applying S88 10 Fiqure 1.10 Convergence of Sequence Selection Figure 1.11 shows an AND condition, or a simultaneous divergence. Figure 1.11 Simultaneous Divergence (AND Condition) Notice how a single transition (in this case, TRUE) starts all three steps simultaneously. The double horizontal line is called the line of synchronization. With a simultaneous divergence, the transition must occur above the line of synchronization. Figure 1.12 shows the corresponding convergence to this condition. Basic Concepts 11 Figure 1.12 Simultaneous Convergence Notice that a compound transition is allowed (Add Water completes AND Add Sweetener completes). Also pay attention to what happens after that transition fires. According to SFC rules, when this transition is true Add Cream becomes active, and Add Water, Add Sweetener, and Agitate all become inactive. So with Agitate, you now see how a step can become inactive even without a transition indicating that the step has completed. In at least some batch control products, you can skip steps as well, which is shown in Figure 1.13. Figure1.13 Skipping Steps Applying S88 12 One last rule on SFCs. If you look through all of the preceding diagrams, you'll notice that no two steps occur without a transition in between, and no two transitions occur without a step in between. This is a golden rule with SFCs. If two transitions need to fire in order for a step to start, perhaps you can create a compound transition. We`re tired of talking about SFCs, so let's talk about mix-making. A TYPICAL MIX-MAKING SYSTEM Figure 1.14 is a diagram of a typical mix-making system. While it is not very "engineering-ish," it'll have to do. Figure 1.14 A Typical Mix-making Process All the examples in this book will be concerned only with the mix-making batching process. In Figure 1.14, this process is represented by all the equipment up to and including the two batch tanks. Most ice cream companies make use of both liquid and powder ingredients. All liquid ingredients, including cream, milk, liquid sugars, eggs, and water can be dispensed using flowmeters or load cells. All powder ingredients, including powdered sugars and cocoa, are generally dispensed using load cells. To make mix, you simply combine the necessary ingredients according to a recipe so as to form a mix "soup," which is not very different from making ice cream in a freezer at home. But while at home you may make a half gallon or gallon of ice Basic Concepts 13 cream mix, ice cream companies sometimes make thousands of gallons of mix per batch. Depending on the mix type, each batch may have over a thousand gallons of cream or milk and may have over a thousand pounds of cocoa. The batch tanks generally operate in parallel, though not simultaneously: mix is made in one, then the other. While one tank is batching, the other is feeding product to a pasteurization process. Often product types and production scheduling require a high level of process flexibility. It's not uncommon for a company to have dozens of different mix recipes and to run several different recipes in one day. Mix makers try to do this without shutting down the pasteurizer. To complicate matters further, the amount of fat and nonfat solids present in milk can vary with each truckload. The amount of solids in milk depends on the cow's diet and on the season. Some companies order standardized cream and milk, which results in the same solids potencies for every truckload. Other companies don't, instead varying their recipe ingredient quantities to achieve consistent final mix specifications. If tomorrow's load of cream has less fat than today's, operators will use more gallons of cream but may balance that with fewer gallons of milk or water. (Cream is sold by pounds of fat, not gallons, so the cost works out to be about the same regardless of potency.) Therefore, even though a plant may be running the same mix type, once operators switch to a different raw dairy tank the recipe quantities may change. Did you get all that? It doesn't really matter; we'll repeat the important points as necessary. Before we go any further, the next two chapters talk about some necessary business and project management topics. Stay tuned; this is good information. PASTEURIZING ICE CREAM MIX We thought you might like us to explain a popular method for pasteurizing ice cream mix, even though understanding a pasteurization process isn't vital to understanding S88. Downstream from the batch tanks is a high-temperature short-time (HTST) pasteurization process. (Old dairymen sometimes call this process "the short time.") Pasteurization is based on a time-temperature curve. The higher the temperature, the less time the mix needs to be held at that temperature to be considered pasteurized. HTST involves somewhat high temperatures (175-200°F) and somewhat short holding times (20-50 seconds). Follow along with Figure 1.15, which shows a more detailed view of the HTST pasteurization process, while we explain the steps: 1. As mix leaves one of the two batch tanks, it travels to the hundred gallon or so balance tank, which serves to ensure that the process remains charged with mix at all times. (continued) Applying S88 14 (Pasteurizing ice Cream Mix continued) 2. From the balance tank, the mix is pumped to the first of three sections of the pasteurizer. In the diagram, the pasteurizer is labeled "Press." Press is slang for the pasteurizer, as it is merely a three-section plate heat exchanger with the plates pressed tightly to one another. It sort of looks like a giant automobile radiator. In the first press section-the regeneration section, or "regen"-the mix is preheated to around 150-170°F. 3. At this temperature, the mix passes through the homogenizer. The homogenizer pulverizes the fat globules into microscopic- sized particles. (The smaller and more equally distributed the fat globules are, the smoother the ice cream tastes.) 4. After being homogenized, the preheated mix moves to the heating section of the press, where its temperature rises to 176- 200°F. 5. The mix then travels through a snaking set of holding tubes, which provide a physical means for ensuring that the mix is held at the pasteurization temperature for the required period of time. At the end of the holding tubes is a temperature transmitter and a divert valve. 6. If the temperature of the mix at the end of the holding tubes is not at or above the minimum acceptable pasteurization temperature, the divert valve will force the mix to the balance tank, where it is recycled back through the HTST process. The HTST system is also pressurized, so that product leaving the pasteurizer is at a higher pressure than product entering the unit. If a leak occurs, pasteurized product will flow to the raw part of the process, not the other way around. As an added safeguard, if a minimum pressure differential is not maintained, the divert valve will force the mix to the balance tank. 7. If the pasteurization process is in normal "forward flow" mode, the mix travels through the "back side" of the regen section to have its heat transferred to the mix coming from the balance tank. After regen, the mix enters the final section of the press-cooling- where it is chilled to about 35-40°F for storage. The "divert valves" are controlled by a separate control system, often an independent programmable logic controller. This PLC is enclosed in a separate panel and is sealed by the state regulatory authority. If a plant makes any alterations to this control system, a state regulatory agency generally must reinspect the system. Information about process and equipment states is generally shared between the two PLCs via hardwired interlocks. Basic Concepts 15 Figure 1.15 The Pasteurization Process 2 ARE YOU READY TO GO YET? "This chapter is all about begging for permission to start your project. (Sorry, we don't have a chapter on begging for forgiveness for completing a project that you never told anyone about.) If you already have the go-ahead, congratulations, you lucky dog. You're the envy of the remaining 99 percent of us. Now quit wasting your time and skip ahead to Chapter 3. For the unlucky ones left reading this chapter, we're going to talk about selling management on the need for an S88 supervisory system. GATHERING REQUIREMENTS How many times have you finished a project only to find that you could have done so much better if you'd known just a little more about what was required? Maybe you had to redesign your solution halfway through the project, or maybe your customers only returned blank stares when you exclaimed, "Ta-daaa!" Hey, let's face it, requirements gathering doesn't hold the distinction of being the most glamorous part of a project. Many engineers either want to start designing or start building. But let's not just point the finger at engineers. You managers sometimes don't help much either. You debate solutions, ponder, wish, and otherwise delay approving the project for so long that by the time the project proposal has the necessary signatures, the original proposed schedule has slipped by weeks or months. You somehow forget why the schedule slipped, mumble something like "How could we let this happen?" and insist that the project be finished by the original date. This can often result in rushed requirements gathering. Regardless of the reason, many companies do not always take sufficient time to analyze requirements. Without clear requirements, project "costs" will rise—and not just capital costs. Don't forget about rising operational costs, schedule slips, inadequate consideration of safety and quality issues, regulatory shortcomings, and a poor design that simply does not meet customer requirements. Depending on your company's policies, you may gather and analyze project requirements before or after you submit the project proposal. In justifying our mix-making supervisory system at Ben & Jerry's, we chose to gather requirements before submitting the proposal. We attached the requirements document to the proposal to help substantiate our analysis of company needs. It's important that you gather requirements; how you go about it isn't critical. We have found that a quick, surgical thrust works best for us. (If that fails, we try a sledgehammer approach.) For "smaller" projects (less than $100,000 in capital costs), the lead engineer typically interviews key people within a day or two, including people from operations, maintenance, quality assurance, and finance. The lead asks another engineer for feedback on a preliminary requirements document, then issues the first draft. For larger projects, we tend to include more people—sometimes from other Applying S88 17 sites—iterate an extra draft or two, and host a review. If we've made assumptions about the project, we state them in the requirements document, and we also include unanswered questions. Sometimes one of the reviewers can answer a question or two. Carefully keep in mind the political benefits of gathering requirements. First, it gives you another chance to sell the project to people who are not yet convinced of the solution. A completed requirements document clearly outlines the expected benefits of the solution and may present concepts in different terms than before. Second, gathering requirements gives you a great opportunity to ensure that your customers assume ownership of the project. By including all the right people in the requirements-gathering process, their needs, thoughts, and fears will be recognized and addressed. But the most important thing about including all the right people is quite simple: if the project fails, the blame is spread among more people. At the very worst, you don't go down alone. Our requirements gathering at Ben & Jerry's included assessing our need for an S88-aware batch control system and for other supervisory system components, such as a database and a human-machine interface (HMI). (We safely made an assumption at this point that we needed an S88-based solution.) A requirements document might include the following five sections: 1. Document purpose 2. System objectives 3. Project scope 4. Implementation plan 5. Tools required The first section, the requirements document's purpose, can be as brief or as elaborate as your audience requires. For the second section, on system objectives, | here are some typical objectives: Better understand where variances occur in the process—Understanding variances is expected to lead to the identification of waste and a more consistent product, subsequently reducing operational costs. Reduce system troubleshooting time—Improving operators' knowledge of the system and ensuring quicker reporting when a process is out of control will result in reduced downtime and reduced risk for loss of quality. (Sounds good, doesn't it? Who were we kidding? The most important thing for us was to reduce the number of 2:00 a.m. calls we received at home when the system didn't work!) Reduce unnecessary and tedious manual calculations and paperwork—Less manual work frees operators for more important tasks and reduces associated errors (e.g., transcription, keypunch). Better understand ingredient usage—The supervisory system will help operations and finance better understand the reasons for inventory adjustments (i.e., the reasons for manufacturing variances or material waste). Improve flexibility of mix-making system—Making new mix recipes, using new ingredients, and modifying CIP procedures is expected to be less cumbersome. (CIP is "Clean-In-Place," a method for automatically cleaning equipment without tearing it apart.) The responsibility for making minor system changes for new recipes and ingredients will shift from engineering to operations. Are You Ready to Go Yet? 18 The first and fourth objectives can be tied to the proposed system in its role as an "enabler." Much of the time, plant floor automation serves as an enabler, helping to identify where problems are occurring. Without the automation these problems may never be identified. Like our requirements document for Ben & Jerry's, section 3 of your requirements document, on project scope, might list specific tasks that the proposed system will perform: Automatically collect accurate data on the amount of raw ingredients received, raw ingredients used in each batch, mix made, and mix transferred to the flavor vats. This is expected not only to reduce tedious paperwork and associated errors but also provide additional information that is currently too difficult to collect. Automatically calculate variances and where they occur. This is determined by analyzing differences in the data collected in the preceding automatic collection task. Improve batch operations and calculations. New software is expected to help tighten batch tolerances; to provide greater flexibility for new products, ingredients, and process changes; to reduce paperwork by automatically calculating recipes; and to provide better batch result information. Provide a detailed explanation to operators as to why a function has failed or will not start. Providing diagnostic capabilities is expected to reduce downtime and loss of quality. Section 4 of the requirements document, on the implementation plan, should provide further detail on each item listed in the project scope section. Finally section 5? on the tools required, can simply list the hardware and software needed to accomplish, the objectives and scope listed in the requirements document. SELLING THE CONCEPT (GETTING FUNDING) As much as you may wish it were otherwise, writing an S88 proposal is no different than writing any capital project proposal: formal justification is key to obtaining funding approval. Each company treats automation justifications differently, and some understand the value of flexibility and enabling technology better than others. At Ben & Jerry's, we chose to base our proposal on the potential for cost savings that the supervisory system would provide. Keep in mind that this early stage of your project can be hampered by fear and politics. People will be: • Afraid of new technology (most likely because they don't understand it) • Trying to get the new technology at their site first, not yours • Attempting to wrest control of the new technology away from your department In our careers, we have experienced all three situations. Let us be the first to assure you that those early days seeking formal justification were some of the happiest and most blissful of our lives—Not. Look, do whatever you need to do to avoid these pitfalls: educate, build consensus, whatever. We're not here to advise you politically (Larry will tell you that's the last kind of advice you want from Jim.) Take it from us, physically visible tools, like HMIs, attract a lot of attention. If choosing a specific HMI is going to create issues, make sure you propose an S88 solution that is flexible enough to work with different HMI products. Applying S88 19 If your project can be easily justified in terms of cost savings, a return on investment (ROI)-based proposal may be the way to go. If you are anticipating cost savings but cannot quantify the details, you may want to consider discussing additional benefits like the following: • Quality issues—Automation may help increase the consistency and quality of products. Don't neglect to tell management that consistency and quality of INFORMATION is important too. (We believe that information is the second- most important asset of any organization.) • Responsiveness and flexibility—The capability to adjust rapidly, efficiently, and effectively to required changes creates a distinct advantage in successfully and quickly bringing products to the marketplace. • Automation as an "enabler"—Supervisory systems can serve as "enablers" that allow operators and managers to better understand where variances and waste occur. With this information, production processes and procedures can be altered to improve quality, minimize waste, and reduce costs. Without automation these problems may never even be identified. A successful proposal clearly shows that the "seller" understands the business's problems. It should show that the proposed project is part of a total vision and that it supports the company's manufacturing strategy or strategic goals. The proposal should make good use of visualization techniques, such as charts and graphics, where appropriate and should discuss case or benchmark studies. Of course, if necessary, don't be afraid to "package" the proposal to the bias of the "buyer." Clearly match the project's benefits to the personal motivators of those with the magic signing pen. Many companies have a standard format for project proposals, so we're not going to outline that here. If you've already created a requirements document, heed this advice: • In the project detail section of your proposal, refer back to your requirements document, or even insert pertinent sections from it. This will help show management that you're not making up your claims. • Unless you enjoy the excruciating pain of approval delays or rewriting proposals, map the project benefits listed in the benefits section of the project proposal to the system objectives outlined in your requirements document, clearly showing how your project will satisfy plant needs. When listing benefits, use quantifiable facts. If you have financial data, use it, but employ tables and graphs so management can visualize it. Do the same when discussing the time savings derived from reducing the manual paperwork activities of operators. If your company's goal is to find better uses for operators' time, not to reduce head count, you may not want to convert the paperwork hours saved into dollars. Don't forget to include time estimates for correcting errors associated with manual data entry. There is also value in timeliness: data collected automatically in real time has a higher value than data entered manually at the end of the day. You may also wish to discuss the project benefit of enhancing system flexibility. To quantify this benefit, consider the amount of engineering time that was required to design, implement, and test ladder logic changes during a recent project. Then explain how this time could be cut if an S8 batch management solution were installed. If you can get it, don't forget to include information that shows how enhanced system flexibility will allow products to enter the market faster. Are You Ready to Go Yet? 20 Enhancing product quality is a definite benefit. Investigate whether increased product quality will result when operators have more detailed, real-time information about the batching processes. This real-time information can provide warnings to operators if processing parameters are expected to fall outside of specification. The operators can then correct the problem before the product falls out of spec. 23 Good luck with your proposal. 3 STARTING (WHAT YOU HOPE WILL BE) A SUCCESSFUL PROJECT Now we're going to talk about planning and preparing for your S88 implementation. This chapter mostly contains project management stuff, but not a lot of it. After all, this isn't a book about project management; it's a book about implementing S88. For your enjoyment, and at no extra charge, we have included SOME important things that we learned about project management during our Ben & Jerry's project and others. STEP ONE OF A SUCCESSFUL PROJECT Buy your operators a new desk. They'll be your best friends throughout the project. All right, so maybe you don't really need to buy a desk—not a big one, anyway. But your operators are among your "customers," and you need to make sure your customers are happy. Without your customers' support, your project is doomed. Getting your management's support is absolutely necessary, but that support really only gets you time and money. For your project to succeed, you must satisfy the needs and wishes of the people who will actually be using the system. If you don't design and implement a solution that satisfies your customer, that customer isn't going to use your whiz-bang system. If no one uses your system, it's a failure. With luck, when you were gathering requirements you focused on the visible needs of your customer. Sometimes this is simple, sometimes not. If your customer is very aware of your process and its potential, he or she will have all kinds of ideas on how to improve it. But in many cases, you may have to dig a little to find out how to improve your customer's work life. And, by George, that's what your job is really all about: Improving your customer's work life! The operator was the center of manufacturing at Ben & Jerry's. As engineers, we didn’t simply try to make a piece of equipment or system run better; our mission was to focus on the needs of our customers—the operators—in order to make their work lives better. Likewise, we worked hard to ensure that we didn't have just "button pushers"; we wanted educated customers! Starting (What You Hope Will Be) a Successful Project 22 When operators can do their jobs better with fewer obstacles, they make consistently great products at the lowest possible cost and highest possible quality. When that happens, everyone benefits: the operator, the engineer, the CEO, shareholders, even the little kid next door eating some Chocolate Chip Cookie Dough ice cream. While we were at Ben & Jerry's, we made things better for our customers by implementing solutions that reduced tedious paperwork, replaced laborious manual tasks with automated counterparts, improved manufacturing efficiencies, and added product and ingredient flexibility to the process. This sounds great, but don't forget about realities. Hey, even Ben & Jerry's had to consider reality. The company's products were in such demand, especially during the summer, that the plants often ran six days a week. As time can be a luxury in any project, this schedule presented problems. One down day a week just wasn't good enough for many of our projects. Having an S88-aware batching system helped Ben & Jerry's roll out new products and make changes to processes in less time, reducing the need for weekend work. Getting back to the desk, we actually bought it because we needed space for a supervisory system desktop computer. We knew we didn't have to buy it to get our mix makers' support. The mix makers we worked with were awesome and any engineer's dream customers. The plant's lead mix maker is a Ben & Jerry's old-timer, who had started with the company back when steam engines turned agitators. She knows the mix-making process better than anyone (including us). All three mix makers at the St Albans plant relied on automation, but they would not allow themselves to become dependent upon it. They realized they needed it to help them make mix better, but they used it as the tool it was meant to be. That way, if automation failed they wouldn't throw in the towel. Instead, they'd find ways of working around the problem until an engineer had a chance to correct it. Working with people like this was critical to the success of the project. All your customers may not be operators. Our plant finance group was instrumental in selling and encouraging the S88 project. The process and inventory information provided by the supervisory systems helped them keep their records more current. The plant cost accountant helped us locate sources of manufacturing variances by evaluating process data. He could do his job better when the systems provided deeper and more accurate data. We included our lead mix maker and plant cost accountant in all aspects of the project right from the beginning. Both helped us determine the project's requirements by clearly explaining what they needed to make their jobs easier. We got critical data about the mix-making process and learned what data could help better identify areas of weakness in mix-making. In the end, the lead mix maker flew with Jim to Phoenix for the first round of OpenBatch training. (The class was held in January; their arms really had to be twisted.) Applying S88 23 MOVING FORWARD WITH A SUCCESSFUL PROJECT First of all, if you didn't do so before submitting your proposal, complete the formal requirements-gathering process. As we mentioned in Chapter 2, be sure to involve the right people during this process to help obtain "ownership" and support for the project. We were lucky. Our lead mix maker was excited enough and understood enough about this project that ownership was never an issue with her. Once you've completed documenting your requirements, host a formal kickoff meeting. Invite operators, managers, engineers, or anyone else you believe will feel the impact of or have an impact on the project. Don't forget to include people from other sites, if they can help. At the meeting, review the project requirements, scope, schedule, and costs. Allow everyone to freely ask questions to help eliminate any last-minute fears or uncertainties, but keep the meeting focused on the right issues. For example, if your audience is not overly technical, keep steering the discussion to the business issues the system will address. Be careful not to severely underestimate the amount of downtime needed for installation and testing or the amount of raw material that may be wasted during start-up. It's been our experience that while managers may not like the terms downtime or waste, these issues can be negotiated. Keep an open and creative mind. The St. Albans production manager was another Ben & Jerry's old-timer, about fifth highest on the company seniority list (including Ben and Jerry!). She was very fair and had a grasp of both details and the big picture. One of our standing goals was to never, ever disappoint or surprise her. If you're planning to use a system integrator, an OEM, or a consulting firm to help design or implement all or a part of your system, here are a few important things we have learned on several projects: • Include requirements for system acceptance in contracts—Most contracts will include standard items like cost, schedule, and performance requirements. Many contracts don't include your expectations for system acceptance and particularly the level of validation testing you desire. See Chapter 13 for more information on validation test plans. • Work hard to ensure compliance with published standards and system specifications—Most contracts will require adherence to standards, including mechanical, electrical, and software specs. (Don't forget S88!) However, many companies assume that the vendor performing the work is following the requirements, and they won't bother to perform periodic audits. We've been burned on this before. It's not that our vendors were being deceptive or trying to save a buck—most of the time the spec wasn't followed because of a misunderstanding or an honest omission. Hosting periodic reviews with your vendor can save you from some nasty headaches later. Sure, you can hold the vendor accountable when you find discrepancies at the conclusion of the project. But then you'll face a choice: have the vendor correct the discrepancies, meaning the project will probably finish late, or have the project finish on time without meeting all the specs. When the vendor leaves, you'll be the engineer with a late or incomplete project on your hands. • You're not hiring a firm, you're hiring skills—Interview the individuals who will be on your site. Use the results from those interviews to help determine which vendor, integrator, or OEM to hire. Obviously, technical and project skills are needed, but don't overlook interpersonal skills. Ben & Jerry's had its own special way of handling projects. Sometimes it took the right type of person to thrive there. When negotiating a contract with a firm, consider including a requirement that specific employees of the firm work with you. Starting (What You Hope Will Be) a Successful Project 24 • Consultants, vendors, and OEMs aren't perfect—You hired them for a reason. Perhaps you needed expertise or you were short on internal resources. In either case, you should be able to expect your contracted help to know what they're talking about. However, question their recommendations and estimates as much as you would those from any other source. It's always frustrating to find that a simple miscalculation or error has created havoc. And just because you've hired a vendor to help you doesn't mean you should assume that the vendor is the expert. We're probably going to catch a lot of flak from some of these companies for saying this, but it may not be in your best interest to hire a firm whose first S88 project is yours. Don't wait until the project is complete to develop training manuals or programs. Start them soon after the design is complete. This helps in two ways. First, if you start right away your manuals will be ready by the time you want to train your users. Second, writing the manuals may provide you with some additional insight from the operator's point of view. You may catch things that you want to change before it's too late. Fix software bugs as you find them while testing your system. (And, yes, you will find them.) This is smart for several reasons: • Fixing bugs as you go provides damage control. The earlier you discover your mistakes, the less likely you are to repeat them. • By keeping the bug count near zero, you'll be in a better position to track your progress against the project schedule. Instead of trying to guess how long it will take to finish 16 software features and 102 bug fixes, you just have to guess how long it will take to finish the 16 features. • As projects near completion, people want to finish them. Programmers may tend to blow off the last few bug fixes, thinking they'll get around to fixing them later. • Telling management that all software features are in and that your programmers are working on nothing but bug fixes just doesn't sound good. • Bugs are a form of negative feedback that keep fast but less-than-thorough programmers in check. If programmers aren't allowed to start working on new features until they have fixed all the bugs on the old ones, they're prevented from spreading half-implemented features throughout the project. • When the system goes on line for the first time, bug-free or not, you'll have less freedom to make changes. The fewer bugs at the beginning, the less pressure you'll be under. Finally, pay fantastic attention to detail, especially with your operator interfaces. You can have the best code in the world, but if your HMI is sloppy, you look sloppy. No detail is too picky. Align those fields perfectly! Keep colors consistent. Don't overuse flashing text or graphics. Don't create clutter just to fit everything on one screen or form. And, for Pete's sake, no spelling errors! Enough of planning, proposing, and managing. Ready to really start learning about S88? Great, but please remember as we begin the ride: there can be no eating, drinking, smoking, or the use of flash photography... 4 THE PHYSICAL MODEL S88.01 defines several models that describe the equipment and procedure hierarchies necessary to make batches. In this chapter and the next, we will introduce and discuss these models in detail. We're going to start with the physical model because it probably is the model that is easiest to grasp. This model is used to describe the physical equipment associated with your batching operations. The model, shown in Figure 4.1, has seven levels. Let's start describing the sections from the top. ENTERPRISE AND SITE LEVELS Enterprise is really a fancy name for company. Some consulting firm decided years ago that enterprise sounded more sophisticated or more businesslike than company. It stuck. Now there are terms like enterprise resource planning (ERP) systems. In very large companies, the "enterprise" might refer to a division or business unit. But as far as we're concerned, enterprise refers to a company. In our case, it was Ben & Jerry's. The S88 standard states that corporate, divisional, or business unit activities and decisions are made at the enterprise level. This includes deciding which products will be made, where they will be made, and when they will be made. Likewise, site is another name for plant. Geography is probably the most common method for determining what a site is, but that doesn't mean two sites cannot be physically adjacent. Different sites can make different products, but they don't have to. Likewise, different sites can have different manufacturing processes, but they may be the same. Figure 4.2 is how we viewed the Ben & Jerry's enterprise and its three Vermont sites, Springfield, St. Albans, and Waterbury. Since S88 is concerned with batch control, the only applicable sites were the three manufacturing plants, even though the company also had a corporate office and a distribution center. Waterbury, the oldest of the plants, packaged ice cream in only pint-sized containers. Springfield produced novelties, bulk tubs for retail "scoop shops," and ice cream in quart-sized containers. Springfield could also produce pints but was not normally scheduled to do so. St. Albans, the newest and largest plant, produced pints and 140 ml, single-serving cups. Although pints could be produced at any site, the process equipment was slightly different at each. Applying S88 26 Figure 4.1 S88.01 Physical Mode The Physical Model 27 Figure 4.2 Ben & Jerry's Enterprise and Sites Regardless of where the ice cream was made, the product had to meet the same manufacturing and quality specifications. AREA LEVEL Areas are sections of a site. Like sites, areas can be organized by various means, including by physical layout or business function. Under S88, not every section of a plant need be part of an area, especially if that section has nothing to do with batch control. Figure 4.3 shows the areas in St. Albans. There are other sections of the plant that are not part of an S88 area, including packaging, dry receiving, our ammonia engine (compressor) room, the office area, and the cafeteria. Figure 4.3 St. Albans's Areas Site Four Areas When you read the S88 standard, you'll find this wording in each of the sections describing the enterprise, site, and area levels: "There are many factors other than batch control that affect the boundaries of the [enterprise/sites/areas]. Therefore, the criteria for configuring the boundaries of a[n] [enterprise/site/area] are not Applying S88 28 covered in this standard." The S88 committee probably went to great pains in deciding how to organize and present this model, but the standard states that the top three levels are not considered beyond the initial definition. S88 is concerned with batch control, not business or political boundaries. Pay attention now, we're skipping the process cell level and moving on to the unit level. We feel that we can explain the physical model better this way. We'll come back to the process cell level in a little bit. UNIT LEVEL Batching activities are focused on something called a unit. If you have faith in S88, batching cannot occur without the existence of units. The standard defines units this way: "One or more major process activities—such as react, crystallize, and make a solution—can be conducted in a unit.... [A unit] is usually centered on a major piece of processing equipment, such as a mixing tank or reactor." In other words, batch processing occurs in units. A unit combines ingredients, performs a reaction, or otherwise adds value to your product or interim product. The S88 definition mentions a mixing tank and reactor. Units are commonly vessels like these, but don't narrow your definition of a unit to just a vessel. A unit can be an in-line mixer, like a powder liquefier. (As we'll discuss later in this chapter, we chose not to make our powder liquefier a unit, but it could have been one.) The term unit is somewhat abstract with respect to the equipment associated with it. For example, if you have a vessel that performs some major processing activity, you can think of the unit as follows: The term unit is somewhat abstract with respect to the equipment associated with it. For example, if you have a vessel that performs some major processing activity, you can think of the unit as follows: • The vessel itself • The vessel and attached instrumentation (such as level or temperature transmitters) • The vessel and other associated equipment (such as valves, agitators, or recirculating pumps) • Any combination of the above Applying the S88 concept is much easier when equipment associated with a single unit is considered part of the unit. For example, if a reactor has a dedicated agitator (no other reactor uses that agitator), it is probably best to associate the agitator with the unit. Coordinating the control of the agitator is easier when it is permanently associated with the reactor. If it is not associated with the reactor, when the reactor needs it a request must be made to the batch management system to acquire the agitator as a resource. After the reactor is finished with the agitator, the reactor must release it. So, if a dedicated unit resource is not permanently associated with the unit, a lot of unneeded overhead is involved to use it. Inlet or outlet valves and instrumentation, such as temperature transmitters, are good candidates to be included as part of a unit. It is probably The Physical Model 29 best to keep equipment not dedicated to a single unit separate or to include it as part of an equipment or control module. (We'll get to those in a minute.) A good way to spot a unit is to determine if a piece of equipment must run a recipe in order to operate. If so, it is a unit. If not, it is used by a unit. Table 4.1 shows some examples of what we consider to be units, and what we don't: Table 4-1. Unit Classification Example A Unit Not a Unit Mix-making batch tank ♦ Pasteurizer ♦ Reactor ♦ Pump ♦ Ingredient storage tank ♦ Washing machine ♦ Kitchen blender ♦ Refrigerator ♦ Dishwasher ♦ Even though we did not use OpenBatch to control the pasteurizer, we considered it to be a unit. Pasteurizers are typically three-section plate heat exchangers, and they can be large enough to hold hundreds of gallons of mix at any one time as part of a continuous process. Even so, we really didn't consider our pasteurizer to be a vessel. Whether or not you might think of a pasteurizer as a reactor, it certainly adds value to the product. After all, what real market value is there for unpasteurized ice cream? (Well, to pathologists, physicians, and lawyers there might be a lot of market value to unpasteurized ice cream.) Starting, running, and stopping a pasteurizer are no trivial tasks. Using a recipe to operate a pasteurizer is certainly valid, even though the "running" portion of the recipe is active much longer than the "starting" or "stopping" portions. Pumps aren't units by themselves; they just move things around, and you typically don't need an entire recipe to operate a pump. (As we discussed earlier, a pump can be included as part of a unit.) We don't consider storage tanks to be units either. Remember that a unit performs a major processing activity, and the last time we checked storing didn't do that. Washing machines and kitchen blenders are units; we don't think refrigerators are. While some food, like pudding, may use a refrigerator to react, a fridge is really nothing more than a storage place. We think a dishwasher is a great example of a unit since it more or less runs a recipe, and we consider cleaning dishes and silverware as adding value. (If you disagree, that's fine; but please don't invite us over for dinner.) Here are some assumptions makes about units, along with some comments from us that show how we interpreted those assumptions: • A unit frequently contains or operates on a complete batch of material—In the St. Albans mix-making area, there were two units: batch tanks or mix tanks. Each batch tank was a receptacle for mixing multiple ingredients. Both batch tanks had outlet valves, multiple inlet valves, a mixer (agitator), and appropriate instrumentation. Applying S88 30 • A unit may contain or operate on only a portion of a batch—If your batches are large, you may run several units in parallel, performing the same activities at once, or you may have two or more units in a process train, each sequentially working on a portion of a batch. At St. Albans, our two batch tanks operated in parallel, but we only made a batch in one of them at a time. This statement from the S88 standard also worked for us when we considered how we transferred mix to our single pasteurizer. From the moment the unit started transferring to the moment it was empty, the unit contained only a portion of the original batch. • A unit does not operate on more than one batch at a time—From a recordkeeping point of view, this made sense. It's hard to track batches or lots if you combine two or more of them into one unit. Defining your units, as with many S88 issues, really depends on your interpretation of the standard. The three guidelines just outlined are based on what we think of units, but you may wish to expand your own definition. However, the number of units generally translates into the number of items that need to be communicated between your batch management system and your PLCs or DCS. (These communication "items" are often referred to as "tags.") Pricing for S88 software, like OpenBatch, is based on the number of tags needed. If you get unit-happy in your design, it'll probably cost you. A word of caution though: don't scrimp on units just to save some bucks on software. The nonmodular design that could result from your money-saving efforts could cost you much more in the long run. PROCESS CELL LEVEL A process cell contains all of the equipment, including units, required to make batches. Sometimes the term train is used to describe the units and all other equipment used to make a batch. A process cell may have more than one train, and the order of equipment used to make a particular batch is called a path. Here are some points to remember about trains: • A batch need not use all the equipment in a train—Different products may require different sets of equipment, or different equipment may have different capacities. For example, one path through a train may require units 1 and 2 because they only hold 1,000 gallons each, while another path through the same train requires only unit 3, as it holds 2,000 gallons. • A train may be processing more than one batch at a time—However, remember that S88 assumes that units only work on a single batch at a time. • A train cannot cross a process cell boundary—A process cell is responsible for taking ingredients (raw or work-in-process [WIP]) and transforming them into finished products or WIP products. Figure 4.4 shows the process cells in the St. Albans mix-making area. The Physical Model 31 Figure 4.4 St. Albans's Mix-Making Process Cells Site Areas Process Cells Deciding upon process cells really depends on how your process works. If you want to effectively manage the making of your batches, all of the resources needed to make batches should be within the process cell. Otherwise, a request to allocate resources will have to go outside the "domain" of the batch management system to some "foreign" system, complicating your operations. You can use your definitions of finished or work-in-process (WIP) products to help establish your process cell boundaries. Both the St. Albans units, the two batch tanks, fed a single pasteurizer (and related equipment such as the homogenizer), so it made sense to us to define our HTST pasteurizing process as a separate cell. Trains within process cells can have three different structures: single-path, multiple-path, and network-path. Figures 4.5, 4.6, and 4.7, respectively, illustrate these. Note that our mix-making system in St. Albans used a multiple-path structure. Figure 4.5 Single-Path Process Cell Structure Applying S88 32 Figure 4.6 Multiple-Path Process Cell Structure Figure 4.7 Network-Path Process Cell Structure The Physical Model 33 CONTROL MODULE LEVEL Time to pay attention, again. We just skipped the equipment module level to help explain the physical model. We'll get to equipment modules in the next section. Control modules are the most basic element of the physical model. The S88 standard defines a control module as "typically a collection of sensors, actuators, other control modules, and associated process equipment that, from the point of view of control, is operated as a single entity." So, from a control standpoint a control module is treated as a single entity. Each control module provides a direct "connection" to the process through actuators and sensors. For example, let's say you want to control the rate of flow of some liquid. You use a pump driven by a variable-speed motor and a flowmeter. A proportional-integral-derivative (PID) controller reads the flow rate and sets the pump speed appropriately. The batch control system wants only to control the flow rate and considers the combination pump, flowmeter, and PID loop as a single control module. Keep in mind that even though the control module exists in the physical model, not all elements need be physical. In our example, the PID controller can be a PLC instruction or DCS object and not a stand-alone device that physically links the flowmeter to the pump. Another example of a control module may be a group of valves on a header that direct flow to one of many destinations based on input to some control function. Again, the control function may exist in a DCS or PLC. The same control module can be used by different functions, such as charging different ingredients, or in the production or clean-in-place (CIP) modes. In the simplest form, control modules can just be device drivers, but they can do so much more for you. Control modules should provide a robust method of device control, including these functions: • Automatic and manual modes—Automatic mode means PLC or DCS logic or some stand-alone function controls the device. Manual mode implies that the device is controlled directly by an operator. • A simulation mode—This allows an operator or engineer to test software without actually manipulating equipment. • Permissives—These prevent a device from actuating if constraints or permissions are not true. For example, a tank outlet valve cannot open if the adjoining header is being cleaned in place. • Alarms—These provide feedback on a device's operation. For example, an alarm is set if a valve is commanded open, but a limit switch does not confirm that it has opened. For example, PLC or DCS logic may command a valve to open via a control module, but if a simulation bit is set the valve will be prevented from opening from within that same control module. Limit switches attached to the valve may provide feedback to the control module for "hard" alarms, while the use of permissives allows for "soft" alarms. Figure 4.8 shows one possible design for a control module. We consider two issues to be especially important with regard to control modules. First, instrumentation can serve more than one control module. For example, one flowmeter can be used by a control module that charges water into a batch tank and another control module that charges cream. Second, a piece of equipment is controlled by one (and only one) control module. There may be several logical events that trigger the control module to manipulate the equipment. For example, a pump can be started by production logic or by CIP logic. The Auto Command Enable bits in Figure 4.8 show this. (Some control engineers may wish to implement a control module by latching or unlatching the Auto Command bit directly, without using the enable bits.) Applying S88 34 Figure 4.8 A Sample Control Module EQUIPMENT MODULE LEVEL The S88.01 standard defines an equipment module as "a functional group of equipment that can carry out a finite number of specific minor processing activities." In other words, equipment modules group physical devices for performing one or more specific functions. An equipment module may be made up of control modules or other equipment modules. S88 implies that equipment modules can include decision-based logic. We agree, but at Ben & Jerry's we kept it very simple. For example, St. Albans incorporated cocoa in batches through a powder liquefier that mixed the cocoa with a liquid ingredient passing through it. If the liquid flow rate fell below a certain limit, the cocoa might plug the powder liquefier. If this happened, the operator had to hold or stop the batch and physically clean the liquefier, a time-consuming and costly process. Therefore, the PLC logic had to constantly check for the proper flow rate and close the cocoa valve if the rate was too low. An equipment module can also work with other forms of instrumentation. Plants often have several storage tanks for the same ingredient. Sometimes, each tank has its own transfer line, pump, and flowmeters. Because each holds the same ingredient, you can choose to write a single set of PLC logic instructions and use an equipment module TOxontrol the correct devices. Not only can you control valves and monitor low-level switches as described earlier, but you can also copy the different flowmeter totalizer values into a common register based on the raw material tank being used to supply the ingredient. This way, the PLC logic need only look at the common register to see if the targeted amount of sweetener has been transferred. Different units can share equipment modules. This makes sense if you have ingredient storage tanks that share a common transfer line. If an equipment module can be active only with one unit at a time, it is called an exclusive-use resource. If it can be active with several units simultaneously, it is called a shared- use resource. Certainly, the converse is true also: there can be equipment modules used exclusively by a single unit. The Physical Model 35 Equipment modules can be permanently "included" as part of a larger grouping, such as a unit or another equipment module. They can be temporarily "attached" as part of a larger grouping, or they can stand alone. If operated stand-alone, an equipment module may be used by only one unit at a time (exclusive use) or by many units simultaneously (shared use). The same is true of control modules. They can be permanently or temporarily part of other control modules, equipment modules, or units. Any temporary attachments are formed when a batch is run. For instance, the process cell might have an ingredient recirculation loop that is common to both batch tanks. The recirc loop can be active while a recipe is running, or the operators can run it "manually" as a stand-alone function. Since the plant only wants to "recirc" the contents of one unit at a time (the operators wouldn't want to mix the contents of two batch tanks), the recirc loop equipment module is an exclusive-use resource. You may be asking a pretty big question right now: "Why couldn't the logic of equipment modules be placed in control modules"? That's a great question, and in some cases control modules can replace equipment modules. Control modules are subordinate to equipment modules only by virtue of the fact that equipment modules trigger actions that cause control modules to physically manipulate equipment. However, if equipment modules aren't needed, why add another level of complexity? There is one big difference between control modules and equipment modules, and it has to do with the type of software logic S88 says they're allowed to run. If you can wait, we're going to answer these questions in Chapter 5. DESIGNING THE PHYSICAL MODEL Designing the physical model isn't that hard. If you are designing a "green field" site or adding new area or process cell to an existing site, you have the luxury of purchasing and locating equipment according to your S88 plans. If you are applying S88 to an existing process, as we did, you may have to think a little differently. Fortunately for us, applying S88 wasn't too difficult. We're assuming that it won't be much different for others retrofitting S88. This is due to the robustness of the standard and the foresight of the committee members. We're going to start from the top. Let's consider the enterprise level as a given. It's your company, business unit, or division. The site level probably is fairly easy also. Just work from a geographical or four-wall approach when defining your sites. If a site essentially manufactures one product, or one type of product, determining areas within it probably isn't too difficult. Look at your plant layouts and your process and instrumentation drawings (P&IDs) to understand issues like material flow. Figure 4.3 shows the areas in our plant that are associated with process manufacturing. If a site manufactures several types of products, plant layouts and material flows can still define boundaries. However, you may have to look at the operation from a business perspective and see what equipment or site functions each product or business unit "owns." Process cells take shape when you further break down the process required to make your products. Consider how you run your site business and keep looking at your P&IDs to help you determine your process cell boundaries. Remember that batches utilize one or more units in a train. A process cell can contain more than one train, but according to S88 a train is not allowed to cross process cell boundaries. Use this fact as an easy test to see if you've defined your process cells too narrowly. S88-aware software, following the standard, starts considering the physical model at the process cell level. Some S88 software packages refer to an "Area Model" because it is the level that encompasses process cells.