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)

Overview

• Aspects of the case study• Towards a model• Model checking experiments &

heuristics• Stochastic approach• Conclusions

Aspects of the case study

1. using Uppaal for an industrial size case studywhat is the right tool/algorithm/abstraction?

2. systematic modellingsystematic cooperation with a domain specialistadequate level of abstractionsuitable representation of design decisionsgranularity of details for comparison of modelsobject (target) of modelling

Towards a Modeldictionary to fix the vocabulary and its meaning

verification of thedictionary?

Towards a model

difficulties:

semantics?

data spread over numbers of tables

other model used than specified

Towards a Model

Different representationof recipes, more readable for computerscientists

Towards a Model

fix the timing behaviour:

earliest start time

deadline

processing time

minimal offset time

maximal offset time

(break time)

performance & availability factors

Towards a UPPAAL Modelrecipes

resource >0

clock:=0,resource -=1

clock processing_time

clock == processing_time

resource += 1

Resources modelled by

integer variabes

location invariant

PRODUCT

AXXOM description

UPPAAL description

Towards a UPPAAL Modelrecipesinterleaving

mainly explicitlymodelled

Towards a UPPAAL Modelsystem

order instantiations:

j25:=Metallic(0, 4,4+336);j17:=Metallic(1, 101,101+336);j27:=Metallic(2, 106,106+336);j3 :=Metallic(3, 151,151+336);j9 :=Metallic(4, 163,163+336);j13:=Metallic(5, 172,172+336);j8 :=Metallic(6, 192,192+336);j1 :=Metallic(7, 331,331+336);j22:=Metallic(8, 494,494+336);j11:=Metallic(9, 499,499+336);j12:=Metallic(10, 504,504+336);j19:=Metallic(11, 581,581+336);j26:=Metallic(12, 674,674+336);j2 :=Metallic(13, 678,678+336);j7 :=Metallic(14, 743,743+336);

j15:=Uni(0, 52,52+336);j5 :=Uni(1, 191,191+336);j14:=Uni(2, 274,274+336);j18:=Uni(3, 278,278+336);j4 :=Uni(4, 388,388+336);j6 :=Uni(5, 555,555+336);j10:=Uni(6, 575,575+336);j23:=Uni(7, 830,830+336);j16:=Uni(8, 974,974+336);

j28:=Special_Metal(0, 276,276+336);j24:=Special_Metal(1, 388,388+336);j21:=Special_Metal(2, 556,556+336);j20:=Special_Metal(3, 576,576+336);j29:=Special_Metal(4, 678,678+336);

systemdefinition:

j1, j2, j3, j4, j5, ..., j29

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

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.

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.

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

greedy strategy

non-laziness

Modelling non-laziness(“active schedules” in operation research):

previous state

resource>0?

urgent?

resource-=1t:=0

t<=production_time

t>=production_timeresource+=1

resource>0t:=0

t<production_time

resource==0

urgent?

non-laziness informally:

don’t wait for a continuously

availible resource before taking it

Modelling a greedy strategy

previous state

resource>0?

urgent?

resource-=1t:=0

t<=production_time

t>=production_timeresource+=1

greedy informally:if the resource i

need is available, i take it

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)

results

feasible schedule

heuristics:

non-laziness

ordered by deadline

upper bound active orders

random depth first search

Adding complexity

Availability and performance factors:

stochastic down-times for machinesdue to breaks and limited human resources

Axxom solution:

multiply processing time by performance/availability factor

e.g. 75% availability, 17 hrs processing time -> 17 x 1/0.75 hrs = 22,666 hrs processing

timeNot really mathematically exiting solution, but we

still do it...

moreresults

feasible schedules

heuristics:

greedy

ordered by deadline

non-overtaking

upper bound for active orders

random depth first search

Adding complexity

70 jobs in place of 29....

even moreresultsfeasible schedules

heuristics:

greedy

ordered by deadline

non-overtaking

upper bound for active orders

random depth first search

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 malus=7,6,5,4,3,2,1,0 ?

no measure how bad the delay is...

(we need uppaal for linearly prized timed automata!!!!!)

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....