Institute for Software Integrated Systems Vanderbilt University Maintenance Scheduler in the MAPLANT...
-
Upload
sybil-dickerson -
Category
Documents
-
view
216 -
download
1
Transcript of Institute for Software Integrated Systems Vanderbilt University Maintenance Scheduler in the MAPLANT...
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