Knowledge Engineering for Automated Planning

1. Knowledge Engineering for Automated Planning Lee McCluskey, Dept of Informatics, University of Huddersfiield, UK ICAPS Summer School June 2006

2. Abstract -1 Domain-independent planners rely on the input of formal, accurate and complete domain ‘descriptions’ before they can be used. …If a description contain bugs, or fails to contain relevant knowledge, then the planner will give incorrect results or no results are all. “If your PhD thesis is vacuous, turn it all into Predicate Calculus…” etc Informatics Research Group University of Huddersfield

3. Abstract -2 But how can domain ‘descriptions’ be accurately and efficiently built up? Is it possible for descriptions to be arrived at by non-planning-experts, or by automated means? This tutorial is concerned with the acquisition, formulation, validation and maintenance of planning domain descriptions. Informatics Research Group University of Huddersfield

4. Abstract -2 We will scratch the surface of: • the general area of knowledge engineering (KE), • the area of KE for AI Planning, • existing KE tools for planning, including some entered in the ICAPS-05 KE for planning competition. We will also do some practical work with GIPO, a tools environment used as a research tool for exploring knowledge formulation methods for classical planners. Informatics Research Group University of Huddersfield

5. Introduction Informatics Research Group University of Huddersfield

6. B A Goal Initial A B A I Planning and Scheduling has moved on in the last 10 – 20 years… THEN NOW Informatics Research Group University of Huddersfield

7. Introduction: MAIN ASSUMPTION The scope of ‘AI Planning’ is the synthesis / generation and execution of PLANS. The MAIN ASSUMPTION of virtually all work in AI Planning is that there should be a logical separation between • The Planning Engine • The Domain Model Planning System Planning Engine Conceptualisation Of APPLICATION DOMAIN Domain Model - A rich Ontology Informatics Research Group University of Huddersfield

8. Introduction Some implications of this assumption: • planning engines AND domain models can be developed, tested, debugged, validated independently - the ‘model’ of the particular application of planning is developed in relative isolation to the Planning Engine • domain models may be useful for more purposes than simply automated planning functions • Planning engines can be re-used • It tends to made AI Planning very different from applied areas such as planning and scheduling in manufacturing Informatics Research Group University of Huddersfield

9. Introduction Some negative consequences of assumption .. • How and what knowledge is encoded is influenced by ‘what planners can handle’ • Potentially we could have gross inefficiencies in systems akin to ‘compilation’ rather than ‘hand coding’ in software. Systems hand coded for particular applications are likely to be much more efficient. Informatics Research Group University of Huddersfield

10. B A Goal Initial A B Introduction Much work has been carried out in developing planning engines, pushed along by the International Planning Competition (AIPS’98, AIPS’00, AIPS’02, ICAPS’04) BUT methods and tools to help develop the domain models have had relatively little attention Conceptualisation ? Informatics Research Group University of Huddersfield

11. Basic Concepts in Knowledge Engineering Informatics Research Group University of Huddersfield

12. Knowledge Engineering – a holistic definition In most general terms, Knowledge Engineering is the engineering of (those parts of) a system which contains and reasons with some explicit representation of knowledge OR (for fans of sub-symbolic AI) the engineering of (those parts of) a system whose behaviour indicates that it contains and reasons with knowledge. Informatics Research Group University of Huddersfield

13. Knowledge Engineering – sum-of-parts definition KE contains sub-processes such as Acquisition – the process of finding and collecting adequate amounts of relevant knowledge, conceptualising it, and formulating it into knowledge structures in a KBS Verification and Validation – validation: are we building the right product? verification: are we building the product right? These processes take the form of identifying and removing bugs in the KBS either because knowledge is inaccurate/incorrect (validation) or knowledge transformations are incorrect (verification) Maintenance – updating and incrementally debugging a KBS Informatics Research Group University of Huddersfield

