Generating Operating Procedures for Chemical ... - Semantic Scholar

Integrated Manufacturing Systems - The International Journal of Manufacturing Technology Management

Generating Operating Procedures for Chemical Process 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 Engineering 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, MultiAgent Systems and Intelligent Virtual Environments.

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

1

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 considered, 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 Salford and Loughborough. The CEP planner is outlined and its application to a double effect evaporator 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 process 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.

2

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 generation 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 commissioning 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.

3

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 procedures at the pre-HAZOP stage of the life-cycle. Once the plant is running, operating procedures may need modification in the light of actual operations 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 reconciling 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 relationship 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;

4

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

5

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 demonstrate some of the basic problems in creating operating procedures with a small-scale ‘toy’ example [Soutter & Chung 97]. This consists of a plant with inputs of acid, alkali and water, and two vessels as shown in Figure 2. Take in Figure 2 on page 27. 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 cooling 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 ‘purging’ - 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

6

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

18 August 1998


associated actions at other valves. However an assumption of the standard AI planner representation 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 generalpurpose 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 quantities which were excluded from CEP’s scope). Having successfully produced correct operating 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. Take in Figure 3 on page 28. This figure shows the complexity of the domain for this case study, which is much nearer to a realworld 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 8

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 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. Take in Figure 4 on page 29.

METHODOLOGY Two closely-coupled steps are involved in applying a planner to a new domain: knowledge acquisition and domain modelling. In the DEE case-study, knowledge was acquired by reading the documentation 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:

9

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 components 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 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 description. 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.

10

18 August 1998


Thus little extra work is required beyond that a plant designer would already undertake in designing the plant layout. 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 elements of plant specific knowledge which CEP can use to narrow down the search space. Take in Figure 7 on page 29. 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 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 precondition(s) for the operator are true - essentially the STRIPS [Fikes & Nilsson 71] 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. Take in Figure 8 on page 30. 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

11

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]. Take in Figure 9 on page 30. 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 planning 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 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 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 of vessel would be too general since there are significant differences 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 12

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 operators that are necessary. Library of Operators A consequence of producing generic planning 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 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 specialisation. 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 components 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 operators in the model. The task of starting up the plant in double-evaporator mode is represented as a

13

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. Take in Figure 11 on page 31. 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. Take in Figure 12 on page 31. 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 of Figure 12 could be replaced by an

14

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

15

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 considered 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 successfully 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 stateof-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 16

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 generated 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 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 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 preheater 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 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 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 17

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

18

18 August 1998


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, OperateHeatExchanger-4 are partially ordered and thus can be taken in any order. Take in Figure 14 on page 31. 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 partially 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 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 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, depthfirst expansion 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 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 desirable 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.

19

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

20

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

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

22

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 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 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 operability 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 23

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 important 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 capabilities 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 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 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

24

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 Planning 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 or Improving Operating Procedures. In: Computers and Chemical Engineering, vol. 15 no 5, pp349-360, Pergamon 1991 Aylett, R.S. & Jones, S.D. (1996) Planner and Domain: Domain Configuration for a Task Planner. International Journal of 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. Proceedings, 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 Procedures for Batch Plants. Chemical Engineering Communications 114, pp117-144 Chien, S.A. (1996) Static and Completion Analysis for Planning Knowledge Base Development and Verification. Proceedings, 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 Difficult: a Tale of Two Applications. In: New Directions in AI Planning, M.Ghallab & A.Milani, eds, IOS Press, Washington DC 1996 pp 287-98 Chung, P.W.H. (1993) Qualitative Analysis of Process Plant Behaviour. Proceedings,Industrial and Engineering Applications 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, 1991 Drabble, B. (1993) Excalibur: a program for planning and reasoning with processes. Artificial Intelligence, v62 no1, pp1-40, Elsevier 1993 Fikes, R.E. & Nilsson, N.J. (1971) Strips: A New Approach to the Application of Theorem-Proving to Problem-Solving. Artificial Intelligence 2: pp189-208 Foulkes, 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-1044 Fusillo, 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, 1987 Ivanov, 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-110 Kinoshita, 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, 1981 Lakshmanan, 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 25

18 August 1998


