www.che.

com
August
2003
www.che.com
A Chemical Week Associates Publication
August
2003
BATCH AUTOMATION:
Make S88
Work For You
BATCH AUTOMATION:
Make S88
Work For You
S
88
*
, a standard addressing
batch control, is well known in
the process-automation world.
It is a design philosophy for
software, equipment, and pro-
cedures. 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-automa-
tion project is to define the require-
ments. Typically, the main deliverable
of this effort is a functional specifica-
tion. In regulated industries (such as
pharmaceutical), a written and ap-
proved functional specification is re-
quired for computer system valida-
tion. In other industries, it may not be
required for regulatory compliance,
but the same requirements must be
defined in order to provide the devel-
opment team with the information it
needs to do the design and implemen-
tation of the process automation.
Traditionally, the process-automa-
tion 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 au-
tomation 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 (see Multiproduct
Plant Design, CE, July, pp. 4249). The
requirements for flexibility and quick
time-to-market have become important
business drivers in many industries.
Process automation and flexible-
batch control can enable a manufac-
turer to quickly produce a new product
in customer-required quantities. How-
ever, the modularity and flexibility
should be designed in from the begin-
ning. 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 au-
tomation project can provide many
benefits, including these:
The standard terminology facili-
tates clear communications between
automation, quality control, manu-
facturing and management
The S88 standard facilitates object-
oriented, class-based designs. Class-
based equipment and procedures
can save time and money because
the software is reusable. This will be
discussed in more detail later
Modular design allows for easier re-
configuration and redeployment of
the facility
This article focuses on industry ac-
cepted definitions of functional spec-
ification, S88 terminology and mod-
els; a methodology for using S88 to
specify automation requirements;
and a proposed structure for the
functional specification. In addition,
some common challenges that the
authors have encountered are ad-
dressed. Tips learned from success-
fully creating functional specifica-
tions are also provided.
Functional specification
A functional specification defines
what the system should do, and what
functions and facilities are to be pro-
vided. It provides a list of design ob-
jectives for the system [1].
The GAMP (good automation manu-
facturing practice) life cycle for com-
puter-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, envi-
ronment and constraints. The func-
tional specification defines the
process-automation requirements and
becomes the basis for the design spec-
ifications. System-acceptance testing
confirms that the requirements in the
functional specification are met.
From a development teams per-
spective, 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 con-
tractual document defining the scope
of a project. Inputs to the functional
specification include the process de-
scription, piping and instrumentation
diagrams (P&IDs), process-flow dia-
grams (PFDs), and an instrument list.
Cover Story
Writing a Functional
Specification for an
S88 Batch Project
Define the requirements first, or youll pay for it later
Christie Deitz, Todd Ham and Steve Murray
Emerson Process Management
*S88 is shorthand for ISA-S88.01-1995. For
more information on S88, see CE March 2000,
pp. 6672.
Failure to develop a comprehensive
functional specification can make pro-
ject-scope management difficult, can
cause the project to exceed the bud-
geted hours and can potentially lead to
unsafe process-automation implemen-
tation. Using S88 and the ideas that fol-
low can help ensure the creation of use-
ful and accurate project specifications.
UNDERSTANDING S88
The S88 standard was approved by ISA
in 1995 and provides models and termi-
nology that an engineer can use to spec-
ify automation requirements in a mod-
ular fashion. This section attempts to
introduce the S88 models and terminol-
ogy 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.
Physical model
The physical model defines the hierar-
chy 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 con-
trol the process. The levels are briefly
defined as:
Enterprise defines the company that
owns the facility (plant).
Site defines the location of the facil-
ity. These first two levels provide a
link to business systems, regulatory
compliance requirements and, possi-
bly, engineering standards that must
be considered as part of the func-
tional-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 batch-
control boundaries for this level.
Process Cell contains all of the pro-
duction and supporting equipment
(Units, Equipment Modules, and Con-
trol 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 Equip-
ment Modules and Control Modules.
Equipment Module is a group of
equipment that can carry out minor
processing activities. It can be subor-
dinate to a Unit, or it can stand alone.
Typically, an Equipment Module con-
sists 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 typi-
cally interfaces directly to plant I/O.
Procedural model
The procedural model defines the con-
trol that enables the equipment in the
physical model to perform a process
task. This is shown graphically in Fig-
ure 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 Op-
erations. 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 por-
tion of the Unit function.
A Unit Phase performs a unique or in-
dependent 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 Equip-
ment Module. It coordinates the con-
trol 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 quies-
cent. Transient states typically con-
tain a sequence of actions that must
be completed in order to proceed to a
corresponding quiescent state (for ex-
ample, Running and Complete.)
Procedural commands cause the
state of the procedural element to
change (for example, Start and Stop.)
An operator or another procedural ele-
ment can issue these commands. Fig-
ure 4 diagrams a control-system ven-
dors interpretation of the S88
procedural state and command ma-
trix. The procedural states can be de-
fined as follows:
Idle: Waits for a Start command to
transition to Running.
Running: Begins when the Start
GAMP Life Cycle
User requirements
specification
Functional
specification
Hardware design
specification
Software design
specification
Software module
specification
System acceptance
testing OQ
Hardware
acceptance testing
Software
integration testing
Software module
testing
Code
modules
Review and test
modules
Enterprise
Equipment
module
Control
module
Site
Area
Process cell
Unit
FIGURE 1. The functional specifications are one of the first steps in
the good automation manufacturing practice (GAMP) life cycle for
developing a computer system
Procedure
Procedural
control model
Unit
procedure
Operation
Phase
Phase
Equipment
module
Process cell
Physical model
(lower 4 levels)
Unit
Unit
Unit
FIGURE 2 (left). The physical
model in an S88 project defines the
hierarchy of equipment used in the
batch process
FIGURE 3. The procedural model
defines the control that enables the
equipment in the physical model to
perform a process task
command is received. Normal opera-
tion actions are executed.
Complete: The Running State has
completed. Waits for a Reset command
to transition to Idle.
Pausing: (Not pictured.) A Pause
command was received in the Running
State. The Running State logic pro-
gresses 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 ele-
ment. 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 dis-
rupted and placed in Holding when an
exception to normal operation is de-
tected or the operator issues the Hold
command.
Held: Holding State has completed. No
actions are taken. At this point, the op-
erator 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 re-
turn equipment to normal operation.
Once Restarting finishes, it transi-
tions to the Running State.
Stopping: Equipment is placed in a
safe state. The current state is dis-
rupted when the operator issues the
Stop command.
Stopped: Stopping State has com-
pleted. At this point, the recipe cannot
be restarted.
Aborting: Equipment is placed in a
safe state. The current state is dis-
rupted when the operator issues the
Abort command.
Aborted: Aborting State has com-
pleted. 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 modu-
larize the physical elements and their
corresponding procedural require-
ments 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 require-
ments. 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 neces-
sary, 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 excep-
tions to its own normal operation
Identify how the module interacts
with other modules. Does the mod-
ule 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 mod-
ule 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 hierar-
chy that defines their relationship
to each other. This is a top-down ex-
ercise 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 valves
and downstream to the valve that al-
lows transfer from the inline mixer-
transfer 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 mod-
ules. 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 equip-
ment 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 solu-
tion (CIPS). Only one valve can be
opened at any given time.
Pressure-control equipment module:
The boundary includes pressure indi-
cator, control valve, and 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
Cover Story
Aborted
Reset
Abort
Aborting
Abort
Abort
Abort
Holding Held Restarting
Running
Complete Stopped
Stopping
Abort
Stop
Stop
Stop
Stop
Reset
Reset
Idle
Start and
not fail
Restart
and
not fail
Sequence
done
Sequence
done
Sequence
done
Fail
hold
Fail
hold
Sequence
done
Sequence
done
FIGURE 4. Here is one vendors interpretation of the S88 procedural state and
command matrix
vessel for mixing or to transfer to a
downstream vessel.
Temperature-control equipment mod-
ule: The boundary includes the tem-
perature 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-speci-
fication effort will be most successful if
its authors involve all of the stakehold-
ers, including people in automation,
process engineering, production and
quality. The document should be writ-
ten so that all of these disciplines can
understand it; and all of the stakehold-
ers should agree to the level of detail
and content of the document. This ap-
proach 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 philoso-
phy 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 pro-
cedures that may run as part of nor-
mal operation, for maintenance, or for
other reasons when drawing phase,
operation, unit procedure and proce-
dure boundaries.
3. Where functionality is similar
but not identical, consult with pro-
duction and process engineering.
Possibly, the requirements could be
modified to allow you to use a class-
based approach, as described in the fol-
lowing section.
4. Identify recipe parameters,
which will be passed down from the
recipe, and unit parameters, which
are fixed for the unit. Generally, pa-
rameters that change based on the
product or the formula are recipe para-
meters (for example, reaction time),
whereas parameters that are based on
the physical characteristics of the
equipment are unit parameters (for ex-
ample, drain time).
5. Identify opportunities to push
control as far down the hierarchy
as possible. For example, define agi-
tator control as an equipment module
rather than as a phase at the unit
level. In general, this is a good prac-
tice because it provides modular con-
trol, streamlines the unit phase, and
increases the chance of reuse.
Once this exercise is complete, it is
time to formally define the require-
ments and structure the functional
specification. This leads to the question
of how to specify these automation re-
quirements. The following section
shows how to take the concepts dis-
cussed 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 typi-
cally the streamlined design, implemen-
tation, 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. How-
ever, class-based control is a logical ex-
tension of S88 and is one obvious way to
simplify the functional specification (In
other words, dont write the same func-
tionality 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 equip-
Buffer prep
tank 101
Vent
PT-101
LI-101
TT-101
TIC-101
Drain
Air
CWR
CWS
In-line
mixer-
transfer
pump
CIPS
WFI
Filter
PIC-101
Unit
boundary
Hold tank
WFI = Water for injection
CIPS = Clean-in-place supply
PIC = Pressure indication and control
PT = Pressure transmitter
TT = Temperature transmitter
TIC = Temperature indication and control
CWR = Chilled water return
CWS = Chilled water supply
LI = Level indication
KEY:
Charge equipment module Pressure control equipment module
Temperature control
equipment module
Buffer prep
tank 101
Vent
PT-101
LI-101
TT-101
TIC-101
Drain
Air
CWR
CWS
In-line
mixer-
transfer
pump
CIPS
WFI
Filter
PIC-101
Discharge equipment
module
Hold tank
WFI = Water for injection
CIPS = Clean-in-place supply
PIC = Pressure indication and control
PT = Pressure transmitter
TT = Temperature transmitter
TIC = Temperature indication and control
CWR = Chilled water return
CWS = Chilled water supply
LI = Level indication
KEY:
FIGURE 5. For this buffer-preparation vessel, the unit bound-
ary is shown in blue. The control modules are circled in green
FIGURE 6. The equipment modules for the buffer prep ves-
sel are defined here
ment 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 re-
peating the same or similar informa-
tion. This approach allows uninten-
tional deviations from one unit to
another. But it may also raise the po-
tential for long-term problems. For in-
stance, process engineering or mainte-
nance 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 con-
sider the impact on the other units.
As an example, consider the buffer-
preparation vessel discussed above.
You might define class-based control
for this buffer prep vessel as follows:
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
3. Identify phase classes for the
equipment-module classes. Based
on the process description, the pres-
sure-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 pres-
sure (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 de-
scription, 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 con-
tents 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 con-
trol 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 inconsis-
tencies 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 di-
verge as the project moves forward,
creating delays and costs. In a class-
based analysis, as with everything else,
you must weigh the advantages versus
the disadvantages.
Organizing the specifications
The writer of the functional specifica-
tion will need to decide where to draw
the boundary between functional-
specification documents. The two ex-
tremes are
1. One functional-specification docu-
ment for the entire facility.
2. Smaller functional-specification doc-
uments for each individual module.
The benefits of the single functional-
specification document for the entire
facility are that it provides one source
of reference and a big picture of how
the facility works and that it can be
more convenient for approvals and
maintenance. A benefit of smaller doc-
uments is that they are more manage-
able. The advantages and disadvan-
tages for dividing up the documents
must be weighed for each project. For a
small project, it probably makes sense
to use a single document to keep all of
the information in a single location.
For larger projects, a single document
could easily become unmanageable.
The authors preference for large
projects is to create a functional-speci-
fication document for each area. This
approach typically allows classes to be
described within a single document
because classes often fall within a
process area. Yet it allows for a lim-
ited number of documents. Typically
five to ten process areas exist on a
process. The authors also typically
create one functional specification
early in the project to describe mod-
ules that exist across all areas such as
the agitator control equipment mod-
ule, temperature control equipment
module, and so on.
An example outline for a buffer prep
area functional specification docu-
ment is shown in the box above.
Involve all stakeholders
Once the functional specification is
written, it is time to get the right peo-
ple together again. All of the stake-
holders that played a part in the func-
tional specifications development
should also take part in reviewing and
ultimately approving the document. It
is important to build a consensus so
that all parties agree on the require-
ments before you proceed to software
design and implementation. This does
not guarantee there will be no argu-
ments in the future but, it does pro-
vide a solid starting point and a stable
platform for change control.
OTHER CONSIDERATIONS
Exception handling
The S88 standard defines exception
handling as those functions that deal
with plant or process contingencies
Cover Story
OUTLINE FOR A FUNCTIONAL SPECIFICATION
OF THE BUFFER-PREP VESSEL EXAMPLE
1. Introduction
2. Equipment Modules
i. Charge Equipment Module
1. CIP Phase Class
2. WFI Phase Class
ii. Pressure Control Equipment
Module
1. CIP Phase Class
2. Pressurize Phase Class
3. Vent Phase Class
iii. Discharge Equipment Module
1. Mix Phase Class
2. Transfer Phase Class
iv. Temperature Control Equipment
Module
1. Cool Phase Class
3. Buffer Prep Unit Definition
i. Alias Definitions
ii. Process Alarms and Batch Failure
Handling
iii. Parameters
iv. Phase Classes
1. CIP
2. Charge WFI
3. Add Raw Material
4. Transfer Buffer
and other events which occur outside
the normal or desired behavior of
batch control. In addition, S88 pro-
vides models, such as the procedural
state matrix, and terminology that
provide the fundamentals to address
exception handling. However, the spe-
cific details of identifying the excep-
tions and determining the appropriate
reaction are left to those specifying the
automation requirements.
There are several considerations
that must be made when specifying ex-
ception-handling requirements. First,
exception handling must be considered
as an integral part of the automation
requirements. It cannot be left as an af-
terthought. One will find that a signifi-
cant part of the specification develop-
ment will be spent on this activity. If
this activity is not adequately ad-
dressed, plant equipment and product
integrity may be jeopardized.
Second, an exception and its corre-
sponding 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 op-
erator 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 ramp-
ing-up may not require the same reac-
tion 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 excep-
tion. For some exceptions, recovery
may be as simple as taking an alter-
nate action in the Running logic. How-
ever, other exceptions may be more se-
vere 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 in-
tensive because one must logically co-
ordinate the actions of the 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 ves-
sel inlet, 2) wait for charged quan-
tity to reach target, and 3) close ves-
sel inlet. One must consider
exceptions relative to these tasks be-
fore recovery can be specified. Re-
covery from an exception during the
wait for charged quantity task is
different than recovery from the
close vessel inlet task. For the for-
mer, the charge is incomplete so re-
covery involves completing the
charge. For the latter, the charge
has already completed so recovery
involves ensuring that no additional
charge is executed.
Modularize
the equipment
To this point, the func-
tional-specification discus-
sion has been limited to
modularizing the automa-
tion requirements. There
has been limited discussion
on the physical plant equip-
ment and its relationship to
automation requirements.
However, the plant equip-
ment used to execute the
process certainly has a di-
rect impact on the automa-
tion requirements.
Accordingly, it makes
sense to examine how the
S88 models might be used
to modularize the physical
plant. If the physical plant
can be modularized, then it
is more likely that areas of
reuse and flexibility can be
identified. For example, an equip-
ment module may include an agitator
motor and a weigh scale to indicate
when vessel level is low, causing the
agitator motor to turn off. If the same
agitator motor and weigh scale types
are used throughout the plant, then
only one equipment module class is
needed to specify the automation re-
quirements for agitators in the plant.
The most benefit, however, comes
when the modular approach is applied
at the unit level. If process vessels
with identical functions, or even simi-
lar functions, are designed with like
equipment, then it is more likely that
the same set of software modules can
specify the automation requirements
for all the vessels.
Of course, there will always be situ-
ations in which a process requirement
can only be satisfied by a unique piece
of equipment. But, the point is that a
modular approach to plant equipment
will lead to modular specifications.
The less modular the physical equip-
ment is, the harder it is to create soft-
ware modules that can be used across
the plant.
This raises the question: When
should automation people get in-
volved? Typically, these people are
called in after the process design and
P&IDs are complete. However, for-
ward thinking would suggest that get-
Buffer prep
tank 101
Vent
PT-101
LI-101
TT-101
TIC-101
Hold tank
Drain
Air
CWR
CWS
CIPS
WFI
Filter
PIC-101
Vent
PT-101
Drain
Air
Filter
PIC-101
Vent
PT-101
Drain
Air
Filter
PIC-101
Raw
material
mixer
Pressure control equipment module (A) Pressure control equipment module (B)
Pressure control equipment module (C)
WFI = Water for injection
CIPS = Clean-in-place supply
PIC = Pressure indication and control
PT = Pressure transmitter
TT = Temperature transmitter
TIC = Temperature indication and control
CWR = Chilled water return
CWS = Chilled water supply
LI = Level indication
KEY
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 ves-
sel to atmosphere (B), and control the vessel pressure (C)
ting these people involved earlier
would allow the process design to take
a more modular approach. Theoreti-
cally, the time that the automation
engineer spends up-front, diminishes
the time that must be spent in the
end. This is for two reasons: 1) He or
she has an intimate knowledge of the
process by the time specification be-
gins; 2) Some of the modularization is-
sues have already been resolved so
less time is spent trying manufacture
modularity in the software.
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 identify-
ing and organizing the modules and
defining the procedural requirements.
Usually several iterations are re-
quired before you arrive at a model
with which you are happy.
In addition to the common structure
and terminology, S88 facilitates class-
based definition of the batch control.
By using the class-based approach,
you can
Minimize documentation by defin-
ing 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 stake-
holders of including automation,
process engineering, production, and
quality in the Functional Specification
effort in order to understand the oper-
ating 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 misunderstand-
ings between stakeholders as the pro-
ject moves forward into startup.
Edited by Gerald Ondrey
References
1. GAMP Guide for Validation of Automated
Systems in Pharmaceutical Manufacture.
V4.0, Good Aurtomated Manufacturing
Practice Forum, 2001.
SUMMARIZING THE TERMINOLOGY
PHYSICAL MODELS
Process cells
Also referred to as trains, these
define the logical grouping of
equipment necessary to pro-
duce one or more batches,
though not necessarily a final
product. Defining process cells
makes production scheduling
easier.
Things to consider when
defining process cells include:
Establish clear boundaries
Functions performed must be
consistent regardless of what
product is being produced
Interact with other process
cells minimally and, when
necessary, conducted at the
same or higher entity level;
that is, from process cell to
process cell
Maintain consistency so op-
erators interacting with simi-
lar entities do so naturally
and without confusion
Units are a collection of
equipment and control mod-
ules in which major processing
activities, such as react, distill,
crystallize, make solution, and
so on, can be conducted. Unit
characteristics are:
Operate on only one batch at
a time
Cannot acquire another unit
Operate independent of
other units
Equipment modules are func-
tional groups centered around
a piece of processing equip-
ment that carry out defined ac-
tivities, such as header control,
dosing, weighing, jacket ser-
vice management, scrubber
control, and so on. A collection
of control modules can become
an equipment module if the col-
lection executes one or more
equipment phases.
Control modules are the low-
est grouping of equipment ca-
pable of carrying out basic
control. For example, solenoids
and limit switches combined
can form Off/On valve control
modules, and transmitters and
valves can be combined into
PID control modules.
Procedural Models
Phases accomplish a specific
process-oriented task, can be
executed sequentially or in par-
allel, can be self-terminating,
and need to account for excep-
tion condition handling. When
defining phases, a few of the
considerations include:
Consistent use of predefined
states, such as holding, held,
restarting, failing
Consistent use of predefined
commands, such as hold,
stop, abort
Definition of the modes for
each phase, and how the
phase will respond to each
mode. For example, is a sin-
gle-step mode needed for
troubleshooting?
Definition of exception han-
dling and recovery mecha-
nisms
Data collection of phase-re-
lated activities
Operations are independent
processing activities that usually
result in a chemical or physical
change in the material being
handled. Operations include
the instructions necessary for
the initiation, organization, and
completion of activities such as
prepare reactor, charge, heat,
cool, and react.
Unit procedures provide a
strategy for carrying out opera-
tions and methods in a contigu-
ous manner within a single unit.
A unit procedure can execute
concurrently on different units.
Procedures are the strategy
for carrying out batch activi-
ties within a process cell. Pro-
cedures, such as clean-in-
place, do not always produce
a product or a product inter-
mediate.
Authors
Christie Deitz is a consul-
tant and project leader for
Emerson Process Manage-
ments Life Sciences Industry
Center, (8301 Cameron Road,
Austin, Tex. 78754; Phone:
512-832-3240; Fax: 512-832-
3785; Email: christie.deitz
@emersonprocess.com) which
specializes in process automa-
tion for the pharmaceutical
and biotech industries. She has
worked for Emerson for fifteen years as a technical
lead for design and implementation teams provid-
ing FDA validatable computer systems for several
large pharmaceutical and biopharmaceutical
processes. She is also a consultant on computer
systems validation issues and a member of the core
team of the PDA Part 11 Task Group. Deitz holds a
B.S. in chemical engineering from Texas A&M
University as well as an M.S. in chemical engi-
neering from the University of Texas.
Todd Hamis a consultant and
project leader for Emerson
Process Managements Life Sci-
ences Industry Center (Phone:
512-832-7136; Fax: 512-832-
3785; Email: todd.ham @emer
sonprocess.com). He has
eleven years of experience in
process control as a technical
lead for batch automation pro-
jects in the pharmaceutical,
biopharmaceutical, chemical,
and food and beverage industries. His experience
also includes plant startups and support. He is
currently the lead engineer and primary batch ar-
chitect for a 9,000 point batch biotech facility.
Ham holds a B.S. in mechanical engineering from
the University of Notre Dame.
Steve Murray is a consultant
and project leader for Emerson
Process Managements Life
Sciences Industry Center,
(Phone: 512-832-3909; Fax:
512-832-3785; Email: steve
.murray@emersonprocess.com).
He has ten years of experience
in process control including six
years of experience in batch
automation. He was recently
the lead engineer and batch
architect for a 5,000-point batch biotech facility.
Murray holds a B.S. in electrical engineering from
the University of Dayton.
Reprinted from CHEMICAL ENGINEERING, August 2003, copyright 2003 by Chemical Week Associates, L.L.C. with all rights reserved.
Additional reprints may be ordered by calling Chemical Engineering Reprint Department (212) 621-4631. To subscribe to Chemical Engineering, call (212) 621-4656.
FORM D351023x012 / 5K AQ/8/03