Manipal University

Manipal Universal Learning Pvt. Ltd.,

Term Paper Review Form

Termpaper1 / Termpaper2 - Master of Science CS / ESD / AES / DDES / VLSICAD / ME / MSD Batch:
INSTRUMENTATION ENGINEERING

Centre:

JAIN COLLEGE, BANGALORE

Student RegNo:

122539010

Paper Title :

S88 BATCH PROJECT

TO BE FILLED BY UNIVERSITY EXAMINERS

Comments:

S88 BATCH PROJECT CONTENTS

NITHIN VARGHESE NINAN

1. Abstract2 2. Functional Specification...2 3. Understanding S88.......3 4. Physical model..4 5. Procedural model..................................4 6. States and commands........................4 7. Apply S88 to the process........ .5 8. Class based requirements .........................7 9. Other considerations..................9 10. Conclusion................................10 11. References.................................10

Page 1

S88 BATCH PROJECT

NITHIN VARGHESE NINAN

S88 BATCH PROJECT ABSTRACT S88, a standard addressing batch control, is well known in the process-automation world. S88 is shorthand for ISA-S88.01-1995. It is a design philosophy for software, equipment, and procedures. S88 provides a consistent set of standards and terminology for batch control. Typically, following S88 on a project means: Defining the physical model Defining the procedures and recipes The first step of a process-automation project is to define the requirements. Typically, the main deliverable of this effort is a functional specification. In regulated industries (such as pharmaceutical), a written and approved functional specification is required for computer system validation. In other industries, it may not be required for regulatory compliance, but the same requirements must be defined in order to provide the development team with the information it needs to do the design and implementation of the process automation. Traditionally, the process-automation requirements that are documented in the functional specification flow from the process design. Process engineers, who define the process sequences and critical control parameters for each unit, hand over their information to automation engineers; however, the process engineers are typically not as familiar with the S88 concepts as are the automation engineers. As a result, the functional-specification effort is usually the first time that the process requirements are translated to S88 batch-process-control requirements. Further complicating matters, many manufacturing facilities these days must produce multiple products in varying quantities. The requirements for flexibility and quick time-to-market have become important business drivers in many industries. Process automation and flexiblebatch control can enable a manufacturer to quickly produce a new product in customer-required quantities. However, the modularity and flexibility should be designed in from the beginning. The S88 standard provides a framework for addressing these needs in the design and implementation of a process-automation project. Using the S88 standard for an automation project can provide many benefits, including these: The standard terminology facilitates clear communications between automation, quality control, manufacturing and management The S88 standard facilitates objectoriented, class-based designs. Classbased equipment and procedures can save time and money because the software is reusable. Modular design allows for easier reconfiguration and redeployment of the facility This article focuses on industry accepted definitions of functional specification, S88 terminology and models; a methodology for using S88 to specify automation requirements; and a proposed structure for the functional specification.

FUNCTIONAL SPECIFICATION A functional specification defines what the system should do, and what functions and facilities are to be provided. It provides a list of design objectives for the system. The GAMP (good automation

Page 2

S88 BATCH PROJECT

NITHIN VARGHESE NINAN

manufacturing practice) life cycle for computer- system development is shown in Figure 1. According to GAMP, the functional specification is based on a user-requirement specification, which identifies the system requirements with regard to data, interfaces, environment and constraints. The functional specification defines the process-automation requirements and becomes the basis for the design specifications. System-acceptance testing confirms that the requirements in the functional specification are met.

From a development teams perspective, the functional specification is the basis for design. It defines what the system will do, but does not say how to do it. Usually it becomes a contractual document defining the scope of a project. Inputs to the functional specification include the process description, piping and instrumentation diagrams (P&IDs), process-flow diagrams (PFDs), and an instrument list. Failure to develop a comprehensive functional specification can make project-scope management difficult, can cause the project to exceed the budgeted hours and can potentially lead to unsafe processautomation implementation. Using S88 and the ideas that follow can help ensure the creation of useful and accurate project specifications. UNDERSTANDING S88 The S88 standard was approved by ISA in 1995 and provides models and terminology that an engineer can use to specify automation requirements in a modular fashion. This section attempts to introduce the S88 models and terminology that is most relevant to functional specification development. Further S88 information can be found in the S88 specification itself. Additionally, there are several published texts that provide detailed discussions on the S88 models and their real-life implementation.

