Food and Pharmaceutical

Division Winter2013

In this Issue
1 Directors Message
2 Networking at ISA
2 Anti-Patterns
3 Alarm management technical report published
3 Alarm Management for Food / Pharmaceutical
Processes
7 Division Meeting at FLM Director
3 ISA Automation Week 2012 Alex Habib, PE
8 Models and Support for Alarm Operation;
Batch vs. Continuous
14 2012 Conference Survey Editor
15 New Members
Andre Michel, PE
16 Division Officers

A message from our Division
Process Analytical Technology (PAT)
Virtualization
Director Alarm Management
Batch Process Controls
Dear members of the Food and Pharmaceutical Industry
Cyber Security
Division (FPID);
Lot Tracking
On behalf of the Food & Pharmaceutical Division, I am Food and Pharma Safety & Security
pleased to confirm that our FPID division board decided to Bio-Pharmaceutical Automation & Process
hold a Food & Pharma symposium in the spring of 2014 at Controls
ISAs Head Quarter at RTP. Control System Validation
Food & Pharma Instrumentation Systems
The decision was based on the following main reasons: (hardware & Software)
1- North Carolina is one of the main centers for the
manufacturing and research facilities of food,
pharma and bio-tech industries in the USA Sincerely
2- ISAs Head quarter provides an excellent meeting Alex Habib, PE
facilities and good support by our staff. FPID Division Director
3- Several ISA divisions had excellent participation 732-679-1887
by operating companies and vendors for example: Alex-habib@msn.com
the Analytical Division, Power Industry and
Water/Waste Treatment, etc.
4- ISA has excellent choices of hotels in the RTP area
at reasonable cost.
5- Our Tar Heel section has a good relationship with
other pharmaceutical societies such as ISPE.
In order to make this Symposium a success; we need your
help to find qualified speakers and potential sponsors.

Please contact me at your earliest convenience if you are

interested or know of a speaker to cover such items like:
Networking at ISA Automation
Week 2012: Real Conversations
Start here
By Robert E. Lindeman, 2012 ISA President
As I look back on ISA Automation Week 2012, there is a lot
to take away rich technical sessions, interactive tours at
one of the most dynamic properties on the planet,
productive and thought-provoking standards meetings
but one thing that really stands out to me is all of the
connections people made during that week.
One of the main reasons that I joined ISA back in 1993 was
to make connections with people in my field. I wanted to
have intelligent conversations with people around the
world who shared my challenges. I wanted to ask
questions, share my knowledge, and figure out better ways
to do my job. I have found all that and more at ISA, and
every time I see a group of people getting that same benefit
from our Society, I take notice. See, I think that making
connections between people with similar interests and
experiences is one of the biggest benefits of being part of
ISA, and an event like ISA Automation Week is the perfect
place to dive in.
Walking through the halls a few weeks ago in Orlando, I
overheard conversations about dozens of interesting
topics: cyber security, compliance issues, safety in plants,
the challenges of developing people to meet the needs of
our plants long-term, the importance of alarm
management and the list goes on and on. I can only
imagine the implications of the conversations I overheard,
but I would bet that someone came away with a new
solution to try in their plant; I would bet that someone
went home feeling like they really helped a colleague; and I
would bet that many people are continuing those
conversations right now. That is a primary function of this
Society: to bring people together, facilitate conversation,
and, as a result, bring out the best in each of us.
One attendee, Eloise Rouche of Dow Chemical Company,
gave this quote for our press release that was sent after
the event: The networking opportunities were fantastic.
Sharing information and participating in in-depth
conversations about critical topics like process automation
safety made the late nights and bleary-eyed mornings
worth it.
This is a great way to explain one of the biggest take-home
benefits of ISA Automation Week: there are a lot of late
nights and hanging out with old and new friends, but
conversations that start there are priceless. Thanks to all
of the attendees for making my 2012 conference
experience one that Ill remember and rely on when I
get back to my day job.
P.S. Do you have comments or feedback about ISA
Automation Week 2012? If you were there, and want to
share your thoughts, or if you could not make it and want
to offer your insights on planning next years event, drop
us an email at info@isa.org. We are always interested in your
opinions and feedback.
Anti-Patterns
A long term collaborator of ISA-FPID and very enthusiastic
volunteer at ISA has recently published a fascinating
article in Control Magazine. You might have recognized:
Dennis Brandl.
You might remember his 2006 very popular book: Design
Pattern. In this article Dennis reminds us that: Good
software design solves hard problems in a standard way
and is well documented and easy to maintain and extend
which was part of the message in the book.
However this article focused on as opposed to code that
seemed reasonable at some time but has spread and
become a nightmare to maintain or extend which he calls
Anti-pattern.
Anti-patterns are often the root cause of the 20% of a
system that cause 80% of the problems. They come from
attempt for software designers to circumvent conflicting
requirements or design specification by create very
specific code to manage the exception. As the system
evolve, the exception manipulation become obsolete and
very often unnecessary.
He proposes very interesting solutions in a very
reasonable context, but I dont want to spoil the end so I
suggest you have a look at:
http://www.controleng.com/channels/manufacturing-
it/manufacturing-it-news/single-article/design-patterns-
and-anti-
patterns/571eeda95dd049436294a12b220feb38.html
For more information on Dennis and his work , he can be
reach at the address in the officer list at the end of this
newsletter.

