generating operating procedures for chemical process plants · 2017-09-15 · integrated...

Integrated Manufacturing Systems - The International Journal of Manufacturing Technology Management

1 18 August 1998

Generating Operating Procedures for ChemicalProcess Plants

Ruth Aylett, Centre for Virtual Environments, University of Salford, Salford, Greater Manchester,

M5 4WT, UK. [email protected].

Gary Petley, Centre for Virtual Environments, University of Salford, Salford, Greater Manchester,

M5 4WT, UK. [email protected].

Paul Chung, Chemical Engineering Department, Loughborough University, Loughborough,

Leicestershire, LE11 3TU, UK. [email protected].

James Soutter, BG plc, Gas Research Centre, Ashby Road, Loughborough, Leicestershire, LE11

3QU, UK. [email protected].

Andrew Rushton, Health and Safety Executive, Nottingham. Tel.: 0151-951-4551.

FAX: (+44) 161 295 2925 or (+44) 1509 223 923

Ruth Aylett is a senior lecturer at the Centre for Virtual Environments of the University of Salford.

She has worked in the application of Artificial Intelligence - in particular AI Planning - to Engi-

neering for eight years and is a principal investigator on the EPSRC funded project: ‘INT-OP -

INTegrating OPerability’ discussed in this article. She also carries out research in Robotics, Multi-

Agent Systems and Intelligent Virtual Environments.

KEYWORDS: Plant Operating Procedures, AI Planning, Chemical Process Plant


2 18 August 1998

ABSTRACT

Operating Procedure Synthesis (OPS) has been used to generate plant operating procedures for

chemical plants. However, the application of AI planning to this domain has been rarely consid-

ered, and when it has the scope of the system used has limited it to solving ‘toy’ problems.

This paper describes the application of state-of-the-art AI planning techniques to the generation of

operating procedures for chemical plant as part of the INT-OP project at the Universities of Sal-

ford and Loughborough. The CEP planner is outlined and its application to a double effect evapo-

rator test rig is discussed in detail.

Particular attention is paid to the issues involved in domain modelling, requiring the description of

the domain, development of AI planning operators, the definition of safety restrictions, and the

definition of the problem. There is then a presentation of the results, lessons learned and problems

still remaining.

INTRODUCTION

In this paper we discuss an approach to Operating Procedure Synthesis (OPS) for chemical proc-

ess plants using AI Planning technology, considering in detail a particular case study, the Double

Effect Evaporator (DEE) Test Rig. We argue that a successful approach to OPS not only has the

potential to reduce the substantial time currently devoted to developing plant operating procedures

manually, but also to support the consideration of operability problems at a much earlier stage in

the plant life-cycle, therefore avoiding late changes to the design. We demonstrate that the use of

modern AI Planning Techniques allows successful generation of Plant Operating Procedures for a

real-world plant. While concentrating on chemical process plant in this work, we believe it is

straightforward to extend our system to other continuous process plant and that in principle it

could also be extended to batch plant, giving it a wide and general applicability.


3 18 August 1998

Operating procedures and plant life-cycle

All industrial plants require an extensive set of operating procedures which define the steps

required - for example - to start the plant up, to shut the plant down, to isolate pieces of equipment

for maintenance or to deal with emergency situations. In older plants, all of these steps are carried

out manually by human operators and are usually officially documented in a multi-volume set of

manuals in the control room, while in highly automated modern plants the lower-level and more

detailed steps are embodied in the plant control system. It is clearly vital for reasons both of safety

and efficiency that procedures are of a high quality and therefore much effort goes into their gener-

ation and subsequent maintenance.

Take in Figure 1 on page 27.

Figure 1 represents the main stages in the design, construction and running of a chemical plant. It

can be seen that operating procedures are a consideration at several different points within this. At

the design stage, where the process is first described at a high level in Process Flow Sheets, and

then in more details as Engineering Line Diagrams (ELDs), they may form an implicit element of

the design rationale - that is, the reasoning lying behind the specific design decisions made.

Designers will clearly avoid design decisions that they perceive will produce inoperable plant.

When the design is evaluated for safety and operability at the HAZOP stage, some of this rationale

may be drawn out as part of the HAZOP process, but investigation conducted during the project

suggests that it is unusual for operating procedures to be documented in any formal and systematic

way at this stage. An output of the HAZOP exercise may consist of operating constraints as well as

