O slideshow foi denunciado.
Utilizamos seu perfil e dados de atividades no LinkedIn para personalizar e exibir anúncios mais relevantes. Altere suas preferências de anúncios quando desejar.

Automated Planning as a Semantic Technology

  • Entre para ver os comentários

  • Seja a primeira pessoa a gostar disto

Automated Planning as a Semantic Technology

  1. 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. 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. 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. 4. Introduction to automated planning 4
  5. 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. 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. 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. 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. 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. 10. Examples of planning systems 10
  11. 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. 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. 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. 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. 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. 16
  17. 17. 17
  18. 18. Siemens Tecnomatix 9 CAM-oriented planning tasks 18
  19. 19. Hierarchical planning 19
  20. 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. 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. 22. Case Study: Configuring the Cloud With Elastra Enterprise Cloud Server 22
  23. 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. 24. The Elastic Modeling Languages: OWL Ontologies for Cloud Computing 24
  25. 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. 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. 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. 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. 29. Semantic Technologies in Planning 29
  30. 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. 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. 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. 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. 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. 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. 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. 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. 38. Thank you for your attention! Questions? 38