IWPSS Oct 2006 Design of a Deep Space

IWPSS Oct 2006 Design of a Deep Space Network Scheduling Application For more information about this work, contact: Brad Clement Jet Propulsion Laboratory MS 126 -347 4800 Oak Grove Drive Pasadena, CA 91109 -8099 Email: brad. clement@jpl. nasa. gov Tel: +1 (818) 393 -4729 Bradley J. Clement, Mark D. Johnston Jet Propulsion Laboratory, California Institute of Technology Contact: {firstname. lastname}@jpl. nasa. gov Abstract The Deep Space Network (DSN) is a collection of ground antennas used to provide communication services for space missions at and beyond Earth. Currently, nearly 30 people work full time to schedule 61 missions over a ten year horizon using a few disconnected tools. The large manual and collaborative effort to generate schedules and resolve conflicts has spurred an effort to build a new scheduling application incorporating automated scheduling. We will describe the basic design of this application, the Service Scheduling Subsystem (SSS), and discuss some of the design issues. We describe the messaging interface to the automated scheduler, including the request and constraint language and support for user-defined constraints. There are many other features that we believe will heavily influence the success of the application. These include an efficient schedule editing interface, request management, non-interfering suggestions from automated scheduling, user -defined alerts, hypothetical schedules, and automated negotiation. Request Language Design Principles Seamless scheduling for all planning horizons Remove artificial temporal boundaries A master schedule always exists, visible to all users A single process and tool suite is used by all classes of users Requests and schedules are fully traceable Conflicts are resolved at the lowest level possible, peerto-peer by default Meetings are called only as needed (e. g. , to resolve difficult conflicts or to address an emerging asset contention period) Workspaces are provided to users to develop requests (especially for what-if analysis) Need both web-based and workstation-based capabilities Distinguish global (shared) workspace and local (private) workspace; private workspace may span a set of peers Need scalability (loading, # users, # assets) and extensibility (evolving technology) Data Management User Interface Automate negotiation Auto-reject obviously bad proposals from others E. g. reject proposal to change critical activities Auto-accept obviously good proposals from others E. g. accept proposal that optimizes an unsatisfied request. Auto-propose when good for all involved Customization for user User-defined track & viewperiod coloring rules User-defined alert criteria User-defined constraints User-defined request rules (automating input) Use SQL select statements for all above Returned records are Tracks/viewperiods to color Alert messages Conflicts or activities/requests in conflict Possible values for a request input variable How to make/suggest schedule changes for user? When to invoke scheduling engine? How to make precise edits with mouse? Implementing “undo” and recording history information Ö Only allow undo back to last save, or No save - every edit is logged to database and can be undone Ö Longer periods between older history data save points Undo for interleaved commits on same data by two users Disallow undo Disallow two users to have write permissions to same data Undo independent of user (i. e. one user can undo changes made by another) Try to determine separability by time and activity (hard since one user’s edit may be based on another’s) Ö Request confirmation from user to undo edits of another if workspace B is derived from workspace A, and some user attempts to delete a track in A that B has modified, what is the appropriate behavior? 1. The track is not allowed to be deleted in A. 2. The track is deleted only in A, and committing B (after a warning) will add the track back to A. 3. The track is deleted in A and in B (and users of B are warned). 4. The track is deleted in A, and users accessing B are notified of the deletion and must resolve the inconsistency before committing any more changes (or the possible resolution choices are listed for the user select). Schedule edit conflicts with request Do not allow Ö Flag as a request conflict Warn user Dialog box to confirm edit Disconnect request from schedule Ö Add new request that overrides this one Ö “Stretch” request so that edit is covered • Requirement/Request – Services – Assets & equipment – Continuous / segmented / arraying. . . – Legacy fields – Criticality / priority • Timing Requirement – Repeated tracks – Data / time / coverage goals – Override / blockout – Constraint query (SQL) Scheduling Engine Analysis Summary Analyses and tradeoffs that contributed to current architecture and design: • Make vs. buy: scheduling engine/algorithms and request and constraint language – 10 companies responded to RFI – committee decided JPL algorithms and language already mature • A hybrid approach that integrates heuristic and systematic search – Local search can handle large problems – Systematic search can guarantee solutions (or prove there are no solutions) for smaller sub-problems • Request language elements, incorporate – high-level needs for easy specification – low-level detail for complete control • Use of SQL in constraint language – Very expressive – Industry standard – third party tools to help users who do not know SQL • Messaging interface to provide distributed server access – Scoping for turning constraints on and off and locking down on allocations – Save points to help with “undo” • Web services vs. JMS as the distributed computing model – JMS is simpler, supports asynchronous messaging, and is more compatible with API spec