design changes, but in the case of the chemical process industry, a multi-disciplinary commission-

ing team is normally responsible for defining the detailed sets of operating procedures for a plant

alongside their other commissioning work. This is often a substantial exercise taking around two

man-years of effort, and usually overlaps with the construction of the plant.


4 18 August 1998

A consequence is that if operability problems are uncovered during this process, as may happen,

they may force late changes to the design of the plant. If this occurs while the plant is actually

being constructed it is clearly undesirable and costly. Thus there is an advantage in considering

operating procedures in a more systematic way and earlier than at present. This is an important

motivation for the development of computer-based tools to aid in the authoring of operating proce-

dures at the pre-HAZOP stage of the life-cycle.

Once the plant is running, operating procedures may need modification in the light of actual oper-

ations experience. If mechanisms 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 recon-

ciling the need for flexibility in the construction and modification of plant operating procedures

with the need for accuracy, consistency and accountability for changes.

Previous work

Operating Procedure Synthesis (OPS) is a field of research that has largely been carried out in the

chemical engineering domain [Rivas & Rudd 74; Ivanov et al 80; Fusillo & Powers 87; Foulkes et

al 88; Lakshmann & Stephanopolous 88a,88b,90; Kinoshita et al 91; Aelion & Powers 91;

Crookes & Macchietto 92], rather than by AI researchers. Yet there is an intuitively obvious rela-

tionship between an operating procedure and the output of an AI Planning system.

AI Planning constructs a plan automatically 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;


5 18 August 1998

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 constructed to solve a spe-

cific bin-packing problem.

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 [Aelion & Powers 91] 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 & Nilsson 71]. Much work has been carried out in


6 18 August 1998

AI Planning since then, and in particular planners which use a hierarchy of actions and which

apply ‘least-commitment’ [Weld 94] 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 demon-

strate some of the basic problems in creating operating procedures with a small-scale ‘toy’ exam-

ple [Soutter & Chung 97]. 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 vessel1 with acid; to create a

flow of acid to vessel2; and to create a flow of alkali to vessel1. However, there are also two safety

considerations: firstly, acid and alkali may not mix in the pipework but only in the reaction vessels;

and secondly, vessel2 must contain acid before vessel1 contains alkali to allow for the proper cool-

ing of the reaction vessels. In order to operate this plant correctly, not only must flows of chemical

be created through paths which meet the safety conditions, and not through others, but also ‘purg-

ing’ - passing a neutral chemical down a flow path to clean it - is required at a specific stage.

Then 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 vessel1 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 produced the flow of


7 18 August 1998

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

ertheless unable to generate 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 96] and in the last two years as part of the

EPSRC-funded INTergrating OPerability (INT-OP) project being carried out jointly between

Loughborough and Salford Universities in the UK. CEP is being developed incrementally through

case studies of increasing scope and complexity, 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-commitment planner [Penberthy & Weld 92], which uses the concept of

‘goals of prevention’ [Soutter & Chung 96] to prevent actions being incorporated into the operat-

ing 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 components - is that the effect of the action at a particular valve is dependent on


8 18 August 1998

associated actions at other valves. However an assumption of the standard AI planner representa-

tion 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 98].

Therefore, valve sequencing is handled by a specialist module in CEP that uses an approach

known in the OPS field as ‘action synergy’ [Foulkes et al 88]. 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 lit-

erature by previous workers in this area (except for those requiring the handling of numerical

quantities which were excluded from CEP’s scope). Having successfully produced correct operat-

ing 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 equivalent in complexity to a section of a commercial plant was sought.

The case study discussed in this paper used a double effect evaporator test rig constructed in the

Chemical Engineering department at Loughborough University. Although no longer used, the test

rig was designed for teaching basic principles of plant operation to chemical engineering students.

The layout of the test rig is shown in the plant diagram - 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


9 18 August 1998

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

tion 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 indefi-

nitely. 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: knowledge acqui-

sition and domain modelling. In the DEE case-study, knowledge was acquired by reading the doc-

umentation on the test rig, visiting the double effect evaporator installation, and by interviewing a

Loughborough University colleague 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 modelling in more detail, as the amount of time and effort

required to construct a particular domain model is a major obstacle to the use of AI planning in the

solution of real-world problems [Chien et al 96]. 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:


10 18 August 1998

• 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 following sections.

Domain description

The elements and configuration of a process plant can be described symbolically in terms of a