Alarm management technical
report published
ISA-TR18.2.6-2012, Alarm Systems for Batch and Discrete
Processes, is published and available at
www.isa.org/standards. This technical report covers the
application of alarm management principles in ISA-18.2-
2009, Management of Alarm Systems for the Process
Industries, to batch and discrete processes.
The alarm system serves to alert, inform, and guide
operators regarding abnormal process conditions or
equipment malfunctions. It may include the basic process
control system (BPCS) and the safety instrumented system
(SIS), each of which uses measurements of process
conditions and logic to generate alarms.
The general principles and techniques described in the
technical report are intended for use in the lifecycle
management of an alarm system based on programmable
electronic controller and computer-based human machine
interface (HMI) technology. Use of this technical report
should consider batch and discrete process alarms from all
systems presented to the operator, which may include
basic process control systems, annunciator panels, safety
instrumented systems, fire and gas systems, and
emergency response systems. (See the May/June 2012
InTech Standards column for more on batch and
continuous applications.)
Following the recommended guidance in this technical
report will not necessarily ensure that alarm management
problems will be avoided. But it will help to identify and
address alarm specification, design, implementation, and
management opportunities that are important to batch
and discrete processes. It can also help minimize the
generation of nuisance alarms that could complicate and
frustrate an operators awareness, understanding, and
response to abnormal situations.
ISA18 has five other working groups producing technical
reports to augment ANSI/ISA-18.2-2009, Management of
Alarm Systems for the Process Industries, commonly
referred to as ISA-18.2. These reports will add rationale,
usage guidelines, and examples in different areas of alarm
management. The other five reports are:
WG1 Alarm Philosophy
WG2 Alarm Identification and Rationalization
WG3 Basic Alarm Design
WG4 Enhanced and Advanced Alarm Methods
WG5 Alarm Monitoring, Assessment, and Audit
The committee hopes to follow this technical report soon
with those from WG4 and WG5. For more information on
this and other ISA18 technical reports, visit
www.isa.org/standards or contact Charley Robinson of
ISA staff, crobinson@isa.org .
Alarm Management for
Food/Pharmaceutical Processes
By Joseph Alford
Introduction
An ISA webinar was presented by Dr. Alford on Oct. 11 on
Alarm Management for Food/Pharmaceutical Processes.
Slides used in the webinar are available upon request. An
invitation was subsequently made by Division leadership
to create an article based on some of the more advanced
aspects of alarm management that were presented in the
webinar.
cGMP Expectations Regarding Alarm
Management
Since quality cannot be tested into product (e.g., some
product quality tests destroy the product sample), cGMP
expectations are for manufacturers to operate a validated
process in which consistent high quality product is
produced. This implies that those process variables
potentially affecting product quality (known as critical
process parameters) be monitored, with process
deviations associated with these variables formally
investigated as part of forward processing and marketing
decision making.
In order to know when a process deviation occurs,
scientists developing a product using a particular
manufacturing process must determine the Proven
Acceptable Range (PAR) of each CPP. This is usually
determined by running pilot plant experiments during
product/process development. The philosophy is that
operating a plant such that all CPPs are maintained within
their PARs maximizes the probability that acceptable
quality product will be produced.
Regarding process alarms, there is a natural tendency for
automation engineers to set CPP alarm limits (i.e., alarm
setpoints) at the PAR values. The problem with this is that
the components involved in making process
measurements (sensors, transducers, etc.) contribute to
some finite uncertainty around the measurement. E.g.,
some flow measurements have a vendor stated
uncertainty of 1 % of span. A consequence of this is that a
measured value that equals a PAR value may or may not
represent an actual deviation, depending on the
measurement uncertainty involved (MU). Therefore, an
important consideration for automation engineers is to
consider MU in setting alarm setpoints- as sometimes the
result will be to set alarm setpoints inside the PAR values.
These concepts are illustrated in Figure 1.

