1. Scheduling Lacquer Productions with Uppaal AXXOM case study of the Ametist project Angelika Mader Distributed 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/abstraction? 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 the dictionary?

5. Towards a model difficulties: semantics? data spread over numbers of tables other model used than specified

6. Towards a Model Different representation of recipes, more readable for computer scientists

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 Model recipes 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

9. Towards a UPPAAL Model recipes interleaving mainly explicitly modelled

10. Towards a UPPAAL Model system 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); system definition: 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 greedy strategy non-laziness

15. Modelling non-laziness (“active schedules” in operation research) : previous state resource>0? urgent? resource-=1 t:=0 t<=production_time t>=production_time resource+=1 resource>0 t:=0 t<production_time resource==0 urgent? non-laziness informally: don’t wait for a continuously availible resource before taking it

16. Modelling a greedy strategy previous state resource>0? urgent? resource-=1 t:=0 t<=production_time t>=production_time resource+=1 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 -> 17 x 1/0.75 hrs = 22,666 hrs processing time Not really mathematically exiting solution, but we still do it...

20. more results 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 more results 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 malus=7,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....