hierarchy of components and the connections between them. The complete taxonomy for the com-

ponents in the DEE domain is shown in Figure 5. CEP uses an implementation of a hierarchical

frame-based description developed during earlier work at Loughborough [Chung 93] to model

individual 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.

Take in Figure 5 on page 29 and Figure 6 on page 29.

As the complexity of Figure 3 demonstrates, the manual entry of these descriptions for every com-

ponent 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 and connections for it. Thus on

completion of the drawing, the necessary information has been collected to allow the automatic

creation of a file, in the form of the instance shown in Figure 6, that describes the plant to CEP.


11 18 August 1998

Thus little extra work is required beyond that a plant designer would already undertake in design-

ing the plant layout.

Pairs

A chemical plant is a large and complex configuration of numerous components, producing enor-

mous search spaces when planning. Engineering Line Drawings (ELDs) contain extra information

associating elements 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

Input4, 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 proce-

dure). Where the domain description gives the static content and layout of a plant, planning opera-

tors define its behaviour. A CEP operator consists of a goal(s) that can be achieved when the

precondition(s) for the operator are true - essentially the STRIPS [Fikes & Nilsson 71] representa-

tion 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


12 18 August 1998

shown in Figure 8 was supplemented with macro operators (Figure 9), which allow information

about the order in which the pre-conditions must be satisfied to be entered [Aylett et al 98].


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 efficiency of the plan-

ning process in a domain depends very heavily on operator definition. We therefore summarise the

lessons of the DEE case study for operator development in 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 procedures to start the plant up as a

single effect or double effect; to shut the plant down; to switch between the previous states; to iso-

late pieces of equipment for maintenance or to deal with emergency situations. Therefore, opera-

tors 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 more important, the greater the scope for re-use. On the

other hand operators must be specific enough in relation to the domain description to prevent vast

amounts of search when instantiating pre and post-conditions [Aylett & Jones 96] and to capture

appropriate differences in functionality. For example, in the DEE class hierarchy shown in

Figure 5, an operator at the level ofvesselwould be too general since there are significant differ-

ences in functionality between, say, an evaporator and mixing tank, and instantiation would have

to consider every vessel in a plant.

It was decided to limit the number of operators by using those generic to any piece of equipment

of the same type, where type was defined as one of the leaves in the class hierarchy for the domain


13 18 August 1998

shown in Figure 5. Thus an operator for a control valve, as in Figure 8. One might expect operators

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 combine both into one operator

acting as a toggle between states - as in the case of valves, further reducing the number of opera-

tors that are necessary.

Library of Operators

A consequence of producing generic planning operators is the possibility this opens up of provid-

ing a good-quality library for equipment commonly found in chemical plants, such as valves,

pumps, heat exchangers etc. [Petley et al 98]. A suitably comprehensive library would standardise

the design of operators by reducing the task to one of selection, with possibly some scope for spe-

cialisation. Indeed, without such a library it is hard to see how CEP could be applied to new plants

in an industrial context 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 com-

ponents have been encountered. An interface for accessing the library of equipment 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 interesting issues arose which will be discussed later.

Hierarchical Structure of Operators

There is a substantial difference in granularity 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 & Jones 96] a clear need for a hierarchical structure in all the opera-

tors in the model. The task of starting up the plant in double-evaporator mode is represented as a


14 18 August 1998

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 represents 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 operator: expansion operators as shown

in Figure 10, macro operators as in Figure 9, and primitive operators as in Figure 8. The latter two

include print statements that are used to display the final operating procedure and use the keyword

‘achieve’ and ‘solve’ in place of the keyword ‘expand’.

Safety restrictions

Safety restrictions in CEP are constraints that prevent unsafe situations from occurring during

planning through the specification 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 - a heater on - before there is a mechanism for energy to leave the plant - a

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

ifying safe states for their use. Thus, the safety restriction of Figure 12 could be replaced by an


15 18 August 1998

operator for activating GP1 with a precondition that the glass cooler is on, though in general this

may require both quantification and disjunction in the operator pre-conditions.

There are two arguments against this approach: firstly, incorporating the restriction into a particu-

lar 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. Secondly, 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, where it can be assessed and checked against safety

regulations, an important consideration 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 about

the specified change in the plant, if one exists for the given operators and restrictions. The Auto-

CAD 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.


16 18 August 1998

RESULTS AND EVALUATION

CEP successfully produced operating procedures for the double effect evaporator. 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 double effect evaporator is found in Table 1 and