Page 3

S88 BATCH PROJECT

NITHIN VARGHESE NINAN

PHYSICAL MODEL The physical model defines the hierarchy of equipment used in the batch process, as shown in Figure 2. This model provides a means to organize and define the equipment used to control the process. The levels are briefly defined as: Enterprise defines the company that owns the facility (plant). Site defines the location of the facility. These first two levels provide a link to business systems, regulatory compliance requirements and, possibly, engineering standards that must be considered as part of the functional-specification development. S88 does not address the batch control boundaries for these levels. Area defines a specific section of the Site, such as a building name. The Area may contain one or many Process Cells. S88 does not address the batchcontrol boundaries for this level. Process Cell contains all of the production and supporting equipment (Units, Equipment Modules, and Control Modules) necessary to make a batch of product. Unit is a major piece of equipment that performs a specific task within the batch process. A Unit consists of Equipment Modules and Control Modules. Equipment Module is a group of equipment that can carry out minor processing activities. It can be subordinate to a Unit, or it can stand alone. Typically, an Equipment Module consists of Control Modules and does not directly interface to plant I/O. Control Module is a single entity that performs state-oriented or regulatory control. It can be subordinate to a Unit or an Equipment Module or it can stand alone. A Control Module typically interfaces directly to plant I/O.

PROCEDURAL MODEL The procedural model defines the control that enables the equipment in the physical model to perform a process task. This is shown graphically in Figure 3, with definitions following below. Procedure is the sequence of Unit Procedures required to make a batch. It orchestrates the control of the equipment in the Process Cell. Unit Procedure is a sequence of Operations. It controls the function of a single Unit. A Unit may have more than one Unit Procedure, but only one Unit Procedure may control the Unit at a time. Operation is a sequence of Phases. Typically, an operation controls a portion of the Unit function. A Unit Phase performs a unique or independent process function on a Unit. It coordinates the control of Equipment Modules and Control Modules. An Equipment Phase performs a simple process function on an Equipment Module. It coordinates the control of Control Modules.

STATES AND COMMANDS S88 provides a convenient matrix of states and commands for the elements in the procedural model. Procedural states can either be transient or quiescent. Transient states typically contain a sequence of actions that must be completed in order to proceed to a corresponding quiescent state (for example, Running and Complete.) Procedural commands cause the state of the procedural element to change (for example, Start and Stop.) An operator or another procedural element can issue these commands. Figure 4 diagrams a control-system vendors interpretation of the S88 procedural state and command matrix. The procedural states can be defined as follows:

Page 4

S88 BATCH PROJECT

NITHIN VARGHESE NINAN

