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

squadron 6 weeks 17 202 678 2089 60 K 4 m16 s

3.855 2002-02-08T14:31

squadron 4 weeks 17 202 272 1155 19 K 0 m58 s

1.909 2001-11-29T05:31

squadron 4 weeks 17 202 411 1158 25 K 1 m24 s

2.391 2001-12-07T08:31

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

0 2002-05-21T16:15

detachment 6 weeks 6 67 448 1085 85 K 1 m1 s

2.033 2002-05-21T16:15

detachment 6 weeks 6 66 443 1049 85 K 0 m56 s

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