Figure 1, Setting alarm limits (setpoints) as a function of PAR values
Special characteristics of batch processes
Batch processes differ from continuous processes in
several respects, some of which are important
considerations in specifying alarm system functional
requirements. E.g., most continuous processes have one
long term operational phase, and are linear, steady-state
processes. Alarm attributes usually are not changed during
the operational phase of the process and alarm
displays/records are presented using calendar time.
Central control rooms are normally manned 24 x 7 so a
control room indication of an abnormal situation will
quickly capture the attention of an operator. Batch
processes usually consist of several shorter operational
steps/phases, most of which are time-varying, non steady-
state and non-linear. Users desire that alarm
displays/records are presented in relative time (time since
the beginning of the batch lot or lot step) and need for data
and alarm records to include important batch identifiers
(e.g, lot number, batch step, alarm class) to assist in alarm
record sorts, queries, and batch record generation. Batch
processes are normally only semi-automated, with many
manual field operations still required- so central control
rooms are not always manned. Means of alerting operators
outside the control room of any new abnormal situations is
often required.
It is important for project teams to consider some of these
nuances of batch processes when specifying functional
requirements (near the beginning of automation projects),
since many commercial automation systems do not
provide, in their off the shelf products, all the alarm
functionality that users may desire. Use of third party
products or customization of the automation system
incorporating advanced/enhanced alarming techniques
may be needed.
An example of one effective batch process alarming
solution, implemented by a major pharmaceutical
company, is shown in Figure 2. The process is a
fermentation and the PV is a measurement of time varying
cell mass in the bioreactor (usually available via a direct
measurement or by a virtual sensor utilizing calculating
oxygen uptake or carbon dioxide evolution. The value of
cell mass during the first part of a fermentation usually
follows an exponential growth function, but then changes
due to a variety of factors in the fermentation that affect
growth rate. Since not all fermentation batches are
identical (variability is usually significant for
bioprocesses), acceptable values for cell mass at a
particular point in time fall in a specified range rather than
being one precise value.
So, the idea in developing Fig. 2 is to identify several (e.g.,
20) acceptable successful historical runs of a particular
fermentation process, then calculate the time varying
average value of a targeted PV (e.g., cell mass) and also
calculate the +/- two standard deviations around the
average value. The +/- two std. deviation plots are then
copied (or piecewise fit to polynomial equations) and used
as a background overlay on the operator console trend
plot. What the operater then sees is the current PV plotted
against the background range of known successful batch
runs. It is then easy for the operator to see that the run is
proceeding normally, without having to memorize or refer
to charts as to what the expected PV acceptable range is at
a particual time. If the automation system is programmed
to allow alarm setpoints to follow the value of the +/- two
std. deviation plots, then an alarm can be generated when
the PV exceeds this range. In the case of Figure 2, an alarm
is generated at abut 13 hours into the fermentation when
the cell mass is higher than that associated with historical
successful runs.
The abnormal situation shown in Fig. 2 is relatively
common in industry, occuring when a fermentation
becomes contaminated (e.g, with foreign bacteria). In fact,
Fig. 2 represents one of the most useful techniques
available for early on-line automated detection of
contamination.
Note that Fig. 2 is specific to the fermentation step of the
overall process, with the X axis showing realtive time
since fermentation inoculation (i.e., the beginning of the
step). This avoids operators and process engineers having
to deal with more traditional calendar time plots for which
time and effort are needed to associate a calendar time to a
particular process step and time within the step. Note also
the need for near continuous changes to the alarm setpoint
(often needed for some batch PVs). Plots such as Fig. 2,
while highly effective and driven by the needs of operators,
are not typically available in most commercial automation
systems. Figure 2, e.g., was made available in
manufacturing plants via use of a 3rd party product and
some customization. So, this is a good example of the need
to identify user alarm requirements near the beginning of
a project, when time is available and resources can be
committed to pursue any special functionality needed.

Figure 2, Using Historical Run Performance to Determine
Alarm Limits for a Fermentation Batch Process
Mining Batch Data and Alarm Records
The good news is that most food and pharmaceutical
companies have now collected a large amount of data
regarding their manufacturing processes due to advances
in recent decades in computer systems, sensors, data
storage, and cost reduction. E.g., process control systems
deal with updates to many process variables every second,
use them to calculate additional variables, with much of
this information potentially sent to the process historian,
either in raw, filtered, or compressed form. Additional
information comes in at lower frequency from at-line and
lab assay equipment.
The bad news is that most of this data continues to sit in
historians as just data and is not mined for the nuggets of
gold representing its information and knowledge content.
Alarm records are a good example of this observation.
Plant automation systems generate large numbers of
alarms and associated alarm records (often thousands per
day) but little use is typically made of these records. The
situation and opportunity are captured in Figure 3, which
shows data (including alarm records) residing at the lower
level of the triangle. The upper levels of the triangle show
some of the opportunities to mine the information and
knowledge content of these records.
Figure 3: Moving from data to information and knowledge
There are several reasons for lack of significant alarm
record mining in data historians. One is the lack of good
English descriptors in alarm records that are
understandable to the technical service (TS) and quality
control (QC) scientists that often have need to review
alarm information. E.g., describing an alarm as associated
with FIC101 may make perfect sense to the automation
engineer configuring the control loop and associated
alarm, but is Greek to the microbiologist scientists who
review CPP data and alarm records in order to pursue
required deviation investigations.
Another reason is the lack of sufficient identifiers in alarm
records to facilitate quick and efficient sorts and queries.
E.g., in preparing a batch report (either manually or
automatically), TS and QC scientists will often want only
those records associated with CPP alarms for a particular
batch lot. If batch records dont have this information in
the record tags (or automatically available via other
means), then such activities are tedious, boring, and an
inefficient time use of valuable resources.
Helping TS/QC with deviation investigations
An example of a graphic developed by a major
pharmaceutical company to help TS and QC personnel in
investigating deviations is that shown in Fig. 4. As noted
before, all CPP deviations must be formally investigated for
processes subject to cGMPS. Further, all deviations should
be investigated anyway as a best practice to discuss ways
of keeping the deviation from happening again.
Rather than having someone spend time gather the
pertinent PV trend plot, alarm records, and any operator
comments associated with a deviation, and then trying to
correlate it all, time wise, on a graphic for presentation to
the deviation investigation team, why not have the
historian automatically generate the desired graphic. In
the Fig. 4 example, one plot shows the pH trend plot which
includes the deviation incident, and then shows on the
same time scale when the alarm activated, when the
operator acknowledged the alarm, and when the alarm
deactivated. It also lists additional detail of these discrete
events along with the comment that the operator entered
into the system explaining what he/she did in dealing with
the abnormal situation. A key question that this plot helps
management with is in determining whether operator
actions were timely and appropriate in dealing with this
deviation.

Fig. 4, Combining deviation information from various sources
Challenges with alarm management
While many aspects of alarm management are well
understood and documented in such references as the
ANSI/ISA 18.2 Standard, there are still challenges in
creating a unified effective alarm management
environment for operators. Figure 5 is shown to help
describe two of these challenges.
Figure 5: Distribution of plant automation systems involved with
alarm management
The first challenge recognizes that personnel in modern
plants are working to integrate enterprise and process
control computer systems, supported in part by the ISA 95
standard which defines 5 different levels of automation.
As computer experts are aware, it can be difficult to
communicate and share data and information between
systems, as such information often exists in different time
frames, formats, and contexts in the different systems.
Referring to Figure 5, some alarm information may exist at
Level 3 in what is known as the MOM environment
(Manufacturing Operations Management) which in turn
consists of Manufacturing Execution Systems, Laboratory
Information Management Systems, Maintenance Records,
Batch Reports, Lot History, Master Recipes, etc. Therefore,
for plants pursuing an integrated computer environment,
there can be a need to sort and send selected data (in
lower level systems such as the historian, alarm loggers,
and 3rd party products such as expert systems) up to MES
systems to provide input to lot history data/knowledge
bases and batch reports. Communication may be needed in
the opposite direction as well, as process control systems
may need to access higher level systems to obtain Master
Recipes (containing configured alarms) as well as LIMS
systems to obtain the latest values of lab assays for
ongoing manufacturing processes.
A second significant challenge exists due to the
proliferation of manufacturing unit operation equipment
from different vendors, with each mounted on a skid and
controlled with an equipment vendor supplied embedded
system (usually a PLC) utilizing proprietary control, HMI,
and alarm logic (ISA is calling these systems Packaged
Systems). These equipment vendors are usually reluctant
to customize their code to meet specific customer
requirements as they then need to support multiple
versions of their software. Further, their systems are often
not compliant with the ANSI/ISA 18.2 Standard on Alarm
Management and are usually limited in the data and
information they are capable of exporting to external
computers (such as a central plant DCS). This creates a
situation where operators need to learn about and deal
with several different alarm systems in a plant, with the
rules of navigating through alarm displays, alarm
acknowledgment, etc. different for different equipment.
This is a very undesirable situation from an operators
perspective and is also counter to alarm philosophy
objectives as stated in the ANSI/ISA 18.2 Standard.
ISA is currently in the process of creating a new 18.2
working group (WG7) to deal with the packaged alarm
system challenge.
Conclusion
This article touches on a few aspects of alarm management
of special interest to practitioners in the regulated food
and pharmaceutical industries, dominated by batch
processes. It is hoped that these aspects of alarm
management convinces readers of the need to think
through needed alarm functionality, as well as to how
alarm records will be utilized, near the beginning of an
automation project. In so doing, adequate time can be
available to consider 3rd party products or any needed
customization of the alarm system. Users should NOT
assume that off-the-shelf commercial systems will
provide all the alarm functionality they may need in their
plant.
FPID at Automation Week 2012
As usual, most divisions have held a division meeting
during automation week. FPID was no exception. Led by
our Director, Alex Habib, several of our division officers
reviewed last year performance and planned for the year
to come.

During the last year we have gained several new members

and we are now over 1,500. We have provided a FPID
speaker from Genentech to the analytical division
symposium at Anaheim, CA.

We have started establishing a strong relationship with

ISPE (International Society of Pharmaceutical Engineers)
chapters in:
North Carolina
Ireland
Philadelphia
New Jersey

We have issued several newsletters in 2012:

Winter
Summer
You are reading Fall now

We have delivered Live webinars on:

Vision Systems
Batch Standards (ISA-88)
MES Standard (ISA-95)
Pharmaceutical Automation Project Management
Alarm Management on October 11, 2012

We will start planning for a Symposium in 2014; a first

kick off phone conference was performed on October 16
to:
Develop Theme
Assign committee chairpersons
Establish location
Establish a date

If you like to volunteer please contact:

Alex Habib
FPID Division Director
Alex-habib@msn.com
Models and Support for Alarm
Operation; Batch vs. Continuous
By E. H. Bristol ; The Foxboro Co.
ABSTRACT
Alarms are traditionally handled as standard contacts or
parameters associated with process sensors, with uniform
implementation, but no application related Alarm
Management organization or strategy. For continuous
processes, where there is a possibility of independent
alarmed events, in different parts of the production, this
has been an easy, lazy approach to Alarms, depending on
operator experience and discretion. In this context, Alarms
are the main connection from the automation to the
operator, for addressing abnormal process operation.
Alarms of this sort address problems that we have been
unable to automate. But they are often as much a source of
consternation as help. The Alarm problem is thus twofold:
How to make traditional Alarms more useful, and how to
provide a more engineered approach to Alarming. For the
former, the paper suggests simple Alarm tools requiring
only the most basic configuration. These include Trending,
automatically generated situation descriptions, causal
Alarm analyses, and situation adaptive Alarm operation.
But Batch control particularly lends itself to better
engineering of the relative role of the operator and
automation because the production steps follow a natural
progression with expected normal and abnormal
consequences. In this case, Alarms and their response can
be integrated into the natural sequencing.
INTRODUCTION
Process control alarms are the main automation system
vehicle for dealing with operations too abnormal for
realistic automated accommodation. These abnormalities
will often be unfamiliar to the operations and applications
personnel. Some will be very mild, some catastrophic.
Large continuous applications may have thousands of
potential alarms defined and hundreds active at any point
in time, sometimes within one or more causal showers.
Traditional alarms, however well designed, are treated as
limited sensor attributes, rather than coherent control
elements. They are inherently inadequate to support the
operator in recognizing and coping with significant
abnormal or crisis situations. The push to operate with
fewer operators places that much more of a load on the
existing ones, exacerbating the problem. The initial tool
discussion focuses on improving the analysis and
presentation of this traditional alarm information. The
later discussion of Batch control discusses how this kind of
operation naturally encourages a more rationalized
approach to Alarms.
Alarms fall in a number of classes, depending on the extent
to which their role is well understood:
1. Alarms reflecting inherent safety or economic limits on
the plant, to be avoided, by their very nature.
2. Alarms, for which well-defined corrective operating
procedures exist (These alarms may well fall in the first
class as well.).
3. Alarms, whose importance and meaning is situation
dependent (To the extent to which the situations are
detectable and recognized, these alarms may also fall in
the first two classes.). Batch by its nature extends this
class.
4. Alarms, which generally reflect qualitative constraints,
not well formalized. Ideally these alarm limits would be
periodically tightened, as operating experience justified it,
in an SQC kind of approach.
The first two kinds of alarm are the result of good
engineering, and subject to it. They should be included
with the orderly automation design, and are improved by
better automation1 and better rationalization of the
operators role. The last two kinds of alarm constitute the
greatest problem to orderly, continuous operation. And
yet, properly supported, they may offer the greatest
opportunity to profit from any operating discretionary
capability. The first part of the paper will address Tools
designed to better support the operator in coping with
large amounts of this kind of Alarm information, most
useful in predicting and diagnosing abnormal process
states.
Excepting a few alarms with well-defined (but not
automated) operating responses, most of the alarm
activity will thus be coping with deficiencies in the process
automation and operator understanding, and in the
adjustment of the alarms themselves. The Alarm Analysis
Tools must minimize these deficiencies, but they will
function better with better application automation. They
presume a general Process Control vantage point, neither
Batch nor Continuous.
The Tools are optimized about poorly understood process
characteristics, requiring easy sensitivity to unusual
behavior, and rapid exploration and diagnosis.
Accordingly, they should not be overloaded with
configuration or operating features. In particular, the Tools
must avoid complex, configured, alarm specific responses
more appropriate to well-understood, systematic plant
automation. The related configuration of the alarms and
their associated displays should be governed by
generalized display Policies applicable to groups of alarms
rather than by detailed configuration of the individual
alarm action. The display approach must support quick,
easy, transparent operator action.
Processes with more systematic relations between process
events and possible alarms support easier formalization of
alarms and the operating role, perhaps with traditional
automation, perhaps with Expert Systems. For example,
the large continuous plant has all aspects of production
running at the same time. The alarms are based on
individual process variables. Event/Alarm relationships
may be localized to the part of the process in which the
causal event may occur. But multiple trains of events may
occur at the same time in different parts of the process,
merging together in an overall alarm flood or shower. On
the other hand, as discussed in the later part of the paper,
the events of a batch plant are ordered, sequentially in
time, giving rise to greater predictability in any associated
alarms. This simplifies operator diagnosis and the
development of standard procedures. It also permits
alarming of specific events independent of generalized
alarming standards.
Batch also emphasizes certain issues not normally
recognized in continuous control, in particular the
dynamic variation of operational conditions with changing
operational phases. The Alarm Tool Category concept is
the most basic vehicle for making the operation phase
dependent. Most of the accommodation of the Tools to the
Batch environment will be through the APIs which allow
the construction of Batch system commands or links to
control the status of associated Categories from the Batch
procedure. Batch will motivate different attitudes for
combining the configuration of controls and Categories,
and for archiving prior Category configurations.
THE ALARM TOOLS
The accompanying demonstration develops a continuous
Styrene Plant example, showing an application based
hierarchical organization. [1] The demo expresses a basic
set of graphic displays including only alarm related data,
which in real life would contain all kinds of information.
The demo also shows a number of default displays, which
would exist even when a graphic was not configured.
The design concept is based on simple hierarchical
Categories of alarms, extended with as many different uses
of these Categories as possible. The Access Map includes a
Process Divisions based hierarchy. But it also shows other
hierarchies as well, based on the process Streams or
Situations (in Batch: Phases) or Operations. The resulting
multi-hierarchy is intended to be fully user configured:
The alarmed process variables are user-defined, as well as
the choices of higher level Categories in the complete
structure. Each of the demo Categories reflects possible
(but not required) user naming and content.
CATEGORIES, CATEGORIZATIONS, AND
PATTERNS
The whole system is based on three mechanisms for
hierarchically classifying Alarm conditions:
User defined Categories, which are lists of alarms (listed
in the default display for any Access Map button except the
Styrene Plant, Feed Tankage, Furnace, Heat Exchanger,
Reactor, and Separator buttons with their graphics).
Categorizations, which are top level nesting Categories
whose subCategories collectively contain all of the
application alarms. They represent different ways of
completely dividing the process alarm variables. Knowing
the Category locations of an alarm in each of the different
Categorizations is like knowing the coordinates of a point
in space. (The # marked buttons, in the Access Map,
correspond to unnamed Categories whose alarms fill out
the associated Categorization.) The Categorizations
support the hierarchical display access. They also support
the Mask/Filter, active in most of the displays (e.g., the
Styrene Plant and Furnace graphics above), as will be
defined shortly.
Patterns, which are Categories, whose alarms make up a
symptom pattern, and whose order of occurrence, in a pre-
defined time window, is presumed significant. They are
divided into Cause Alarms, and Main (important) and
Secondary Effect Alarms. In the Access Map (and Mask
displays), their buttons are distinguished in Italics.
BASIC ALARM RECORDING: LOGGING AND
TRENDING; SIDE LOGS
Traditional Alarm display takes three forms: Alarm Panels,
Indicators in Graphic Panels or Displays, and Logs. Of these
the simplest (below left) is the log, shown in its role as an
absolute archival record of events for later analysis. But
even here, and particularly as a vehicle for online
diagnosis, the log has a lot of defects:
The events of a given variable are spread among many log
entries,
The log is hard to search for different alarmed variables
or events,
Events for a given variable are hard to correlate.
For its basic archival and post situation analysis purpose,
the log may be adequate. But it is hardly an operational
tool. For operations, the Tools provide a trending
capability, which supports each alarmed variable with its
own (in this case letter coded) trend line. The demo codes
the six kinds of alarm events (Deviation, High Deviation,
Lo, Hi, Lo Lo, and Hi Hi) with appropriate lower or upper
case letters. More powerfully, these could be color coded,
giving rise to our name for this kind of trending: Battle
Ribbon Trending. The color-coding can also trend the
acknowledgment history. The display is intended to allow
user choice of time window and prediction display as well.
The log and trend figures show that the Mask/Filter
extends to these displays.
One benefit of a trending (which groups all data about a
single variable in a single line) is that its lines can be
ordered alphabetically (and include only lines for alarmed
variables) for easy search. This automatic ordering can be
extended to fit hierarchically grouped tags. The system
automatically orders every listing, button array, or other
appropriate display, in every figure, consistently in this
way.
The demo is based on various standard full-screen
Operator displays covering particular classes of
information calling for sustained attention. In addition it is
handy to have a few simple pull down displays supporting
a quick summary capability. The figure shows what we
have called Side Logs, displaying different overall alarm
views.
From top to bottom three kinds of display are shown:
A Pareto ordered listing of the Alarms, indicating the
frequency of every alarmed variable. Pareto ordering
supports a nice alarm discipline encouraging the
development of general procedures for addressing or
removing frequently occurring alarm conditions.
An alphabetical listing of all current alarm conditions.
This also includes One Word and Priority Summaries
(defined in a later section) for the whole plant.
A trending of the most recently changed alarm conditions.
UNIFORM MASK/FILTER
The Mask/Filter is displayed as a row or column of buttons
with their associated Categorization buttons. It allows
controlled alarm display with selection of any Category in
any Categorization. The alarms displayed in the current
(list, graphic, log, or trend) display are those which occur
in at least one of the selected/highlighted Categories of
each Categorization. Thus the selected alarms occur within
the intersection of the different Categorization selections,
suppressing all others.
The selection process is designed to make Category
selection or deselection easy, whether carried out
incrementally or from scratch. The Selected/DeSelected
button allows all Categories to be selected or deselected,
defining the Selection/DeSelection starting point. Similarly
the Categorization buttons allow the Categorization
Categories to be all selected or deselected. Collectively the
group and individual buttons simplify the Mask/Filter
selection.
So far the discussion has addressed Category Selection and
DeSelection. The Category selection process can be
extended in three more ways:
Full Selection. This allows the alarms of a selected
Category to be fully displayed, without regard to other
selections.
Full DeSelection. This allows the alarms of a deselected
Category to be fully masked, without regard to other
selections.
Partial Selection, applicable only to Patterns, as described
later.
These modes permit the, always visible, manual or
automatic, expression of suppressed or displayed alarms.
The two sets of five small buttons, next to the
Select/DeSelect button control the choice of available
modes. The upper set controls the modes selectable for
individual Categories. The lower set controls the modes
selectable for the Select/DeSelect and Categorization
buttons. The lower set does not allow the change of mode
to or from any mode not permitted in the lower buttons.
The result is that special conditions, for example an out of
service Category, can be imposed without affecting the
normal operator use of the Mask/Filter.
ONE WORD AND PRIORITY SUMMARIES
One of the dilemmas of operator display is the meaningful
summary of information in alarm indicators representing
groups of alarms. The figure below shows a kind of display
that might normally be used in an alarm panel, displaying a
large number of alarms as labeled alarm lights. In this case,
each indicator group summarizes the state of a particular
process unit (Category). Each indicator includes button
selection of the associated display graphic and One Word
and Priority Summary text displays.
A One Word Summary is the name of that other Category
whose computed intersection with the group indicator
Category contains the fewest listed alarms while
containing all of the active alarm conditions of the original
Category. It is thus a computed, most-descriptive summary
of the Alarm State of the original Category. Where there is
only one alarmed variable with active Alarm State in the
Category the name of that variable with its state becomes
the One Word Summary. In this case, a low level alarm
condition can, when nothing else is happening, percolate
up to any higher level display. As more activity takes place,
the level of abstraction provided by the One Word
Summary goes up, providing the operator with a constant
information rate but the best possible description at that
level.
One awkward tendency in alarm processing is to configure
alarm priorities in neutral categories (e.g. categories 1
through 5). This has the side effect of causing most alarms
to be assigned the highest category. A better strategy is to
define meaningful, user named Categories of grouped
alarms, as described above, and then prioritize the
Categories. The Priority Summary is the name of that
highest priority Category still containing any of the alarms
of the original (e.g. Furnace) Category.
The One Word Summary Category will always fall in a
single Categorization. A more powerful use of the
underlying concept would make use of intersections
between Categories in each Categorization, to further
group and localize the alarms of the overall indicator
Category. This is not practical in the above displays.
However, a special alarm display is provided to allow this
form of analysis.
The figure shows three main display elements:
An alphabetical listing of all alarm variables with their
states, similar to that shown later in the default displays.
A Categorization grouped Category list (similar to the
Mask/Filter) that allows the Category membership display
of selected alarms.
The Mask/Filter.
Using the Mask/Filter and Set Buttons, any arrangement of
the alarm variables and states can be selected (then
highlighted in darker shading). In particular the alarms in
any Category can be selected. The Categorization/Category
list then indicates (by different shadings), which other
Categories (in every Categorization) include all of the
selected alarms, and which include only some of them. In
this way, the display expands the One Word Summary as
an intersection of Categorizations. The display can also be
used for a number of other What If explorations.
PATTERNS
A number of papers, over the years, have proposed
showing alarms in terms of recognized sequences of alarm
events reflecting causality between the different
events.[4,5] Recognition of such a sequence can be used
for diagnosis or prediction. The simplest way is to store
the sequence and have the system record occurrences of
events, which follow that order. The earlier reference
recognized that the actual occurring alarms might never
follow the sequence directly; moreover there might be
several sequences occurring concurrently. Accordingly, a
Metric was computed which identified the longest,
properly ordered, subsequence occurring within a defined
time window. The most likely sequences could then be
provided to the operator for his more detailed selection
and analysis.
The left-hand figure above shows the resulting ordering
with the displayed Pattern Name buttons, number of
alarms in the best match sequence, and the normalized
(against the total number of Pattern alarms) Metric. The
buttons permit selecting a display for a particular Pattern
(the right-hand figure), with sequence ordered Alarm
variables divided into Cause, and Main (important) and
Secondary Effect Alarm variables. Each variable is
displayed with its current alarm state. Those alarms, which
occurred in the sequence order, as part of the computation
of the Metric, are displayed with asterisk. In this form, the
display permits operator diagnosis and action on some
prescribed recovery procedure.
The Pattern can be used for event prediction as well. In
this case the Metric is computed, based only on Cause
events. When the number of such Causes exceeds a
specified threshold, the remaining Main and Secondary
Effect Alarms may then be predicted. The figure below
shows the default listed display for the earlier Fire Hazard
(as with any other Category). In this case all occurring
alarms are displayed with their alarm state. In addition,
the remaining alarms are indicated as predicted by the
deeper shading. (The right-hand side checkbox display is
designed to show the complete Alarm State of any selected
alarm variable, with other related information.)
The same shaded prediction is applied to any display
including the predicted alarms. The Pattern analysis
provides a much simpler substitute for Expert System
application. But it can also be interfaced with an external
Expert System, through APIs, to integrate their analyses
consistently into the Pattern display. This supports the
best of both worlds.
ADAPTIVE ALARMING
Simpler that normal control configuration, these Patterns
and Categories can still become too complex for
convenient user configuration. There is a need for
automatic recognition of usable Alarm situations,
Categories, and Patterns. Moreover, the alarm limits
themselves can call for situation dependence, making the
process of setting limits still more complex than it already
is. The Alarm Tools include a number of mechanisms for
simplifying all of this:
Those basic alarms, which do not have inherent limits (as
in category 1, above), will be supported by an adapting
system, which keeps track of worst case excursions. The
engineer can use these to support semi-automatic setting
of the limits.
Categories and Patterns can be supplied with their own
set of alarm limits so that whenever the Category or
Pattern is selected, the special limits replace the standard
ones. In the case of Patterns, the replacement would occur
in a timed and sequenced order natural to the Pattern. This
allows the Alarm Tools to support situation dependent
alarm limits. The Categories and Patterns used this way
would be supported by historical records, which allowed
the after-the-fact engineer supported adaptation of these
limits as above.
On recognition of a problematic situation the operator
could call for a special historian recording action that
would record potential Pattern events for later
configuration as a Pattern.
 We have defined a special event based auto-correlation
strategy, which allowed an engineer to process months of
data looking for correlated events constituting potential
Patterns.
POLICIES
Currently many vendors support the configuration of
alarm characteristics on a variable by variable basis. This
is particularly cumbersome for annunciation,
acknowledgment, and similar issues, which depend on
grouped action for effectiveness. A much better strategy
would be to configure such issues for different Categories,
as grouped Policies, in the same way that priorities are
defined above for the same Categories. The earlier Priority
discussion already gives an example of Policy
configuration discipline.
BATCH CONTROL ALARMING vs.
CONTINUOUS CONTROL ALARMING
The above Tools address alarms in general terms, as
related to individual process variables, thorough the
simple mechanisms provided by the Categories. They
particularly support continuous processes, or the
continuous support facilities in Batch processes, by
allowing the diagnosis between the many different
production activities and failure causality sequences
potentially coexisting in time. In the Batch process, each
unit or train is naturally operating in a more restricted
focus, perhaps in a single phase.
Even in the multi-train facility, the alarms of each train
correlate with the particular phases running in the train.
can build standard practices, similar to those developing in
the continuous control world.
CONCLUSIONS
Alarms are the main connection between the operator and
the automation when addressing operation of the process
outside of the normal support of the automation. Such
operation, beyond traditional engineered automation,
requires tools that allow the operator to effectively call on
his working experience. The paper first presents a set of
tools, based on the simple configuration of multiple
intersecting hierarchies of Categories. These tools allow
the operator to control his displays by display selection
and information masking. The One-Word Summaries
provide summary capability. This permits low level
information to percolate up through higher level displays
in a controlled level of abstraction with high detail when
little is happening and abstraction when more is going on.
The Pattern concept supports causal modeling for
prediction and diagnosis. Logging and trending access time
data. This support exists on top of more organized alarms.
Batch control particularly lends itself to these more
organized alarms, especially ones indicating exceptional
events naturally related to particular phases of the
sequencing.

In Batch control it is more natural to build an alarm

structure clearly integrated with the logic already
operating in the control program, and with any normal
operating display. These alarms can be seen as special
kinds of requests extending the normal operator requests
for action. At the same time, the natural program logic
lends itself to a higher level of automatic failure reaction,
reducing the extent and dependence on operator alarm
reaction.

All kinds of processing should be better organizing their

collective manual/automated operational support to
distinguish different modes or regimes of normal and
abnormal operation. These regimes need to be related to
clearly distinct kinds of operator display and automation
support. The design of Batch control systems should take
advantage of their natural characteristics. For example, as
relates to the Tools, Batch control already has the Pattern
built into the sequencing of the control program. Thus the
first part of causal prediction and diagnosis is already
inherent in the Batch sequencing. We still need to develop
generally recognized regimes of operation, on which we
Free ISA Web Seminars Is a Fire & Gas System a Safety Instrumented
Isnt it time you explored ISAs free web seminars? As an System?
ISA Member, you can enjoy unlimited, free access to a Manufacturing System Security Using ISA SP99
library of over 40 online pre-recorded web seminars Motivating Team Members
covering todays hottest topics. Its a great way to get extra Network Security Series Part 1: Cyber Security
training that fits your schedule. Risk Assessment for Automation Systems
Network Security Series Part 2: Firewalls and
Below is an alphabetical listing of the seminars. They can Filtering Security on the Plant Floor
be accesses at: Network Security Series Part 3: Encryption and
http://www.isa.org/template.cfm?Section=Web_Seminars6&tem Virtual Private Networks
plate=/customsource/isa/ArchivedSeminars/Series.cfm
Next Generation Fieldbuses - Picking the Right
One
Dont forget, you must be logged into www.isa.org
Noise Reduction in Signal Replacement
Applying Manufacturing Execution Systems
Overview of Enterprise Control Integration
Benefits of ISA Certification
Overview of Foundation Fieldbus Technology
Boiler Control Fundamentals
Overview of HMI Applications
CSE PE Exam Review Part 1: Standards &
References Safety Instrumented Systems Series Part 1:
Determining Safety Integrity Levels
CSE PE Exam Review Part 2: Measurement I
Safety Instrumented Systems Series Part 2: The
CSE PE Exam Review Part 3: Measurement II
Pros and Cons of Logic System Technologies
CSE PE Exam Review Part 4: System Analysis
Safety Instrumented Systems Series Part 3: Field
CSE PE Exam Review Part 5: Final Control
Device Issues and Their Impact on System
Elements
Performance
CSE PE Exam Review Part 6: Control System
Sell More Through Effective Technical
Implementation
Presentations
DCS Alarm Assessment Overview
The ISA95 Object Models for Enterprise - Control
Deployment of ISA100.11a - The First Proposed
System Integration Part 2
Standard of the ISA100 Universal Family of
Wireless Networking of Sensors and
Wireless Standards for Industrial Automation
Instrumentation: Applications & Techniques
Designing & Applying Model Predictive Control
Strategies
Effective Project Team Building
Engineering Influence: Unlock the Secrets to
Getting Your Way
Fiber Optic Sensing
FOUNDATION Fieldbus H1 Field-Level Installation
and Commissioning
Grounding in Instrumentation Systems
How Can OPC Reduce Your Plant Control
Integration Costs?
Hybrid Systems Overview
Industrial Ethernet Series Part 1: Understanding
Ethernet Cabling & Hardware
Industrial Ethernet Series Part 2: Is Ethernet
Ready for the Plant Floor?
Industrial Ethernet Series Part 3: Designing
Industrial Ethernet Networks
Introduction to DCS Alarm Management
Introduction to ISA100.11a - The First Proposed
Standard of the ISA100 Universal Family of
Wireless Standards for Industrial Automation
Introduction To Patents & Patent Process
Introduction to Process Control
Introduction to Safety Instrumented Fire & Gas
Systems
Introduction to SCADA
Introduction to Temperature Measurement
Is a Burner Management System (BMS) a Safety
Instrumented System (SIS)?
FPID 2014 Conference Survey 7) Do you value continuing educations?
a) Yes continue at question 8.
As Alex explains in his introduction, we have started b) No continue at question 9.
working on our first Supply Chain Symposium for ISA
planned for the spring of 2014. 8) If you value continuous education, what is your main
To help us in planning this event, we are distributing a reason?
survey to get the pulse of the membership on the subject. a) It is a core value in my company.
The survey will cover subject like: b) It is an easy way to obtain professional development
units for my qualification.
1) What topics would make you take a day or two from the c) Both
office? d) None of the above

