Incorporating High-Speed, Optimizing Scheduling into NASA’s EUROPA Planning Architecture AIAA Infotech@Aerospace 2012June 19-21, 2012

Authors: Dick Stottler stottler@stottlerhenke.comDavid Breeden dbreeden@stottlerhenke.com

Presented by: Dick Stottler

Copyright © 2012 by Stottler Henke Associates, Inc. Published by the American Institute of Aeronautics and Astronautics, Inc., with permission.

Problem Description

Gulf between Artificial Intelligence (AI) planning & scheduling

Planning: cascading levels of action choice

Scheduling: optimizing choice of resources/time windows larger number of activities and/or resources but with significantly less choice as to what those activities are

Traditionally, advanced, robust, autonomous planners have not focused on the scheduling decisions

And high-quality, optimizing schedulers have rarely been integrated with such planning systems

Yet all planning ultimately must result in specific resources carrying out specific actions (activities) at specific times

2

EUROPA Background

Extensible Universal Remote Operations Planning Arch.

Developed at NASA Ames Research Center

A powerful software platform for building configurable and extensible planners for a wide variety of domains.

Expressive New Domain Description Language (NDDL) enables the formulation of complex problems

High degree of modularity and plug-in architecture

Impressive array of missions and research:• Mars Exploration Rover (MER), Deep Space 1 (DS1), Earth-

observing satellite scheduling (EOS), ISS scheduling, etc.

Extending for Action Notation Modeling Language• Higher level language

3

Aurora BackgroundGeneral Architecture for creating intelligent scheduling systems

Architecture mimics human scheduling decision process

Useful for generating algorithms that follow the same cognitive processes as human expert schedulers

Typically algorithms are linear (or nearly so) and run very fast

Like human schedulers, typically very little search or back-tracking (but usually some)

Plug-ins for different steps in the scheduling process (preprocessing, ordering queue, selecting resources/time windows, propagating constraints, solving conflicts, post-processing optimization)

Library of general and specific methods/heuristics for each• EG Bottleneck

No Planning (No task generation except for occasional insertion)

Scheduling in Aurora vs EUROPA

EUROPA Aurora

Planning No Planning

Schedule tasks early Generate all tasks then sched.

Search-based Linear

Lots of back-tracking Very little

Good support for BT Only swapping/shuffling/moving

Least Commitment Maximal commitment

Little support for DM Much Decision-Making support

No post processing Post-processing common

Difficult S/S/Moving

Simple Example

1 Resource• E.g. Power• 5 units

4 Sequences of tasks

Simple Example (continued)

Styles/Synergies of Joint Use

Continuum:• EUROPA generates tasks and EUROPA schedules tasks• EUROPA generates tasks, solver includes Aurora Algorithms

– Use least commitment, constraint prop, & back-tracking of EUROPA

• EUROPA generates tasks, sends tasks to Aurora for scheduling, Aurora does all constraints, no least commitment, can use EUROPA decision points to track major scheduling options

• EUROPA generates tasks, Aurora Schedules them

EUROPA using Aurora information when it makes task generation decisions (bottlenecks (current or previous schedule))

Quick Infeasible feedback

Aurora algorithms schedule much faster; better schedules

SCORE Application

SCORE developed by NASA AMES using EUROPA for International Space Station (ISS) scheduling

Currently Tasks input and manually scheduled

EUROPA used to check constraints

Screen Capture

Temporal Constraints

Resource and Condition Constraints• Beyond Astronauts’ Time

Resource Sets

14 step video – will only show a few steps

Scenario Background

130 June 14th Activities Pulled from NASA files• Require an astronaut resource Or • Temporally constrained to such an activity • Used the conditions and resources from the files• Added additional constraints

Focused on automatic scheduling and supporting constraints types/flexibility

Did NOT implement User Interface• Prototype UI is the Aurora default

ISS Scheduling Prototype Screen

Temporal constraintsXFS = eXact Finish to Start. The first activity must end

exactly when the second activity starts.

FS = Finish to Start. The first activity must end before the second activity can start and there may or may not be a gap of time in-between.

FS (0 – x minute Gap) = Finish to Start with an x minute gap. The first activity must end before the second activity can start and the gap in between can not be longer than x minutes and a 0 minute gap is preferred.