contains 52 steps. The total number of operators used in planning was under 20. 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 backtracking at user request.

Take in Table 1 on page 32.

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 previously attempted. The work of the early 80s [Ivanov et al 80,

Kinoshita et al 81] using state-graphs limited sample problems to plants containing a handful of

valves because of the number of states they generated: 20 valves each with 2 states produces

1,048,576 nodes in a state-graph. Other workers used larger plant [Rivas & Rudd 74] but only con-

sidered valves and not vessels. A real-world nuclear fuel processing plant was used in [Crookes &

Macchietto 92], but this work concentrated on optimising a hand-generated plan. CEP has suc-

cessfully solved every sample problem reported in the OPS literature except for those requiring

numerical calculations. We therefore argue that 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


17 18 August 1998

complexity and validates the overall approach of using AI Planning technology on this problem.

However he also found the generated procedures in some ways naive - 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 accordingly CEP originally gen-

erated a procedure that did not use it. The reasons for using the preheater during start-up are: the

temperature of the brine can be increased in stages, protecting the glass lined vessels, and the con-

trol 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 examin-

ing the issue in more detail.

Producing a start-up procedure which did use the glass preheater, as seen in Table 1, required the

use of the restrictions mechanism discussed above. 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 pre-

heater is on, forcing its use. While the restrictions mechanism 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 thecold sideof the plant before thehot 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 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


18 18 August 1998

the start-up of the operating procedure.This kind of optimization 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 &

Macchietto 92].

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 example, 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

linearization. As the example above demonstrates, there may be reasons apart from ‘any order that

works’ for linearizing 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 happens. 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 linearization.

A number of comparable issues arose from considering the linearization process for CEP in which

its partially ordered output is turned into a sequence of operating instructions. An extract from a


19 18 August 1998

plan net generated by CEP can be seen in Figure 14 and represents a plan fragment for the opera-

tion of an evaporator. Figure 14 shows that actions OperateGlassPreheater-3, OperateHeatEx-

changer-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 immediately after another, without interpolation of other actions par-

tially ordered with respect to them. For example, changing the operation of the plant from using

one evaporator to using both requires the opening of one valve and the closing of another at virtu-

ally 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 linerarization is formally possible. As a step towards

capturing this type of dependency, CEP’s original linearization mechanism was rewritten so that

all the actions down one parallel branch of the plan net are placed together - in other words, depth-

first expansion was applied to parallel branches rather than any other ordering. We are also consid-

ering the use ofshort linksbetween actions that allow the links in the plan graph to carry the infor-

mation that actions should be kept close together at linearization [Soutter et al 97].

The plan net supports user interaction in the linearization process since it shows what actions can

be moved in a particular linearization and which cannot. The re-ordering of actions may be desira-

ble for two reasons in addition to the one just discussed. Firstly, grouping actions together for

operating a certain piece of equipment makes the plan clearer. Secondly, 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.


20 18 August 1998

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

problems 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 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, thirteen 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 double effect evaporator 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 impossible. An obvious approach to this problem is to con-

sider 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.


21 18 August 1998

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

ies 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 ‘chunk-

ing’ process originates in design. Each of the functional units we examined was of the same order

of complexity 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

processes 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 business 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.

Firstly, 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 decomposi-

tion 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.


22 18 August 1998

Thus it is not only desirable - as discussed in the last section - that CEP supports OPS in functional

subsets of the plant, it is in fact very important that it does not force the whole plant to be consid-

ered 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 procedures at the early

stages of design, possibly at the Process Flow Sheet stage. CEP supports this through the hierar-

chical definition of actions, though further work is needed in this area. Lastly, 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-considered areas such as maintenance. CEP has an important

role to play here in allowing a much wider range of operational conditions to be considered.

Support for user interaction is the other important consideration in relation to system 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 proce-

dure. Tools have been developed to help the user create and debug the domain and are in the proc-

ess 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 instantia-

tions of the variables in them. CEP allows the user to view that section of the search space it tra-

versed 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. Investigation suggests that this is essential


23 18 August 1998

since professional engineers would not accept a system in which planning was wholly automatic

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

cedure 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 relationships between actions in the plan and thus the

possible orders allowable after linearization. This allows the user to alter the ordering of some of

the actions in the original text list, while respecting the essential 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 relevance 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 above, 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

linearization process, in the valve sequencing component and in the incorporation of general oper-

