Date post: | 14-Dec-2015 |
Category: |
Documents |
Upload: | sybil-dickerson |
View: | 216 times |
Download: | 1 times |
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