14. Knowledge Engineering – historical angle Knowledge Acquisition/ Engineeringis a huge area in AI related to Knowledge-based Systems (KBS) • Initially KA was focused on the idea of 'knowledge transfer', where constructing aKBS amounted to extracting the ‘knowledge’ from expertsand encoding it within an expert system 'shell‘ (20 – 30 years ago..) Expert System Application expertise Knowledge transfer Procedural expert knowledge Informatics Research Group University of Huddersfield

15. Knowledge Engineering – historical angle The old ideas of KA lead to the famous knowledge acquisition ‘bottleneck’ of the 70’s/80’s Knowledge Expert System brittle shallow Informatics Research Group University of Huddersfield

16. Knowledge Engineering – current wisdon: building deep, reusable models • Now KBS wisdom emphasises the building of • a deep causal model prior to the building of an operational system. This domain model has to embody not just the proceduralexpert knowledge but enough environmental and ‘first principle’ knowledge to justify the procedural knowledge. • Re-usable, globally exchangeable knowledge structures such as ontologies, so that KBS need not be constructed from scratch Rules Globally Accessible Ontologies Causal model Informatics Research Group University of Huddersfield

17. Knowledge Engineering – Methodological and Tool Support In the last 20 yrs modelling frameworks with tool support have been developed– most notably CommonKads “Knowledge has come to be recognized and handled as a valuable entity in itself.” “there is a strong need to convert the art and craft of knowledge engineering into a real scientific discipline” Quotes from the web site: http://www.commonkads.uva.nl/ Tools such as this support the process of knowledge acquisition and validation, and areunderpinned by an overall method of development.CommonKads advocates the use of a series ofmodels during domain capture, each dealing with differentaspects of the domain. Informatics Research Group University of Huddersfield

18. Knowledge Engineering – increase in scope • In the last 10 yrs KE is now much broader in scope than simply crafting knowledge for expert systems. This is because of the rise of The Knowledge-Driven Economy The main artifact emerging from this is the “ontology”. KE now encompasses ‘ontological engineering’ and ontology building tools such as Protégé have been built specifically to encode Ontologies in common forms of description logics. = Knowledge Informatics Research Group University of Huddersfield

19. Knowledge Engineering of the Semantic Web The Semantic Web – making internet resources globally understandable by internet programs – demands that these ‘resources’ have to be acquired in an explicit form (like a knowledge base). Trust (part of) the Layer-Cake Model of the Semantic Web Inference Logic RDF XML Informatics Research Group University of Huddersfield

20. My KE history: Aircraft Separation Criteria segment2 segment1 Shanwick Oceanic Area Informatics Research Group University of Huddersfield