a) Supply Chain Cost Reduction / Performance 9) If you do not value continuous education, what is your
Enhancement main reason?
b) Line / Process Automation techniques and strategies a) My company is going to tough time and do not have
c) Product safety / product counterfeit prevention & any budget.
detection b) My company hired me because I have all the
d) Process Analytical Technology (PAT) education I need for my position.
e) Manufacturing IT, MES and Virtualization c) I am not a member of a professional organization that
f) Batch Control Standard ISA-88 requires it.
g) Manufacturing Operations Management (ISA-95) d) None of the above
h) Product Tracing & Tracking (Serialization)
i) Project Management 10) What is the method you preferred for continuous
j) Validation education?
k) Plant tour a) Webinar (go to question 11)
l) Food Safety b) Local Seminar / Conference (go to question 12)
m) System and ERP integration c) Focused short course

2) What must a seminar / workshop deliver for you to 11) I prefer Webinars because.
consider it successful? a) This is convenient to be able to do it from my desk, a
conference room and/or from home.
a) Technical Content, b) We have limited (or no) travel budgets for continuous
b) Networking Opportunity, education.
c) Business Acumen/Strategy, c) I have a busy schedule and can only do continuous
d) Other, please specify. education when nothing else is urgent. A recorded
webinar is the perfect tool.
3) How far are you willing to travel? d) Other, please specify.
a) Overnight drivable (100 miles)
b) Plane trip - travel capped at $1000. 12) I prefer local seminar and/or conference because.
c) Plane trip travel capped at $3000. a) If I stay at the office, I get interrupted all the time.
d) Other, please specify. b) I have difficulty to concentrate if I am on-site and
have other things on my mind.
4) If you get the information, you needed what would be a c) We have a limited budget for continuous education
reasonable fee for the conference? but if the course does not involve any major cost such
a) $50 to $100 as air travel or hotel, it is usually approved.
b) $100 to $300 d) We have a no travel policy at the site.
c) $300 to $500 e) Other, please specify.
d) $500 to $1000
13) Would you prefer to participate in a multi-week Lunch
5) If you get the information and attend one or more training & Learn Seminar series instead of going to an offsite
seminars, would be a reasonable fee for the conference? seminar?
a) $50 to $100 a) Yes
b) $100 to $300 b) No
c) $300 to $500 c) Dont know
d) $500 to $1000
14) How long should each session be?
6) Does your company encourage continuing education? a) Less than 1 hour
a) Yes b) Less than 2 hours
b) No c) Less than day
c) Sometimes d) Not important
 Yvonne Duckworth CRB Consulting Engineers