ability knowledge: 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. Hopefully, 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 establish abstract categories in such domains which will support a


24 18 August 1998

more principled approach to the choice of planning technologies for particular problems [Valente

95, Aylett & Jones 96, Soutter et al 97].

A number of knowledge engineering issues arose from the DEE case study. Firstly, the time and

effort required to develop the domain was substantial, with about 20 person-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 AutoCad, is a step along this

path, and the library of generic operators derived from the case study is another even more impor-

tant one. Validation and verification tools such as those described in [Chien 96] 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 capabili-

ties were increased, so it became possible to solve each problem in a more general and principled

way. Thus the ability to produce a library of generic operators is not only an indispensable tool for

domain development in the future, it is also, 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 suc-

cessfully 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 poten-

tial to solve problems in this area previously seen as too complex to be tackled successfully.

In particular, Operating Procedure Synthesis 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


25 18 August 1998

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

ning approach to the generation of other types of operational procedure.

ACKNOWLEDGEMENTS

This work was made possible through funding from the EPSRC grant: “Intergrating Operability

into Plant Design”, the ESRC, the SERC, BG plc, BP, Cogsys, ICI and Subs-IAD. Paul Chung is

grateful to BG plc and The Royal Academy of Engineering for financial support through a Senior

Research Fellowship.

REFERENCES

Aelion, V. & Powers, G.J. (1991) A Unified Strategy for the Retrofit Synthesis of Flowsheet Structures for Attaining orImproving Operating Procedures. In: Computers and Chemical Engineering, vol. 15 no 5, pp349-360, Pergamon1991

Aylett, R.S. & Jones, S.D. (1996) Planner and Domain: Domain Configuration for a Task Planner. International Journalof Expert Systems v9 no2 pp279-318, JAI Press 1996

Aylett, R.S; Soutter, J; Petley, G; Chung, P.W.H. & Rushton, A. (1998) AI Planning in a Chemical Plant Domain. Pro-ceedings, 13th European Conference on Artificial Intelligence, ECAI ‘98, pp622-26

Crooks, C.A. & Macchietto, S. (1992) A Combined MILP and Logic-Based Approach to the Synthesis of Operating Pro-cedures for Batch Plants. Chemical Engineering Communications 114, pp117-144

Chien, S.A. (1996) Static and Completion Analysis for Planning Knowledge Base Development and Verification. Pro-ceedings, 3rd International Conference on AI Planning Systems, pp53-61, AAAI Press, 1996

Chien, S.A; Hill, R.W; Wang, X; Estlin, T; Fayyad, K.V. & Mortenson, H.B.(1996) Why Real-world Planning is Diffi-cult: a Tale of Two Applications. In: New Directions in AI Planning, M.Ghallab & A.Milani, eds, IOS Press, Wash-ington DC 1996 pp 287-98

Chung, P.W.H. (1993) Qualitative Analysis of Process Plant Behaviour. Proceedings,Industrial and Engineering Appli-cations of AI and Expert Systems,ed. P.W.H.Chung, G.Lovegrove & M.Ali, pp277-83 Gordon & Breach 1993

Currie, K, & Tate, A. (1991) O-plan: the Open Planning Architecture. Artificial Intelligence, 52:49-86, 1991Drabble, B. (1993) Excalibur: a program for planning and reasoning with processes. Artificial Intelligence, v62 no1,

pp1-40, Elsevier 1993Fikes, R.E. & Nilsson, N.J. (1971) Strips: A New Approach to the Application of Theorem-Proving to Problem-Solving.

Artificial Intelligence 2: pp189-208Foulkes, N.R.; Walton, M.J.; Andow, P.K. & Galluzo, M. (1988) Computer Aided Synthesis of Complex Pump and

Valve Operations. Computers and Chemical Engineering, 12 pp1035-1044Fusillo, R.H. & Powers, G.J. (1987) A Synthesis Method for Chemical Plant Operating Procedures. In: Computers in

Chemical Engineering, vol 11 no 4, pp 369-382, Pergamon, 1987Ivanov, V.A.; Kafarov, V.V.; Perov, V.L. & Reznichenko, A.A. (1980) On Algorithmization of the Start-up of Chemical

Productions. Engineering Cybernetics, 18, pp104-110Kinoshita, A.; Umeda, T & O’Shima, E. (1981) An Algorithm for Synthesis of Operational Sequences of Chemical