Idle: Waits for a Start command to transition to Running. Running: Begins when the Start command is received. Normal operation actions are executed. Complete: The Running State has completed. Waits for a Reset command to transition to Idle. Pausing: A Pause command was received in the Running State. The Running State logic progresses to the next defined pause point. At the pause point the state transitions to Paused. Paused: (Not pictured.) Used for short-term stops to the procedural element. The state returns to Running once the Resume command is issued. The Running State logic continues from the pause point. Holding: Equipment is placed in a safe state. The Running State is disrupted and placed in Holding when an exception to normal operation is detected or the operator issues the Hold command. Held: Holding State has completed. No actions are taken. At this point, the operator or a batch recipe can issue a Hold, Restart, Stop or Abort command. Restarting: The Restart command has been issued by the operator when the state is Held. Takes action to return equipment to normal operation. Once Restarting finishes, it transitions to the Running State. Stopping: Equipment is placed in a safe state. The current state is disrupted when the operator issues the Stop command. Stopped: Stopping State has completed. At this point, the recipe cannot be restarted. Aborting: Equipment is placed in a safe state. The current state is disrupted when the operator issues the Abort command. Aborted: Aborting State has completed. At this point, the recipe cannot be restarted APPLY S88 TO THE PROCESS The first step is to break down process-automation requirements into modules following the S88 standard. Use the S88 models to begin to modularize the physical elements and their corresponding procedural requirements at a conceptual level. Typically, this exercise starts by using P&IDs and process descriptions. The goal is to identify and organize the modules according to their automation requirements. It is not critical at this stage to define details. Some guidelines for this exercise are: Mark up the P&IDs to define the boundaries of the modules. If necessary, create separate drawings to simplify module boundaries Focus on the function of the module. Does the module boundary drawn include the appropriate equipment to carry-out the function? Can the module act independent of others? When identifying the function and the boundary of a module, ensure that the module can handle exceptions to its own normal operation Identify how the module interacts with other modules. Does the module belong to a unit? Or, can it be shared by multiple units, as might be the case with a supply header? Identify what information the module must pass to other modules Begin to establish classes of modules. Do other modules perform the same or similar function? This is probably the single most important task when trying to achieve reuse or flexibility of automation requirements Organize the modules into a hierarchy that defines their relationship to each other. This is a top-down exercise that follows the S88 Physical Model and Procedural Model Example makes things clearer For example, you might modularize control of a buffer-preparation vessel (Figure 5) as follows: 1. Define the unit boundary. In this case, we will draw the unit boundary (the blue boundary in Figure 5) around the entire buffer prep vessel upstream to the water (WFI) and cleaning solution (CIPS) inlet

Page 5

S88 BATCH PROJECT

NITHIN VARGHESE NINAN

valves and downstream to the valve that allows transfer from the inline mixertransfer pump to the next vessel. This unit performs the task of making buffer for use in other plant areas. 2. Define the control modules. The authors prefer to define the control modules, or entities that perform state-oriented or regulatory control, before defining the equipment modules. For the buffer prep vessel, the control modules include the individual valves, the mixer motor, the agitator motor, and the analog indicators. These are circled in green in Figure 5. 3. Define the equipment modules. For the buffer prep vessel, the equipment modules, or modules that work together to perform a minor function, might include the following, shown in Figure 6: Charge equipment module: The boundary is drawn to include discrete valves used to charge the vessel with either water (WFI) or cleaning solution (CIPS). Only one valve can be opened at any given time. Pressure-control equipment module: The boundary includes pressure indicator, control valve, and

FIGURE 5. For this buffer-preparation vessel, the unit boundary is shown in blue. The control modules are circled in green FIGURE 6. The equipment modules for the buffer prep vessel are defined here discrete valves used to control the pressure of the vessel. Discharge equipment module: The boundary includes the in-line mixer transfer pump and discrete valves used to either recirculate back to the vessel for mixing or to transfer to a downstream vessel. Temperature-control equipment module: The boundary includes the temperature indicator and valves used to control vessel temperature. Typically, identifying modules and organizing them is an iterative cycle. Dont worry too much about the first pass. Just get started and reconsider everything after you have a first draft. Once you have a draft, it is time to collect further details and refine the contents. Now is the time to make sure all of the involved people sign off on the proposed model. This functional-

Page 6

S88 BATCH PROJECT

NITHIN VARGHESE NINAN