FS (Minimum x minute Gap)

Late-End t = The activity must end by t or sooner.

Early-Start t = The activity can not start sooner than t.

Concurrent = The two activities must occur at the same time.

Resource and Condition Constraints

Resources/Quantities: Added Resources:

HRFM_VIDEO_PORT 4 To prevent concurrency when

KU_DL_BW_UNRESERVED 93.5 it appeared a resource existed.

HRDL_TOTAL 760 PC_RESOURCE

NODE_1_VIDEO_PORT 1 ORIENTATION_RESOURCE

VIDEO_SYSTEM_TOTAL 380 EHS_TEST_RESOURCE

NODE_3_VIDEO_PORT 1

HRFM_DIGITAL_PORT 1 Condition: ALL_S_AVAIL = 1

LAB_CAMCORDER 3

DIGITAL_TOTAL 150

RACK_LAO1_HRL 1

VSU_3 4

PC_RESOURCE: 1

ORIENTATION_RESOURCE: 1

EHS_TEST_RESOURCE: 1

Resource Sets

FE_3_4: FE_3 or FE_4: 367, 468, 443, 472, 424 -> 425

 

FE_5_6: FE_5 or FE_6: 434, 368, 441,

408 -> 411 -> 415 -> 419

Same Resource Constraint:

In the case of a chain of activities where a specific resource is not specified but, instead, one of a resource set is specified, it often makes sense that whichever resource is chosen for one activity continues to be the one used for all activities in the chain

SCORE Demo Sequence

Start (already a 417 ->FS (0-30min)->435): They start together

Add 417->XFS->375• Rescheduling inserts it• Delete it – they go back together

Lengthen 425 from 15 to 45 min• Less room so 472 and 443 move later

Lengthen 472 from 20 to 30 –> moves from FE_3 to FE_4

Add 417 ->XFS -> 435 Make 435 early start of 14:00• 435 will move later, and, 417 will move with it

Make 392 (at FE_1) early start of 14:00• 392 will move later, and (XFS chain), 385/390 move too • Also, 395 (at ISS_CDR) moves since 392 concurrent constraint• 391 moves too (XFS with 395)

15

EVA Demo

Hand translated from PDDL from TRACLabs

Test domain is simplified subset of the TRACLabs model. Tasks modeled at a high level, without spatial or equipment constraints.

Bottleneck Implemented in EUROPA• Combined with EUROPA’s constraint propagation nicely• Picking Resources• Originally Ordering Tasks

Chain Complexity/Duration/# of Resources for ordering

Post-Processing Optimization (Swap and Compress)

EVA tasks

EVA 2 of ULF 6, Revision T (Dec 2010)

EVA tasks

EVA Prototype ResultsDefault Europa solver:• 1239 steps• Run time: 13.13 minutes• Makespan: 6 hours, 25 minutes

EVA Prototype ResultsWith bottleneck scheduling and postprocessing:• 78 steps• Run time: 4.985 minutes• Makespan: 5 hours, 35 minutes

EVA Prototype Results6 hr horizonDefault Europa solver:• 6000 steps• Run time: 66.179 minutes• Makespan: N/A (timeout)

EVA Prototype Results6 hr horizonWith bottleneck scheduling and postprocessing:• 78 steps• Run time: 4.404 minutes• Makespan: 5 hours, 34 minutes

23

Conclusions3rd application (recovery for an Electrical Power System)

• Different developer - just a few minutes to install our plugin• 80 minutes/6600steps/no answer -> 4 minutes/200/optimal answer

Can add high-quality scheduling algorithms to EUROPA

EUROPA and Aurora’s algorithms are highly complementary• EUROPA’s back-tracking search good for action generation• Aurora’s near-linear algorithms are more suited for scheduling• EUROPA’s back-tracking useful for small number of arbitrary major

Aurora decisions• Aurora has much better support for moving and shuffling tasks• Aurora provides for a very explicit post-processing step • EUROPA follows a least commitment strategy (can be expensive)

– associated sophisticated constraint propagation – Easily computes data for some of Aurora’s more complex heuristics

• Aurora’s maximal commitment strategy is more runtime efficient

24