Lakshmanan, R. & Stephanopolous, G. (1988b) Synthesis of Operating Procedures for Complete Chemical Plants - 2. A Nonlinear 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. Planning in the Presence of Qualitative Mixing Constraints In: Computers in Chemical Engineering, vol 14 no 3, pp301-317, Pergamon 1990 Penberthy, J.S. & Weld, D.S. (1992) UCPOP: A Sound, Complete, Partial Order Planner for ADL. Proceedings of the 3rd International 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 Plant Domains.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, March 1974. 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 UK Planning 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 1995 Weld, D. (1994) An introduction to least-commitment planning. AI Magazine, 15, pp27-61

26

18 August 1998


FIGURE 1. The Plant Life-Cycle

ELD Development

Process Flow Sheet

HAZOP

OPS

Construction

Commissioning

Detailed Design

OPS Operation and Maintenance

Continuous Improvement OPS

FIGURE 2. A Simple OPS Example

The procedure produced by CEP 1. 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

27

18 August 1998


FIGURE 3. Plant Diagram for Double Effect Evaporator Test Rig

28

18 August 1998


FIGURE 4. Basic Process for Double Effect Evaporator Test Rig

FIGURE 5. DEE Component Hierarchy

FIGURE 6. Example CEP Domain Description frame(unit).

Unit Inlet Heat Inlet Cool Inlet Outlet Drain Vessel Evaporator Barometric Condenser Feed Tank Condensate Pot Mixing Tank TempChanger Heater Heat Exchanger Heat ExchangerII Glass Preheater Cooler Glass Cooler Valve Solenoid Hand OneWay Controller Regulator Pump Vacuum Header Divider Trap Drain

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]] ]).

FIGURE 7. Example Pair Descriptions pair (heaterSource, HE1 : Input4). pair (chemSupply, Input4 : steam).

29

18 August 1998


FIGURE 8. Operator - Control Valve 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 9. Macro - Activate Evaporator 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 10. Hierarchical Operator operator OperateDoubleEffectPlant { expand * state of DoubleEffectPlant is double_effect; using state of DoubleEffectPlant is single_effect; state of Evaporator2 is started; end }

30

18 August 1998


FIGURE 11. Goal Hierarchy for the DEE domain State of Double Effect Evaporator (Single Effect, Double Effect, etc.)

State of ?Vessel (Started / Stopped) Fill (True / False)

State of ?Tempchanger (Started / Stopped)

Flow (True / False)

State of ?Pump (On / Off)

State of ?Valve (Open / Closed)

FIGURE 12. Example Safety Restriction

FIGURE13.GlassPre-heaterRestriction restrictions { prevent aperture of FRC_4+LRC_2 is open; state of GP1 is stopped; end }

restrictions { prevent state of GP1 is started; state of GC1 is stopped; end }

FIGURE 14. Plan net for Operating Evaporator E1

Start - 1

OperateGlassPreheater - 3

OperateHeatExchanger - 4

OperateEvaporator - 5

End - 2

31

18 August 1998


TABLE 1.

Double Effect Evaporator Start-up

Check Regulators and Set Controllers

29

Open valve HV10.

30

Turn on pump P2.

1

Check regulator PRe_2 setpoint.

2

Check regulator PRe_1 setpoint.

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.

6

Set controller FRC_1 and turn on.

33

Open valve HV26.

7


34

Open valve HV22.

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


37

Close valve HV26.

11

Set controller LRC_7 and turn on.

12


38

Open valve HV27.

13

Set controller TRC_9 and turn on.

39

Open valve HV23.

40

Open valve HV29.

Make Brine

Activate Glass Cooler

Activate Glass Preheater

Activate Heat Exchanger

14

Open valve HV7.

41

Wait until air flushed out of HE1.

15

Open valve HV25.

42

Close valve HV27.

16

Open valve HV6.

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.

46

Turn on Pump P4.

Flows to and from Evaporator E1

Attain Vacuum in Spray Condenser

20

Open valve HV16.

Flows to and from Evaporator E2

21

Open valve HV20.

47

Open valve HV18.

22

Open valve HV1.

48

Open valve HV14.

23

Open valve HV4.

49

Open valve HV15.

24

Open valve HV5.

25

Turn on pump P3.

50

Open valve HV13.

26

Turn on pump P1.

51

Wait until air flushed out of HE2.

27

Open valve HV11.

52

Open valve HV12.

28

Open valve HV2.

Activate Catchpot

32

18 August 1998