specification effort will be most successful if its authors involve all of the stakeholders, including people in automation, process engineering, production and quality. The document should be written so that all of these disciplines can understand it; and all of the stakeholders should agree to the level of detail and content of the document. This approach may also allow it to serve as a training tool for new plant engineers, chemists, operations personnel, and other plant personnel. When you get these people involved, include the following considerations: 1. What is the operating philosophy at the plant? To what extent will automation be required? You will need to know what will be considered a batch in order to define the process cell and the philosophy for running equipment in order to define the units. 2. Consider how production wants to operate the facility. Consider procedures that may run as part of normal operation, for maintenance, or for other reasons when drawing phase, operation, unit procedure and procedure boundaries. 3. Where functionality is similar but not identical, consult with production and process engineering. Possibly, the requirements could be modified to allow you to use a class based approach, as described in the following section. 4. Identify recipe parameters, which will be passed down from the recipe, and unit parameters, which are fixed for the unit. Generally, parameters that change based on the product or the formula are recipe parameters (for example, reaction time), whereas parameters that are based on the physical characteristics of the equipment are unit parameters (for example, drain time). 5. Identify opportunities to push control as far down the hierarchy as possible. For example, define agitator control as an equipment module rather than as a phase at the unit level. In general, this is a good practice because it provides modular control, streamlines the unit phase, and increases the chance of reuse. Once this exercise is complete, it is time to formally define the requirements and structure the functional specification. This leads to the question of how to specify these automation requirements. The following section shows how to take the concepts discussed in this section and capture them in a functional specification that fully defines the automation requirements.

CLASS BASED REQUIREMENTS A functional specification that uses the S88 model is beneficial because it uses standard terminology and concepts. However, the principal benefit is typically the streamlined design, implementation, and testing effort that comes from using a class-based approach to defining the automation requirements. The S88 standard does not address the concept of class-based control. However, class-based control is a logical extension of S88 and is one obvious way to simplify the functional specification (In other words, dont write the same functionality more than once). In a purely unit-based functional specification, there is not much consideration given to standardizing functionality. Consider a fermentation suite that has four production-class fermenters. Each fermenter has identical equipment and performs standard functions, such as pressure testing, clean-in-place (CIP), and sterilizein-place (SIP). A unit-based functional specification would define each of the four units and three phases on each unit, possibly repeating the same or similar information. This approach allows unintentional deviations from one unit to another. But it may also raise the potential for long-term problems. For instance, process engineering or maintenance could specify a change for one of the four units without considering the others. But if the units were instead part of the same class, the class-based design would force the engineers to consider the impact on the other units. As an example, consider the

Page 7

S88 BATCH PROJECT

NITHIN VARGHESE NINAN

bufferpreparation vessel discussed above. You might define class-based control for this buffer prep vessel as follows:

FIGURE 7. Shown here are three different phase classes for the pressure-control equipment module of the buffer-preparation-vessel example. These are clean the equipment (A), vent the vessel to atmosphere (B), and control the vessel pressure (C) 1. Group the control modules into classes. Control-module classes might include analog input, discrete input, discrete valve, PID loop, and motor. 2. Group the equipment modules into classes. For the buffer prep vessel, the equipment modules classes become: Charge equipment module Pressure-control equipment module Discharge equipment module Temperature-control equipment module

Page 8

S88 BATCH PROJECT

NITHIN VARGHESE NINAN