Plants. 14th Symposium on Computerized Control and Operation of Chemical Plants, Vienna, Austria, 1981Lakshmanan, R. & Stephanopolous, G. (1988a) Synthesis of Operating Procedures for Complete Chemical Plants - 1.

Hierarchical Structured Modelling for Nonlinear Planning In: Computers in Chemical Engineering, vol 12 no 9/10,pp985-1002, Pergamon 1988


26 18 August 1998

Lakshmanan, R. & Stephanopolous, G. (1988b) Synthesis of Operating Procedures for Complete Chemical Plants - 2. A Non-linear Planning Methodology In: Computers in Chemical Engineering, vol 12 no 9/10, pp1003-1021, Pergamon 1988

Lakshmanan, R. & Stephanopolous, G. (1990) Synthesis of Operating Procedures for Complete Chemical Plants - 3. Planningin the Presence of Qualitative Mixing Constraints In: Computers in Chemical Engineering, vol 14 no 3, pp301-317, Per-gamon 1990

Penberthy, J.S. & Weld, D.S. (1992) UCPOP: A Sound, Complete, Partial Order Planner for ADL. Proceedings of the 3rdInternational Conference on Knowledge Representation and Reasoning. October 1992.

Petley, G; Aylett, R.S; Chung, P.W.H. & Rushton, A. (1998) Development of a Reusable Operator Library for Chemical PlantDomains.Proceedings, 17th UK Planning and Scheduling SIG, University of Huddersfield, Sept. 1998.

Rivas, J.R. & Rudd, D.F. (1974) Synthesis of Failure-Safe Operations. In: AIChE Journal, vol 20 no 2, pp 320-325, March1974.

Soutter, J. (1996) An Integrated Architecture for Operating Procedure Synthesis. PhD thesis, Loughborough University,Loughborough LE11 3TU, UK.

Soutter, J. & Chung, P.W.H. (1996) Partial Order Planning with Goals of Prevention. proceedings, 15th Workshop of the UKPlanning and Scheduling SIG, vol 2 pp300-11, John Moores University, Liverpool, UK.

Soutter, J. & Chung, P.W.H. (1997) Utilising Hybrid Problem Solving to Solve Operating Procedure Synthesis Problems,IChemE Research Event 97, vol2 pp793-796, Nottingham, UK.

Valente, A. (1995) Knowledge-level Analysis of Planning Systems. ACM SIGART Bulletin Special Issue, 6(1), Jan 1995Weld, D. (1994) An introduction to least-commitment planning. AI Magazine, 15, pp27-61


27 18 August 1998

FIGURE 1. The Plant Life-Cycle

Process FlowSheet

ELDDevelopment

HAZOP

Commissioning Construction Detailed Design

ContinuousImprovement

Operation andMaintenance

OPS

OPS

OPS

FIGURE 2. A Simple OPS Example

The procedure produced by CEP1. Open f,d,b,c

2. Wait for the tank to fill

3. Close f,d,b,c

4. Open j, h, d, b, e, i, l

5. Wait for the acid to be purged

6. Close j, h, d, b,e, i, l

7. Open f, h, k, i, g

8. Open a, b, c


28 18 August 1998

FIGURE 3. Plant Diagram for Double Effect Evaporator Test Rig


29 18 August 1998

FIGURE 5. DEE ComponentHierarchy

FIGURE 6. Example CEP DomainDescription

FIGURE 7. Example Pair Descriptions

FIGURE 4. Basic Process for Double Effect Evaporator Test Rig

UnitInlet

Heat InletCool Inlet

OutletDrain

VesselEvaporatorBarometric CondenserFeed TankCondensate PotMixing Tank

TempChangerHeater

Heat ExchangerHeat ExchangerII

Glass PreheaterCooler

Glass CoolerValve

SolenoidHandOneWayController

RegulatorPump

VacuumHeaderDividerTrap Drain

frame(unit).

frame(vessel isa unit).

frame(mixing_tank isa vessel, [ propLinks info[arc([in1, composition], 1, [mid, composition]),arc([in2, composition], 1, [mid, composition]),arc([in3, composition], 1, [mid, composition]),arc([in4, composition], 1, [mid, composition]),

arc([mid. composition], 1, [out, composition])]]).

instance(MT1 isa mixing_tank,[outports info [out is [HV7, in]]]).

pair (heaterSource, HE1 : Input4).

pair (chemSupply, Input4 : steam).


