Integrated Manufacturing Systems

Generating operating procedures for chemical process plants

Ruth Aylett Gary Petley P.W.H. Chung James Soutter Andrew Rushton
Article information:
To cite this document:
Ruth Aylett Gary Petley P.W.H. Chung James Soutter Andrew Rushton, (1999),"Generating operating procedures for
chemical process plants", Integrated Manufacturing Systems, Vol. 10 Iss 6 pp. 328 - 342
Permanent link to this document:
http://dx.doi.org/10.1108/09576069910293004
Downloaded on: 12 July 2016, At: 14:42 (PT)
References: this document contains references to 26 other documents.
To copy this document: permissions@emeraldinsight.com
The fulltext of this document has been downloaded 902 times since 2006*
Users who downloaded this article also downloaded:
(1995),"Policies, procedures and standards: an approach for implementation", Information Management & Computer
Downloaded by University of South Carolina Libraries At 14:42 12 July 2016 (PT)

Security, Vol. 3 Iss 3 pp. 7-16 http://dx.doi.org/10.1108/09685229510092057

(2005),"Adapting security operating procedures to threat levels", Journal of Facilities Management, Vol. 3 Iss 1 pp. 53-64
http://dx.doi.org/10.1108/14725960510808392

Access to this document was granted through an Emerald subscription provided by emerald-srm:123683 []
For Authors
If you would like to write for this, or any other Emerald publication, then please use our Emerald for Authors service
information about how to choose which publication to write for and submission guidelines are available for all. Please
visit www.emeraldinsight.com/authors for more information.
About Emerald www.emeraldinsight.com
Emerald is a global publisher linking research and practice to the benefit of society. The company manages a portfolio of
more than 290 journals and over 2,350 books and book series volumes, as well as providing an extensive range of online
products and additional customer resources and services.
Emerald is both COUNTER 4 and TRANSFER compliant. The organization is a partner of the Committee on Publication
Ethics (COPE) and also works with Portico and the LOCKSS initiative for digital archive preservation.

*Related content and download information correct at time of download.

 Generating operating procedures for chemical
process plants

Ruth Aylett and Gary Petley

University of Salford, Salford, Greater Manchester, UK
P.W.H. Chung
Loughborough University, Leicestershire, UK
James Soutter
BG Plc, Loughborough, Leicestershire, UK
Andrew Rushton
Health and Safety Executive, Bootle, UK

Keywords effort goes into their generation and subse-

Plant efficiency, Chemical industry, Introduction quent maintenance.
Downloaded by University of South Carolina Libraries At 14:42 12 July 2016 (PT)

Operations management,
Operating systems In this paper we discuss an approach to Figure 1 represents the main stages in the
operating procedure synthesis (OPS) for design, construction and running of a che-
Abstract chemical process plants using AI planning mical plant. It can be seen that operating
Operating procedure synthesis procedures are a consideration at several
(OPS) has been used to generate
technology, considering in detail a particular
case study, the double effect evaporator different points within this. At the design
plant operating procedures for
chemical plants. However, the (DEE) test rig. We argue that a successful stage, where the process is first described at a
application of AI planning to this
approach to OPS has the potential not only high level in process flow sheets, and then in
domain has been rarely consid- more details as engineering line diagrams
ered, and when it has the scope of to reduce the substantial time currently
devoted to developing plant operating proce- (ELD), they may form an implicit element of
the system used has limited it to
solving ``toy'' problems. This paper the design rationale ± that is, the reasoning
dures manually, but also to support the
describes the application of state- lying behind the specific design decisions
of-the-art AI planning techniques to
consideration of operability problems at a
made. Designers will clearly avoid design
the generation of operating proce- much earlier stage in the plant life-cycle,
decisions that they perceive will produce
dures for chemical plant as part of therefore avoiding late changes to the design.
the INT-OP project at the Univer- inoperable plant.
We demonstrate that the use of modern AI
sities of Salford and Loughbor- When the design is evaluated for safety and
planning techniques allows successful gen-
ough. The CEP planner is outlined operability at the HAZOP stage, some of this
and its application to a double eration of plant operating procedures for a rationale may be drawn out as part of the
effect evaporator test rig is dis- real-world plant. While concentrating on
cussed in detail. Particular atten- HAZOP process, but investigation conducted
tion is paid to the issues involved
chemical process plant in this work, we during the project suggests that it is unusual
in domain modelling, requiring the believe it is straightforward to extend our for operating procedures to be documented
description of the domain, devel- system to other continuous process plant and in any formal and systematic way at this
opment of AI planning operators,
that in principle it could also be extended to stage. An output of the HAZOP exercise may
the definition of safety restrictions,
and the definition of the problem. batch plant, giving it a wide and general consist of operating constraints as well
There is then a presentation of the applicability. as design changes, but in the case of
results, lessons learned and pro- the chemical process industry, a multi-
blems still remaining.
Operating procedures and plant life-cycle disciplinary commissioning team is nor-
All industrial plants require an extensive set mally responsible for defining the detailed
of operating procedures which define the sets of operating procedures for a plant
This work was made
possible through funding steps required; for example, to start the plant alongside their other commissioning work.
from the EPSRC grant: up, to shut the plant down, to isolate pieces of This is often a substantial exercise taking
``Integrating Operability into equipment for maintenance or to deal with around two man-years of effort, and usually
Plant Design'', the ESRC, emergency situations. In older plants, all of overlaps with the construction of the plant.
the SERC, BG plc, BP,
Cogsys, ICI and Subs-IAD. these steps are carried out manually by A consequence is that if operability pro-
P.W.H. Chung is grateful to human operators and are usually officially blems are uncovered during this process, as
BG plc and The Royal documented in a multi-volume set of manuals may happen, they may force late changes to
Academy of Engineering for the design of the plant. If this occurs while
financial support through a in the control room, while in highly auto-
Senior Research Fellowship. mated modern plants the lower-level and the plant is actually being constructed it is
more detailed steps are embodied in the plant clearly undesirable and costly. Thus there is
control system. It is clearly vital for reasons an advantage in considering operating pro-
both of safety and efficiency that procedures cedures in a more systematic way and earlier
Integrated Manufacturing are of a high quality and therefore much than at present. This is an important moti-
Systems vation for the development of computer-
10/6 [1999] 328±342 based tools to aid in the authoring of operat-
The current issue and full text archive of this journal is available at
# MCB University Press ing procedures at the pre-HAZOP stage of the
[ISSN 0957-6061] http://www.emerald-library.com
life-cycle.
[ 328 ]
 Ruth Aylett, Gary Petley,
