Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Automated Planning as a Semantic Technology


Published on

Published in: Technology, Business
  • Be the first to comment

  • Be the first to like this

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 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, 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:  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:  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:  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
  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