30 18 August 1998

operator OperateControlValve {

aperture ?state1;aperture ?state2;controller ?c;

?state1 != ?state2;

achieve * aperture of ?c is ?state2;

using aperture of ?c is ?state1;

end

print (?n) ‘Set controller ‘ ?c ‘ and turn ‘ [name of ?state2 is ?n;]; }

FIGURE 8. Operator - Control Valve

macro OperateEvaporator{ unit ?unit, ?unit2, ?evaporator, ?condensor; port ?port1, ?port2, ?port3, ?port4; chemical ?mainchem, ?evapchem; vent ?vent;

pair unitFlowFrom, ?evaporator : ?unit; pair equipmentChem, ?evaporator : ?mainchem; pair evaporatedChemical, ?evaporator : ?evapchem; pair evaporatorCondensor, ?evaporator : ?condensor; pair evaporatorOutTo, ?evaporator : ?unit2;

solve active(?evaporator) is true; nodes 1 instant createFlowIn; 2 instant createFlowOut; 3 instant createVent; require 1, @ flow(?unit, ?port1, ?evaporator, in, ?mainchem, fill); 2, @ > flow(?evaporator, ?port2, ?unit2, ?port3, ?mainchem, fill); 3, @ > flow(?evaporator, ?port4, ?vent, in, ?evapchem, fill); order 3,1,2,$; achieve $, @ active(?evaporator) is true; end}

FIGURE 9. Macro - Activate Evaporator

operator OperateDoubleEffectPlant {

expand* state of DoubleEffectPlant is double_effect;

usingstate of DoubleEffectPlant is single_effect;state of Evaporator2 is started;

end}

FIGURE 10. Hierarchical Operator


31 18 August 1998

FIGURE 12. Example SafetyRestriction

FIGURE13.GlassPre-heaterRestriction

State of Double Effect Evaporator

State of ?Vessel State of ?Tempchanger

FlowFill

State of ?Pump State of ?Valve

(Single Effect, Double Effect, etc.)

(Open / Closed)(On / Off)

(True / False)(True / False)

(Started / Stopped)(Started / Stopped)

FIGURE 11. Goal Hierarchy for the DEE domain

restrictions {

preventstate of GP1 is started;state of GC1 is stopped;

end }

restrictions {

preventaperture of FRC_4+LRC_2 is open;state of GP1 is stopped;

end }

FIGURE 14. Plan net for Operating Evaporator E1

Start - 1

OperateHeatExchanger - 4

End - 2

OperateGlassPreheater - 3

OperateEvaporator - 5


32 18 August 1998

TABLE 1. Double Effect Evaporator Start-up

Check Regulators and Set Controllers 29 Open valve HV10.

1 Check regulator PRe_2 setpoint. 30 Turn on pump P2.

2 Check regulator PRe_1 setpoint. Activate Glass Cooler

3 Set controller PC_4 and turn on. 31 Open valve HV31.

4 Set controller PC_3 and turn on. 32 Open valve HV24.

5 Set controller FRC_4+LRC_2 and turn on. Activate Glass Preheater

6 Set controller FRC_1 and turn on. 33 Open valve HV26.


8 Set controller FRC_3+LRC_1 and turn on. 35 Open valve HV28.

9 Set controller LRC_5 and turn on. 36 Wait until air flushed out of GP1.

10 Set controller FRC_6 and turn on. 37 Close valve HV26.

11 Set controller LRC_7 and turn on. Activate Heat Exchanger


13 Set controller TRC_9 and turn on. 39 Open valve HV23.

Make Brine 40 Open valve HV29.

14 Open valve HV7. 41 Wait until air flushed out of HE1.

15 Open valve HV25. 42 Close valve HV27.

16 Open valve HV6. Attain Vacuum in Spray Condenser

17 Turn on pump P3. 43 Open valve HV21.

18 Open valve HV32. 44 Open valve HV19.

19 Close valve HV32. 45 Wait for SC1 to fill with Process Water.

Flows to and from Evaporator E1 46 Turn on Pump P4.

20 Open valve HV16. Flows to and from Evaporator E2




24 Open valve HV5. Activate Catchpot

25 Turn on pump P3. 50 Open valve HV13.

26 Turn on pump P1. 51 Wait until air flushed out of HE2.


28 Open valve HV2.

generating operating procedures for chemical process plants · 2017-09-15 · integrated...

Documents