P.W.H. Chung, James Soutter
and Andrew Rushton
Generating operating
procedures for chemical
process plants
Integrated Manufacturing
Systems
10/6 [1999] 328±342
Downloaded by University of South Carolina Libraries At 14:42 12 July 2016 (PT)
Figure 1
The plant life-cycle
Once the plant is running, operating proce-
dures may need modification in the light
of actual operations experience. If mechan-
isms for doing this in a controlled way do not
exist, there is a risk of operations practice
diverging noticeably from the documented
procedures. A further source of change is
modification of the plant whether as a result
of maintenance and repair or of continuous
improvement methodologies. The application
of computer-based tools offers the means of
reconciling the need for flexibility in the
construction and modification of plant oper-
ating procedures with the need for accuracy,
consistency and accountability for changes.
Previous work
OPS is a field of research that has largely
been carried out in the chemical engineering
domain (Rivas and Rudd 1974; Ivanov et al.,
1980; Fusillo and Powers, 1987, 1988a, 1988b;
Foulkes et al., 1988; Lakshmann and Stepha-
nopolous, 1988a, b, 1990; Kinoshita et al., 1981;
Aelion and Powers, 1991; Crookes and Mac-
chietto, 1992), rather than by AI researchers.
Yet there is an intuitively obvious relation-
ship between an operating procedure and the
output of an AI planning system.
AI planning constructs a plan automati-
cally using a model of the domain and a
knowledge base of relevant actions. Each
action has a set of logical pre-conditions,
defining the situation in which it must be
applied, and a set of post-conditions, defining
the effects of carrying it out. For example, a
general GRASP action for a robot arm might
have the following pre-conditions:
1 The object to be grasped is in a given
location.
2 The robot arm is in the same location.
3 The robot gripper is empty.
4 The robot gripper is open.
The post-conditions, or effects of carrying out
a GRASP action would then be:
1 The object location is now in the gripper
of the robot.
2 The robot arm is in the same location as
before.
3 The robot gripper is full.
4 The robot gripper is closed.
Note that this general action can be used for
any robot in any location grasping any object
by instantiating its pre- and post-conditions
to particular values.
A particular planning problem consists of a
description of the initial state of the world (in
the robot example, the objects in the world
and the location of each, together with the
initial state of the robot) together with a
description of the goals that should be true in
the desired end-state of the world. The
planner will then build a sequence of actions
from those in its repertoire which when
executed will produce the desired end-state
from the given initial state. In the robot
example a sequence of GRASP, RELEASE,
and TRANSPORT actions might be con-
structed to solve a specific bin-packing pro-
blem.
Now the steps in an operating procedure
are actions to be carried out; the procedure is
designed to take a plant from a start state to
an end state; each step in the procedure must
be carried out in the appropriate state and
will result in a new state. This clearly
matches the description of AI planning just
given. However, only Aelion and Powers
(1991) of the works referenced above have
seriously considered AI planning technology,
and in this case a linear STRIPS type engine
was used, dating back to the mid-1970s (Fikes
and Nilsson, 1971). Much work has been
carried out in AI planning since then, and in
[ 329 ]
 Ruth Aylett, Gary Petley,
P.W.H. Chung, James Soutter
and Andrew Rushton
Generating operating
procedures for chemical
process plants
Integrated Manufacturing
Systems
10/6 [1999] 328±342
Downloaded by University of South Carolina Libraries At 14:42 12 July 2016 (PT)
[ 330 ]
particular planners which use a hierarchy of
actions and which apply ``least-commitment''
(Weld, 1994) techniques have been developed.
The failure to draw on these techniques has
limited the scope of the systems developed so
far to ``toy'' plant domains and has led to a
number of specific omissions: for example,
the inability to deal with the creation of flows
of chemicals by the opening and shutting of
valves, while at the same time reasoning
about the filling of a tank or the starting up of
a heater.
A small-scale example
Having outlined why AI planning is seen as
an appropriate technique for OPS, we now
demonstrate some of the basic problems in
creating operating procedures with a small-
scale ``toy'' example (Soutter and Chung,
1997). This consists of a plant with inputs of
acid, alkali and water, and two vessels as
shown in Figure 2.
There are three objectives in the operation
of this plant: to charge vessel 1 with acid; to
create a flow of acid to vessel 2; and to create
a flow of alkali to vessel 1. However, there are
also two safety considerations: first, acid and
alkali may not mix in the pipework but only
in the reaction vessels; and second, vessel 2
must contain acid before vessel 1 contains
alkali to allow for the proper cooling of the
reaction vessels. In order to operate this
Figure 2
A simple OPS example
plant correctly, not only must flows of
chemical be created through paths which
meet the safety conditions, and not through
others, but also ``purging'' ± passing a neutral
chemical down a flow path to clean it ± is
required at a specific stage.
Then the system described in this paper
generates the procedure shown at the bottom
of Figure 2 in one second on a Sparc IPX
station. Instructions 1-3 result in vessel 1
filling with acid; instructions 4-5 purge the
pipework with water in order to meet the
first safety criterion; finally, instructions 7
and 8 establish the required flows in the
correct order. Note that if Step 7 had pro-
duced the flow of acid through the top route
in the plant ± by opening f,d,b,e and g ± this
would have violated the first safety criterion
as soon as Step 8 started the alkali flow
through part of the same route.
This example is a long way from the
complexity of a real plant, but earlier OPS
systems were nevertheless unable to gener-
ate this procedure.
The chemical engineering planner
(CEP)
The chemical engineering planner (CEP),
discussed in this paper, has been developed
over the last five years, initially as a PhD
project (Soutter, 1996) and in the last two
years as part of the EPSRC-funded
 Ruth Aylett, Gary Petley,