21. [(one_or_both_of Segment1 and Segment2 are_flown_at_subsonic_speed) & ( the_Aircraft_on(Segment1) and the_Aircraft_on(Segment2) meet_mnps) & ( the_Aircraft_on(Segment1) and the_Aircraft_on(Segment2) are_jets & (the_Profile_containing(Segment1) & the_Profile_containing(Segment2) are_wholly_or_partly_in_the_ mnps_airspace) ] => [(the_basic_min_longitudinal_sep _Val_in_mins_required_for Segment1 and Segment2) = 10 <=> …. ETC the_basic_min_longitudinal_sep_Val_in_mins_required_for(Segment1,Segment2,10):- are_subject_to_oceanic_cpr(Segment1,Segment2), both_are_flown_at_supersonic_speed(Segment1,Segment2), (both_are_flown_at_the_same_mach_number_in_level_flight(Segment1,Segment2) ; the_Aircraft_on_segment(Segment1,Aircraft1), the_Type_of(Aircraft1,Type1), the_Aircraft_on_segment(Segment2,Aircraft2), the_Type_of(Aircraft2,Type2), Type1=Type2, are_cruise_climbed(Segment1,Segment2) ), .. ETC And the formulation.. Informatics Research Group University of Huddersfield

22. Planning Domain Engineering with GIPO Informatics Research Group University of Huddersfield

23. GIPO – what is it? GIPO (Graphical Interface for Planning with Objects) is an experimental GUI and tools environment for building planning domain models. • It is written mainly in Java, with some embedded tools in Prolog, and is under continuous development. • It is a product of PLANFORM, a UK EPSRC-funded research project, written at The University of Huddersfield UK. Website: http://scom.hud.ac.uk/planform • Our long term aim is make planning technology more usable and available! Informatics Research Group University of Huddersfield

24. GIPO – versions GIPO 1 Generally available For ‘Flat’ models (ECP’01) GIPO+ Not on release For models with cts time, events and processes (PlanSig’03) GIPO 2 + automated induction of action schema (AIPS’02) + HTN represntation (ICAPS’03) GIPO 3 + OLHE + Cts domains ICKEPS award (ICAPS’05) Informatics Research Group University of Huddersfield

25. GIPO -functions GIPO allows a user to create new domain models, import and change old ones via a GUI, or store and re-use components. It features • on-line tutorial and OCL manual • Tools for initial model acquisition and re-use • Tools for model validation • Planning engines 3rd party Planning engines can be ‘bolted on’ at the ‘GIPO 1’ level as it outputs PDDL v1.2, and can accept generated plans from them. Informatics Research Group University of Huddersfield

26. GIPO – main tools Some are specific to a particular GIPO version • syntax and semantic checks for individual components of a model. Semantic cross checking between components. • Object Life History Editor • an action schema induction tool • a plan stepper • a plan animator • a random task generator • built-in planners Informatics Research Group University of Huddersfield

27. Language underlying GIPO: OCLh OCLh is a language developed precisely for helping with the BUILDING of domain models It is similar in some respects to PDDL but- • It has structure using object classes and state abstractions • It has a tools environment called GIPO which supports a model building method Informatics Research Group University of Huddersfield

28. Demonstration Example: Lazy Hiking World • Imagine Sue and Fred want to have a hiking holiday in the Lake District in North West England. • They walk in one direction, and do one ``leg'' each day. But not being very fit, they use two cars to carry them / the tent / their luggage to the start/end of a leg. • They must have their tent up already so they can sleep the night, before they set off again to do the next leg in the morning. • Actions include walking, driving, moving and erecting tents, and sleeping. • The requirement for the planner is to work out the logistics and generate plans for each day of the holiday. Fairfield Helvelyn Coniston Informatics Research Group University of Huddersfield

29. Automated acquisition by induction(Opmaker) INPUTS: Offline: Partial domain spec, got via GIPO or other acquisition method (eg importing an ontology):- Objects, object classes, predicates, invariants Online: Training sequences, initial states, and user input. Example training sequence: Load tent1 sue keswick Get-in-car sue car1 keswick Drive sue car1 keswick helvelyn tent1 Unload tent1 sue car1 helvelyn Putup tent1 sue helvelyn ETC OUTPUTS: A set of Action Schema – one for each action name in training Informatics Research Group University of Huddersfield

30. Knowledge Engineering in AI Planning Informatics Research Group University of Huddersfield

31. My Definition Knowledge Engineering in AI Planning is the process that deals with • acquisition,validation and maintenance of planning domain models, and • theselection and optimization of appropriate planning machinery to work on them. Hence, knowledge engineering processes support the planning process –theycomprise all of the (mainly off-line) knowledge-based aspects of planning that are todo with the application being built. (definition in EU PLANET Roadmap – http://scom.hud.ac.uk/planet/home/) Informatics Research Group University of Huddersfield

32. Knowledge Engineering for AI Planning: More Terminology • Domain is the conceptualisation of the application area • Domain model is a formal model (theory or ontology) of the conceptualisation • Acquisition is the process of producing a domain model of the application area • Modelling is the area of using the model to predict behaviour in the application area • What about domain description, domain specification, domain definition…? Informatics Research Group University of Huddersfield

33. Knowledge Engineering for AI Planning: Terminology Symbolic World DOMAIN = Conceptualisation of an APPLICATION AREA Acquisition Domain Model Domain Model Language Validation and Model Refinement Informatics Research Group University of Huddersfield

34. Knowledge Engineering for AI Planning: Validation Validation of a model is the process that promotes its quality interms of internal and external criteria by the identification and removal oferrors in the model. Note the distinction between • validation of a domain model and • validation of a planning system. The former supports the latter, and occurs ata much earlier stage in system development. Informatics Research Group University of Huddersfield

35. Knowledge Engineering for AI Planning: Validation Validation Criteria • Internal criteria includes properties such as syntacticcorrectness and logical consistency; in general these properties can be provedformally and are not problematic. • External criteria includes properties suchas accuracy, correctness and completeness. Given that the sources of the modelwill not often be a mathematical object, these properties can never be provedcorrect (in the same sense that a requirements specification can never beproved correct). Informatics Research Group University of Huddersfield

36. Support for KE in AI Planning: the Domain Model Language When experts think about creating domain models/description, they immediate think of the DML/DDL eg PDDL. Languages should.. Be associated with a method. This will give a set of ordered steps to be carried out in order to capture the domain model, thus guiding the knowledge engineer throughout the process. It could contain activities such as modeling of state changes and the discharging of proof obligations. Be tool supported. These tools will support the steps in the method and, using the structure of the model language, be able to provide powerful support for statically validating, analyzing and operationalizing the model. Be expressive and customizable. The language needs to be generally applicable, yet customizable in some sense so that it ``fits'' well with applications. Since there is a whole range of assumptions involved in planning which may or may not hold in an application (\eg to do withuncertainty, resources, closed world) it may be that the modeling languagewill have ``variants'' to deal with different assumptions. Informatics Research Group University of Huddersfield

37. Support for KE in AI Planning: the Domain Model Language Support the operational aspects of the model.The language's framework should include a set of properties and metrics which can be evaluated to assess a model's operationality and likely efficiency. It should be possible predict whether the model can be translated to an efficient application. Have a clear syntax and semantics. As a basis for the other aspects above, and for the analysis of models encoded in the language, it should be possible to map models to a ``meaning'' within some well-known formal system such as a modal logic. Be structured. It should provide mechanisms that allow complex actions, complex states and complex objects to be broken down into manageable and maintainable units. For example, the dynamic state of a planning application could be broken down into the dynamic state associated with each object.On this structure can then be hung ways of checking the model for internal consistency and completeness. Informatics Research Group University of Huddersfield

38. Current State of AI Planning PDDL is the common communication language. Main variants of PDDL.. PDDL 1 1998 – first IPC 2002 - Added Duration and Numerical Quatities PDDL 2.1 2003 - Added timed initial facts, derived predicates PDDL 2.2 PDDL+ 2002 - Added Processes, Events, cts time Informatics Research Group University of Huddersfield

39. PDDL PDDL is a family of ‘standard’ communication language for domain descriptions/models which is ‘extensible’ and ‘modular’ to some degree But PDDL … • has no associated method for building models • has little ‘structure’ for helping in model building • has little in the way of ‘standard’ static tools to help in de-bugging. They are some dynamic tools (eg VAL) Rather – designers use an environment for KE and then produce PDDL (machine code!) to interface with a planner Informatics Research Group University of Huddersfield

40. Current State of AI Planning Summary - Good News: • Plan generation algorithms are much more efficient than 10 years ago, and can work efficiently in more expressive problems domains But there is Bad News: • Technology transfer: there is much to do in making the technology generally available and usable • Model development: domain model authors tend to use planners themselves to try to develop and debug a domain model. Planners have not generally been designed for this purpose Informatics Research Group University of Huddersfield

41. Summary Planning Domain Models are hard to design, write, debug, maintain - even for experts. The process of encoding is laborious. Bugs are of various types can lurk in models for a long time. As planners and planning applications become larger, the problems of engineering planning domain models become more acute. There is a need to research into engineering environments and explore their synergy with general purpose planners. Application Domain Model Acquisition is Very hard!! Informatics Research Group University of Huddersfield

42. Brief Biased Survey of Knowledge Engineering for AI Planning: Tools and Systems Informatics Research Group University of Huddersfield

43. Introduction There are few deployed AI Planning systems There are even fewer KE tools for Planning There are even fewer planner-independent KE tools for Planning Informatics Research Group University of Huddersfield

44. Applications of AI Planning See web site http://vitalstatistix.nicve.salford.ac.uk/planet2/ Industrial / Government / Control e.g. • Planning in a forest fire simulation system (PHOENIX, SIADEX) .. + disaster recovery in general • Brewery production-line scheduling (SIPE-2) • Generation of control programmes for industrial plant - the MACHINE planning system • Oil Spill Response Planning in SIPE-2 • Ship Building using ARGOS shipyard scheduling optimisation system • Aircraft crew scheduling • Chemical Plant control Informatics Research Group University of Huddersfield

45. Applications of AI Planning See web site http://vitalstatistix.nicve.salford.ac.uk/planet2/ Aerospace e.g. • Satellite mission planning and scheduling (European Meteostat) • Planning and Scheduling of Spacecraft Assembly • Autonomous control of spacecraft - the NASA Remote Agent experiment • ‘Vicar’ Planner applied to automated image processing Military e.g. • Planning for military air campaigns - SIPE-2 • DARPA/Rome Planning Initiative - A military scheduling project Informatics Research Group University of Huddersfield

46. Applications of AI Planning Other Current and Future Application areas • Web Agents, • Games Software • Physical Robots, Autonomous Vehicles • Other area in ‘Control’: • Workflow/Workforce • Air Traffic • Project planning • Transport Logistics Informatics Research Group University of Huddersfield

47. Deployed planning systems The two main ‘general’ domain-independent planning systems used in ‘real’ applications are: • O-Plan / I-X (Edinburgh University) • SIPE (Stanford Research Institute) Both have very expressive domain models languages, BUT - to make an application efficient, the user must encode appropriate heuristics -to be able to use them, one has to be a planning expert, a modelling expert and an application expert. Even then, developing domain models is a painstaking process. Informatics Research Group University of Huddersfield

48. ICKEPS - aims The First International Competition on Knowledge Engineering for Planning and Scheduling was held at ICAPS last year… The aims of the Competition were to • promote the knowledge-based and domain modelling aspects of P&S • accelerate knowledge engineering research in AI P&S • encourage the development and sharing of prototype tools or software platforms that promise more rapid, accessible, and effective ways to construct reliable and efficient P&S systems Informatics Research Group University of Huddersfield

49. ICKEPS - systems • Tailor: Helping end users modify procedures by instructionJim Blythe and Varun Ratnakar • Hamlet: Tool for automatically acquiring control knowledge for planningDaniel Borrajo, Susana Fernández, Raquel Fuentetaja, Juan D. Arias, Manuela Veloso • PlanWorks: A debugging environment for constraint based planning systemsPatrick Daley, Jeremy Frank, Michael Iatauro, Conor McGann, Will Taylor • ModPlan: Knowledge acquisition and knowledge engineering in the ModPlan workbenchStefan Edelkamp and Tilman Mehler • GIPO: A graphical interface for planning with objectsRon M. Simpson • itSIMPLE: Tool for modelling planning domains Tiago Stegun Vaquero, Flavio Tonidandel, José Reinaldo Silva • ARMS: Action-relation modelling system for learning action modelsKangheng Wu, Qiang Yang, Yunfei Jiang Informatics Research Group University of Huddersfield

50. Example ICKEPS tool set: Hamlet/PLTOOL Aim: mixed – initiative tool for creating and selecting control rules and planning heuristics Inputs: Training problems, user choice, quality metric Outputs: A selected set of control rules (macros) and heuristics Method: This system developed at UC3 Madrid is a collection of learning techniques hooked into planners. They analyse the solutions/search trees of the training examples and extract heuristics / macros / control rules from them Informatics Research Group University of Huddersfield