Development of a Reusable Operator Library for Chemical Plant Domains Gary Petley, Ruth Aylett Centre for Virtual Environments, Salford University, UK. P. W. H. Chung, Andrew Rushton Chemical Engineering Department, Loughborough University, UK. email:
[email protected] Keywords: Reusable operator library, chemical plant domains, domain description language, operator development tools. Abstract: There has been little published on the development of operators for AI planners, even though it is a difficult task.This paper addresses this important issue by looking at the requirements of the language used to describe operators, the methodology behind the synthesis of operators, and tools that could be used to aid in their development. The major theme through out all of this is the idea of a library of operators that can be used to retrieve the relevant operators for a new domain from the operators that have already been created for similar domains. The results of using a library of operators for domains concerned with the generation of operating procedures for chemical plant are discussed.
1.0 Introduction The development of the operators (also known as schema [1], [2]) for an AI planner is one of the areas in AI planning about which little has been published. However, we argue that for AI planning to become more widely used, and in particular by experts in complex real-world domains [3] rather than in planning itself, methodologies and/or tools for the development of operators are required. The first part of this paper summarises the major issues and available tools for operator development. This document has resulted from the research that is taking place as part of the INTegrating OPerability (INT-OP) project, which is developing a system that uses AI planning to generate operating procedures for chemical plant [11]. The AI planner used was the Chemical Engineering Planner (CEP) [4]. In the main section of this paper we discuss the operator development problems encountered when constructing domains for specific chemical plant and how these were tackled. We argue that the creation and then storage of reusable operators in a library will improve the process of developing planner operators for chemical plant. The library will allow easy access to and reuse of operators in new chemical plant domains, speeding up the development time and also allowing a user to develop a domain without knowing the CEP language. An outline is given of what is required of the CEP domain description language to allow operators to be reusable in other chemical plant domains. Secondly, a design methodology is described that will aid the development of reusable operators. There then follows a description of how the library of operators was constructed. Finally, the results of using the library of operators in the development of domains for various real-world chemical engineering plant case studies is presented.
2.0 Operator Development The development of planner operators is a problem area in AI planning. Chien [3] talks about the need for tools in domain development, including tools for the development of operators, “for planning systems to compare favourably in terms of software life cycle costs to other means of automation”, Currie and Tate say it is “hard work” [5], Knoblock a “black art” [6] and McCluskey talks about the coding up and maintenance of these operators as “difficult” [7]. Our experience also suggests that operator development is the most difficult part of writing a new domain. Planner operators have a dual aspect - on the one hand they embody knowledge about the behavioural aspects of the domain but on the other they have a substantial effect on how the planner behaves when it is asked to solve problems in the domain. Relatively trivial changes in planner operators may make a substantial difference to the efficiency and the correctness of planning. Constructing ‘good’ operators thus requires knowledge of both how the domain behaves, and how the planner behaves. Other parts of the domain definition are much more declarative and thus easier to handle. For example, the description of the layout of a domain with the connections and positions of entities within it can and has been achieved using conventional computer tools, as in our use of AutoCAD to draw the layout of a chemical plant and then generate the plant’s topological model for CEP.
2.1 Domain Description Language The first task is to provide a language for describing the operators to the planner. Every planner has a Domain Description Language (DDL) of which the operator description forms a significant part. A DDL also supports the definition of the objects in the domain, the relationships between them, the start and end states and sometimes search heuristics or control rules. Until now, each planner in AI Planning has had its own DDL which is defined for the user, as for example the O-Plan Task Formalism [2]. However, the need to compare the performance of planners and to develop a standard base set of planning problems is leading to the development of DDLs that will hopefully be taken up as standard, for example the Planning Domain Definition Language (PDDL) for the AIPS-98 planning competition [1] and (ARPA/Rome Planning Initiative) ARPI [8]. The set of standard planning problem domain definitions will then be developed in this language and made readily available. An important issue is that the problem description should allow for the operators to be easily separated from the rest of the domain definition. This would allow the user to develop their own possibly unique operators, as there are different ways of structuring operators even with the same operator language [9], and also support the establishment of libraries of operators for particular broad domains. Such libraries could be used by a planner as CEP does, but would also serve as a useful aid in the development of operators for new domains as the operator developer could view the existing operators for guidance. This is important as little has been published to guide users on the actual process of domain development.
2.2 Operator Development Methodology We have found very little in the literature discussing any methodology for operator development. There is some work on tools for such development, which may be taken as embodying an implicit methodology, as in the next section. The O-Plan Task Formalism(TF) manual [2] does discuss how to approach the modelling of a domain for a planner. However, this section on guidelines for writing TF is only three pages long and only provides examples of experience gained and common errors for specific domains, though it does suggest that a guide to modelling is forthcoming. These guidelines are further developed by Jarvis [10], stating that a planned approach is required and would benefit form the use of the KADS methodology. Here we provide a guide to writing operators for the specific domain of chemical plant, but try to extract some general lessons for developing operators in other types of domain.
2.3 Operator Development Tools As discussed earlier, the problem with writing operators is the difficulty in creating an operator that combines the behavioural knowledge for the domain with the requirements of an operator for a planner. This problem becomes more acute in more complex real-world domains. One response is to develop tools for creating the operators automatically from the domain knowledge, or alternatively, tools to support the user in developing the operators. Examples of the first response include the induction of operators from an entity-relationship model [9] and the generation of operators from the definitions of objects and states [7]. An example of the second response is the graphical user interface for the generation of planner domains, including operators, under development at Edinburgh University by Steve Polyak [13] - called the Common Process Editor. This interface lets the user draw a diagram of actions and links between them, and from these links the add and delete lists of the operator can be created. Worries about the scalability of these approaches in very large domains have led us to an alternative method of a library of operators for a particular type of domain. The operator library we are developing is for the chemical plant domain.
3.0 Operator Development for Chemical Plant Domains We argue that under certain circumstances, a library of operators is a sensible solution to the operator definition problem. This will be true for a domain which is broad enough to contain a large number of subdomains, but not so broad that these subdomains have nothing in common. For example, it is unlikely that the same library would be of use in our chemical plant domain and in the military logistics domains of ARPI. However, we argue that a chemical plant is a more or less unique configuration of a finite set of components - the pieces of equipment which can themselves be arranged in an abstraction hierarchy [11]. Therefore, a particular piece of equipment will almost always be found in many plants and the operators representing its behaviour can in principle be reused. The library allows both the planner’s DDL and the planner-specific details in operators to be hidden from a chemical plant operator or plant design engineer - who does not wish or need to know this - while making the domain behaviour visible. A planner operator can be retrieved from the library by using a simple tool so long as operators have been written in a way that makes them reusable. The rest of this paper discusses how we will create this library of operators. We examine what the operator description language will need to provide, how this is then used to create reusable operators, what tools can be used to help and how the library should be structured.
3.1 INT-OP Domain Description Language Operators in CEP are basically STRIPS operators. They contain the standard components: preconditions, post-conditions and conditions that must hold while the operator is being used. Expandible and primitive operators were supplemented with macro operators, which specifically allow the pre-conditions which must be satisfied to be ordered. Macros are described in more detail in the DDL definition for the following planners [7] and [10]. An example of a CEP macro operator is found in Figure 1, where the ordering can be seen in the order and require sections.
3.2 Generic Operator Domain Description Language A major concern in the development of reusable operators is that they contain no details specific to a particular domain- that is they are generic operators. In a chemical plant domain this means that references to equipment instances (rather than equipment types) and to specific configurations, must be excluded from operators. For example, a generic pump operator can be
used in any chemical plant domain that uses a pump. The operator in Figure 1 is generic in this sense as it can be applied to any fuel for any pilot. A lesson learned in developing domains within CEP is that it is often possible to overcome shortcomings in a planner DDL by including domain specific information in operators [11]. The drive to develop generic operators has therefore produced changes in CEP’s DDL as general solutions have been sought to the problems that were being temporarily fixed by domain specific operators.
FIGURE 1. A CEP Macro Operator macro SupplyFueltoPilot { inlet ?source; vent ?vent; unit ?pilot; chemical ?fuel;
pair unitSource, ?pilot : ?source; pair chemSupply, ?source : ?fuel;
solve supplyFuel(?fuel, ?pilot) is true; nodes 1 instant flowOfChemical; 2 instant pressureControl; 3 instant stopVenting; order 1, 2, 3, $; require 1, 2 flow(?source, out, ?vent, in, ?fuel, fill); 2, $ > flow(?source, out, ?pilot, in, ?fuel, fill); 3, $ noFlowUpstream(?fuel, ?vent, in); end }
The operators used within the macro are flow and noFlowUpstream. These start and stop the flows around a chemical plant, Figure 2 shows the flow operator.
FIGURE 2. Flow Operator macro Flow { valve *?opened, *?closed, *?allocUnit; pump *?pumps; unit *?unit, ?su, ?du; port *?port, *?allocPort, ?sp, ?dp; chemical ?chem, *?immiscable; use ?use; call $ flow(?su, ?sp, ?du, ?dp) [*?opened, *?closed, *?pumps, + ]; solve flow(?su, ?sp, ?du, ?dp, ?chem, ?use); nodes 1 instant ’valvesClosed’; 2 instant ’flowStarted’; 3 instant ’pumpsInactive’; order 1, 2, $, @, 3; require 1, @ allocated(*?allocUnit, *?allocPort) is ?chem; 1, @ use(*?allocUnit, *?allocPort) is ?use; 2, 3 > aperture of *?opened is open; $, @ > state of *?pumps is on; 3
> state of *?pumps is off;
achieve 1, @
contains(*?unit, *?port, ?chem);
print $
’
Achieved: Flow route from ’ ?su ’ to ’ ?du ’ for ’ ?c;
end }
3.2.1 Variables The first requirement of the domain description language is naturally to be able to define variables within an operator which are then initiated with a value during the planning process. Without variables, specific values would have to be included in operators, and the operators could not be generic.
Variables are prefixed by a ‘ ?’ in our planner, as in Figure 1, and other examples in this document. In CEP, variables must be defined as a type of object that is known to the domain, for example: inlet ?source;
The capability to define variables in a DDL is standard, see [7] and [10].
3.2.2 Information Association A chemical plant is typically a large and complex configuration of hundreds or possibly thousands of components, producing potentially enormous search spaces in planning. Where variable instantiations are related to each other for a specific plant, it is desirable to allow this information to be presented to CEP, rather than leaving it to search through all possible combinations. Initially, this information was included directly into operators, allowing faster performance, and in some cases successful planning for a domain that the planner was previously failing on. However, an operator containing this information for a specific plant cannot be generic. Thus a new feature was added to CEP that allows the definition of plant specific knowledge outside of the operators. This involved the association of two pieces of knowledge called a pair. Note that a pair should only be used for well defined and obvious associations within the domain. Two pairs can be seen in the macro operator of Figure 1: pair unitSource, ?pilot : ?source pair chemSupply, ?source : ?fuel
This means that when the operator instantiates the variables ?pilot and ?source the only possibilities will be the values used in the definitions for this pair, which are declared outside the operator as part of the plant model. Thus the pair definitions are plant specific, but the calling of the pair in the operator is generic due to the use of variables. In the given example, a flow of fuel is required from a source into the pilot. Without the pair feature CEP would have to try all the possible sources during planning until one was found that was suitable, but now only the sources defined in a unitSource pair would be tried. Here are a unitSource and a chemSupply pair declaration: pair (unitSource, PI1 : Input4). pair (chemSupply, Input4 : NaturalGas).
These definitions state that for this domain the pilot PI1 has a source Input4 which supplies Natural Gas. This knowledge is obvious from the Engineering Line Diagram for the plant, but is not captured in the domain model generated from AutoCad. It seems perfectly feasible to extract pairs automatically from the ELD by recording the pair requirements of operators selected from the library and then matching these against the plant model. Pair definitions are held in a separate file in the domain specific set. There must be at least one pair definition for each type of pair used in the operators for a domain. Pairs are a good example of the additions required in CEP’s DDL to support generic operators and were a result of the size and complexity of real-world chemical plant.
3.2.3 Hierarchical Operators Hierarchy is basic in two separate ways in the chemical plant domain. Firstly, as previously seen, a plant can be thought of as a part-of hierarchy where the root - the whole plant - is unique, but the leaves - the specific pieces of equipment - are generic. This was the justification above for creating generic operators. However, secondly, the pieces of equipment in a plant can be thought of as part of an abstraction hierarchy [11], with categories of equipment towards the top and more specific components lower down. A pump may sound like a specific component, but in fact there are different types of pump - for example a rotary pump and a centrifugal pump - and each type may be
made by different manufacturers who implement the functionality in slightly different ways. Generic operators can be thought of as the behaviour associated with a specific level in the equipment hierarchy. A high level generic operator can be created for a piece of equipment and then specialised as a lower level operator containing specific details. For example any pump needs to have a flow of material passing through it before activation, and so a generic operator could be used for this, but the way the pump is turned on might involve a switch for one make, and a lever for another make. However, note that even the more specific lower level operators may still be reusable as it may be possible to split different manufacturers into different sets by equipment design. The importance of hierarchy in the domain meant that it was important that the structure of operators could be hierarchical in CEP. This is similar to the expands structure of operators found in O-Plan [2].
3.3 Reusable Operator Development Methodology Once a satisfactory DDL has been written a methodology is needed for the design of operators that will result in as many possible of them being generic and reusable. The following sections discuss the lessons learned from the development of operators for the various domains that have been investigated as part of our research
3.3.1 Operator Names A sensible naming convention must be established for operators as the name is the index for retrieving it from the library. Its name needs to indicate what the operator does and what domain object it does it to. For example, startPump tells us that an operator is going to start-up a piece of equipment and the second word (the beginning of which is indicated by the capital letter) tells us the piece of equipment it will start-up.
3.3.2 Reusable Pre-conditions Operator pre-conditions are a major potential source of material which would prevent generic use of the operator. Firstly, the conditions might not be generic because they directly referenced a plant specific value. However, badly designed operators can also have conditions that prevent the operator being used successfully again during the creation of a particular plan, and though an operator is generic it is not reusable in a new domain. For example, in the domains we are currently working on, the synthesis of operating procedures for chemical plants, there is an operator for creating flows [12]. The original flow operator required all the valves in and around the flow to be shut before creating the flow. This produced problems when creating two flows through the same part of the plant as valves would be closed to create the second flow that resulted in the stopping of the first flow. The result was that plant specific details - viewed as ‘cheats’ - had to be used in a domain specific operator that was used to create the second flow. The solution was to solve the problem in a more general manner by changing the pre-conditions of the flow operator to allow multiple flows through the same part of the plant. The flow operator was adapted to prevent any unwanted closing of valves by assigning a ‘use’ to flows, which then made it possible for flows to use the same part of a plant without closing other valves if they were for the same use.
3.3.3 Information Association There are three main aspects to the use of pairs. Firstly, the use of too many pairs should be avoided as this leads to the representation of knowledge that the planner does not need to know or can deduce. Secondly, using pairs for knowledge that is not clear from the ELD for the plant should also be avoided. Thirdly, the naming of pairs should stick to a standard format which will make it easier for the user to understand the reasoning for the existence of a pair. The name
for the first part of a pair is all lower case and then the name for the second part starts with a capital letter.
3.3.4 Hierarchical Operators Discussion with experts in plant operation suggests that they operate at three levels: that of the individual components, that of ‘chunks’ of plant, and that of the plant as a whole. We advocate writing the operators at the bottom of this hierarchy first. These are precisely the reusable generic operators that can form part of an operator library and which will be used the most in the creation of the final overall plan. For example, in a chemical plant the low level operators would be for the valves, pumps, evaporators etc. These are used to create the set of actions for starting up the plant. One can then proceed to operators for chunks of plant and thence to the whole plant. Creating the operators from the bottom up ensures that the important re-usable low level operators for a domain are independent of each other, hence making them generic and reusable. Developing operators from the top down was found to create operators for low level equipment that were wrongly linked to the operation of other low level equipment operators. Thus our experience contradicts that of some others - for example the top down approach is recommended by O-Plan [2].
3.4 Reusable Operator Development Tools This section discusses how the library of operators is structured and used. We discuss the CEP user interface - actual and projected - for the generation of the domain description and for the generation of operators when the library of operators does not contain a suitable operator for a new domain.
3.4.1 Library Structure The index for operators in the library is the piece of equipment for which they model the behaviour. Thus the library needs as its first component the equipment hierarchy. Added to this are the list of states that are used in a chemical plant - for instance on/off, open/closed, true/ false - and the other categories and objects which belong to the chemical plant domain - such as solid/gas/liquid, cooling water, steam etc. - which themselves form a hierarchy. These components of the library can be thought of collectively as an ontology for the chemical plant domain. The operators component of the library is held for convenience in a separate file, with the operators grouped according to equipment type. To support browsing of this file, markers were added to certain lines to allow the user to view its contents in different ways and at different levels: such as the titles of the sections into which the operators are grouped, operator names, and the goal(s) achieved by an operator. The sectioning of the file and the adding of markers allows easier access to the contents of the library of operators, and should aid in the selection of operators when necessary.
3.4.2 Implementation Two ways of using the library were considered. The whole library could be loaded when planning or alternatively only the relevant operators for a particular plant could be pulled out of the library into a domain-specific file. Loading the whole library means handling large files which will get even larger with time. This is bound to slow down planning and may also pose a problem for checking and validation of a particular domain. Moreover CEP requires instantiation of all the variables and pairs that are used in the loaded operators, resulting in the use of dummy values for the operators in the library that are not actually applicable to the current plant.
The second approach is to select the relevant operators from the library and then only load these operators. A file of operators which is smaller than the main library of operators will be created which will be easier to use. The selection of the correct operators is important, especially making sure that no useful operators are missed out. The library has to be structured in a way that allows access to its contents. Unique, expressive names (with the correct level of detail) for operators will be important for finding the relevant operators. A consistent structure for the operators will also help greatly in the selection of operators, and at the same time make it easier for the user to understand the working of an operator. Both approaches were used successfully in our case studies, but the second approach was selected for the reasons just suggested. Finally, an interface for interacting with the operator library is required, and the use of markers is a first step in this direction.
3.4.3 Creation Interface It is unlikely that the library will always contain every operator required for a new chemical plant domain. Therefore, an interface for the creation of new operators is important as this will aid in the difficult process of operator creation, and will not require that the user knows the DDL for the planner. The new operators will be for previously not encountered items of equipment, and for the high-level operators that are concerned with a chunk of plant or the whole plant as these are bound to be plant specific. A high-level operator must be checked to see if its goals can be solved by the available low-level operators, with any that cannot throwing up warnings. The interface should present an example operator to the user in order to guide them. This could be an operator for a piece of equipment that is judged to have a similar operation, either selected automatically or by the user with the interaction interface. The creation interface should also help the user by providing a blank template for an operator. An operator editor is also required to detect errors in format, query the structure, and advise the user. As an operator is developed the example operator shown to the user should change if the most similar existing operator is found to change.
4.0 Results In this section the development of the DDL for CEP, and the resulting library of operators is described and the results discussed.
4.1 Development of Domain Description Language The process followed for the development of a domain description language for CEP that allowed a library of operators is shown in Figure 3. The diagram shows when the initial domain description language provided by CEP had to be changed. The first changes to the DDL were needed as the development of generic operators was made a priority and the language used by CEP was found to be insufficient. Then the failure of the planner to create a plan due to these generic operators and the use of more complicated domains facilitated the further development of the DDL for CEP.
4.2 Current Position A library of states, equipment definitions and reusable generic operators has been developed. This library of information has then been used on two different domains. Firstly, a Double
FIGURE 3. Development of Domain Description Language
Develop Domain Description Language
Write Operators
Debug Operators
Generate Plan
Add Operators to to Library
Effect Evaporator rig at Loughborough University (see [11] for an earlier implementation of this domain) and an ICI Ammonia Plant at Severnside, Bristol. The current library of operators contains 36 generic operators for the operation of equipment found in chemical plants. Of these 36 operators, 13 were found to be used by both domains, demonstrating in practice the validity of our hypothesis that operators are often useful for more than one domain when they are in a similar field. This was further demonstrated by a recently finished case study on a BP plant at Hull, the results of which will be published soon. We expect that the library will be of growing use for other chemical plants as we populate it with more operators. The current library was mainly created from the two case studies mentioned earlier, with virtually all of the operators that were created for the operation of each plant generic, and suitable for addition to the library. The only non-generic operators were the high level operators used to provide the order of operation for the major pieces of equipment in a chemical plant domain. The equipment types used to index the library were: Non-Tubular Heater, Tubular Heater, Reactor, Vessel, Separator, Plant structure, Machine and Valve. Markers were added to the library of operators file to display the sections into which the operators were grouped, operator names, and the goal(s) achieved by operators.
5.0 Conclusions and Future Work The case studies that we have carried out have shown that an AI planner can use a library of operators and the usefulness of such a library of reusable generic operators in practice. The library of operators for chemical plant domains will become even more useful as the number of different types of equipment whose operation is covered increases with further case studies. However, further work needs to be carried out in automatically selecting the operators from a library that are relevant to the current plant. It is felt that this can be incorporated into the current interface for creating the plant configuration in AutoCAD by prompting the user to add the behaviour of components as they are placed into the ELD. Further work also needs to be carried out on the interfaces for interaction with the libraries, and for library development. A new case study on a BP plant is currently in progress which will make use of the library, result in the addition of new reusable generic operators and give some feel for the amount of development time saved by using the library.
6.0 Acknowledgement This document has resulted from research done as part of the INTegrating OPerability (INTOP) project, which is developing a system that uses AI planning to generate operating procedures for chemical plants. This project is funded by EPSRC, with case studies provided by BP, ICI, Loughborough University and Science Systems.
7.0 References [1] Numerous People “PDDL - The Planning Domain Definition Language” AIPS-98 Planning Competition (1997). [2] O-Plan Task Formalism Manual, p59-61 [3] S. Chien, R. Hill, X. Wang, T. Estlin, K. Fayyad, and H. Mortenson “Why Real-World Planning is Difficult: A Tale of Two Applications.” New Directions in AI Planning, IOS Press, Washington, DC (1996) 287-298. [4] J.K. Soutter “An Integrated Architecture for Operating Procedure Synthesis” Ph.D. Thesis. Chemical Engineering, Loughborough University, Leicestershire, UK (1997). [5] K. Currie, and A. Tate, “O-Plan: The Open Planning Architecture” Artificial Intelligence 52 (1991) 49-86. [6] C.A. Knoblock “Automatically Generating Abstractions for Problem Solving” Ph.D. Thesis, School of Computer Science, Carnigie Mellon University, Pittsburgh, PA (1991). [7] T. L. McCluskey, and J.M. Porteous “Engineering and Compiling Planning Domain Models to Promote Validity and Efficiency” Artificial Intelligence 95 (1997) 1-65. [8] ARPI (Air Force Research Laboratory (Rome) Planning Initiative) http://arpi.isx.com/ [9] T.J. Grant, H.J. van de Herik,and P.T. Hudson, “Which Blocks World is The Blocks World?” 13th Workshop of the UK Planning and Scheduling Special Interest Group, Glasgow (1994). [10] P. Jarvis, and G. Winstanley, “Using the Task Formalism Method to Guide the Development of a Principled HTN Planning Solution for the Construction Industry”. Submitted to the 17th Workshop of the UK Planning and Scheduling Special Interest Group, Huddersfield (1998). [11] R.S. Aylett, G.J. Petley, P.W.H. Chung, J.K. Soutter, and A. Rushton “Planning and Chemical Plant Operating Procedure Synthesis: a Case Study”. Proceedings of the 4th European Conference on Planning, Toulouse, France (1997). [12] R.S.Aylett, J.K.Soutter, G.J.Petley, P.W.H.Chung and A,Rushton.”AI Planning in a Chemical Plant Domain”. Proceedings, ECAI 98, John Wiley, pp622-626 [13] S. Polyak “Common Process Editor”. http://www.dai.ed.ac.uk/students/stevep/cpe/coa.gif
