S88 BATCH PROJECT TERMPAPER

7/31/2019 S88 BATCH PROJECT TERMPAPER

1/11


2/11


3/11

S88 BATCH PROJECT NITHIN VARGHESE NINAN

Page 2

S88 BATCH PROJECT

ABSTRACT

S88, a standard addressing batch control, is well known in the process-automation world. S88 isshorthand for ISA-S88.01-1995. It is a design philosophy for software, equipment, and procedures. S88provides 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 recipesThe 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 otherindustries, 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 aredocumented 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 conceptsas 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 invarying 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 ofa 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 procedurescan 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 andmodels; 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


4/11


Page 3

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 functionalspecification 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 managementdifficult, can cause the project to exceed the budgeted hours and can potentially lead to unsafe process-

automation implementation. Using S88 and the ideas that follow can help ensure the creation of usefuland accurate project specifications.

UNDERSTANDING S88The 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 S88information 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.


5/11


Page 4

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. Thelevels 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 Cellcontains all of the production and supporting equipment (Units, Equipment Modules, andControl 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 ControlModules and does not directly interface to plant I/O.

Control Module is a single entity that performs state-oriented or regulatory control. It can besubordinate 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 aprocess 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 Phaseperforms a unique or independent process function on a Unit. It coordinates the control ofEquipment Modules and Control Modules.

AnEquipment Phaseperforms a simple process function on an Equipment Module. It coordinates the

control of Control Modules.

STATES AND COMMANDSS88 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:


6/11


Page 5

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 toRunning 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 actionto 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 theAbort 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 S88standard. 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 automationrequirements. 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 clearerFor 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


7/11


Page 6

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 performstate-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

discretevalves used to control the pressure ofthe 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 valvesused tocontrol vessel temperature.Typically, identifying modules andorganizing them is an iterative

cycle.Dont worry too much about the firstpass. Just get started and reconsidereverything after you

have a first draft.Once you have a draft, it is time tocollect further details and refine thecontents. Nowis the time to make sureall of the involved people sign off on theproposed model. This functional-


8/11


Page 7

specificationeffort will be most successful ifits authors involve all of the stakeholders,including people

in automation,process engineering, production andquality. The document should be writtenso that all

of these disciplines canunderstand it; and all of the stakeholdersshould agree to the level of detailandcontent 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 willautomation be required? You willneed to know what will be considereda batch in

order to define the processcell and the philosophy for runningequipment 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 procedureboundaries.

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 recipeparameters (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 agitatorcontrol as an equipment modulerather than as a phase at the unitlevel. In

general, this is a good practicebecause it provides modular control, streamlines the unit phase, andincreases 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 sectionshows how to take the concepts discussedin thissection and capture themin a functional specification that fullydefines the automation requirements.

CLASS BASED REQUIREMENTSA 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 S88standard 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 isnot 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 sterilize-in-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. Forinstance, 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


9/11


Page 8

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 mightinclude 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


10/11


Page 9

3. Identify phase classes for the equipment-module classes. Based on the process description, the

pressure-control equipment module mayhave 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 areidentical. 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 UnitClassmay 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 equipmentmodules 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 threeunits), 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 mustweigh the advantages versus the disadvantages.

OTHER CONSIDERATIONS

Exception handlingThe 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. Inaddition, 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 productintegrity 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, thereaction 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 thatexception. 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


11/11


Page 10

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 tasksbefore 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 recoveryinvolves ensuring that no additional charge is executed

CONCLUSIONSDeveloping 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 theprocedural 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 theaccuracy 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 tostreamline 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.

S88 BATCH PROJECT TERMPAPER

Documents

Transcript of S88 BATCH PROJECT TERMPAPER