Scheduling Lacquer Productions with Uppaal

1
Scheduling Lacquer Productions with Uppaal

• AXXOM case study
• of the Ametist project

Angelika MaderDistributed and Embedded Systems
Group, University of Twente with Gerd Behrmann
(Aalborg) Martijn Hendriks (Nijmegen)
2
Overview

• Aspects of the case study
• Towards a model
• Model checking experiments heuristics
• Stochastic approach
• Conclusions

3
Aspects of the case study

1. using Uppaal for an industrial size case
   study what is the right tool/algorithm/abstractio
   n?
2. systematic modelling systematic cooperation with
   a domain specialist adequate level of
   abstraction suitable representation of design
   decisions granularity of details for comparison
   of models object (target) of modelling

4
Towards a Model
dictionary to fix the vocabulary and its meaning
verification of thedictionary?
5
Towards a model
difficulties semantics? data spread over numbers
of tables other model used than specified
6
Towards a Model
Different representationof recipes, more
readable for computerscientists
7
Towards a Model
fix the timing behaviour earliest start
time deadline processing time minimal offset
time maximal offset time (break
time) performance availability factors
8
Towards a UPPAAL Modelrecipes
Resources modelled by integer variabes
location invariant
PRODUCT
AXXOM description
UPPAAL description
9
Towards a UPPAAL Modelrecipes
interleavingmainly explicitlymodelled
10
Towards a UPPAAL Modelsystem
j25Metallic(0, 4,4336) j17Metallic(1,
101,101336) j27Metallic(2, 106,106336) j3
Metallic(3, 151,151336) j9 Metallic(4,
163,163336) j13Metallic(5, 172,172336) j8
Metallic(6, 192,192336) j1 Metallic(7,
331,331336) j22Metallic(8, 494,494336) j11
Metallic(9, 499,499336) j12Metallic(10,
504,504336) j19Metallic(11,
581,581336) j26Metallic(12, 674,674336) j2
Metallic(13, 678,678336) j7 Metallic(14,
743,743336)
j15Uni(0, 52,52336) j5 Uni(1,
191,191336) j14Uni(2, 274,274336) j18Uni(3
, 278,278336) j4 Uni(4, 388,388336) j6
Uni(5, 555,555336) j10Uni(6,
575,575336) j23Uni(7, 830,830336) j16Uni(8
, 974,974336) j28Special_Metal(0,
276,276336) j24Special_Metal(1,
388,388336) j21Special_Metal(2,
556,556336) j20Special_Metal(3,
576,576336) j29Special_Metal(4, 678,678336)
order instantiations
systemdefinition
j1, j2, j3, j4, j5, ..., j29
11
Model checking experiments
first model checking experiments failed state
space explosion
looking at the search traces too many delays,
e.g. in the beginning too many active jobs
struggling for the same resource jobs start too
late
12
Modelling Model checking experiments
adding heuristics that prune the search space 1.
cut and pray no guarantees that there is a good
schedule left 2. nice heuristics for
each schedule in a pruned part of the search
space there is an equivalent one in the
remaining search space.
13
Modelling Model checking experiments
modelling technique explicit modelling of
schedulers as parallel automata heuristics as far
as possible in the explicit schedulers in
contrast to heuristics and strategies hidden in
variables etc.
14
Modelling Model checking experiments
heuristics used start the jobs early enough such
that they can reach the deadline order the jobs
according to their deadlines (within one sort of
bronce, uni, metal) restrict the number of active
jobs such that not too many jobs struggle for the
same resources (dose spinner) non-overtaking greed
y strategy non-laziness
15
Modelling non-laziness
(active schedules in operation research)
resourcegt0t0
previous state
tltproduction_time
resource0 urgent?
resourcegt0? urgent? resource-1t0
non-laziness informally dont wait for a
continuously availible resource before taking it
tltproduction_time
tgtproduction_timeresource1
16
Modelling a greedy strategy
greedy informally if the resource i need is
available, i take it
17
Modelling non-overtaking

• start jobs in order of their deadlines, per sort
  
• non-overtaking per sort of lacquer (uni, bronce
  metal)
• variable for the phases in the recipe (0,1,2)
• allow a job only to enter a new phase, if the
  previous job has already entered this phase.
• no global non-overtaking
  (bronce-job may overtake a uni-job)

18
results
feasible schedule heuristics non-laziness
ordered by deadline upper bound active
orders random depth first search
19
Adding complexity
Availability and performance factors stochastic
down-times for machines due to breaks and
limited human resources Axxom solution multiply
processing time by performance/availability
factor e.g. 75 availability, 17 hrs processing
time -gt 17 x 1/0.75 hrs 22,666 hrs
processing time
Not really mathematically exiting solution, but
we still do it...
20
moreresults
feasible schedules heuristics greedy ordered
by deadline non-overtaking upper bound for
active orders random depth first search
21
Adding complexity
70 jobs in place of 29....
22
even moreresults
feasible schedules heuristics greedy ordered
by deadline non-overtaking upper bound for
active orders random depth first search
23
Towards non-feasible schedules
originally a cost-optimality problem as long as
we find feasible schedules there are no costs
(delay costs, in the first place) first
experiments a counter malus for missed
deadlines explicit property can we find a
schedule with malus7,6,5,4,3,2,1,0 ? no
measure how bad the delay is... (we need uppaal
for linearly prized timed automata!!!!!)
24
Conclusion further work

• still feasible schedules no delay costs yet
• add complexity costs for changing products on
  machines still more jobs
  weekends, nights more timing
  restrictions...
• using cost-optimal extension of UPPAAL
• techniques for scaling up time windows,
  split jobs resources in subsets
• case study for MoMS, modelling techniques,
  comparison of models, structural patterns of
  scheduling problems
• still more questions....