Institute for Software Integrated Systems Vanderbilt University Maintenance Scheduler in the MAPLANT tool Gabor Szokoli, ISIS

Institute for Software Integrated SystemsVanderbilt University

Maintenance Scheduler in the MAPLANT tool

Gabor Szokoli, ISIS

The Problem

• Task Scheduling Problem• Starting times of tasks must conform to rules

– Resource limits• (quantity and type)

– Numerous simpler constraints• Hard deadline and release time• Sequencing of tasks• Conflicting tasks• Task start and endtime alignments• At certain times the task can not run

• Duration of tasks is constant– A task can not be completed faster using more

resources

Problem Magnitude

• Schedule ~2500 tasks• ~3000 timeslots ( 5 weeks by 15

minutes)• Time Variant Resources• Hard and Soft Constraints• “Anytime” scheduling algorithm• Failure Explanations• Integration with MAPLANT

Constraints

• Time Variant Resource Capacities • Non-contiguous Due Windows (e.g.

flights)• Precedence• Conflicts• Overlaps, Alignments

Domain Independent Representation

• Java data structure internal to MAPLANT captures the whole problem specification

• Well defined, stable interface to problem encoders (for different solvers)

• Task times and resource availabilities represented as actual dates

• Mapping the solution (Task start times) back to the domain model

• No resource allocation

CSP representation

• XML file describing the integer problem • Loaded and solved by external module• Solution passed back in a simple textfile• Problem instances and documented

schema file available for anyone in need of hard real-life problems

Features of the solver

• FD variables to hold start-time of each task

• Time invariant resources

• Conflicting, Preceding, etc relationships

• Job preemption disallowed

Mapping Between the Models

• FD variables to hold start-time of each task– Task durations are constant: no need for

separate variable for end-time

• Time invariant resources– Time variance modeled by dummy tasks

• Conflicting, Preceding, etc relationships– Same as in domain model

• Job preemption disallowed– Weekends, holidays removed from timeline

Why CLP(FD)?

• Problem size grew unmanageable with time resolution in our binary SAT encoding

• Most constraints seem awkward for linear programming solvers

• Intuitive model mapping• Efficient implementations available• Previous experience• Fast prototyping

Why MOZART?

• Love at first sight• Unprecedented control over search• “Multiparadigm” (imperative-friendly)

easy-to-learn language: OZ• Multiplatform, Distributed, Open Source,

…: Buzzword Compliant• Ongoing development, strong (helpful!)

user base

Explanation of OZ terms I.

• Variable– Single-assignment logic variable

• Domain variable– Variable with monotonically decreasing set

of allowed values

• Constraint– Formula or indicator function of value

configurations

• Propagator– OZ thread enforcing a Constraint with

certain eagerness

Domain Variables

• Start-time of each task is modeled as an Integer variable– Initial domain: the whole planning horizon– Restricted by Deadline, Ready time, and

similar unary (“basic”) constraints: not-on, etc.

– N-ary constraints are propagators that are posted on variables to remove inconsistent values from the domains

Constraint Types: Basic

• Unary domain restriction• No need for persistent propagator• Examples

– Deadline • Task.start+Task.duration<:Task.deadline

– Ready Time • Task.start >=: Task.ready

– Not On • {Schedule.disjoint

Task.start Task.duration Flight.start Flight.duration }

Constraint Types: Binary

• Classic arc constraints• Persistent propagators act on variable domain

or interval modification events• Strong 2-consistency • Examples:

– Precedence • T1.start+T1.duration <: T2.start

– Conflict• {Schedule.disjoint

T1.start T1.duration T2.start T2.duration }

– Runs While• T1.start=<:T2.start

T1.start+T1.dur >=:T2.start+T2.dur

Constraint Types: Global

• N-ary constraints maintain path-consistency of a subgraph

• Same propagator behaviour as before• Efficient C++ implementation• Example:

– Cumulative resource requirement constraint

1 2 3 4

Propagation, Search

1 2 3 4

A<:B A+B:=4

A

B

1 2 3 4

1 2 3 4

A<:B A+B:=4

A

B

A=:1

1 2 3 4

1 2 3 4

A<:B A+B:=4

A

B

A=\:1

Explanation of OZ terms II.

• Computational Space– First-class, nestable entity encapsulating

domain variables and threads (e.g. propagators)

• Cloning– Operation on Space returning an independent

but identical copy

• Distribution– Action executed in a Space (Space.choice)

resulting in choices for the search engine.

• Commit– Operation on Space when a choice is selected

and the associated constraint is posted.

Computational Space Stability

• No propagators or threads in runnable state– All changes processed

• Arc-consistent state• Note: Propagators do not interact in any

other way than the domains of shared variables

• Not a solution, not even a path consistent state.

Distribution - in general

• A special thread waits on space stability• Creates two (or more choices) for the

space• When either is picked, an extra

constraint is posted• Choices cover all alternatives

– e.g. X=:1 V X=\:1

• The Distributor thread goes to sleep until stability is reached again– Functionally similar to the variable() and

value() options of labeling/2 in SiCStus Prolog

Search - in general

• Search engine encapsulates problem space– Runs in toplevel space, all constraints in child-spaces

• Choices offered by distributor are picked by the engine to shape the search tree (Commit)– E.g. in depth-first manner

• The problem-space is cloned for backtracking– Choices may be logged to avoid cloning

• The search engine may utilize multiple workers to split the search tree– Independent distributed execution aspect handles

multi-host issues

Distribution details

• Pick an undetermined variable: X – Ideally: Try to find tasks involved in the

tightest resource bottlenecks– Heuristic: number of propagators (arcs)

• Find a value from its domain: V– Ideally:Try to position the task into less

congested timeslots– Heuristic: middle of the domain

• Create the choices X=:V [] X\=:V

Experimental Results• Engine performance is usually acceptable

– Measurements on a 500MHz Celeron laptop

UnitType

PlanningHorizon

# AC # Maintrs # Sorties # MaintActions

# Constraints

Time Man YrsScheduled

Dataset

squadron 3 mos 17 201 1236 3750 181 K 19 m58 s

6.439 2001-11-06T08:31

squadron 3 mos 17 201 1236 3758 181 K 19 m42 s

6.446 2001-11-06T08:31

squadron 6 weeks 16 202 677 2130 63 K 4 m5 s

4.113 2002-02-06T06:31


3.855 2002-02-08T14:31


1.909 2001-11-29T05:31


2.391 2001-12-07T08:31

detachment 6 weeks 6 66 448 0 85 K 1 m12 s

0 2002-05-21T16:15


2.033 2002-05-21T16:15


2.021 2002-05-22T08:13

Runtime vs resource margin

0

20

40

60

80

100

120

0 0.2 0.4 0.6 0.8 1

Runtime is in seconds. Timeout shown as 100s, actually 30min

•“Dolly Parton”-like effect on critically constrained problem instances

Documents

Institute for Software Integrated Systems Vanderbilt University Maintenance Scheduler in the MAPLANT tool Gabor Szokoli, ISIS