3. Identify phase classes for the equipment-module classes. Based on the process description, the pressure- control equipment module may have the following phase classes: CIP: clean the equipment (Figure 7A) Vent: Vent the vessel to atmosphere (Figure 7B) Pressurize: Control the vessel pressure (Figure 7C) 4. Group the units into classes. In our example plant, we have three buffer prep vessels that are identical. Therefore, we will create a unit class called Buffer Prep Vessel with three instances: Buffer Prep Tank 101, Buffer Prep Tank 102, and Buffer Prep Tank 103. 5. Identify phase classes for the unit classes. Based on the process description, the Buffer Prep Unit Class may have the following phases: CIP: Clean the vessel Charge WFI: Charge a specified amount of purified water to the vessel Add Raw Material: manually add a specified amount of raw material to the vessel Transfer Buffer: Transfer the contents of the vessel to another vessel Note that this class-based approach allows three units to be reduced to one unit class, twelve equipment modules to be reduced into four equipment module classes, and many control modules to be reduced into a few control module classes. Also, instead of twelve phase definitions (four phases times three units), only four phase classes need to be defined. The modular approach forces the writer to evaluate deviations among the three units to determine if inconsistencies exist. It may also reduce design, implementation, and testing time. But keep in mind that forcing items that are not truly similar into a class may cause more headaches than good. Items forced into a class will often diverge as the project moves forward, creating delays and costs. In a classbased analysis, as with everything else, you must weigh the advantages versus the disadvantages. OTHER CONSIDERATIONS Exception handling The S88 standard defines exception handling as those functions that deal with plant or process contingencies and other events which occur outside the normal or desired behavior of batch control. In addition, S88 provides models, such as the procedural state matrix, and terminology that provide the fundamentals to address exception handling. However, the specific details of identifying the exceptions and determining the appropriate reaction are left to those specifying the automation requirements. There are several considerations that must be made when specifying exception- handling requirements. First, exception handling must be considered as an integral part of the automation requirements. It cannot be left as an afterthought. One will find that a significant part of the specification development will be spent on this activity. If this activity is not adequately addressed, plant equipment and product integrity may be jeopardized. Second, an exception and its corresponding reaction must be considered as a pair. The reaction to an exception should fit the severity of the exception. In some cases, an alarm sent to the operator is sufficient. Other exceptions may require that a batch be aborted. Additionally, the reaction may change relative to the current step of the process. A high-temperature alarm that occurs while the process is ramping- up may not require the same reaction as when the process is stable. Third, for Phase logic, consider not only how to react to an exception but also how to recover from that exception. For some exceptions, recovery may be as simple as taking an alternate action in the Running logic. However, other exceptions may be more severe and their recovery complicated. The most complicated recovery is from exceptions that require the Phase to go to a safe state such as Holding. This type of recovery can be labor intensive because one must logically coordinate the actions of the

Page 9

S88 BATCH PROJECT

NITHIN VARGHESE NINAN

Running, Holding, and Restarting states. Take, as an example, a Unit Phase that charges material to a vessel. The Running logic can be divided into three major tasks: 1) open vessel inlet, 2) wait for charged quantity to reach target, and 3) close vessel inlet. One must consider exceptions relative to these tasks before recovery can be specified. Recovery from an exception during the wait for charged quantity task is different than recovery from the close vessel inlet task. For the former, the charge is incomplete so recovery involves completing the charge. For the latter, the charge has already completed so recovery involves ensuring that no additional charge is executed CONCLUSIONS Developing the requirements for batch process automation can be a very complicated task. Using the S88 model for batch control provides a common structure and terminology from which to start. Generally, you take a stepwise approach to identifying and organizing the modules and defining the procedural requirements. Usually several iterations are required before you arrive at a model with which you are happy. In addition to the common structure and terminology, S88 facilitates classbased definition of the batch control. By using the class-based approach, you can Minimize documentation by defining requirements only once for the entire class Improve consistency Reduce the design, implementation, and testing efforts by streamlining many instances into one class A functional specification defines the batch automation requirements. Some factors that help ensure the accuracy and the usefulness of the functional specification include 1. Getting automation or other S88-knowledgeable people involved early in process design in order to facilitate modular process design, which will enable more modular automation. 2. Involving all of the different stakeholders of including automation, process engineering, production, and quality in the Functional Specification effort in order to understand the operating philosophy and to get buy-in on the content. 3. Organizing the documents so that they are a manageable number and size for the project. Avoid oversized documents and excessive numbers of documents. 4. Identifying exception handing Investing time and effort into the functional specification will help to streamline the design, implementation and testing efforts and will minimize changes due to early misunderstandings between stakeholders as the project moves forward into startup.

REFERENCES 1. GAMP Guide for Validation of Automated Systems in Pharmaceutical Manufacture. V4.0, Good Automated Manufacturing Practice Forum, 2001.

Page 10