15) How many weeks should the program consist of?
Kleber Falcao
a) 2 weeks or less
b) Not more than 2 to 3 weeks Elias Ferreira
c) Not important Forest Gardner
Lethicia Goncalves
16) What time of day / night (Eastern Time)?
a) In the morning Richard
b) At lunch (12:00) Hargenrader
c) In the afternoon Richard Harris
d) At night (after 5:00 PM, I understand this would Nagaraj Hegde
limit participating from Europe )
Chris Heng Cargill Inc
17) Would you pay a minimal fee for such a webinar series? Diane Heurtin HIPP Engineering and
a) Yes Consulting Inc
b) No Hugh Jenkins
c) Maybe, depend on the content. Victor Osvaldo Jesus
A separate invitation with a website link will be sent to you S. Kester
in the next couple of weeks. If you have any comments or Jeffery Kibalo
suggestions on the survey contact Alex-habib@msn.com Robert Koneck
Thomas Kosse Vipa USA
Welcome New Members of ISAs Robert Lesutis
Food & Pharmaceutical Division Lucas Lima
Scott Little Tropicana Products Inc
Name Company Luiz Augusto Longaray
Andrew Almendares Sycal Engineering Inc James Lustig
Loic Alpha Arkadiusz Maciak Wyeth Ayerst Pharmaceuticals
Boyko Baharov Signum Soft Na Elkin Manrique
James Baillargeon Medimmune Lee McDaniel
Michael Baldauff Fujifilm Diosynth Biotechnology Thomas McDonnell
Timothy Barz S. Mecum
Carlos Bedia Keld Moeller
Richard Bellelis JP O Riordan
Pat Boner Randy Oakley
Diego Caceres Eoin O'Brien Tandem Project Management
Richard Carpenter Dermot O'Callaghan Enterprise System Partners
Limited
Yamei Chen Eli Lilly and Co
Danilo Oliveira
Donald Cherry The RMH Group Inc
Jean O'Reilly Roche Molecular Systems
Xavier Climent
Lida Paz
Didier Collas Invensys
Wendell Pearson
Henry Collins
Alessandro Pestana
Chris Cook
Jaideep Raje
Gabriel Coutinho
Joseph Rakos
Brinton Crawford
Donald Richmond
Colm Cronin Leo Pharma
Paul Roberge RTI Products
Phillip Custer Instrument Technologies
Pedro Henrique Rodrigues
Jospeh DeBitetto Fougera Pharmaceuticals Inc
Bryan Rose
Adam Dittbenner Interstates Instrumentation
Ralph Russotto Corrosion Fluid Products Corp
Alexandre Djordjevic
Giovanny Sabogal
Atila Santos
David Adler
Richard Sara Special Assignment
Timothy Shannon davidadler@comcast.net
John Campbell
Katia Silva Petrobras Industry & Science Department VP
Jensy Solano Correa campbjr@msn.com
Renan Souza
Mike Nager
Bruce Summerfield Sales & Marketing Chairman
Luis Fernando Susin PUC PR Phoenix Contact Inc
(717) 944-1300
Zaida Tiruganya
Ingrid Valasco Torres Dennis Brandl
Special Assignment
Brian Vincent Genzyme BR&L Consulting
Michael Walsh Eli Lilly and Company (919) 852-5322
DnBrandl@BRLConsulting.com
Corey Williams Pharmaceutical Calibrations
and Instrumentation Llc Amit Desai
Daniel Xavier Education Chairman
Bayer HealthCare LLC
Carlos Garcia
(510) 705-7309
Christopher Hogan Parsons amit.desai.b@bayer.com
Peter Steimel Total Instrumentation &
Sunil Mehta
Programming Services Inc
Special Assignment
Zubin Varghese Ingersoll Rand PCS Engineering
Mack Hu Dalian Huaqi Electronics Tech (919) 359-4990
Co Ltd Sunil.Mehta@talecris.com
Ken Jones
Kevin Dignam
Wayne Lee Genentech Special Assignment
Michael McInroe Rockwell Automation DPS Engineering & Construction Ltd
353- 21 7305000
Michael Waker kevin.dignam@dpseng.com

Bob Hubby
Facilitator
(508) 349-1050
2012 Division Officers bob.hubby@verison.net
Alex Habib, PE
Division Director James Bouchard
Industry & Science Department VP-Elect Historian
alex-habib@msn.com jamesb@aei.ca

Mike Baldauff Rodney Jones,

Director Elect Staff Contact
michael.baldauff@merck.com (919) 990-9418
rjones@isa.org
Andr Michel
Newsletter Editor
amichel300@gmail.com

Gary Campbell
Webmaster
gcampbellisa@cox.net

Randy Dwiggins, PE
Standards & Practices
(908) 704-9041
rdwg@nnepharmaplan.com

Bill Dugery
Section-Division Liaison
dugaryw@ace-net.com