P.W.H. Chung, James Soutter
and Andrew Rushton
Generating operating
procedures for chemical
process plants
Integrated Manufacturing
Systems
10/6 [1999] 328±342
Downloaded by University of South Carolina Libraries At 14:42 12 July 2016 (PT)
INTergrating OPerability (INT-OP) project
being carried out jointly between Loughbor-
ough and Salford Universities in the UK. CEP
is being developed incrementally through
case studies of increasing scope and com-
plexity, and as the case study discussed in
this paper shows, is already more capable
than any of the systems referenced earlier.
We will only summarise the structure of CEP
in this paper.
CEP divides the tasks involved in OPS into
three areas: planning using operators, the
handling of safety considerations and valve
sequencing. The first two of these three areas
are handled by a state-of-the-art least-com-
mitment planner (Penberthy and Weld, 1992),
which uses the concept of ``goals of preven-
tion'' (Soutter and Chung, 1996) to prevent
actions being incorporated into the operating
procedure that will take a plant through any
unsafe states. Safety is clearly a particular
concern in a chemical plant domain: a plan
which moves the plant to a desired end-state
is unacceptable if, for example, along the way
explosive gases have been mixed together.
``Goals of prevention'' are defined as safety
restrictions as part of the overall description
of the plant and those required for the DEE
domain are discussed below.
CEP deals with valve sequencing as a
special case. A characteristic of the opening
and closing of valves in a chemical plant ±
actions required in order to produce flows of
chemicals to specified vessels or other com-
ponents ± is that the effect of the action at a
particular valve is dependent on associated
actions at other valves. However, an as-
sumption of the standard AI planner repre-
sentation of actions is that the effect of an
action should be represented through its
post-
conditions ± and should therefore always be
the same. Valve operations violate this
assumption (Aylett et al., 1998).
Therefore, valve sequencing is handled by
a specialist module in CEP that uses an
approach that we call ``action synergy'' and is
based on work by O'Shima (1978) and Foulkes
et al. (1988). A maze-searching algorithm is
used to find a route for a flow between given
start and end points. All the valves around
this route are then closed and finally those
actually on the route are opened. Thus CEP
can be seen as a general-purpose AI planner
with domain-related specialist additions.
Double effect evaporator (DEE)
An incremental approach was taken to the
development of CEP through its application
to case studies of increasing complexity.
First it was applied to all the ``toy'' problems
discussed in the literature by previous
workers in this area (except for those
requiring the handling of numerical quanti-
ties which were excluded from CEP's scope).
Having successfully produced correct oper-
ating procedures from these examples, it was
decided that CEP should be applied to a real-
world plant. The jump from ``toy'' problems to
the whole of an ammonia plant, say, was felt
to be too large, and so a small plant equiva-
lent in complexity to a section of a commer-
cial plant was sought.
The case study discussed in this paper used
a DEE test rig constructed in the chemical
engineering department at Loughborough
University. Although no longer used, the test
rig was designed for teaching basic princi-
ples of plant operation to chemical engineer-
ing students. The layout of the test rig is
shown in the plant diagram (see Figure 3).
This Figure shows the complexity of the
domain for this case study, which is much
nearer to a real-world chemical plant than
the domains used in the previous work
referenced above. Not only does the DEE set-
up contain a larger number of components
than in most previous domains, but the
number of different types of equipment is
also large, with valves, controllers, pumps,
heaters, coolers, evaporators, feed tank,
mixing tank and a barometric condenser.
The purpose of the DEE is to remove water
from a salt-water solution (known as brine).
It is called ``double effect'' because the steam
that is evaporated off from the brine solution
in the first evaporation is used to supply the
energy for the second evaporation. Because
the test rig was used for teaching, the
concentrated brine is returned to the starting
point and mixed with water to return the
brine solution to its original concentration of
salt, thus allowing the process to continue
indefinitely. A diagram of the basic process is
shown in Figure 4.
Methodology
Two closely-coupled steps are involved in
applying a planner to a new domain: knowl-
edge acquisition and domain modelling. In
the DEE case-study, knowledge was acquired
by reading the documentation on the test rig,
visiting the DEE installation, and by inter-
viewing a Loughborough University collea-
gue with an understanding of the working of
the test rig. While there are important issues
here, we will not touch on them in this paper.
We will, however, discuss domain model-
ling in more detail, as the amount of time and
effort required to construct a particular
[ 331 ]
 Ruth Aylett, Gary Petley,
P.W.H. Chung, James Soutter
and Andrew Rushton
Generating operating
procedures for chemical
process plants
Integrated Manufacturing
Systems
10/6 [1999] 328±342
Downloaded by University of South Carolina Libraries At 14:42 12 July 2016 (PT)
Figure 3
Plant diagram for double effect evaporator test rig
[ 332 ]
domain model is a major obstacle to the use
of AI planning in the solution of real-world
problems (Chien et al., 1996). If CEP is to be
used by design engineers for real industrial
plant, it must be straightforward to construct
the domain model. We therefore report the
lessons learned from the DEE case study.
Domain modelling
After knowledge acquisition, the information
acquired must be transformed into a form
that the planner CEP can understand and
use. CEP requires the following:
. Domain description (plant model).
. Pairs (knowledge association).
. Planning operators (actions that can be
carried out).
. Safety restrictions.
. Domain problems (what plant operations
are to be carried out).
We discuss each of these areas in the follow-
ing sections.
Domain description
The elements and configuration of a process
plant can be described symbolically in terms
of a hierarchy of components and the con-
nections between them. The complete taxon-
omy for the components in the DEE domain
is shown in Figure 5. CEP uses an imple-
mentation of a hierarchical frame-based
description developed during earlier work at
Loughborough (Chung, 1993) to model indi-
vidual components in a particular plant.
Figure 6 shows the frame definitions for a
component type within the framework of the
component hierarchy and then provides an
example of the description of one such
component.
As the complexity of Figure 3 demon-
strates, the manual entry of these descrip-
tions for every component in a particular
plant using CEP's syntax is non-trivial: it is
both very time-consuming and prone to
error. An automatic system was therefore
developed for producing the domain descrip-
tion. A popular drawing package, AutoCAD,
has been adapted to provide the standard
chemical engineering equipment symbols for
the user. When a new piece of equipment is
added to the plant diagram, a text box
appears prompting the user to add the name
 Ruth Aylett, Gary Petley,
P.W.H. Chung, James Soutter
and Andrew Rushton
Generating operating
procedures for chemical
process plants
Integrated Manufacturing
Systems
10/6 [1999] 328±342
Downloaded by University of South Carolina Libraries At 14:42 12 July 2016 (PT)
Figure 4
Basic process for double effect evaporator test rig
and connections for it. Thus on completion of
the drawing, the necessary information has
been collected to allow the automatic crea-
tion of a file, in the form of the instance
shown in Figure 6, that describes the plant to
CEP. Thus, little extra work is required
beyond that which a plant designer would
already undertake in designing the plant
layout.
Figure 5
DEE component hierarchy
Pairs
A chemical plant is a large and complex
configuration of numerous components,
producing enormous search spaces when
planning. Engineering line drawings (ELDs)
contain extra information associating ele-
ments of plant specific knowledge which CEP
can use to narrow down the search space.
The pairs in Figure 7 from the DEE domain
state that heat exchanger HE1's source of
heat is from Input 4, and this input is
supplying steam. Pairs are currently entered
manually, but it is clear that they could be
integrated into the existing capture of the
plant configuration within AutoCAD.
Planning operators
The next stage is to develop the planning
operators used to produce the plan (the
operating procedure). Where the domain
description gives the static content and
layout of a plant, planning operators define
its behaviour. A CEP operator consists of a
goal(s) that can be achieved when the pre-
condition(s) for the operator are true ±
essentially the STRIPS (Fikes and Nilsson,
1971) representation still widely used in AI
planning systems in spite of all the other
changes in the field since then. The CEP
operator for operating a control valve is
shown in Figure 8.
In this operator, the identifiers starting
with ``?'' represent variables which will be
instantiated with actual components when
the operator is used: ?c with the particular
control valve, ?state1 with the initial state of
the valve, ?state2 with the final state of the
valve. Thus one action can be instantiated to
operate any of the many control valves in
Figure 3. The primitive operator that is
shown in Figure 8 was supplemented with
macro operators (Figure 9), which allow
[ 333 ]
 Ruth Aylett, Gary Petley,
P.W.H. Chung, James Soutter
and Andrew Rushton
Generating operating
procedures for chemical
process plants
Integrated Manufacturing
Systems
10/6 [1999] 328±342
Downloaded by University of South Carolina Libraries At 14:42 12 July 2016 (PT)
Figure 6
Example CEP domain description
[ 334 ]
information about the order in which the pre- Figure 7
conditions must be satisfied to be entered Example pair descriptions
(Aylett et al., 1998).
Operator development is a time-consuming
and difficult part of domain development and
one on which there is minimal guidance in
the literature. Yet the correctness and effi-
ciency of the planning process in a domain
depend very heavily on operator definition.
We therefore summarise the lessons of the Figure 8
DEE case study for operator development in Operator-control valve
the sections below.
Required operators
The initial step is to establish the task
requirements by producing a list of all the
tasks to be carried out in the domain. For
example, the DEE requires operating proce-
dures to start the plant up as a single effect or
double effect; to shut the plant down; to
switch between the previous states; to isolate
pieces of equipment for maintenance or to
deal with emergency situations. Therefore,
operators are required for the start-up and
shutdown of each piece of equipment in the
test rig.
Generality of operators
One important issue concerns the generality
of operators. The more generic the operators,
the fewer the number required, and, even in Figure 5, an operator at the level of vessel
more important, the greater the scope for
would be too general since there are signifi-
re-use. On the other hand, operators must be
cant differences in functionality between,
specific enough in relation to the domain
say, an evaporator and mixing tank, and
description to prevent vast amounts of search
instantiation would have to consider every
when instantiating pre- and post-conditions
vessel in a plant.
(Aylett and Jones, 1996) and to capture
It was decided to limit the number of
appropriate differences in functionality. For
operators by using those generic to any piece
example, in the DEE class hierarchy shown
of equipment of the same type, where type
was defined as one of the leaves in the class
hierarchy for the domain shown in Figure 5.
Thus an operator for a control valve, as
shown in Figure 8. One might expect opera-
tors for particular types of equipment to
occur in pairs: one for start-up and one for
shutdown. While this generally proved to be
the case, sometimes it was possible to com-
bine both into one operator acting as a toggle
between states ± as in the case of valves,
further reducing the number of operators
that are necessary.
Library of operators
A consequence of producing generic plan-
ning operators is the possibility this opens up
of providing a good-quality library for
equipment commonly found in chemical
plants, such as valves, pumps, heat exchan-
gers, etc. (Petley et al., 1998). A suitably
comprehensive library would standardise
the design of operators by reducing the task
to one of selection, with possibly some scope
for specialisation. Indeed, without such a
 Ruth Aylett, Gary Petley,
P.W.H. Chung, James Soutter
and Andrew Rushton
Generating operating
procedures for chemical
process plants
Integrated Manufacturing
Systems
10/6 [1999] 328±342
Downloaded by University of South Carolina Libraries At 14:42 12 July 2016 (PT)
Figure 9
Macro-active evaporator
library it is hard to see how CEP could be
applied to new plants in an industrial con-
text, since one could not expect a plant design
engineer to design the planning operators
from scratch. The DEE case study discussed
here provided the first generic operators for
the library which has been extended by two
later case studies, an ICI and a BP plant, as
new components have been encountered. An
interface for accessing the library of equip-
ment operators is being designed.
As we will see below, one criterion for
evaluating the success of CEP in the case-
study domain was the extent to which it
proved possible to solve the required tasks
with generic operators. A number of inter-
esting issues arose which will be discussed
later.
Hierarchical structure of operators
There is a substantial difference in granu-
larity between the task requirement level
(e.g. start-up plant in single-evaporator
mode) and the primitive action level (e.g.
open valve HV5) in OPS domains. This shows
(Aylett and Jones, 1996) a clear need for a
hierarchical structure in all the operators in
the model. The task of starting up the plant in
double-evaporator mode is represented as a
high-level operator (see Figure 10), with an
effect which expands into a set of goals
satisfied by operators at the next level of
expansion. These, in turn, may expand the
effects further to a new level of operators.
The result is a goal-hierarchy which repre-
sents the declarative structure of planning
in the domain. The goal-hierarchy for the
DEE domain can be seen in Figure 11,
showing that the top-level goals for the
system concern the state of the DEE system
itself, expanding into the states of vessels and
temperature changers, which may be started
or stopped.
These expand, in turn, into fill and flow
goals, where each may be true or false ± the
goal of making a fill false is equivalent to
emptying a vessel, for example. At the lowest
level, goals reduce to the states of valves and
pumps. Thus there are three types of opera-
tor: expansion operators (Figure 10), macro
operators (Figure 9) and primitive operators
(Figure 8). The latter two include print
statements that are used to display the final
operating procedure and use the key word
``achieve'' and ``solve'' in place of the key
word ``expand''.
Safety restrictions
Safety restrictions in CEP are constraints
that prevent unsafe situations from occur-
ring during planning through the specifica-
tion of incompatible states. Figure 12 is an
example of a safety restriction for the DEE,
which specifies that glass preheater GP1 is
not allowed to be started if the state of the
glass cooler GC1 is stopped. The reason for
this restriction is to prevent energy from
entering the plant ± heater on ± before there
is a mechanism for energy to leave the plant ±
cooler on.
Safety restrictions allow issues of safety to
be dealt with separately from the design of
planning operators. An alternative approach
would have been to add extra pre-conditions
to operators specifying safe states for their
use. Thus, the safety restriction, as shown in
Figure 12, could be replaced by an operator
for activating GP1 with a precondition that
the glass cooler is on, though in general this
may require both quantification and dis-
junction in the operator pre-conditions.
There are two arguments against this
approach: first, incorporating the restriction
into a particular planning operator will not
prevent the glass cooler being turned off
while the heat exchanger is still on at a later
stage in the plan. Second, such an operator is
specific to a particular heat exchanger, GP1,
and so it is not generic. For these reasons, we
argue that restrictions should be used in
preference to modified operators. In addition,
the use of safety restrictions ensures that
safety knowledge is represented in one place,
[ 335 ]
 Ruth Aylett, Gary Petley,
P.W.H. Chung, James Soutter
and Andrew Rushton
Generating operating
procedures for chemical
process plants
Integrated Manufacturing
Systems
10/6 [1999] 328±342
Downloaded by University of South Carolina Libraries At 14:42 12 July 2016 (PT)
Figure 10
Hierarchical operator
Figure 11
Goal hierarchy for the DEE domain
[ 336 ]
where it can be assessed and checked against
safety regulations, an important considera-
tion for user acceptance in the industry. We
will return to this issue in a later section
since it is an example of a general point: it
appears that problematic aspects of a domain
can often be dealt with by manipulating
planning operators but that such solutions
turn out in practice to be very much ad hoc.
Domain problems
Finally, a definition of a problem in the
domain for the planner to solve is required.
The problem definition requires two domain
states, one at the start and the other at the
end of the problem. In general, a domain state
is defined by setting the state of each
component in the plant, though in practice
this is not necessary for end-states in which
only the high-level goals to be achieved are
specified. From this, CEP will produce a plan
consisting of a sequence of actions that bring
Figure 12
Example safety restriction
about the specified change in the plant, if one
exists for the given operators and restric-
tions. The AutoCAD tool used to provide the
domain description also provides a method
for defining the state of the equipment for a
domain state, allowing the domain problem
descriptions to be developed in parallel with
the domain description.
Results and evaluation
CEP successfully produced operating proce-
dures for the DEE. A single model of the
domain allowed procedures to be created for
the start-up, shutdown and the isolation of
pieces of equipment for maintenance.
The start-up procedure generated by CEP
for the DEE is found below and contains 52
steps:
Check regulators and set controllers:
1 check regulator PRe_2 setpoint
2 heck regulator PRe_1 setpoint
3 Set controller PC_4 and turn on
4 Set controller PC_3 and turn on
5 Set controller FRC_4 + LRC_2 and turn on
6 Set controller FRC_1 and turn on
7 Set controller FRC_2 and turn on
8 Set controller FRC_3 + LRC_1 and turn on
9 Set controller LRC_5 and turn on
10 Set controller FRC_6 and turn on
11 Set controller LRC_7 and turn on
12 Set controller FRC_8 and turn on
13 Set controller TRC_9 and turn on
Make brine:
14 Open valve HV7
15 Open valve HV25
16 Open valve HV6
17 Turn on pump P3
18 Open valve HV32
19 Close valve HV32
Flows to and from Evaporator E1:
20 Open valve HV16
21 Open valve HV20
22 Open valve HV1
23 Open valve HV4
24 Open valve HV5
25 Turn on pump P3
26 Turn on pump P1
27 Open valve HV11
28 Open valve HV2
29 Open valve HV10
30 Turn on pump P2
Activate glass cooler:
31 Open valve HV31
32 Open valve HV24
Activate glass preheater:
33 Open valve HV26
34 Open valve HV22
 Ruth Aylett, Gary Petley,
P.W.H. Chung, James Soutter
and Andrew Rushton
Generating operating
procedures for chemical
process plants
Integrated Manufacturing
Systems
10/6 [1999] 328±342
Downloaded by University of South Carolina Libraries At 14:42 12 July 2016 (PT)
35 Open valve HV28
36 Wait until air flushed out of GP1
37 Close valve HV26
Activate heat exchanger:
38 Open valve HV27
39 Open valve HV23
40 Open valve HV29
41 Wait until air flushed out of HE1
42 Close valve HV27
Attain vacuum in spray condenser:
43 Open valve HV21
44 Open valve HV19
45 Wait for SC1 to fill with process water
46 Turn on Pump P4
Flows to and from Evaporator E2:
47 Open valve HV18
48 Open valve HV14
49 Open valve HV15
Activate catchpot:
50 Open valve HV13
51 Wait until air flushed out of HE2
52 Open valve HV12
The total number of operators used in plan-
ning was 19. The time taken to generate the
operating procedure was under five seconds
on a Sparc 5. Moreover, CEP proved capable
of finding alternative procedures via back-
tracking at user request.
Comparison with previous systems
The planner CEP has been used to produce
operating procedures using AI planning for a
domain more complex than any other pre-
viously attempted. The work of the early
1980s (Ivanov et al., 1980; Kinoshita et al.,
1981) using state-graphs limited sample pro-
blems to plants containing a handful of
valves because of the number of states they
generated: 20 valves each with two states
produces 1,048,576 nodes in a state-graph.
Other workers used larger plant (Rivas and
Rudd, 1974) but only considered valves and
not vessels. A real-world nuclear fuel pro-
cessing plant was used in Crookes and
Macchietto (1992), but this work concentrated
on optimising a hand-generated plan. CEP
has successfully solved every sample pro-
blem reported in the OPS literature except
for those requiring numerical calculations.
We therefore argue that CEP's success in this
case study demonstrates a big step in the
state-of-the-art for OPS.
Quality of results
The procedures produced were evaluated by
the same domain expert who had been used
for knowledge acquisition. He found the
generated procedures adequate ± in the sense
that the start-up procedure would
successfully start up the plant. This is an
important result for a domain of this com-
plexity and validates the overall approach of
using AI planning technology on this pro-
blem. However, he also found the generated
procedures in some ways naõÈve ± in the sense
that they were not always identical to the
ones an expert would produce.
A major example of this concerned the use
of the glass preheater (GP1 in the top-left of
Figure 3). It is possible to start up the plant
without using this preheater, and accord-
ingly CEP originally generated a procedure
that did not use it. The reasons for using the
preheater during start-up are: the tempera-
ture of the brine can be increased in stages,
protecting the glass-lined vessels, and the
control of the temperature of the brine
entering the first evaporator is easier with
two heaters. An expert in operability, seeing
that the design contained a glass preheater,
would infer that it was there for the purpose
of start-up and accordingly use it. This
operability knowledge does not appear to be
representable within the confines of planning
operators and we are currently examining
the issue in more detail.
Producing a start-up procedure which did
use the glass preheater, as seen in the list,
required the use of the restrictions mechan-
ism discussed. The restriction shown in
Figure 13 states that a flow cannot occur
through the glass preheater, and therefore
the rest of the plant, until the preheater is on,
forcing its use. While the restrictions me-
chanism provides a general capability which
can be used for other issues than safety, its
use in this way is an ad hoc solution, since it
does not explicitly represent the operability
knowledge being used but only the plant-
specific consequences of applying it. We are
exploring the possibility of dealing with such
issues in a more generic way. For example,
the domain expert reports that ``start the cold
side of the plant before the hot side'' is a
general plant operations heuristic which
could sensibly be encoded in a restriction.
A further quality issue concerns the glass
cooler (GC1 in Figure 3) in the test rig. The
cooler is turned on by flowing cooling water
Figure 13
Glass pre-heater restriction
[ 337 ]
 Ruth Aylett, Gary Petley,
P.W.H. Chung, James Soutter
and Andrew Rushton
Generating operating
procedures for chemical
process plants
Integrated Manufacturing
Systems
10/6 [1999] 328±342
Downloaded by University of South Carolina Libraries At 14:42 12 July 2016 (PT)
[ 338 ]
through it at any time before there is a flow of
brine into the cooler. Now, the smaller the
time gap between turning on the cooler and
the brine arriving, within the constraints of
safety, the smaller the amount of cooling
water wasted and the more economical the
start-up of the operating procedure.This kind
of optimisation is not, we feel, well handled
by a planner and suggests the need for an
optimising back-end such as that in the work
of Crookes and Macchietto (1992).
Linking and ordering actions
The output of a partial-order planner such as
CEP is a plan-network in which only those
actions which must follow each other are
ordered with respect to each other. Actions
which may be taken in any order appear in
parallel in such a representation. For exam-
ple, a plan to make a cup of instant coffee
might be represented at a high level as: fill
and boil the kettle; get cup, coffee, sugar and
milk; put coffee and sugar in cup; add boiling
water; add milk. The plan will still work
whether the kettle is boiled first or the cup
and other materials are assembled first, so
that these actions may be partially ordered.
On the other hand, it is not possible to put
boiling water into the cup until after the
kettle has boiled, so these actions must occur
in that order.
It is usual for the last step in an AI planner
to be the transformation of the plan net into a
linear sequence, since usually only one-step-
at-a-time execution is planned for. This
process is known as linearisation. As the
example above demonstrates, there may be
reasons apart from ``any order that works''
for linearising in a particular way: most of us
would prefer to put the kettle on before
assembling the other materials since we
know that it takes time to boil the kettle and
the overall time for the task will be shorter if
we assemble the materials while this hap-
pens. In addition, while it is still possible to
make a cup of instant coffee if the milk is
added before the boiling water, many people
would not do this since they feel the coffee
tastes better if the water really is boiling
when it is poured on rather than being
instantly cooled by the presence of milk.
Thus questions of efficiency and quality may
arise at linearisation.
A number of comparable issues arose from
considering the linearisation process for CEP
in which its partially ordered output is
turned into a sequence of operating instruc-
tions. An extract from a plan net generated
by CEP can be seen in Figure 14 and
represents a plan fragment for the operation
of an evaporator. Figure 14 shows that
actions OperateGlassPreheater-3, Operate-
HeatExchanger-4 are partially ordered and
thus can be taken in any order.
However, it may be the case that some
actions which are in a particular order in the
plan really should be carried out one im-
mediately after another, without interpola-
tion of other actions partially ordered with
respect to them. For example, changing the
operation of the plant from using one eva-
porator to using both requires the opening of
one valve and the closing of another at
virtually the same time to create a flow of
steam through the second heat exchanger.
One would not wish other valve operations
elsewhere in the plant along a different
branch of the plan graph to be inserted into
this sequence even though this linearisation
is formally possible. As a step towards
capturing this type of dependency, CEP's
original linearisation mechanism was
rewritten so that all the actions down one
parallel branch of the plan net are placed
together ± in other words, depth- first ex-
pansion was applied to parallel branches
rather than any other ordering. We are also
considering the use of short links between
actions that allow the links in the plan graph
to carry the information that actions should
be kept close together at linearisation
(Soutter and Chung, 1997).
The plan net supports user interaction in
the linearisation process since it shows what
actions can be moved in a particular linear-
isation and which cannot. The re-ordering of
actions may be desirable for two reasons in
addition to the one just discussed. First,
grouping actions together for operating a
certain piece of equipment makes the plan
clearer. Second, a ``better'' plan may be
produced by taking the actions in a certain
order. For example, if two valves have to be
opened manually, then these actions should
be together if they are geographically next to
each other in the plant. CEP cannot currently
take geographical proximity into account,
however, since the ELD from which it works
contains only the topological relationship of
equipment.
Generic operators
We argue that the extent to which operators
are generic is a touchstone for the extent to
which CEP has principled solutions to the
problems of OPS. We have seen above that
both the use of safety restrictions and of
a specialist valve sequencing component
removes the need to solve particular pro-
blems by manipulating the operators into a
plant-specific form. An earlier version of the
DEE case study required a number of ad hoc
fixes, implemented in plant-specific planning
operators, but careful analysis of the issues
 Ruth Aylett, Gary Petley,
P.W.H. Chung, James Soutter
and Andrew Rushton
Generating operating
procedures for chemical
process plants
Integrated Manufacturing
Systems
10/6 [1999] 328±342
Downloaded by University of South Carolina Libraries At 14:42 12 July 2016 (PT)
Figure 14
Plan net for operating evaporator E1
involved produced improvements to CEP ± in
particular its valve-sequencing component ±
which have solved these problems in a more
principled way.
In the DEE case study, every component is
now operated by a generic operator, all of
which are found in a component operator
library. Moreover, 13 of these operators were
reused for a subsequent case study using
the back-end loop section of an ICI ammonia
plant, and six for the corrosion metal
removal system of a BP acetic acid plant,
demonstrating the value of a library of
planning operators.
A more important issue concerns the
extent to which real-world components in
process plant are generic. For example, of the
two heat exchangers in the DEE test rig,
one has an extra out port for the steam used
to heat the material passing through the
exchanger. In real plants, components are
sourced from a variety of manufacturers and
so there may be differences in the way each
is constructed and operated. If this variation
is empirically shown to be very large, a
generic library of operators might be impos-
sible. An obvious approach to this problem
is to consider attaching the library of
operators more firmly to the component
hierarchy, with the use of object-oriented
inheritance and specialisation mechanisms
to control variation, and this is now being
investigated.
Scaling up
While the DEE is a real-world plant, it is very
small compared to most industrial plant.
Thus for CEP to be used by plant designers,
scaling-up issues must be investigated. Two
further case studies have been completed
since the DEE, one of the ICI ammonia plant
mentioned above, and the other of a BP acetic
acid plant. In both cases, it was found that
operations staff viewed the plant as a small
(six or less) set of ``chunks'', that is, large
functional units, such as the ``back-end loop''
referred to in connection with the ICI plant.
They then conceptualised the operation of
the plant at an abstract level in terms of these
functional units. As discussed in the next
section, this ``chunking'' process originates
in design. Each of the functional units we
examined was of the same order of complex-
ity in terms of numbers of components and
connections between them as the DEE. We
therefore argue that a large plant may be
hierarchically decomposed and that CEP is
capable of dealing with its functional units in
the same sort of time as the DEE.
Usability issues
The work on the DEE and later case studies
indicates the technical feasibility of OPS
based on AI planning technology. However,
this is not the only factor in producing an
industrially useful application: it is also
vital to consider how the technology can
be integrated into existing business pro-
cesses and methods of working if it is in
fact to be taken up in practice. As argued at
the start of this paper, the maximum busi-
ness benefit can be obtained from OPS if it is
used at an early stage in the plant life-cycle,
so that design decisions are not made which
impact operability and have to be changed
later on. Three consequences follow from
this.
First, at the ELD stage of the design
process, a real-world plant is decomposed
into a number of sub-assemblies, each
associated with a set of ELDs. Each set of
ELDs then normally goes through HAZOP
separately as and when they are ready.
Investigation to date suggests that this
decomposition is normally based on the main
functional elements of a plant, though the
utilities and services required by a number
of sub-assemblies are also usually grouped
together into one set of ELDs. Thus not only
is it desirable ± as discussed in the
last section ± that CEP supports OPS in
functional subsets of the plant, but also it is
in fact very important that it does not force
the whole plant to be considered at one time.
The CEP domain representation does
indeed allow the plant to be split into pieces
like this.
A second consideration is the need to
support the generation of high-level proce-
dures at the early stages of design, possibly at
the process flow sheet stage. CEP supports
this through the hierarchical definition of
actions, though further work is needed in
this area. Finally, a plant is often designed
around a few major procedures, such as start-
up, so that operability problems are more
likely to manifest themselves in less-
[ 339 ]
 Ruth Aylett, Gary Petley,
P.W.H. Chung, James Soutter
and Andrew Rushton
Generating operating
procedures for chemical
process plants
Integrated Manufacturing
Systems
10/6 [1999] 328±342
Downloaded by University of South Carolina Libraries At 14:42 12 July 2016 (PT)
[ 340 ]
considered areas such as maintenance. CEP
has an important role to play here in allow-
ing a much wider range of operational
conditions to be considered.
Support for user interaction is the other
important consideration in relation to sys-
tem usability. The user ± say a process design
engineer ± must be able to use a system
easily, have confidence and a feel for the way
the procedures are generated, and be able to
understand the resulting procedure. Tools
have been developed to help the user create
and debug the domain and are in the process
of development for operator development and
problem definition.
The user can gain an understanding of how
the procedure has been generated within
CEP through various outputs. Planning can
be thought of as a search problem for the
correct sequence of actions in a very large
space containing all possible combinations of
actions with all possible instantiations of the
variables in them. CEP allows the user to
view that section of the search space it
traversed in building its plan, giving an
insight into the choices it made and the
difficulties it encountered.
CEP also allows varying amounts of details
on the planning process to be displayed and
gives the user some ability to interact with
the process of plan generation. This is
achieved by allowing the user to select the
type of goal for CEP to solve first. Investiga-
tion suggests that this is essential since
professional engineers would not accept a
system in which planning was wholly auto-
matic and they were unable to apply their
own expertise.
The form in which the generated procedure
is displayed is also important. CEP can show
the procedure as a text list of actions, which
are in a similar format to the manually
generated procedures with which the user
will be familiar. In addition, the procedure
can be shown as a plan-net of the type
discussed above, showing the ordering rela-
tionships between actions in the plan and
thus the possible orders allowable after
linearisation. This allows the user to alter
the ordering of some of the actions in the
original text list, while respecting the essen-
tial ordering constraints.
Conclusions
A number of conclusions can be drawn from
the DEE case study, some specific to the
domain of process plant operating procedure
synthesis, and others of more general rele-
vance to industrial applications of AI
planning.
A positive conclusion is that the DEE case
study validates the use of state-of-the-art AI
planning techniques in OPS. As discussed,
this has made it possible to deal successfully
with a large and complex domain. Further
case studies have taken place using full-scale
industrial plants ± an ammonia plant and an
acetic acid plant ± belonging to the project's
industrial collaborators.
During the DEE case study, it became
clear that a number of improvements were
needed: in the linearisation process, in the
valve sequencing component and in the
incorporation of general operability knowl-
edge: all of these improvements have now
been made. We argue that this indicates that
though general-purpose hierarchical least-
commitment planning algorithms are
powerful, real domains also require domain-
specific problem solving along with a great
deal of domain-specific knowledge. Hope-
fully, in the same way as work in knowledge-
engineering methodologies has identified
specific approaches to different types of
diagnosis, work in a wider range of real-
world planning domains will begin to estab-
lish abstract categories in such domains
which will support a more principled
approach to the choice of planning technolo-
gies for particular problems (Valente, 1995;
Aylett and Jones, 1996; Soutter and Chung,
1997).
A number of knowledge engineering issues
arose from the DEE case study. First, the
time and effort required to develop the
domain was substantial, with about 20 per-
son-days of effort involved in developing the
operators alone (though a proportion of this
was due to a learning curve which would be
climbed quicker next time as a result of this
experience). Development of tools to assist in
domain development is, we believe, vital to
the use of AI planning to solve real-world
problems. The automatic generation of the
domain description, as for CEP from Auto-
Cad, is a step along this path, and the library
of generic operators derived from the case
study is another even more important one.
Validation and verification tools such as
those described in Chien (1996) are also
important.
The production of a library of generic
operators in the DEE case study illuminated
a particular problem. It is often possible to
solve problems in a particular domain by
ad hoc fixes, frequently in the planning
operators. We discussed a number of these
above and remarked that a measure of CEP's
ability in this domain lay in how many or few
such fixes were required. As CEP's capabil-
ities were increased, so it became possible
to solve each problem in a more general
 Ruth Aylett, Gary Petley,
P.W.H. Chung, James Soutter
and Andrew Rushton
Generating operating
procedures for chemical
process plants
Integrated Manufacturing
Systems
10/6 [1999] 328±342
Downloaded by University of South Carolina Libraries At 14:42 12 July 2016 (PT)
and principled way. Thus not only is the
ability to produce a library of generic opera-
tors an indispensable tool for domain devel-
opment in the future, but also it is, we argue,
indirectly a measure of the adequacy of a
planner.
We argue that AI planning technology
has now reached a level of maturity where
it can be successfully applied to difficult
real-world problems. Just as KBS technology
in general has made a powerful contribution
to the management of manufacturing
systems, so AI planning has the potential to
solve problems in this area previously
seen as too complex to be tackled success-
fully.
In particular, OPS is a new applications
area for AI planning, but we suggest one of
considerable promise. The DEE case study
forms the basis for continuing work in the
INT-OP project towards a system which can
be used in a real-industrial environment to
produce quality operating procedures earlier
in the plant life-cycle with real savings in
time and effort. We note that plant operating
procedures are only one example of the need
for accurate, efficient and safe procedures in
manufacturing industries and see many
possibilities for extending the AI planning
approach to the generation of other types of
operational procedure.
References
Aelion, V. and Powers, G.J. (1991), ``A unified
strategy for the retrofit synthesis of flowsheet
structures for attaining or improving operat-
ing procedures'', Computers and Chemical
Engineering, Vol. 15 No. 5, pp. 349-60.
Aylett, R.S. and Jones, S.D. (1996), ``Planner and
domain: domain configuration for a task
planner'', International Journal of Expert
Systems, Vol. 9 No. 2, pp. 279-318.
Aylett, R.S., Soutter, J., Petley, G., Chung, P.W.H.
and Rushton, A. (1998), ``AI planning in a
chemical plant domain'', Proceedings of the
13th European Conference on Artificial
Intelligence, ECAI '98, pp. 622-6
Chien, S.A. (1996), ``Static and completion analy-
sis for planning knowledge base development
and verification'', Proceedings of the 3rd
International Conference on AI Planning
Systems, AAAI Press, pp. 53-61.
Chien, S.A., Hill, R.W., Wang, X., Estlin, T.,
Fayyad, K.V. and Mortenson, H.B. (1996),
``Why real-world planning is difficult: a tale of
two applications'', in Ghallab, M. and Milani,
A. (Eds), New Directions in AI Planning, IOS
Press, Washington DC, pp. 287-98
Chung, P.W.H. (1993), ``Qualitative analysis of
process plant behaviour'', in Chung, P.W.H.,
Lovegrove, G. and Ali, M. (Eds), Proceedings ±
Industrial and Engineering Applications of
AI and Expert Systems, Gordon and
Breach, Cooper Station, New York, NY,
pp. 277-83.
Crooks, C.A. and Macchietto, S. (1992), ``A com-
bined MILP and logic-based approach to the
synthesis of operating procedures for batch
plants'', Chemical Engineering
Communications, Vol. 114, pp. 117-44.
Fikes, R.E. and Nilsson, N.J. (1971), ``Strips: a new
approach to the application of theorem-prov-
ing to problem solving'', Artificial Intelligence,
Vol. 2, pp. 189-208.
Foulkes, N.R., Walton, M.J., Andow, P.K. and
Galluzo, M. (1988), ``Computer aided synthesis
of complex pump and valve operations'',
Computers and Chemical Engineering, Vol. 12,
pp. 1035-44.
Fusillo, R.H. and Powers, G.J. (1987), ``A synthesis
method for chemical plant operating proce-
dures'', Computers in Chemical Engineering,
Vol. 11 No. 4, pp. 369-82.
Fusillo, R.H. and Powers, G.J. (1988a), ``Computer-
aided planning of purge operations'', AIChE
Journal, Vol. 34 No. 4, pp. 558-66
Fusillo, R.H. and Powers, G.J. (1988b) ``Operating
procedure synthesis using local models
and distributed goals'', Computers in
Chemical Engineering, Vol. 12 No. 9/10,
pp. 1023-34.
Ivanov, V.A., Kafarov, V.V., Perov, V.L. and
Reznichenko, A.A. (1980), ``On algorithmiza-
tion of the start-up of chemical productions'',
Engineering Cybernetics, Vol. 18, pp. 104-10.
Kinoshita, A., Umeda, T. and O'Shima, E. (1981),
``An algorithm for synthesis of operational
sequences of chemical plants'', presented
at the 14th Symposium on Computerized
Control and Operation of Chemical Plants,
Vienna.
Lakshmanan, R. and Stephanopolous, G. (1988a)
``Synthesis of operating procedures for com-
plete chemical plants ± 1. Hierarchical struc-
tured modelling for nonlinear planning'',
Computers in Chemical Engineering, Vol. 12
No. 9/10, pp. 985-1002.
Lakshmanan, R. and Stephanopolous, G. (1988b),
``Synthesis of operating procedures for
complete chemical plants ± 2. A nonlinear
planning methodology'', Computers in
Chemical Engineering, Vol. 12 No. 9/10,
pp. 1003-21.
Lakshmanan, R. and Stephanopolous, G. (1990),
``Synthesis of operating procedures for com-
plete chemical plants ± 3. Planning in the
presence of qualitative mixing constraints'',
Computers in Chemical Engineering, Vol. 14
No. 3, pp. 301-17.
O'Shima, E. (1978), ``Safety supervision of valve
operations'', Journal of Chemical Engineering
of Japan, Vol. 11 No. 5, pp. 390-5.
Penberthy, J.S. and Weld, D.S. (1992), ``UCPOP: a
sound, complete, partial order planner for
ADL'', Proceedings of the 3rd International
[ 341 ]
 Ruth Aylett, Gary Petley,
P.W.H. Chung, James Soutter
and Andrew Rushton
Generating operating
procedures for chemical
process plants
Integrated Manufacturing
Systems
10/6 [1999] 328±342
Downloaded by University of South Carolina Libraries At 14:42 12 July 2016 (PT)
[ 342 ]
Conference on Knowledge Representation and
Reasoning, October.
Petley, G., Aylett, R.S., Chung, P.W.H. and
Rushton, A. (1998), ``Development of a reusa-
ble operator library for chemical plant
domains'', Proceedings of the 17th UK
Planning and Scheduling SIG, University of
Huddersfield, September.
Rivas, J.R. and Rudd, D.F. (1974), ``Synthesis of
failure-safe operations'', AIChE Journal,
Vol. 20 No. 2, March, pp. 320-5.
Soutter, J. (1996), ``An integrated architecture
for operating procedure synthesis'', PhD
thesis, Loughborough University,
Loughborough.
Soutter, J. and Chung, P.W.H. (1996), ``Partial
order planning with goals of prevention'',
Proceedings of the 15th Workshop of the UK
Planning and Scheduling SIG, Vol. 2, John
Moores University, Liverpool, pp. 300-11.
Soutter, J. and Chung, P.W.H. (1997), ``Utilising
hybrid problem solving to solve operating
procedure synthesis problems'', Proceedings
of IChemE Research Event 97, Vol. 2, Notting-
ham, pp. 793-6.
Valente, A. (1995), ``Knowledge-level analysis of
planning systems'', ACM SIGART Bulletin,
special issue, Vol. 6 No. 1, January.
Weld, D. (1994), ``An introduction to least-
commitment planning'', AI Magazine,
Vol. 15, pp. 27-61.