Your SlideShare is downloading. ×
Automated Planning as a Semantic Technology
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Introducing the official SlideShare app

Stunning, full-screen experience for iPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Automated Planning as a Semantic Technology

1,667
views

Published on

Published in: Technology, Business

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
1,667
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
42
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Configuring the Cloud Automated Planning as a Semantic Technology 2010 Semantic Technology Conference Blazej Bulka, PhD Stuart Charlton Clark & Parsia, LLC Elastra blazej@clarkparsia.com stuartc@elastra.com www.clarkparsia.com www.elastra.com 1
  • 2. Who we are?  Clark & Parsia is a semantic  Elastra is a cloud computing software startup software startup  Offices in DC and Cambridge,  Offices in San Francisco, CA MA  Co-Funded by Amazon.com, Bay  Software products for end-user Partners, and Hummer Winblad and OEM use  Provides software and services for  Provides software development helping organizations migrate and and integration services manage their applications in private and public clouds  Specializing in Semantic Web, web services, and advanced AI  Elastra Cloud Server available for technologies for federal and Amazon Web Services and VMWare enterprise customers
  • 3. Outline  Introduction to automated planning  Examples of planning systems  Hierarchical planning  Case Study: Planning in Cloud Computing  Semantic technologies in planning: HotPlanner from Clark & Parsia  Conclusion 3
  • 4. Introduction to automated planning 4
  • 5. What is automated planning?  Automated process to determine which actions need to be taken to achieve a desired goal  Current state of the world  Description of actions Planning Required actions  Goals and constraints system (plan)  Multiple applications of produced plans − Software execution − Human execution 5 − Assistance in solving a problem
  • 6. Simple example Installing new software package  Current state of the world: Description of installed software packages and their dependencies  Available actions: − Retrieve list of packages available for install from a server − Retrieve package dependencies − Download software package − Install software package  Goal: Install software package X  Plan – sequence of actions specifying which packages to download and install, and in which order 6
  • 7. Domain-dependent planning  Solves one type of problem well  Specialized algorithm and data representation (the designer encoded the structure of the problem and solution in the code)  Small modifications to problem (e.g., new kinds of dependencies between software packages) = modifications to the planning system  Larger modifications to problem = rewriting 7 significant portions of the planning system
  • 8. Domain-independent planning  Solves problems in multiple, entirely different domains (e.g., software management, truck routing, space mission control)  Domain (actions, state of the world, goals) have to be specified in a way understandable to the planning system  Generic planning algorithm  Modifications to planning problem (small or large) – modifications to the domain specification = No change of planning system's 8 code
  • 9. What makes a plan good?  Depends on the application  Typical quality metrics − Plan length (number of actions) − Makespan (time to execute the plan) − Plan cost (every action has a cost associated with it) − Multi-objective metrics 9
  • 10. Examples of planning systems 10
  • 11. Space Exploration: Deep Space Network Images: nmp.nasa.gov/ds1/  Deep Space 1 (DS1) − First ever close pictures of a comet (Borelly in 1999) − Part of Deep Space Network − Proof-of-concept for later systems  Benefits − Spacecraft autonomy − Commands = goals − Plan verification − Execution monitoring 11
  • 12. Earth Observing-1 Mission (EO-1) Images: eo1.gsfc.nasa.gov  Proof-of-concept for autonomous sensor web (incl. satellites, buoys etc.)  Autonomous analysis of data  Feature detection (e.g., fire) and decide to investigate on its own  Collaboration among multiple satellites  Plan activities: transmissions, power usage, set-up, camera usage  Dramatic increase in amount of scientifically usable data (1000 x ?) 12
  • 13. Mars Exploration Rovers and MAPGEN Images: www.nasa.gov  Autonomous execution of plans prepared on Earth  Very limited planning on Mars  MAPGEN – computer planning system assisting human planners  Can produce explanations of dependencies  Successor of MAPGEN is EUROPA (Extendable Uniform Remote Operations Planning Architecture) 13
  • 14. Xerox RMP  Planning system for Rack Mounted Printing prototype − System with multiple parallel printing engines (for performance and fault tolerance) − Sheet path planning (and re-planning in case of failure) 14 Images: Do, Ruml, and Zhou (ICAPS 2008 Proceedings)
  • 15. Planning in games  Strategy games and first-person shooters − Killzone 2 (Game of the Year 2009 in Shooter category)  500 plans per second − F.E.A.R. and Condemned: Criminal Origins 15
  • 16. 16
  • 17. 17
  • 18. Siemens Tecnomatix 9 CAM-oriented planning tasks 18
  • 19. Hierarchical planning 19
  • 20. Hierarchical planning  HTN (Hierarchical Task Network) planning  Hierarchy of actions/goals  Hint on the problem structure from the domain expert  Prevents reinventing the wheel by the planning system  Planner can first solve high-level goals and then refine lower-level ones  Significant improvement in performance  Designed templates of desired solutions (e.g., plans that adhere to internal policies) 20
  • 21. Example HTN Plan Goal: Have package X Install package X Download Satisfy Download Install package list dependencies X X for X Have package Have package Y Z Install Already package Y installed Satisfy Download Install dependencies Y Y for Y 21
  • 22. Case Study: Configuring the Cloud With Elastra Enterprise Cloud Server 22
  • 23. Elastra Enterprise Cloud Server Monitoring & Capacity Application-Level Automation OS-Level Automation Event Virtualization Correlation Managers Automated Application Discover Systems Manage Publish Deployment & Scale Out Integrate Subscribe Planning & Orchestration Configuration Agents Monitoring Systems Integrate Public Cloud APIs 3 Party IT Systems rd PDP Federated Identity & Access Control PEP • Configure, Deploy, and Scale Multi-Tier Applications » Commercial and/or open source software • Manage Applications Across a Hybrid Cloud » VMWare, Amazon Web Services, others • Portable & Consistent Cloud Application Management
  • 24. The Elastic Modeling Languages: OWL Ontologies for Cloud Computing 24
  • 25. Meeting the Challenges of IT Automation: How can these two servers communicate? Possible areas of problems: • Security » Bad credentials • Server Configuration » Wrong IP or Port » Bad setup to listen or call • Network Configuration » Wrong duplex » Bad DNS or DHCP • Firewall Configuration » Ports or protocols not open
  • 26. How do we usually automate a configuration? • Scripts & Runbooks • In Situation X, do this • In Situation Y, do this • In Situation Y, but exception Z, do this • …. • Problems: Context, Variability, Timing & Transitions • Scripts require you to explicitly write out each control transition, assume you know in advance the one right way to do things • That’s fine in the small; in the large, it gets complicated. 26
  • 27. Elastra Next Generation Automation Engine: Elastra Plan Composer Strategy Examples: HTN Strategies Configure Full System Scale-Out a System Application Recover a Database & Deployment Data HTN Tactics Search for Next Tactics : (Background Set Firewall Rules HTN Atomic Restore Filesystem Individuals) Actions Install & Start Service Provision Network Elastic Jena + SPARQL Modeling Languages Search for Atomic Bindings: Clark & Parsia HotPlanner Configuration Agent Callout (OWL v2 Ontology) Cloud API Callout Clark & Parsia Pellet Virtualization Manager Callout 27
  • 28. Elastra’s Success Results with HotPlanner • Reduced, More Maintainable Codebase » Custom SPARQL and Java Code to interpret RDF, vs. HotPlanner’s Domain-Specific Language for HTN » Up to a 3x reduction in code length for various modules • Performance » Ability to generate a plan in under a minute for a 20 server, 20 component, multi-tier system design » Typical planning time: 3 to 5 seconds, up to 15 for complex » Near-equivalent to classic manual SPARQL-based analyzer • Visibility and Modifiability of Plan » Plans are just OWL-S processes, easy to parse, render to GUI, and/or modify before execution 28
  • 29. Semantic Technologies in Planning 29
  • 30. Semantic technologies in planning  Semantic technologies have not been used together with planning frequently so far − Promising opportunity  Modern semantic technologies (RDF and OWL) are relatively new compared to planning  Planning finally became usable in real-world settings − The two areas can contribute to each other − Many places where one area's weakness is the other's strength 30
  • 31. Expressing planning domain  Planners depend on accurate formal description of planning domain − Language to describe the current state of the world − Goals − Actions  Parameters (e.g., install package X)  Preconditions (when an action may be executed)  Effects (what changes in the world when the action is executed)  Hierarchy  Ideal solution − Expressive (e.g., describing quantities) − Keep computational complexity under control 31
  • 32. Classical planning formalisms are inadequate  Traditional formalisms − STRIPS, PDDL (Planning Domain Definition Language) − Limited expressivity Expressing complex domains difficult − Support for hierarchical planning is sparse 32
  • 33. Representing planning knowledge in OWL  Describing the current state of the world in RDF and OWL − Expressive language − Designed with computational complexity in mind (e.g., various profiles EL, RL, QL) − Can be used to infer information about the current state of the world that is not explicitly specified 33
  • 34. Describing actions and hierarchies based on OWL-S  OWL-S is designed to specify descriptions of Web services  Can be used to specify any action in Hierarchical Planning by using owls:Process − Composition of actions (hierarchy) − Preconditions − Effects − Parameters of actions 34
  • 35. Challenges  OWL ontologies are designed to represent static data  Planning includes reasoning about changes − Describing effects of action (some axioms become true, other become false) − Identifying invariants that are preserved − Matching effects of one actions with preconditions of others 35
  • 36. HotPlanner  Clark & Parsia's response to these challenges  Used in production systems  Uses Pellet OWL reasoner for state knowledge base management, reasoning and query answering – Can plan and optimize for multiple objectives – Extension to OWL-S for actions – Scheduling and planning for parallel task execution  For more information go to http://clarkparsia.com/planner36
  • 37. Conclusions  Planning is a proven technology for task automation, decision support, autonomous systems  Semantic technologies and planning have a lot to offer to each other  Automated planning is quickly growing in use for Cloud Computing automation 37
  • 38. Thank you for your attention! Questions? 38