Heuristics in dynamic scheduling - CiteSeerX

1 downloads 0 Views 3MB Size Report
garantie over de optimaliteit wordt gegeven (of zelfs maar hoe dichtbij optimaliteit ze zullen ...... As an enhancement of the cheating CDC setup (Section 7.1.2.3), a cheating park- ...... Kim, C., Seong, K. A., Lee-Kwang, H., and Kim, J. O. (1998).
Uitnodiging

Heuristics in dynamic scheduling

Voor het bijwonen van de verdediging van mijn proefschrift

Heuristics in dynamic scheduling a practical framework with a case study in elevator dispatching

Woensdag 28 november 2012 om 15.00 uur in de Aula van de Technische Universiteit Delft, Mekelweg 5 te Delft

Voorafgaand aan de verdediging zal ik om 14.30 uur een korte uitleg geven over mijn promotieonderzoek

Na afloop van de verdediging is er een receptie Jeroen de Jong

Jeroen de Jong

ISBN: 978-90-5335-611-1

Paranimfen Ineke de Jong

[email protected] 015-2137841

Jeroen de Jong

Bram Kranenburg

[email protected] 0492-552025

Heuristics in dynamic scheduling a practical framework with a case study in elevator dispatching

Heuristics in dynamic scheduling a practical framework with a case study in elevator dispatching Proefschrift

ter verkrijging van de graad van doctor aan de Technische Universiteit Delft; op gezag van de Rector Magnificus prof. ir. K.Ch.A.M. Luyben; voorzitter van het College voor Promoties, in het openbaar te verdedigen op 28 november 2012 om 15:00 uur

door Jeroen Leonard DE JONG Master in Artificial Intelligence geboren te Rotterdam

Dit proefschrift is goedgekeurd door de promotor: Prof. dr. C. Witteveen Samenstelling promotiecommissie: Rector Magnificus Prof. dr. C. Witteveen Prof. dr. F.M.T. Brazier Prof. dr. C.M. Jonker Prof. dr. J. Köhler Prof. dr. A. Nowé Dr. H.P. Lopuhaä Dr. C.H.M. Nieuwenhuis Prof. dr. K.G. Langendoen

Voorzitter Technische Universiteit Delft, promotor Technische Universiteit Delft Technische Universiteit Delft Lucerne University of Applied Sciences and Art Vrije Universiteit Brussel Technische Universiteit Delft Thales Research & Technology Technische Universiteit Delft, reservelid

The research described in this dissertation was financially supported by Thales Nederland B.V. and by the Dutch Ministry of Economic Affairs as part of the BSIK-ICIS project, grant nr: BSIK03024

Cover design by Hester van der Scheer ISBN: 978-90-5335-611-1

Preface

The book you hold in your hands could not have been created without the help of numerous people, in numerous ways, whom I would like to thank here. Cees Witteveen, for accepting me as a PhD student although I was somewhat out of your normal scope of pupils and very application driven. You have greatly helped me shape this dissertation, and have spent countless hours reading and re-reading stuff in the iterative process that is finished now. Kees Nieuwenhuis, for believing in me successfully working on a project of “hybrid metaheuristics”, and for maintaining trust in the following years, while the subject drifted off to heuristics in dynamic scheduling. Thanks to Jimmy Troost for making it possible to finish this study. Rik Lopuhäa, for the hours you spent helping me to get the statistics right, and the numerous fun discussions that we had, trying to understand each other’s professional language. The other members of the promotion committee, Jana Köhler, Catholijn Jonker, Frances Brazier, Ann Nowé, Koen Langendoen, for your thorough reading and valuable comments. Lukas Finschi and Paul Friedli of Schindler elevators, for providing me with a realistic elevator case, and valuable comments. Colleagues at D-CIS and TU Delft for discussions and chit chat, and, for a large part of you, for willingly or unwillingly bestowing your precious computers on me to run my experiments on, for weeks uninterupted. Hester, for your silent acceptance of me dragging away your husband as much as I can (mentally, if not physically), and for the many hours you spent in having me over yourself, creating the lovely cover that people will more strongly remember

vi than its contents! Roelof, for the never-ending joy of the dragging-away part... My friends and family, who have supported me in the previous years, never getting tired of having to ask after my progress. My paranimfen. Bram, not only because I enjoy the long friendship that we have, but for the professional discussions as well. I still believe you would do a better job defending this book than I could. It was an honor serving you as paranimf, it is a complete pleasure having you as one. Ineke. For your love, for knowing me like no one else, for sharing the parenthood of the most delightful people we will ever meet. Unstinting belief in your loved one is the one true door-knob test. You never fail it.

Jeroen de Jong, 15 October 2012

Abstract

This dissertation investigates and analyzes methods to improve the performance of schedulers in the context of (highly) dynamic scheduling, with a case study in elevator dispatching. Chapter 1 introduces the problem of dynamic scheduling, and highlights the pitfalls in dealing with them. A number of generic research questions are identified, which are more elaborately outlined in later chapters. Chapter 2 outlines the scheduling problem. Scheduling consists of putting tasks on a timeline, subject to various constraints and optimization criteria. Scheduling problems can be complex, depending on the nature of the problem or the size of the problem instance. For a large amount of problems, heuristic problem solvers are employed. These approaches aim for solutions that are as good as possible, without guarantees on the optimality, or even the distance to the optimal result. The chapter discusses heuristic approaches based on constructive algorithms and local search methods, as well as various extensions, such as metaheuristics and hybrids. Chapter 3 introduces dynamicity, problems that change over time. The dynamicity is mostly found in the tasks, becoming known or being retracted over time. The level of dynamicity is an important property. Static problems do not encounter change events within their scheduling horizon. Lowly dynamic problems have some such changes occurring, but the changes are regarded disruptions, and the original solutions are only changed slightly. In (highly) dynamic problems, the focus of this dissertation, change is a given: multiple change events occur within the scheduling horizon, and the scheduler is driven by those changes. A specific feature of dynamic scheduling problems is that an optimal solution cannot be calculated while the system is running: Since the future is unknown, current solutions to the problem

viii become obsolete before they are finished executing, thereby rendering any notion of optimality void. The difficulty of solving such problems is further increased by decision timing constraints: solutions have to be calculated on short notice. These two aspects in particular call for heuristics when solving the problem. Problems can be dynamic in two senses: the short term dynamicity regards the change events themselves. Second-order dynamicity means that the nature of the presented problem changes over time. For example, a junction with traffic lights may face a different kind of dynamic problem during the morning rush hour and the evening rush hour, since traffic streams and congestion risks may be different. Dynamic scheduling problem solvers usually take the form of either ad-hoc algorithms or full reschedulers. Ad-hoc algorithms make decisions on what to do next, each time a production unit becomes available. These decisions are based on the current system state and available problem information. Full reschedulers produce complete schedules, adjusting or overhauling them when necessary. Full reschedulers are increasingly used to cope with short-term and second-order dynamicity, often applying heuristics and hybrid approaches. The application of heuristics and hybrids in dynamic scheduling is the focus of this dissertation. Chapter 4 focuses on a number of issues in dynamic scheduling. There are issues related to the problem solver, to the problem itself, and to experimenting in this domain. Looking more closely at the problem solver, we see that dynamic scheduling applications that apply metaheuristics tend to focus most on the chosen algorithm. A metaheuristic problem solver, however, incorporates a triangle of algorithm (how to investigate the space of local alternative solutions?), neighborhood (how to modify a solution to create local alternatives?) and objective function (how to assess the quality of a candidate solution?). Focusing on the algorithm alone may result in underexposure of the neighborhood and the objective function. To compensate for that, complex metaheuristics such as evolutionary algorithms are often used. However, this comes at the price of a less transparent problem solver, and possibly suboptimality. The first Research Question (RQ) is: RQ 1: Can improved neighborhoods and objective functions reduce the need for a complex metaheuristic while maintaining the same overall quality? Since a large amount of research in this domain is devoted to evolutionary algorithms, a specific research question is: RQ 2: What are the advantages and pitfalls when applying evolutionary algorithms to dynamic scheduling?

ix Different hybridizations are possible to enhance the performance of a single algorithm. However, this comes at the cost of increased computational complexity. Furthermore, when focusing on a single algorithm, with fixed parameter settings, a dynamic scheduler may remain static in itself, and does not adapt itself to cope with second-order dynamicity. By making the parameterization flexible, or by adaptively mixing problem solving approaches, schedulers that effectively deal with secondorder dynamicity come within reach. RQ 3: How could a simple hybrid approach increase the performance of a dynamic scheduler, both in the case of short-term and second-order dynamicity? Looking more closely at the problem of dynamic scheduling itself, we observe a tendency in the literature to focus on the scheduler alone. This may result in underexposure of the environment surrounding the scheduler. The environment provides the information needed by the scheduler. Availability and timing of that information are important aspects in the schedulability of a dynamic problem. A system design that does not acknowledge this, may lead to a suboptimal performance, regardless of the scheduling technique applied. Since influencing the environment is often possible, it is worthwhile to investigate such opportunities. RQ 4: To what extent could modifications in the environment increase the performance of dynamic schedulers? Dynamic scheduling problems ask for schedules that are flexible or robust. Flexible schedules can easily accommodate future tasks. Robust schedules have little need for rescheduling of currently scheduled tasks, when change events occur. Flexibility and robustness are two sides of a medal. The scheduling approach used should reward schedules that are likely to exhibit flexible and/or robust qualities. RQ 5: How could flexibility and robustness measures increase the performance of a dynamic scheduler? Looking more broadly at studies conducted in dynamic scheduling - especially in elevator dispatching - the use of benchmarks or self-generated test data is often observed. The similarity of such data with real world data is questionable, and so is the applicability of research findings obtained from such studies. RQ 6: What is the external validity of research findings obtained by benchmarks or self-generated test data? Chapter 4 goes on to provide a set of building blocks, that are aimed at answering these questions. The building blocks are also used in the remaining chapters, when they are applied to improve elevator dispatching.

x The Chapters 5-7 consist of an elevator dispatching case study. The elevator dispatching problem is first detailed in Chapter 5. It is a good example of a complex dynamic scheduling problem. The combinatorial complexity is high, and even when treated as a static problem it is proven to be NP-hard. It has a high short term dynamicity, where schedules become outdated long before execution is finished. It also has a strong second-order dynamicity that is often described in the literature. For example, the traffic characteristics of morning up-peak, lunchtime inter-floor-peak, and afternoon down-peak differ greatly. The problem has a strong link to routing and other logistic problems. The chapter presents a number of Research Hypotheses that translate the generic questions asked in Chapter 4 to the elevator dispatching domain. In Chapter 6, the simulation framework is described that was used to perform the elevator dispatching experiments, as well as the statistical methods that were used to assess the quality of various elevator dispatching approaches. The chapter also focuses on the question of self-generated test data (RQ 6). The simulated elevators are taken from an actual building, and the passenger data were actual traffic data from that same building. The chapter compares results obtained by using these realistic data with results from self-generated data such as found in various articles. Chapter 7 discusses the experiments that have been run, in four sections. The first section investigates the influence of the environment of the scheduler (RQ 4). In the case of elevator dispatching, conventional control and destination control present two existing environments with different properties. Conventional control provides the scheduler with information both late and inaccurately, whereas destination control provides early and accurate information. Conversely, conventional control has relaxed decision demands, whereas in destination control, decisions have to be made on short notice. A novel mode that is not currently manufactured, ‘cheating destination control’ is investigated with expected ideal qualities: early and accurate information, and relaxed decision timing. The second section in this chapter investigates the issue of complex metaheuristics, neighborhoods and objective functions. Since they are closely related, RQ 1 and 2 are treated in this section. Different neighborhood designs are investigated, and a wide range of objective function parameters is investigated that balances individual passenger needs with overall performance, reducing the need for a complex problem solver (RQ 1). Evolutionary algorithms are compared to more straightforward k-opt search (RQ 2). The third section investigates the search space & objective function relation even further by exploring various methods to increase robustness and flexibility (RQ 5). For low traffic periods, parking is an obvious, and well-known, method to increase flexibility. For medium to high traffic, a number of methods to create flexible and

xi robust schedules are investigated. The fourth section investigates schedulers that adapt themselves to cope with second-order dynamicity, using hybrid heuristics (RQ 3). Chapter 8 presents a discussion on the dissertation. RQ 1 could be positively answered, as abstract solution encodings and neighborhood optimization enabled the use of a straightforward algorithm, leading to a powerful combination. The answer to RQ 2 is ‘limited’, since evolutionary algorithms have profound problems that appear to disadvantage in the area of dynamic scheduling, and did indeed perform badly on the elevator case study. RQ 3 could be positively answered by the use of a building block on hybridization, which lead to pragmatic hybridizations that outperformed all other approaches in this study. The use of hybridizations to cope with second-order dynamicity, however, appeared to be of limited use in the case study, but is still likely to be useful in other domains. Modifications in the scheduling environment (RQ 4) played a large role in scheduling performance, showing that obtaining as much information as possible, as early as possible, and delaying decisions as much as possible are important virtues in dynamic scheduling systems. RQ 5 could not be answered in general, since attempts at increasing robustness and flexibility are problem-dependent. However, calculating the risk of task-postponement and incorporating this risk into objective functions appeared to be a successful factor in elevator dispatching, and is likely usable in other domains as well. The use of self-generated test data (RQ 6) is limited, since it was shown to lead to different performance results than when using actual data. The use of benchmarks is shown to be limited as well for specific algorithmic setups, since even a within the single case study, different results were found using the same algorithmic setup under a slightly modified scheduling regime.

Samenvatting

In dit proefschrift worden methoden onderzocht en geanalyseerd, om de prestaties van schedulers voor hoog-dynamische scheduling problemen te verbeteren. Er wordt ook een case study gedaan naar liftbesturing. Hoofdstuk 1 is een introductie in dynamische scheduling, en laat zien waar de moeilijkheden zitten om hiermee om te gaan. Een aantal algemene onderzoeksvragen wordt gesteld, die in latere hoofdstuken uitvoerig behandeld zullen worden. Hoofdstuk 2 beschrijft het scheduling probleem. Bij scheduling worden taken op een tijdbalk geplaatst, waarbij aan bepaalde eisen voldaan moet worden, en waarbij optimaliteit nagestreefd wordt. Deze problemen kunnen erg complex zijn, afhankelijk van het soort probleem en de grootte van het specifieke probleem. Voor veel problemen worden heuristische probleemoplossers gebruikt. Zulke benaderingen proberen oplossingen te genereren die zo goed mogelijk zijn, maar zonder dat er een garantie over de optimaliteit wordt gegeven (of zelfs maar hoe dichtbij optimaliteit ze zullen komen). Het hoofdstuk beschrijft heuristische methoden die gebaseerd zijn op constructieve algoritmen en local search algoritmen, alsmede uitbreidingen op dit thema, zoals metaheuristieken en hybrides. Hoofdstuk 3 beschrijft dynamische problemen, die veranderen in de tijd. Meestal zit de dynamiek in de taken, die tijdens de uitvoering worden toegevoegd of teruggetrokken. De mate van dynamiciteit is een belangrijk aspect. Statische problemen hebben geen last van veranderingen binnen hun scheduling horizon. Laagdynamische problemen hebben zo nu en dan zo’n verandering, maar die veranderingen worden gezien als verstoringen, en de oplossing die eerder bedacht is hoeft nauwelijks aangepast te worden. Bij hoog-dynamische problemen (het onderwerp van dit proefschrift) is verandering een gegeven: veel veranderingen zullen zich

xiv voordoen binnen de scheduling horizon, en het zoekproces naar oplossingen wordt gedreven door die veranderingen. Een bijzonder aspect van dynamische problemen is dat je, terwijl het systeem draait, niet meer kunt spreken over optimaliteit: de toekomst is onbekend, dus oplossingen die je nu bedenkt worden achterhaald tijdens de uitvoering. De lastigheid om dit soort problemen op te lossen wordt verder opgevoerd door het feit dat beslissingen meestal heel snel genomen moeten worden. Deze twee aspecten in het bijzonder maken dat heuristieken gebruikt worden voor het oplossen van dynamische problemen. Problemen kunnen op twee manieren dynamisch zijn. Korte-termijn dynamiek gaat over de veranderingen die zich voordoen, zoals net beschreven. Tweede-orde dynamiek betekent dat het karakter van het probleem in de tijd verandert. Een kruispunt met stoplichten staat bijvoorbeeld ‘s ochtends (tijdens de ochtendspits) voor een ander soort probleem dan ‘s avonds, omdat de verkeersstromen en het risico op files anders zijn. Probleemoplossers voor dynamische scheduling werken doorgaans ofwel met ad-hoc algoritmen of met volledige reschedulers. Ad-hoc algoritmen nemen elke keer dat er een machine vrijkomt, of wanneer er een nieuwe taak bijkomt, onmiddelijk een beslissing over wat er nu moet gebeuren. Volledige reschedulers maken complete roosters, en als dat nodig is passen ze die aan of halen ze die volledig overhoop. Zulke volledige reschedulers worden steeds meer gebruikt om problemen met korte-termijn en tweede-orde dynamiek op te lossen, en maken meestal gebruik van heuristieken en hybride methoden - het hoofdonderwerp van dit proefschrift. Hoofdstuk 4 zoomt in op een aantal problemen binnen de dynamische scheduling. Die kunnen te maken hebben met de probleemoplosser, met het probleem zelf, en met het experimenteren binnen dit probleemdomein. Als we naar de probleemoplosser kijken, zien we dat dynamische schedulers die metaheuristieken gebruiken, zich vaak richten op het gekozen algoritme. Maar een metaheuristische probleemoplosser werkt op basis van een driekhoek van het eigenlijke algoritme (hoe doorzoeken we de ruimte van lokale oplossingen?), de zoekruimte (hoe veranderen we een oplossing om lokale oplossingen te genereren?), en een objective function (hoe bepalen we de kwaliteit van een potentiele oplossing?). Als je vooral naar het algoritme kijkt, blijven die twee andere aspecten onderbelicht. Om dat te compenseren wordt soms naar hele complexe metaheuristieken gegrepen, zoals evolutionaire algoritmen. Daarvoor moet echter wel een prijs betaald worden: een minder transparante probleemoplosser, en mogelijk ook mindere prestaties. De eerste algemene onderzoeksvraag (Research Question, RQ) is daarom: RQ 1: Kunnen verbeterde zoekruimtes en objective functions de noodzaak voor complexere metaheuristieken wegnemen, zonder in te boeten op de kwaliteit van de oplossingen?

xv Aangezien zoveel onderzoek binnen dit domein zich richt op evolutionaire algoritmen, is de tweede onderzoeksvraag: RQ 2: Wat zijn de voor- en nadelen bij het toepassen van evolutionaire algoritmen voor dynamische scheduling problemen? Er zijn allerlei hybridisaties mogelijk om de prestaties van een enkel algoritme te verbeteren. Dit leidt alleen wel tot een ingewikkelder probleemoplosser. Aan de andere kant: als je met een enkel, vast algoritme werkt, houd je geen rekening met veranderingen in het karakter van het probleem (tweede-orde dynamiek). Een algoritme waarvan de parameters tijdens het draaien kunnen worden bijgesteld, of een variabele mix van algoritmen, kunnen mogelijk leiden tot een probleemoplosser die een antwoord biedt aan tweede-orde dynamiek. RQ 3: Hoe kan een simpele hybride aanpak de prestaties van een dynamische probleemoplosser verbeteren, zowel op korte als op lange termijn? Als we naar het dynamische probleem zelf kijken, zien we dat veel literatuur zich richt op de probleemoplosser, en niet op de omgeving waarin het probleem zich voordoet. Die probleemomgeving levert de informatie die de scheduler nodig heeft. De beschikbaarheid daarvan, en de timing waarmee die informatie beschikbaar komt, zijn belangrijke factoren voor het gemak waarmee het probleem kan worden opgelost. Een systeemontwerp waarin daar niet naar gekeken wordt, zou tot matige prestaties kunnen leiden, ook al zijn de gebruikte technieken nog zo goed. Aangezien het vaak mogelijk is de omgeving te beïnvloeden, is het zinnig die mogelijkheden te verkennen. RQ 4: In welke mate kunnen veranderingen aan de omgeving de prestaties van dynamische schedulers verbeteren? Dynamische problemen vragen om oplossingen die flexibel en robuust zijn. Flexibele oplossingen bieden gemakkelijk ruimte aan toekomstige taken die nu nog onbekend zijn. Robuuste oplossingen hoeven niet al teveel overhoop gehaald te worden als er in de toekomst iets veranderd. Flexibiliteit en robuustheid zijn twee kanten van dezelfde medaille. Een probleemoplosser moet daarom oplossingen prefereren die flexibel en/of robuust zijn. RQ 5: Hoe kunnen maatregelen voor flexibiliteit en robuustheid de prestaties van een dynamische probleemoplosser verbeteren? Als we wat breder naar de literatuur kijken (zeker bij liftbesturing), zien we dat experimenten vaak gedraaid worden op benchmark-problemen of zelf-verzonnen testdata. In hoeverre die overeenkomen met situaties in de gewone wereld is nog maar

xvi zeer de vraag - en het is dus ook zeer de vraag of de resultaten van dat onderzoek ‘in het echt’ ook gebruikt kunnen worden. RQ 6: Wat is de externe validiteit van onderzoeksresultaten die gebaseerd zijn op benchmarks en zelf-verzonnen test-data? Hoofdstuk 4 gaat verder met het beschrijven van een aantal bouwstenen die antwoord kunnen geven op deze vragen. Die bouwstenen worden in de volgende hoofdstukken ook gebruikt, in het bijzonder toegepast op liftbesturing. De hoofdstukken 5-7 bevatten de case-study over liftbesturing. Het probleem zelf wordt beschreven in hoofdstuk 5. Liftbesturing is een goed voorbeeld van een complex, dynamisch schedulingprobleem. Zelfs wanneer je het probleem als een statisch probleem bekijkt, is het bewezen NP-moeilijk. Het heeft een hoge korte-termijn dynamiek, en ook een sterke tweede-orde dynamiek die al vaak in de literatuur beschreven is. Bijvoorbeeld: het reizigersvervoer tijdens de ochtend-piek, lunch-piek en namiddag-piek verschillen sterk van karakter. Het probleem is ook nauw verwant aan andere routerings- en logistieke problemen. Het hoofdstuk geeft een aantal onderzoekshypotheses (Research Hypotheses) die de algemene vragen uit het vorige hoofdstuk vertalen naar het liftendomein. In hoofdstuk 6 wordt de simulatieomgeving beschreven, die gebruikt is voor de liftbesturingsexperimenten, en ook manieren om vast te stellen hoe je de kwaliteit van een bepaalde besturingsmethode kunt meten. Dit hoofdstuk gaat ook in op het probleem van de zelf-verzonnen test-data (RQ 6). De passagiersgegevens die in dit proefschrift gebruikt worden zijn gegenereerd op basis van echte gebouwendata die zijn aangeleverd door een liftenfabrikant. Het hoofdstuk vergelijkt resultaten die met deze data verkregen zijn met resultaten op basis van zelf-verzonnen data zoals dat in de literatuur veel voorkomt. Hoofdstuk 7 beschrijft de experimenten die gedaan zijn, in vier secties. De eerste sectie gaat in op de invloed van de omgeving op de scheduler (RQ 4). In het geval van liftbesturing zijn er twee bestaande omgevingen: een conventioneel besturingssysteem en een bestemmingsbesturingssysteem. Deze twee systemen hebben verschillende eigenschappen. Het conventionele systeem voorziet de scheduler van late en gebrekkige informatie, terwijl bestemmingsbesturing juist vroeg en gedetailleerd informatie aanlevert. Aan de andere kant vergt een conventioneel systeem geen snelle beslissingen, terwijl dat bij bestemmingsbesturing zeer snel moet gebeuren. Een nieuwe omgeving, die op dit moment niet gefabriceert wordt, ‘valsspelende bestemmingsbesturing’, wordt ook onderzocht, en heeft naar verwachting ideale kwaliteiten: vroege en gedetailleerde informatie, terwijl beslissingen in alle rust genomen kunnen worden. De tweede sectie gaat over het probleem van de complexe metaheuristieken, zoekruimtes en objective functions. Omdat ze nogal dicht bij elkaar liggen worden

xvii RQ 1 en 2 in deze sectie behandeld. Verschillende zoekruimtes worden geanalyseerd, en een breed scala aan parameters voor objective functions wordt onderzocht, zodat de noodzaak voor een complexe probleemoplosser wordt gereduceerd (RQ 1). Evolutionaire algoritmen worden vergeleken met het meer recht-toe-recht-aan k-opt algoritme (RQ 2). De derde sectie gaat nog dieper op de relatie tussen zoekruimte en objective function in, door verschillende methoden te onderzoeken om de robuustheid en flexibiliteit te verhogen (RQ 5). Bij weinig reizigersverkeer is het slim parkeren van liften een voor de hand liggende (en bekende) methode. Voor middelmatig tot druk reizigersverkeer wordt een aantal specifieke methoden voor het verhogen van flexibiliteit en robuustheid onderzocht. De vierde, en laatste, sectie gaat in op schedulers die zichzelf aanpassen om goed aan te sluiten op tweede-orde dynamiek, gebruikmakend van hybride technieken (RQ 3). Hoofdstuk 8 sluit het proefschrift af met een discussie. RQ 1 kon positief beantwoord worden. Abstracte oplossingscoderingen en het optimaliseren van de zoekruimte bleken een krachtige combinatie, die het mogelijk maakte een eenvoudig algoritme te gebuiken. Het antwoord op RQ 2 is ‘beperkt’, want evolutionaire algoritmen sluiten vanuit hun aard slecht aan op dynamische problemen, en deden het ook inderdaad erg slecht bij liftbesturing. RQ 3 werd positief beantwoord door gebruik van een bouwsteen over hybridisatie, die leidde tot zeer pragmatische hybridisaties, die elke andere gebruikte methode uit dit onderzoek overschaduwd hebben. Het gebruik van hybridisaties om met tweede-orde dynamiciteit om te gaan bleek echter, in ieder geval binnen deze case-study, niet te leiden tot verbetering (ook niet tot verslechtering). Dit was echter goed te verklaren vanuit het specifieke liftbesturingsprobleem zelf, en zulke hybridisaties zijn nog steeds veelbelovend in andere probleemdomeinen. Aanpassingen in de probleemomgeving (RQ 4) speelden een enorme rol in de prestaties van de scheduler. Het zo vroeg mogelijk verkrijgen van zo gedetailleerd mogelijke informatie, waarbij het nemen van een beslissing zoveel mogelijk wordt uitgesteld, blijken belangrijke deugden in dynamische scheduling systemen. RQ 5 kon niet in zijn algemeenheid beantwoord worden, aangezien pogingen tot het verhogen van robuustheid en flexibiliteit erg probleem-gerelateerd zijn. Het bleek wel dat het incalculeren van het risico dat een taak in de toekomst uitgesteld zal worden, een belangrijke succesfactor was in liftbesturing, en waarschijnlijk ook elders bruikbaar is. Het nu van zelf-verzonnen test-data (RQ 6) is beperkt, en het leidde tot andere resultaten dan wanneer échte gebouwen-data gebruikt werden. Het nut van benchmarks buiten hun eigen context is ook beperkt, en zelfs binnen deze enkele case study bleek al dat hetzelfde algoritme verschillende resultaten opleverde als de scheduling omgeving een klein beetje werd aangepast.

Contents

Preface

v

Abstract

vii

Samenvatting

xiii

1

Introduction 1.1 Overview . . . . . . 1.2 Pitfalls . . . . . . . 1.3 Research questions 1.4 Dissertation outline

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

I

General discourse on dynamic scheduling problems

2

Scheduling and heuristics 2.1 Generic scheduling problem . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.2 Constraints and optimality criteria . . . . . . . . . . . . . . . . . 2.1.3 Problem complexity . . . . . . . . . . . . . . . . . . . . . . . . . 2.2 Solution strategies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.1 Basics of solution searchers . . . . . . . . . . . . . . . . . . . . . 2.2.1.1 Building a solution from scratch: constructive approach 2.2.1.2 Refining a solution: Local search . . . . . . . . . . . . . 2.2.2 Heuristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1 1 2 4 5

7 9 9 9 12 14 15 15 16 17 19

xx

2.3

2.4 3

4

2.2.2.1 Heuristic functions . . . . . . . . . . . . . . . . 2.2.2.2 Heuristic algorithms and heuristic approaches 2.2.3 Metaheuristics . . . . . . . . . . . . . . . . . . . . . . . . Hybrid heuristics . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.1 Low level vs. High level integration . . . . . . . . . . . . 2.3.2 Relay vs. Teamwork . . . . . . . . . . . . . . . . . . . . . 2.3.3 Homogeneous vs. Heterogeneous . . . . . . . . . . . . . 2.3.4 Global vs. Partial . . . . . . . . . . . . . . . . . . . . . . . 2.3.5 Specialist vs. General . . . . . . . . . . . . . . . . . . . . . 2.3.6 Static vs. Adaptive . . . . . . . . . . . . . . . . . . . . . . Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Dynamic Scheduling 3.1 Dynamic aspects . . . . . . . . . . . . . . . . 3.1.1 Direct change events . . . . . . . . . . 3.1.2 Second-order dynamicity . . . . . . . 3.1.3 Issues and challenges . . . . . . . . . 3.2 Solution approaches for dynamic scheduling 3.2.1 Different problem solving modes . . . 3.2.1.1 Schedule repair . . . . . . . 3.2.1.2 Full rescheduling . . . . . . 3.2.1.3 Ad hoc scheduling . . . . . . 3.2.1.4 Mixed modes . . . . . . . . . 3.2.2 Anticipation . . . . . . . . . . . . . . . 3.2.3 Adaptivity . . . . . . . . . . . . . . . . 3.2.4 Reducing nervousness . . . . . . . . . 3.3 Discussion . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

20 23 24 31 31 33 34 35 35 36 38

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

39 39 40 42 43 45 45 45 46 47 48 49 54 55 57

Designing heuristics for dynamic scheduling 4.1 Research questions . . . . . . . . . . . . . . . . . . . . . . . . 4.1.1 Issues related to the problem solver . . . . . . . . . . 4.1.1.1 Solution over-complexity . . . . . . . . . . . 4.1.1.2 Hybrid possibilities in dynamic scheduling 4.1.2 Issues related to the dynamic scheduling problem . . 4.1.2.1 Informedness of the dynamic scheduler . . 4.1.2.2 Flexibility and robustness . . . . . . . . . . . 4.1.3 Issues related to experimenting . . . . . . . . . . . . . 4.1.3.1 Experimental validity . . . . . . . . . . . . . 4.1.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . 4.2 Building blocks . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

59 59 60 60 61 62 62 62 63 63 63 64

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

xxi 4.2.1 4.2.2 4.2.3 4.2.4 4.2.5

4.3

II 5

6

BB 1: System design enhancements . . BB 2: Realism measures . . . . . . . . . BB 3: Abstract solution encoding . . . . BB 4: Hybridization . . . . . . . . . . . BB 5: Heuristic interaction . . . . . . . . 4.2.5.1 Algorithm and neighborhood 4.2.5.2 Objective function . . . . . . . 4.2.6 BB 6: Evolutionary algorithms . . . . . Elevator dispatching case study . . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

Case study: Elevator dispatching

85

Introduction to elevator dispatching 5.1 Background . . . . . . . . . . . . . . . . . . . . 5.1.1 Elevator system setups . . . . . . . . . . 5.1.2 Constraints . . . . . . . . . . . . . . . . 5.1.3 Optimality criteria . . . . . . . . . . . . 5.1.4 Classification within generic scheduling 5.1.5 Complexity . . . . . . . . . . . . . . . . 5.1.6 Existing studies . . . . . . . . . . . . . . 5.1.7 Discussion . . . . . . . . . . . . . . . . . 5.2 Research hypotheses . . . . . . . . . . . . . . . 5.2.1 Scheduling environment . . . . . . . . 5.2.2 Heuristic interaction . . . . . . . . . . . 5.2.3 Flexibility and robustness . . . . . . . . 5.2.4 Hybridization . . . . . . . . . . . . . . . Experimental setup 6.1 Elevator simulation setup . . . . . . . . . . 6.1.1 Office building . . . . . . . . . . . . 6.1.2 Elevator car . . . . . . . . . . . . . . 6.1.3 Elevator doors . . . . . . . . . . . . . 6.1.4 Passenger . . . . . . . . . . . . . . . 6.1.5 Scheduler . . . . . . . . . . . . . . . 6.2 Data and analysis . . . . . . . . . . . . . . . 6.2.1 Input data . . . . . . . . . . . . . . . 6.2.2 Performance evaluation . . . . . . . 6.2.2.1 Pairwise comparison . . . 6.2.2.2 Evaluating types of traffic

64 66 66 71 76 77 79 81 83

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . . . .

87 87 88 89 91 95 97 100 103 105 105 106 107 107

. . . . . . . . . . .

109 109 111 112 114 115 115 118 118 120 120 122

xxii 6.2.3 7

Statistical significance . . . . . . . . . . . . . . . . . . . . . . . . 123

Experiments 7.1 Alternative control paradigms in elevator dispatching . . . . . . . . . 7.1.1 Operational hypotheses . . . . . . . . . . . . . . . . . . . . . . 7.1.1.1 Destination control vs. conventional control . . . . . 7.1.1.2 Cheating destination control vs. standard destination control . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.1.2 Experimental setup . . . . . . . . . . . . . . . . . . . . . . . . . 7.1.2.1 Independent variables . . . . . . . . . . . . . . . . . 7.1.2.2 Dependent variables . . . . . . . . . . . . . . . . . . 7.1.2.3 Experimental design . . . . . . . . . . . . . . . . . . . 7.1.2.4 Testing . . . . . . . . . . . . . . . . . . . . . . . . . . 7.1.3 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.1.3.1 Conventional control vs. destination control . . . . . 7.1.3.2 Destination control vs. cheating destination control . 7.1.4 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.2 Heuristic triangles in elevator dispatching . . . . . . . . . . . . . . . . 7.2.1 Hypotheses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.2.1.1 On algorithms and search space structure . . . . . . 7.2.1.2 On objective functions . . . . . . . . . . . . . . . . . 7.2.2 Experimental setup . . . . . . . . . . . . . . . . . . . . . . . . . 7.2.2.1 Independent variables . . . . . . . . . . . . . . . . . 7.2.2.2 Dependent variables . . . . . . . . . . . . . . . . . . 7.2.2.3 Experimental design . . . . . . . . . . . . . . . . . . . 7.2.2.4 Testing . . . . . . . . . . . . . . . . . . . . . . . . . . 7.2.3 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.2.3.1 Different neighborhoods . . . . . . . . . . . . . . . . 7.2.3.2 Objective functions . . . . . . . . . . . . . . . . . . . 7.2.4 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.2.4.1 Different neighborhoods . . . . . . . . . . . . . . . . 7.2.4.2 Objective functions . . . . . . . . . . . . . . . . . . . 7.2.4.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . 7.3 Robustness and flexibility in elevator dispatching . . . . . . . . . . . 7.3.1 Hypotheses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.3.1.1 Low traffic: Parking (flexibility) . . . . . . . . . . . . 7.3.1.2 Medium and high traffic: elevator spreading (flexibility) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.3.1.3 Medium and high traffic: Future risk estimation (robustness) . . . . . . . . . . . . . . . . . . . . . . . . .

129 . 129 . 130 . 130 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

131 131 132 132 132 135 136 136 136 136 138 139 139 141 144 144 145 145 150 150 150 153 157 157 159 161 161 162 162

. 162 . 163

xxiii 7.3.2

7.4

III 8

Experimental setup . . . . . . . . . . . . . . . . . . . . . . . . . 7.3.2.1 Independent variables . . . . . . . . . . . . . . . . . 7.3.2.2 Dependent variables . . . . . . . . . . . . . . . . . . 7.3.2.3 Experimental design . . . . . . . . . . . . . . . . . . . 7.3.2.4 Testing . . . . . . . . . . . . . . . . . . . . . . . . . . 7.3.3 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.3.3.1 Low traffic: Parking (flexibility) . . . . . . . . . . . . 7.3.3.2 Medium and high traffic: Elevator spreading (flexibility) . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.3.3.3 Medium and high traffic: Future risk estimation (robustness) . . . . . . . . . . . . . . . . . . . . . . . . . 7.3.4 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.3.4.1 Low traffic: Parking (flexibility) . . . . . . . . . . . . 7.3.4.2 Medium and high traffic: Elevator spreading (flexibility) . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.3.4.3 Medium and high traffic: Future risk estimation (robustness) . . . . . . . . . . . . . . . . . . . . . . . . . 7.3.4.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . Hybridization in elevator dispatching . . . . . . . . . . . . . . . . . . 7.4.1 Hypothesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.4.2 Experimental setup . . . . . . . . . . . . . . . . . . . . . . . . . 7.4.2.1 Independent variables . . . . . . . . . . . . . . . . . 7.4.2.2 Dependent variables . . . . . . . . . . . . . . . . . . 7.4.2.3 Experimental design . . . . . . . . . . . . . . . . . . . 7.4.2.4 Testing . . . . . . . . . . . . . . . . . . . . . . . . . . 7.4.3 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.4.4 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . .

. 173 . 173 . 175 . 175 . 176 . . . . . . . . . . .

Discussion Discussion 8.1 Improving neighborhood and objective function 8.1.1 BB 3: Abstract solution encoding . . . . . 8.1.2 BB 5: Heuristic interaction . . . . . . . . . 8.1.3 Lessons learned . . . . . . . . . . . . . . . 8.2 Evolutionary algorithms . . . . . . . . . . . . . . 8.2.1 BB 6: evolutionary algorithms . . . . . . 8.2.2 Lessons learned . . . . . . . . . . . . . . . 8.3 Hybridization . . . . . . . . . . . . . . . . . . . .

163 164 164 164 170 171 171

176 177 177 177 177 178 178 178 179 179 179

183 . . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

185 186 186 186 187 188 188 189 190

xxiv

8.4

8.5

8.6

8.7

8.3.1 BB 4: hybridization . . . . . . . . . . 8.3.2 Lessons learned . . . . . . . . . . . . Scheduling environment . . . . . . . . . . . 8.4.1 BB 1: System design considerations 8.4.2 Lessons learned . . . . . . . . . . . . Flexibility and robustness . . . . . . . . . . 8.5.1 BB 5: Heuristic interaction . . . . . . 8.5.2 Lessons learned . . . . . . . . . . . . Self-generated test data . . . . . . . . . . . . 8.6.1 BB 2 Realism measures . . . . . . . . 8.6.2 Lessons learned . . . . . . . . . . . . Conclusions . . . . . . . . . . . . . . . . . . 8.7.1 Concluding statements . . . . . . . . 8.7.2 Future work . . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

190 191 192 192 193 193 194 195 195 195 196 196 197 198

Bibliography

201

A Algorithms A.1 Creating a new data set . . . . . A.2 Conventional control (CC) . . . A.3 Destination control (DC) . . . . A.4 Fine-grained neighborhoods . . A.5 Elevator parking and flexibility

211 211 213 214 215 216

Curriculum Vitae

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

219

1 Introduction 1.1

Overview

Dynamic scheduling enjoys increasing research attention. In dynamic scheduling problems, changes occur while the schedule is carried out. Various approaches from different research fields exist to cope with dynamic scheduling problems. One branch of problem solvers is ad hoc scheduling. A simple example of this can be seen at the check-in desks of an airport. Every time a desk becomes available, the ‘next in line’ is called forward. This scheme is better known as ‘first in first out’ (FIFO). Other problem solvers, instead of taking ad hoc decisions, create complete schedules based on the current knowledge. Upon change events, this schedule will have to be revised. This is known as ‘full rescheduling’, the main focus of this dissertation. Techniques to perform full rescheduling are rooted in generic search algorithms. For dynamic scheduling, no ‘exact solutions’ exist, since the usability of a proposed schedule depends on an unknown future. Therefore, these techniques always involve the use of heuristics. Heuristics can be described as rules of thumb, approaches that try to deliver a best-as-possible solution in a problem environment in which no exact optimum can be calculated. In the field of heuristics, there is particular interest in so called metaheuristics, of which evolutionary algorithms are a well-known example. Furthermore, there is a growing interest in the application of hybridizations: putting multiple algorithmic approaches together. The driving force behind hybridizations is the assumption that the whole is better than the sum of the parts. Metaheuristics and hybrids are also increasingly used for dynamic scheduling. In the area of dynamic scheduling, hybrid solutions may yield a specific advantage. Many dynamic scheduling problems both have a short-term and a secondorder dynamicity to them. Short-term dynamicity is described above: a problem

Introduction

2

changes before its solution is carried out completely. Second-order dynamicity, however, means that the nature of the problem can change. For example, consider a traffic junction with traffic lights. Incoming and leaving vehicles change the situation continuously, all day long. But the traffic characteristics change as well: there are morning and afternoon rush hours, the more relaxed periods in between, and the tranquility of the night. For each of these situations, a different algorithmic approach may perform best. Hybridization could be used to pick approaches on the fly: choose the best scheduling algorithm to cope with varying circumstances, while the process continues to run. Applying heuristics and hybrids to dynamic scheduling may incur a number of pitfalls. This dissertation tries to identify those, offering approaches and directions to divert away from these pitfalls. The dynamic scheduling problem will be discussed from different angles, and the dissertation more closely investigates a particular instance of a dynamic scheduling problem: Elevator dispatching. Elevator dispatching is a highly dynamic problem, having both short-term dynamicity (e.g., each time someone registers a hall call) and second-order dynamicity (e.g., the difference in traffic characteristics between the morning rush hour and the lunch peak). Solution approaches in elevator dispatching suffer from the same vulnerabilities that were identified for dynamic scheduling in general, and could therefore benefit from the proposed approaches. Although investigating multiple instances of dynamic scheduling problems would have showcased the benefits even more, elevator dispatching is an ideal test case to investigate dynamic scheduling mechanisms.

1.2

Pitfalls

• Heuristics as used in full rescheduling, involve the local search paradigm. In local search, a solution is compared to modifications of that solution. The latter are ‘local’ solutions, they are near the original. By continually hopping to local solutions, the search algorithm hopes to find a better solution than the original starting point. In such approaches, the algorithm is only one of three aspects. The others are the neighborhood (how to modify a solution to create a local alternative?) and the objective function (how to assess the quality of a candidate solution?). In literature describing metaheuristics, the focus is strongly on the algorithm. Some of those metaheuristics are chosen to solve difficult problems, thereby often paying more attention to the chosen algorithm, than to neighborhood and objective function. In hybridizations, this tendency of overestimating the importance of the algorithm is even stronger, since the hybridization usually involves only the algorithms. However, all three aspects are important in local search. Therefore, the pitfall here might be underestimating

1.2. Pitfalls

3

the importance of good neighborhood and objective function design. • Dynamic scheduling problems are often difficult problems. In such problems, engineers rely on problem solving methods like metaheuristics and hybridizations, since these methods are known for coping with complex problems. One particular example of a metaheuristic concerns evolutionary algorithms. These are often applied in a black-box manner. However, their inner working - mixing different solutions in order to create new solutions - may not work for solutions that have a strong internal coherence, such as schedules (Goldberg, 1989). Furthermore, these methods involve a (large) number of extra parameters to be set, which is a difficult problem in itself (Eiben et al., 1999). If the difficulty of applying such metaheuristics at all, leads to underexposure of attention to neighborhood and objective function, the resulting scheduler will likely produce suboptimal scheduling results. Lastly, the short time frame in which solutions are required in dynamic scheduling might rule out algorithms with too high computational complexity. • In dynamic scheduling there is an important tradeoff between available and necessary time for computation. A problem environment that provides information late, and also demands an immediate solution, makes it difficult for the dynamic scheduler to provide good results. In environments where these factors can be modified, such that information is provided earlier and decisions can be made later, a performance increase is very well possible using a scheduler that exploits these factors. • In dynamic scheduling, lack of knowledge of the environment, such as expected events in the near future, make it difficult for the scheduler to produce desirable results. Dynamic scheduling problems are often presented as a direct copy of their static counterpart, and literature sometimes even describes dynamic problems being solved as if they were static. However, if the dynamicity of the problem is not taken into account in the search for a solution, the value of that solution may be short-lived. When a change event occurs, the change may be difficult to incorporate into the schedule (the schedule is ‘inflexible’), or the objective value for the modified schedule would differ greatly from the previous one (the schedule is not ‘robust’). • Benchmark problems and self-generated test data are often used to assess the performance of scheduling techniques. However, the correspondence between a benchmark problem and a real world problem may be disputable. In dynamic scheduling, the moving peaks problem has been proposed and used as a benchmark. However, this benchmark has little or no connection to any actual

Introduction

4

problem. This raises the question to what extent the results using that benchmark are applicable to problems in the real world. To a lesser extent, this is also true for simulations of real world problems in which self-generated random test data are used to analyze the performance. When these test data are not modeled in accordance to realistic scenarios, the test results may be disputable as well.

1.3

Research questions

Deriving from the pitfalls, this dissertation aims to answer a number of research questions and to provide opportunities to increase the performance of dynamic schedulers: 1. Can improved neighborhoods and objective functions reduce the need for a complex metaheuristic while maintaining the same overall quality? 2. What are the advantages and pitfalls when applying evolutionary algorithms to dynamic scheduling? 3. How could a simple hybrid approach increase the performance of a dynamic scheduler, both in the case of short-term and second-order dynamicity? 4. To what extent could modifications in the environment increase the performance of dynamic schedulers? 5. How could flexibility and robustness measures increase the performance of a dynamic scheduler? 6. What is the external validity of research findings obtained by benchmarks or self-generated test data? In order to answer these questions, a number of building blocks is proposed for the design of practical dynamic schedulers. To check the viability of these building blocks in practice, elevator dispatching was used as a typical, and challenging, example of dynamic scheduling. A simulation environment was created that closely mimics an actual building in Paris. Using real world passenger data from that building, realistic experiments were run and analyzed. The general research questions above were translated into hypotheses that posed specific questions regarding elevator dispatching. Finally, in the discussion chapter, specific attention is paid to the broader applicability of research findings from this specific case study.

1.4. Dissertation outline

1.4

5

Dissertation outline

In addressing the issues and challenges, Chapter 2 first charts the area of scheduling and the use of heuristic approaches in general. Chapter 3 then focuses on the particularities of dynamic scheduling, both from a problem and a solution perspective. The chapter shows that the complexity of dynamic problems is of different nature than the complexity of static problems. On the solution side, the applicability of techniques that were discussed in Chapter 2 to dynamic scheduling problems are discussed. We will see that no exact solution can exist for a dynamic scheduling problem, and heuristics are always needed in some form or another. Chapter 4 discusses the previous two chapters, culminating in the aforementioned research questions. Then it proposes building blocks to alleviate the problems mentioned before. The second part of the dissertation presents the elevator dispatching case study. Chapter 5 outlines the problem itself, and states four Research Hypothesis that are specific to the elevator dispatching problem. Chapter 6 discusses the experimental design, focusing on the simulation environment, the input data and the proposed methods for analysis. Chapter 7 provides operational hypotheses for each of the, more generic, Research Hypotheses. The chapter includes the specific experiments to investigate these operational hypotheses, the results and the conclusions. Finally, in the third part, Chapter 8 discusses the research questions and the building blocks from Chapter 4, both in view of the case study and in its general applicability.

Part I

General discourse on dynamic scheduling problems

2 Scheduling and heuristics This chapter presents a general background on scheduling problems, and approaches to solve them. The first section outlines the generic scheduling problem, followed by a section on solution strategies that are commonly applied to scheduling problems. So-called metaheuristics and hybrid algorithms will come to closer investigation there. The next chapter (3) discusses the focal point of this dissertation, dynamic scheduling.

2.1

Generic scheduling problem

Pinedo (2008) gives the following definition of scheduling: “Scheduling concerns the allocation of limited resources to tasks over time. It is a decision-making process that has as a goal the optimization of one or more objectives”. Within research fields such as Artificial Intelligence and Operations Research, much attention is devoted to developing solutions to solve scheduling problems. This section discusses aspects of the scheduling problem, whereas the next section focuses on solution strategies.

2.1.1

Terminology

Tasks and Resources are the basic entities in all scheduling problems (T’kindt and Billaut, 2002; Cottet et al., 2002). A task set T = {τ0 , ..., τn−1 } with n tasks has a number of properties, also depicted in Fig. 2.1. • ri is the release time of task τi , the earliest possible starting time for that task. If τi is a periodic task, ri,j denotes the jth occurrence of ri .

Scheduling and heuristics

10

pi Di τi ri,0 si

ci

di

ri,1

t

ei

Figure 2.1: Timing diagram of the task model

• pi is the task period of task τi . If τi is a periodic task, pi is the time at which τi is repeated. • ci is the completion time of task τi , the time it takes for task τi to complete. In some contexts where the completion time is not fixed, ci denotes the worst-case task duration, i.e., the maximum possible time it takes τi to complete. • di is the deadline of task τi , i.e., the latest time at which task τi has to be completed. • Di is the relative deadline of task τi , the time interval within which task τi is to be scheduled. • si is the start time of task τi , the absolute time at which the execution task τi is started. • ei is the end time of task τi , the absolute time at which the execution of task τi is finished. A number of other properties of a task can be distinguished. Of those, Preemptiveness and Task Dependency are the most important ones. A preemptive task can be stopped once execution has been started. This may be done in order to free resources currently in use by the execution of that task. A non-preemptive task has to be carried out completely after its execution has been started. Task dependency means that a task can only be executed after a specific set of one or more other tasks have been completed. The task dependencies within T induce a partial order on T, otherwise, a deadlock situation occurs. Resources are the means using which tasks can be executed. There are two types, renewables and consumables. Renewable resources, like machines, can be used again. Consumable resources, like fuel, can only be used once. In most scheduling problems, the resource environment is primarily described in terms of renewable resources, mostly machines. The number of machines is denoted by m, with subscript i referring to a specific machine. The processing time pij denotes the processing time

2.1. Generic scheduling problem

11

of job j on machine i. If the processing time does not depend on the actual machine used, the subscript i is omitted. Example 2.1. As an illustration of scheduling properties, consider a taxi scheduling example in which multiple taxis are driving around in the same city, picking up and delivering passengers. In this example, the tasks consist of passenger trips. The tasks are not preemptive, since passengers are always delivered before new passengers are picked up. The resources are taxis, taxi drivers and fuel. The release time for the task is the moment a passenger calls for a taxi (or hails one).

Shop scheduling problems A specific family of scheduling problems is called Shop Scheduling Problems (SSP). Members of this family that are often treated in the literature include Job Shop Scheduling Problems (JSSP) and Flow Shop Scheduling Problem (FSSP). Within SSPs, tasks are grouped in jobs. Each job may consist of a number of tasks, which are called operations. The number of jobs is usually referred to as n, with the subscript j used to refer to a specific job. Properties like release date (r j ) and due date (d j ) are analogous to what is mentioned for tasks alone (Pinedo, 2008). SSP’s are classified using the triplet α| β|γ (Graham et al., 1979): • The α part describes the machine environment. For example, ‘1’ refers to a single machine problem. ‘Pm0 refers to an environment with m machines in parallel. • The β part denotes the constraints that have to be met. For example, ‘s jk ’ refers to sequence dependent setup times, when a machine has a setup time after job j before it can handle job k. ‘nwt’ refers to a no-wait environment, when no waiting time is allowed between the execution of different operations in a job. • The γ part refers to the scheduling objective, the goal to be reached. ‘Cmax ’ is a typical example, denoting makespan: minimize the completion time of the last job in the system. Some practical problems can, with some moderations, be categorized as, or reduced to, Shop Scheduling Problems (Landa Silva et al., 2004). However, practical problems often have specific properties that make a translation into this framework hard or impossible (Pinedo, 2008).

Scheduling and heuristics

12

2.1.2

Constraints and optimality criteria

As noted before, a schedule is a mapping of tasks to resources at specific times. In producing a schedule, the scheduler has to find a solution that does not violate constraints. Such a solution is called a feasible solution. Constraints are demands on a schedule, for which a violation leads to an infeasible schedule. Examples of constraints are “jobs that are scheduled on the same machine cannot have overlapping time intervals”, or “all jobs must be scheduled”. When a problem is underconstrained, multiple solutions to the problem exist. In this case, the solution provider can choose from multiple feasible solutions the one that meets his objectives best. When a problem is over-constrained, different constraints are counteracting each other to such an extent that no feasible solution exists (Beaumont et al., 2001). Definition 2.1. If S is a set of solutions, an objective function is a function f : S → R that provides an objective value to any solution s ∈ S. In addition to satisfying constraints, the scheduler mostly wants to find an optimal solution. Using optimality criteria, the scheduler can compare different schedules and choose the best. Optimality criteria are encompassed in an objective function, which is used to calculate an objective value1 . The objective value is a measure to quantify the performance of a solution. A typical examples of an optimality criterion is “minimize the time needed to complete all jobs”. In the literature, some make the distinction of constraints and optimality criteria as discussed before (Pinedo, 2008). Others make the distinction between hard constraints and soft constraints (Cohen et al., 2006; Landa Silva et al., 2004). The hard constraints are the constraints we have seen before. The soft constraints, however, can be violated, without rendering the solution infeasible. The scheduler will try to minimize the soft constraint violations. For example, the hard constraint “all jobs must be scheduled” might be relaxed into a soft constraint: “maximize the number of scheduled jobs”. Soft constraints are therefore optimality criteria by themselves, and are often treated as such. In the remainder of this dissertation, we will not use this hard/soft distinction, but refer to constraints and optimality criteria instead. Apart from constraints related to the actual problem and the environment, another type of constraint encountered in scheduling is the quality of service (QoS) constraint. A QoS constraint is a demand on the problem solver, defining the performance levels to which the problem solver has to adhere. An example of a QoSconstraint is “a solution has to be provided within 0.1 seconds”. In real world sce1 Objective functions and objective values are sometimes called fitness functions and fitness values, or, shortly, the fitness of a candidate solution. The term ‘fitness’ is derived from the field of evolutionary algorithms, in which the search for an optimal solution follows the Darwinian concept of the survival of the fittest (genetic algorithms are more closely discussed in Section 2.2.3). Nevertheless, the term fitness is often used in heuristics literature next to the term objective (value). In some cases, like ‘fitness landscape’, fitness is the only term used. In this dissertation, both terms will interchangeably occur.

2.1. Generic scheduling problem

13

f0

f1 Figure 2.2: Pareto optimality: The circles form a pareto-optimal boundary in a situation where two optimality criteria play a role ( f 0 and f 1 - higher values are better). They dominate other solutions (like the rectangles), by improving performance on at least one criterion, while being at least as good on all other criteria.

narios, especially in real-time dynamic scheduling which is the main topic of this dissertation, available scheduling time may be extremely short. Example 2.2. Taxi driver scheduling is restricted by constraints, such as labor time laws for the driver, speed limits, or the maximum number of passengers in a taxi. The optimality criteria can be diverse, for example, minimizing the waiting time for passengers or minimizing the distance travelled by the pool of taxis.

Multi-criteria optimization In real world problems, multiple optimality criteria may be present. When a candidate schedule is valued higher than another schedule according to one of the optimality criteria, without losing its value on the other criteria, this candidate dominates the other schedule. Alternatively, this candidate is called a Pareto improvement over the other schedule. Definition 2.2. Pareto dominance: An objective vector u = (u0 , ..., un−1 ) dominates v = (v0 , ...vn−1 ), denoted by u ≺ v, iff ui ≤ vi ∀i < n and ∃i : ui < vi . A schedule that is not dominated by any other possible schedule is called a Pareto optimum. Definition 2.3. A solution s ∈ S is Pareto optimal if F ( x ) ⊀ F (s) ∀ x ∈ S. In problems with multiple optimality criteria, a set of Pareto optimal solutions may exist that may be improvable for some of the optimality criteria, but only by sacrificing other optimality criteria (Fig. 2.2).

Scheduling and heuristics

14

Example 2.3. Continuing the taxi driver scheduling example from Section 2.1.1, a new passenger calls for a taxi somewhere in the outskirts of town. There are two options: sending an empty taxi to the passenger, or assigning another taxi that coincidentally has to deliver another passenger in that area. The vacant taxi will arrive earlier than the taxi that has a delivery first. On the other hand, sending the empty taxi will increase the overall distance travelled for all taxis. The choice is whether to let the passenger wait five minutes longer, or have all taxis drive five kilometers extra. When the scheduler assigns equal values to an extra minute waiting time and an extra kilometer driven, the choice becomes arbitrary, since no solution is a Pareto improvement over the other. Several schemes to multi-criteria optimization can be applied (Landa Silva et al., 2004): • a priori: when different values are, via some calculation, joined into one single objective value. The weighing of values (adding? multiplying? using one value as an exponent for another?) is a difficult issue. However, when the engineer aims at a fully automated system, this is the method of choice as it produces one number that can easily be used in any optimizing algorithm, and it does not require user intervention. • mixed initiative: when the (human) user can intervene in the process, guiding the search for a preferable solution. As synchronizing a human user and a computerized scheduler is a research topic in itself, this option is not used much. • a posteriori: where the (human) user is presented with a choice, after the search for solutions has been done. The user can make a decision based on his personal preferences and experience combined with the specific situation at hand. T’kindt and Billaut (2002) give an excellent overview of multi-criteria scheduling. For a more concise overview, the reader is referred to (Landa Silva et al., 2004).

2.1.3

Problem complexity

In scheduling, the number of tasks and resources is referred to as the size of a problem instance, problem size for short. The size of the solution space, on the other hand, reflects the amount of scheduling possibilities. An increase in problem size typically leads to an increase of the size of the solution space. Although the size of the solution space and its growth speed relative to the problem size seem an indication of the problem complexity, problem complexity is actually defined by the best algorithm available to solve it. For example, the problem of finding the shortest path between two cities yields a solution space that grows exponentially with the size of the road

2.2. Solution strategies

15

network (i.e., the number of roads). Yet, the A* algorithm solves this problem in a time span that is a polynomial function of the problem size (not the solution space size). Such an algorithm is called an efficient algorithm. Hence, the shortest path problem is regarded an ‘easy’ problem. A problem is considered ‘hard’ when no efficient algorithm exists. The notion of (non) polynomial time complexity of algorithms is formalized in the theory of NP-completeness (Cook, 1971; Garey and Johnson, 1979). An important aspect of NP-hard optimization problems, such as most scheduling problems that are treated in this dissertation, is that no efficient algorithm exists to solve them. More aspects than the time complexity can play a role in describing the complexity of a problem. For example, the spatial complexity of an algorithm (not of a problem) deals with the fact that the memory requirements of an algorithm can be explosive. However, both spatial and time complexity can lead to a situation in which the practically available processing capacity is limited below the bounds of efficient calculability, so that even an ‘easy’ problem becomes ‘hard’. Furthermore, the information provided to the problem solver may be uncertain or incomplete. In such situations, finding a solution may become more difficult, and reaching optimality may not even be possible.

2.2

Solution strategies

The scheduling problem as introduced in the previous section, lends itself to be solved by a diverse range of problem solvers. For some problems, solutions can efficiently be calculated. As we have seen in Section 2.1.3, a large number of problems cannot be solved efficiently. In that case, heuristics are used. Heuristics are problem solving tools that help to solve the problem, aiming for solutions that are as good as possible: optimality cannot be guaranteed. Since heuristic problem solving approaches are strongly rooted in generic problem solving techniques, those are treated first in this section. The next subsection focuses on heuristics. In the last subsection, metaheuristics are introduced as a more generic means to solve problems.

2.2.1

Basics of solution searchers

Producing a solution to a given problem basically takes one of two forms: constructing a solution from scratch, or refining a given solution by investigating related solutions. The former, the constructive approach, builds up a solution by concatenating atomic solution elements. The latter, called local search, starts with a given complete solution and improves it until no further improvement can be found, or time is running out. There are problems for which finding a solution at all is the major

Scheduling and heuristics

16 a b e

a

c f

g

d h

b i

e

c f

g

d h

i

Figure 2.3: Depth first search and breadth first search

challenge. In that case, using a constructive algorithm is the appropriate approach. In other problems, finding a solution in itself is easy, but the real challenge lies in optimization. In that case, constructive algorithms may be helpful in quickly creating a starting solution, but local search methods will be used to optimize the solution. 2.2.1.1

Building a solution from scratch: constructive approach

Typically, a constructive approach takes the shape of a tree: initially, the solution is empty (the root of the tree), and at each iteration atomic elements are added, thereby branching the tree. The amount of possibilities to do so defines the branching factor. The nodes within the tree represent incomplete solutions, whereas the leaves at the end of the tree are the complete solutions. The walk from root to leaf defines how the solution is created. Some branches may lead to dead ends: it is not a complete solution yet, but due to constraint violations, no more elements can be added. This may be possible at a great distance from the root of the tree. In Depth First Search (DFS), a solution is created by consecutively adding elements to an incomplete solution, and backtracking each time a dead end is found. As only the path to the current (incomplete) solution is stored, this method is not memory intensive. However, it can easily run into long, unpromising branches. In Breadth First Search (DFS), as long as no solution is found, the complete next layer of (incomplete) solutions is examined. This method is memory intensive as all nodes up until the current layer are stored, but it guarantees finding a solution with the shortest path from the root of the tree to the final leaf (Fig. 2.3). In order to find an optimal solution, a complete search has to be carried out. Of course, incomplete branches to which no element can be added anymore limit the search space. Furthermore, branches from which it can be determined that they cannot produce better results than a solution that was already found, can also be discarded (‘Branch and Bound’, Land and Doig (1960)). In scheduling problems, constructive approaches take a somewhat different form. Time is continuous, but tasks have to be placed at specific points in time. A task τi with a shorter completion time ci (Fig. 2.1) than its relative deadline Di has an infinite number of possible starting times si . In practice, however, the task is chosen to start

2.2. Solution strategies

17 τ0 τ1 τ2 t

S0

τ2

τ0

S1

τ1

S2

τ1

S3

τ2

S4

τ2

τ0 τ2 τ0 τ1

τ0

Figure 2.4: Constructive approach applied to scheduling. Tasks τ0 , τ1 and τ2 with their respective earliest possible starting times and deadlines are shown above the timeline. Below, schedules S0 ..S4 result from placing tasks on the timeline. For example, S0 starts with putting τ0 at the earliest possible time, after that, there is no room left for τ1 , and finally τ2 is put on its earliest possible start time. If the scheduler does not allow for schedules in which tasks remain unscheduled, the scheduler would backtrack when such a dead end is found. Finally, by starting with τ2 , a schedule containing all tasks can be created.

at the earliest possible time, or to end at the deadline, or the task is placed directly adjacent to another task (Fig. 2.4). Limiting the placement options in this manner facilitates tree-based constructive approaches. 2.2.1.2

Refining a solution: Local search

Local search comprises a few key notions, that can be formalized as follows (following Michiels et al. (2006)): Definition 2.4. An instance of an optimization problem is a pair (S, f ), where the solution space S is a set of solutions and f is a cost function. f is a mapping f : S → R that assigns a real value to each solution in S. This value is called the objective value, or alternatively, the cost of the solution. Definition 2.5. An optimization problem is, given an instance (S, f ), to find a solution s0 ∈ S that is globally optimal. The problem is either a maximization or a minimization problem. For a minimization problem, s0 ∈ S is a global optimum if f (s0 ) ≤ f (s) ∀s ∈ S. Consequently, for a maximization problem, s0 ∈ S is a global optimum if f (s0 ) ≥ f (s) ∀s ∈ S. Optimization means to either maximize or minimize a cost function. For the remainder of this dissertation, without loss of generality a maximization problem

18

Scheduling and heuristics

is assumed. Obviously, a minimization problem can be turned into a maximization problem by changing the sign. Definition 2.6. A neighborhood function is a mapping N : S → 2S , with 2S denoting the power set {V |V ⊆ S}. The neighborhood of a solution s ∈ S is a set N (s) ⊆ S. s0 is a neighbor of s if s0 ∈ N (s). Example 2.4. Traveling salesman problem neighborhood Consider a traveling salesman problem (TSP) with five cities (a..e). A tour has to be created that visits each city once. The optimization problem strives for the shortest possible tour.

In the picture, on the left, an initial tour is given. Writing this solution as a string, we get "abedc". A neighborhood function creates alternative solutions by swapping the cities from two positions in the original string. Swapping the first two positions from the string ("ab") leads to a new tour "baedc". Doing this for all permutations of positions leads to the 10 neighboring tours depicted on the right. The two thick-lined neighbors are the obvious shortest routes. Local search starts with making a complete initial solution of a problem. This initial solution is created by some heuristic constructive algorithm. It may not even be a feasible solution yet. Next, a local search algorithm searches through the solution space by continually moving from a solution to one of its neighbors. Choosing a solution from the neighborhood is done using a decision strategy. The process is repeated until some stopping criterion is met. A typical criterion that can be used in the TSP example is to stop if the neighborhood of a solution does not contain a better solution. Alternatively, timing constraints can also serve as stopping criteria. In the most simple setup (a greedy hill climber, or steepest ascent algorithm, see Algorithm 2.1) the current solution is always replaced by the best solution in the neighborhood, until no further improvements are possible. In the TSP-example, the stopping criterion is already met after one neighborhood investigation, after which the algorithm returns one of the two best solutions. This resulting solution is a local optimum, which is not necessarily a global optimum (see Fig. 2.5). Definition 2.7. A local optimum is a solution s ∈ S for which holds that f (s) ≥

2.2. Solution strategies

19

local and global optimum local optima

Figure 2.5: Local vs. global optimum

Algoritme 2.1 Greedy hill climber sbest ← some initial solution repeat Result ← sbest N ← Neighborhood(s) best ← FindBest( N ) until f (best) ≤ f ( Result) return Result f ( s 0 ) ∀ s 0 ∈ N ( s ). Local search is applied when the search space is complex, and it may provide a good solution fast. Particular problems can arise when applying local search. For instance, the neighborhood function may be such that not all solutions are reachable from a given initial solution: Definition 2.8. A solution s0 is reachable from solution s if there is a sequence of solutions s1 ..sk with k ≥ 1, such that si+1 ∈ N (s)(1 ≤ i ≤ k ), s1 = s and sk = s0 . Also, a decision strategy such as applied in the greedy hill climber is prone to get stuck in local optima. Therefore, careful engineering of the decision strategy and the neighborhood function are important factors in creating a local search algorithm.

2.2.2

Heuristics

As we have seen in Section 2.1.3, not all problem instances can be solved optimally in an efficient manner. The time needed for processing may not be present. Also, optimality may not be reachable due to uncertain or incomplete knowledge about the value of solutions - in which case optimality is undefined. In such cases, heuristics may be used to increase the chance of finding a solution of acceptable quality. Heuristics can be described as rules of thumb: techniques based on experience to

Scheduling and heuristics

20

aid problem solving. In this subsection, two basic types of heuristics are discussed, heuristic functions and heuristic algorithms. 2.2.2.1

Heuristic functions

Definition 2.9. Let N be the set of nodes n of a search tree. A heuristic function h is a mapping h : N → R, that assigns a real value to each node in the search tree. The goal of the search process is either to find a leaf-node with the best value, or to find a leaf-node that is closest to the root of the tree. The value h(n) for a node n is an estimate for the cost of the best leaf in the subtree, or the distance to the earliest leaf in the subtree. Example 2.5. In chess, players take turns in moving a piece. Each position in the play can be seen as the root of a tree, the possible moves cause the tree to branch. Mostly, it is not possible to compute the whole game tree. For a player, each possible move leads to a different position - the nodes in the tree. The question is: which of these nodes will most likely lead to winning the game?

To assess the value of a node, a heuristic may be used. A simple heuristic that just subtracts the opponent’s pieces from the player’s pieces, leads to a very rude informedness about the position: a positive value is good for the player, a negative value is good for the opponent. In this figure, white has advantage with 8 pieces against 7. The use of heuristic functions leads to informed search: the search algorithm can use the heuristic values in order to rank options in the search process. The better the heuristic function, the higher the informedness of the search algorithm (Luger and

2.2. Solution strategies

21

Stubblefield, 1993). The branching factor may be cut down by using a heuristic function. For example, best first search is a way of traversing through a search tree. The algorithm will only expand the currently known child node with the best heuristic value, until a solution is found (see Algorithm 2.2). Algoritme 2.2 Best First Search OPEN ← initial state while OPEN 6= ∅ do n ← BestNode(OPEN) if n = goal state then return n end if OPEN ← OPEN \n OPEN ← OPEN ∪ GetSuccessors(n) end while A heuristic function that provides good estimates of the actual value of a (partial) solution may dramatically shorten the search to an optimal solution. However, this may come at the cost of long computation times for the values, which are calculated very often in a search process. It might be advantageous to simplify the heuristic, and be able to visit more nodes in the search process. Therefore, when using heuristic functions, it is important to trade off their quality with the time needed for computation, and find out the right balance by pilot experiments. Example 2.6. (Chess example, cont.) In chess, players take turns, and therefore, the aim for a high or low heuristic value alternates, from the viewpoint of one of the players. When thinking a few steps ahead, the player himself has to alternate minimization and maximization, to pick the moves the opponent is most likely to take - based on the assumption that the opponent applies the same or a similar strategy. It is difficult to determine how far to think ahead, since it depends on the quality of the heuristic. The worse the heuristic function, the further ahead the player has to look. The figure (in the previous example) shows a position in a chess play. As we have seen, a simple heuristic would just count the number of pieces each player has, giving white the highest chances of winning. A more expensive heuristic would also take the relative weight of the pieces into account. In that case, black has the advantage of having a 3-point bishop against two 1-point pawns. The most expensive heuristic considers the position itself as well, for example: comparing it to known positions in a database, whose outcome is known. This would inevitably show that white is in advance, since analysis shows that white is going to be a sure winner (1. d5-d6+, Ke7xd6. 2. Ktd4-b5+, K~. 3. Ktb5-c7, black

22

Scheduling and heuristics without a queen, white is the obvious winner. Alternatively: 1. d5-d6+, Qc7-d6. 2. Ktd4-f5+, K~. 3. Ktf5xd6, black without queen again, white is the obvious winner. Thanks to Kees van der Meer for providing the example). Reviewing the three heuristics, the last heuristic may seem best. However, using the cheap heuristic the supremacy of white might have been clear as well. The algorithm using that simple function could look more steps ahead, in the same time that is needed by the expensive heuristic to evaluate only the current position. How this balance works out in a practical application, has to be found out using pilot experimentation.

Heuristic functions can play a role in tree searchers, by providing an estimate of an expected outcome. However, they can play a similar role in the objective functions used in local search. Objective functions provide a valuation to a complete solution. This value can be an accurately measurable value, like fuel cost or spent time. However, it can also include heuristic parts: 1. The objective value can have a heuristic construction. Problems often involve multiple objectives to be maximized. As these objectives may be incomparable, they cannot be combined into a single number that reflects the actual value of a solution. For instance, the taxi example shows that waiting time and total distance traveled should both be minimized. However, minutes and kilometers are different units of measurement, that cannot directly be summed or compared. In such cases, there is no actual value of a solution, and each attempt to come up with a number is in fact a heuristic estimation - a subjective valuation that cannot be expressed in any known unit of measurement. 2. Objective values can also be calculated for infeasible solutions, by treating a hard constraint as a ‘soft constraint’2 . For instance, a taxi driver schedule may not cater for all passengers to be served, and as such it is not a feasible solution. In the search for a feasible solution, the scheduler might maximize an optimality criterion, namely the number of passengers served. Such a heuristic value may guide the search process towards a feasible solution, or to a solution that is as close as possible to a feasible solution. The combination of such heuristic objective values and a certain search space leads to a so-called ‘fitness-landscape’. The local search procedure could be seen as roaming that fitness landscape. 2 Note that the term soft constraint may also refer to objective functions in general. In this case, it denotes a relaxation of a hard constraint. See Section 2.1.2.

2.2. Solution strategies 2.2.2.2

23

Heuristic algorithms and heuristic approaches

The previous subsection describes heuristic functions. They may be used to help an exact search algorithm find an optimal solution more quickly. Heuristic algorithms, on the other hand, are never exact. Definition 2.10. Given an instance of optimization problem with (S, f ), a heuristic algorithm is a method returning a feasible solution s ∈ S without guaranteeing optimality of s. An example of a heuristic algorithm is the ‘hill climber’ (Alg. 2.1). Its method of choosing a neighbor is to always replace the current solution with the neighboring solution that has the highest objective value, unless that value is smaller than the objective value of the current solution. In that case, the search process stops and the last solution is returned. Fig. 2.5 shows that climbing uphill from a random point could lead to getting stuck in a local optimum. A hill climber algorithm will strive for a solution that is as good as locally possible, but it does not guarantee global optimality. A heuristic local search algorithm works in close collaboration with the neighborhood and the objective function. A specific neighborhood function might propose an alternative solution in a manner that is likely to increase the objective value. Then, the overall performance of the resulting schedule is calculated by the objective function, which, as we have seen, may include heuristic elements. Lastly, the heuristic algorithm applied may or may not accept the new schedule as a replacement of the current schedule. This only goes to show that heuristic optimization involves much fine tuning on the side of the algorithm, the neighborhood function, and the objective function (Coy et al., 2001). Example 2.7. Consider another Traveling Salesman Problem, for which an initial solution is given in this picture:

A possible neighborhood function might try two swap two cities in the tour such that the number of crossing lines is decreased (the optimal solution can have no crossing lines). A possible objective function just measures the total distance traveled - in which case we are dealing with a minimization problem. A possible heuristic algorithm may accept the alternative solution which objective value is the lowest of all alternatives, including the current solution.

Scheduling and heuristics

24

An alternative neighborhood function may just swap two cities without looking for decreasing crossings - which yields a larger neighborhood. An alternative objective function may take the number of crossings into account as well, driving the search process to a cross-free solution. An alternative heuristic algorithm may choose a random solution whose objective value is better than the current, but not necessarily the best. This example shows that experimenting on different strategies for neighborhood, objective function, and algorithm, involves a large part of the engineers work. Heuristic functions in the strict sense may be applied to any kind of algorithm ranging from exact to heuristic. Therefore, using ‘heuristics’ does not strictly imply aiming for solutions that are not exact. Nevertheless, use of the term heuristics, especially within the field of dynamic scheduling, usually refers to non-exact problem solvers, involving both heuristic functions and heuristic algorithms. In this dissertation, we will use the term heuristics in this manner from now on.

2.2.3

Metaheuristics

Section 2.2.2 shows how local search heuristics cannot give a guarantee for the optimality of a solution. In fact, the simple, yet often used, hill climber algorithm is prone to get stuck in local optima, depending on the shape of the ‘fitness landscape’. In trying to escape local optima a variety of more generic heuristic approaches have seen the light. These approaches have been gathered under the term metaheuristics. Definition 2.11. A metaheuristic is a heuristic local search algorithm that incorporates two qualities: diversification and intensification. Diversification drives the algorithm to escape local optima by exploring a larger, currently unknown, area of the search space, or by exploring solutions of lower quality than the current solution. Intensification is the inverse of diversification, driving the algorithm towards local optimality in a smaller area of the search space. Fig. 2.6 shows that diversification aims at increasing the search area by both distance from the current solution, as well as allowing ‘downhill’ movement to a certain extent. Intensification narrows the search space again, and aims for up-hill movements. Diversification and intensification need not necessarily follow each other in a 2-phased manner, but can take place concurrently or repeatedly. Blum and Roli (2003) give an excellent overview of metaheuristics, as well as their history and properties. Various differing definitions of metaheuristics are discussed, hinting at efficiency (Voss et al., 1999), guiding low-level specific heuristics, escaping local optima, and using randomness in a biased, intelligent form (Stützle, 1998). There is no consensus on a definition of the term metaheuristics (Blum and

2.2. Solution strategies

25

Figure 2.6: Diversification: allowing movements to solutions of lower quality than the current solution, or to solutions that are further away from the current solution.

Roli, 2003). However, within the metaheuristics research area, Blum and Roli note a general acceptance of the basic properties of diversification and intensification (alternatively: exploration and exploitation). The definition given here is used as a working definition for the rest of this dissertation, based on this general consensus. Definition issues notwithstanding, the research field of metaheuristics is gaining momentum. The next few subsections discuss the most common characteristics of metaheuristic approaches. Deterministic vs. Randomized Definition 2.12. Given the same input and parameters, a randomized metaheuristic may follow different paths in finding a solution during different runs. A deterministic metaheuristic would always follow the exact same path in finding a solution. Randomized approaches are common in metaheuristics. In analogy to biological processes, trial and error, or, randomization, has been introduced to escape local optima and find promising regions in the search space. This randomization can occur on different levels. First, randomization can be used to produce an initial solution for a Local Search approach. Starting a solution from a random spot in the search space rather than using a quite optimal constructive algorithm to get initial solutions, may help in avoiding getting stuck in local optima. Example 2.8. Gomes et al. (1998) discuss Restart strategies, which use the idea of randomized initial solutions continuously: every time the (otherwise standard) hill climber finds a local optimum, the process is restarted from scratch, using a different initial solution. The algorithm remembers the current best local optimum that has been found. A new-found local optimum replaces the current best solution if it outperforms that solution. Second, randomization can be used to determine whether or not a certain alternative

Scheduling and heuristics

26

solution is accepted as the next solution in a neighborhood search. Straightforwardly, the best solution from the neighborhood is picked, with the inherent risk of sticking to local optima (greedy hill climber, Alg. 2.1). Adding randomization to the process leads to slower up-hill climbs, or even downhill movements. When the driving force on the long term is up-hill, chances of finding a better optimum increase. Example 2.9. Simulated Annealing (SA, Kirkpatrick et al. (1983)) is an example of the second case, randomization in the acceptance of a solution. SA is an analogy to the controlled, slowed cooling down of hot metal, thus enabling the crystals to form and prevent defects. SA is an escape strategy to get hill climbers out of local optima. Sometimes it is necessary to go a little bit downhill in order to climb a bigger hill than before. Algoritme 2.3 Simulated Annealing s ← some initial solution best ← s T ← Tmax repeat repeat N ← Neighborhood(s) pick ← PickRandom( N ) f ( pick)− f (s)

T if ( f ( pick) > f (s)) ∨ (e s ← pick end if if f (s) < f (best) then best ← s end if until equilibrium reached T ← UpdateTemperature(T) until stopping criterion met return best

>Random(1)) then

The algorithm allows for going to random solutions in the neighborhood that can have a lower objective value than the current solution. The extent to which these steps back are allowed is determined by a temperature T, which is gradually decreased during the process. In the beginning, when T = Tmax , practically any move will be accepted. When T approaches 0, only uphill moves are accepted. This way, when SA is started, neighboring solutions are almost picked at random with only a slight tendency upwards, whereas at the end the algorithm goes straight uphill, hardly allowing for downhill movements anymore. Third, randomization can be used to shrink the set of neighboring solutions that is

2.2. Solution strategies

27

currently under investigation, when the amount of solutions in the neighborhood is (extremely) large. Example 2.10. Evolutionary Algorithms (EA) are a good example (Holland, 1975; Goldberg, 1989; Eiben and Smith, 2003) of the third case. They are designed to be a computational analogy to the biological (Darwinistic) survival of the fittest theory. Algoritme 2.4 Evolutionary algorithm population ← CreateInitialPopulation() EvaluatePopulation(population) while stopping criterion not met do newPopulation ← ∅ while Size(newPopulation) < populationSize do s1 ← ProportionallySelectIndividual(population) repeat s2 ← ProportionallySelectIndividual(population) until s1 6= s2 newPopulation ← newPopulation∪ CrossoverIndividuals(s1, s2) end while ApplyMutation(newPopulation) EvaluatePopulation(newPopulation) population ← newPopulation end while A population consisting of a fixed number of individuals or chromosomes represent a set of solutions. The fitness value of each individual determines its chance to form offspring. In each iteration, dubbed generation, all individuals are replaced by offspring. In the usual elitist approaches, a few of the best individuals are directly copied into the next generation to prevent good solutions from getting lost. To prevent inbreeding, some form of mutation is applied to the individuals. The general idea is that certain elements of an individual, represented by a multidimensional vector, make up for a relatively fit solution. By combining two of the better individuals, the problem solver hopes to combine the good parts and get an even better solution. Of course, combining just the bad parts is equally well possible, but these individuals will not live for a long time in a survival of the fittest contest. Although the chance for an individual to form offspring is proportional to its fitness, there is always a factor of randomness included. The choice of vector elements that are to be exchanged is done completely at random, usually. Although stochastic in nature, EAs have proven to be good problem solvers in complex cases, capable of tasks like combinatorial optimization, machine learning, and parameter setting problems.

Scheduling and heuristics

28

An often used example of evolutionary algorithms has chromosomes that are strings of 0’s and 1’s. The objective is to find a string with as much 1’s as possible. The fitness of each individual is calculated by counting the number of 1’s. Consider an initial population of five solutions: Individual 1 2 3 4 5

Chromosome 101100101001001 000000011011011 100110000000100 111011110100110 001000110100010

Fitness 7 6 4 10 5

The chromosome selector may choose chromosome 2 and 4 to form offspring. A single crossover point is chosen at random, after the 6th element: Individual 2 4 child 1 child 2

Chromosome 000000 | 011011011 111011 | 110100110 000000 | 11010010 0 10 1011 | 1 11011011

Fitness 6 10 4 11

A few mutations have been applied at random - the italic characters were flipped. The result is that child 1 has a worse fitness than both of the original chromosomes, but child 2 outperforms all previously known chromosomes. Continuing in this manner, a new population is formed. Depending on the settings, some chromosomes may be directly copied into the new population. In an elitist approach, the best chromosome (i.e., chromosome 4) is always directly copied into the new population. Some metaheuristics make use of randomization in all phases of the process. Evolutionary algorithms make extensive use of randomization in all three of the described phases. Metaheuristics can also have a deterministic approach: given a fitness landscape and a starting solution, the algorithm would always follow the same steps towards the same optimum. Tabu search, which is described further on, is an example of such a deterministic approach. Deterministic approaches are far less common in metaheuristics. Trajectory approach vs. Population based Definition 2.13. A trajectory approach metaheuristic follows a single path from start to final solution. In a population based metaheuristic, a population of multiple solutions, or multiple identical problem solvers, coexist. The elements of this population will

2.2. Solution strategies

29

either independently search for a solution, or cooperate in finding a solution. Most algorithms described in the previous sections use the trajectory approach. The path followed could be in a search tree, leading from an empty to a complete solution, or it could be a walk over the surface of a fitness landscape, traveling a path of neighboring solutions. In population based approaches, the population can take shape in various forms, including multiple runs of the same algorithm, solutions that learn from each other, and relatively simple problem solvers that work together to solve a problem. Evolutionary algorithms are one of the most well-known population based methods: multiple solutions compete for survival and create offspring pairwise. Furthermore, in the already described Restart Strategies, coupled with a deterministic trajectory approach, multiple search processes are run parallelly or serially, each time from a different starting position. This makes restart strategies a hybrid approach, in being both trajectory based and population based. Example 2.11. Next to evolutionary algorithms, another popular example of a population based approach is Ant Colony Optimization (ACO), a constructive approach designed in analogy to foraging ants that want to find the shortest route from the colony to food (Dorigo and Stützle, 2002). When food is found, ants walk back to the colony as quickly as possible, leaving a pheromone trail behind. Other ants are likely to follow the pheromone route, thereby reinforcing it. When shorter routes are found, more ants will walk that route on average, since it costs less time than walking a detour. The pheromone trail on all paths slowly evaporates. This will lead to detours being chosen less and less, and shortest routes being preferred. Algoritme 2.5 Ant colony optimization while stopping criterion not met do GenerateSolutions() UpdatePheromoneTrails() ApplyEvaporation() end while In the metaheuristic variant, artificial computerized ants, agents, ‘walk’ through the construction tree of a problem, from root to leaf. At each node, pheromone trails on the branches in front of the ant will seduce the agent to follow that route with a probability proportional to the pheromone strength. When all agents have constructed a complete solution, the solutions are compared. The better the solution, the more pheromone is distributed along the edges of the search tree path that constituted this solution. Pheromone on all edges will also evaporate according to a predefined formula. A priori knowledge can be added to the system in some form of ‘fixed pheromone’ levels. The idea behind this kind of

Scheduling and heuristics

30

swarming approach is that individually relatively ‘dumb’ agents construct a powerful problem solving team.

Experience

Any tree-search algorithm has to keep track of already visited nodes. As such, nearly all metaheuristics make use of memory in some sense. However, in some metaheuristics memory plays an important role. The memory may be used to remember recent solutions, good or bad solution elements, or preferable or undesirable solution space areas. This memory can be used to enhance the search process by preferring or avoiding certain parts of the solution space.

Example 2.12. Tabu Search (TS) is a typical example of a metaheuristic in which memory or experience plays an important role (Glover and Laguna, 1997). Algoritme 2.6 Tabu Search tabuList ← emptyset while stopping criterion not met do N ← GetNeighborhood(currentSolution) N ← N \tabuList newSolution ← ChooseSolution(N) if Size(tabuList) = tabu tenure then RemoveOldest(tabuList) end if tabuList ← tabuList ∪ newSolution end while TS is a popular trajectory-based metaheuristic where visited solutions are stored in a tabu-list of certain length (the tabu tenure). This length defines the amount of ‘short term memory’ in use. Solutions in the tabu list cannot be revisited. This may force the neighborhood searcher to go downhill. Extensions of this algorithm may have mechanisms in place to handle dead-end situations, when there are no solutions in the neighborhood left. Another extension is to store solution-features in the tabu-list, instead of complete solutions. Thereby, some kind of ‘long term memory’ could be created, that enables guidance of the search process in a more abstract manner.

2.3. Hybrid heuristics

2.3

31

Hybrid heuristics

As of yet, no single best heuristic approach is found for all possible problems. A certain approach, therefore, may perform well in one situation, but could perform sub-average on others. A problem may be of such type that more than one algorithm is suited to solve the problem. Furthermore, the problem may call for different problem solvers over the course of the problem solving process. A typical example of this stems from the intensification/diversification distinction made in definition 2.11: a greedy hill climber is good at intensification, but it performs badly on diversification since no downhill movements are allowed, and no mechanisms are in place to explore a larger area of the search space. On the other hand, evolutionary algorithms are mainly used when diversification is important, but their intensification qualities are weak since their innate random qualities make it difficult to converge to a local optimum. These observations call for cooperation between existing approaches, rather than inventing new ones. This cooperation is the topic of interest of Hybrid (Meta)heuristics. Definition 2.14. An algorithmic part is a building block of an algorithmic approach, such as a neighborhood function or an objective function. Definition 2.15. A hybrid metaheuristic approach, or hybrid heuristic, is a method in which (1) two or more algorithms, or, (2) two or more algorithmic parts of the same type, are used concurrently. Hybridization can be done in many ways. The next few subsections outline the most important aspects related to hybridization, exemplifying each possibility from literature. The aspects are primarily taken from Talbi’s taxonomy of hybrid metaheuristics (Talbi, 2002).

2.3.1

Low level vs. High level integration

The various algorithms that make up a hybrid system can be connected on different levels. Definition 2.16. In a low level integration approach, the hybridization is done on the level of algorithmic parts. Conversely, in high level integration, different algorithms are self-contained, and do not directly influence each other’s working. Low level integration means that the algorithms work in an interleaved manner: specific parts of an algorithm are replaced by a (complete) other algorithm, or by parts from those other algorithms.

32

Scheduling and heuristics Example 2.13. As an example of low level integration hybrids, Ulder et al. (1991) describe methods to solve the Traveling Salesman Problem (TSP). They use an evolutionary algorithm to solve the problem. However, in a normal EA, mutation is carried out in completely randomized fashion. In their low level integration setup, however, the standard mutation procedure is replaced by a specialized operator that closely resembles the greedy hill climber local search approach. This speeds up finding an optimum in the otherwise rude performance of EAs. Thus, the resulting algorithm is not an EA in the classic sense. Such a hybrid approach aims at combining strong diversification qualities (EA) with strong intensification qualities (Hill Climber).

In high level integration, each algorithmic approach works on its own in delivering complete solutions. Those complete solutions may become input for another algorithm in a stove-pipe manner, or they may compete with solutions brought forward by other algorithms. An example of the latter possibility is formed by the Restart Strategies discussed in Section 2.2.3. Example 2.14. An example of a high level integration approach in which solutions from one algorithm are used as input for another algorithm is given by Nguyen et al. (2007). They describe a hybridization in which a constructive approach is used to seed an evolutionary algorithm population. Often, the initial EA population is filled with randomly created solutions, that may not even be feasible. Seeding a population means that already quite fit solutions created by another heuristic approach are used as seeds. For the EA to function properly, it is important that the seeds are different. Otherwise, crossover makes little sense as it would not produce alternative solutions. Therefore, deterministic approaches cannot be used to seed an EA. The EA is expected to ‘grow’ better solutions out of these seeds. The advantage of harvesting the diverse qualities of two (or more) algorithms seems obvious. However, as soon as algorithms are set to cooperate, they have an influence on each other’s working. In the two examples given, evolutionary algorithms were enhanced by changing the mutation part of the algorithm to greedy hill climber, or by seeding the algorithm with a constructive heuristic. Both approaches lead to populations that are very fit, in the first case by post-processing, in the last case by pre-processing. This will certainly speed up convergence. However, for an EA it is more difficult to do exploration, when the population is very fit (Eiben and Smith, 2003). This is due to the fact that the crossover operator, which is crucial for the EA-effect, will produce solutions that are likely (far) less fit than solutions in the current population. They will, therefore, likely be abandoned when forming a new

2.3. Hybrid heuristics

33

generation. This, in turn, makes it more difficult than usual for the EA to escape local optima, which was the idea behind using EAs in the first place. This shows that blindly putting algorithms together whose workings are considered complementary will not automatically produce desired results. In the first EA case (changing mutation to greedy hill climber), a promising solution to this problem is to only use hill climber in the objective function: After cross-over, a copy of the newly created solution is improved by hill climbing, after which the objective function is applied to the optimized solution. The original solution is (potentially) used in the next population of chromosomes. In doing so, the somewhat ‘rude’ shape of the chromosomes are stored in the population, but their potential (i.e., the objective value after applying greedy hill climber) is used in the selective ranking mechanisms (Hinton and Nowlan, 1987). Obviously, the final solution returned is enhanced by greedy local search.

2.3.2

Relay vs. Teamwork

Definition 2.17. In a relay hybridization, different algorithms or algorithmic parts take turns in the problem solving process, where the output of one process is used as input for another process. This is done in a fixed order. In teamwork settings, this order is not fixed: all algorithms may work on the same input, which may or may not be another algorithm’s output. In relay settings, different algorithms work in a stovepipe manner. It is a popular method when using algorithms that are only well-suited to a specific phase of problem solving. In the example ‘Seeding an evolutionary algorithm’, the relay method was used: a constructive algorithm produces initial solutions for an EA to work on. This is a High Level Relay solution. It is also possible to have a Low Level Relay solution, when an algorithmic part is replaced, or augmented, by another algorithm or algorithmic part. The example ‘Hybridization of evolutionary algorithms and hill climber’ is an illustration of a Low Level Relay hybridization. In teamwork, algorithms do not operate in a strict order, but cooperate in a (quasi-)simultaneous way, to come up with a solution. Example 2.15. An example of a teamwork approach is described by le Bouthillier et al. (2005). They search solutions for a Vehicle Routing Problem with Time Windows (VRPTW) - a problem in which parts of the Traveling Salesman Problem and scheduling are combined. In this study, different heuristics (construction algorithms, tabu search, evolutionary algorithms) are scattered around a warehouse. The algorithms provide complete solutions to the warehouse. In the warehouse, analysis is performed on the solutions: specific solution elements that occur in multiple solutions are labeled as ‘promising’. This can for example be a connec-

Scheduling and heuristics

34

tion between two locations in the VRPTW. These promising bits are sent back to the heuristics in order to improve results. Arguably, a teamwork can only be a High Level hybridization 3 . No clear-cut advice can be given on the choice between relay and teamwork. The advantage of a relay setting is that it is easier to implement, and the inner workings are easier for the engineer to comprehend. Plus, when specific operators are changed within an existing algorithm, such as in the ‘EA and hill climber’ example, it is the only possible hybridization. The advantage of teamwork may be that it is flexible: multiple algorithms can be scattered around a solution warehouse, new ones can easily be added, or algorithms can be taken out, even during run-time. However, the choice of algorithms still has to be made, and the processing time given to each algorithm in a single-processor setup still has to be decided. This leads to an extra complexity layer for the engineer to deal with. Furthermore, it is difficult to assess the success of the system as a whole: which algorithms contribute greatly to the final solution? And in what cooperation?

2.3.3

Homogeneous vs. Heterogeneous

Definition 2.18. Homogeneous hybrids apply only identical algorithms or algorithmic parts. In Heterogeneous hybridizations, different algorithms or algorithmic parts are applied. Homogeneous hybrids do not so much exploit the combination of strong points of various algorithms, but increase performance by performing similar tasks in parallel instead of sequentially, decentralizing the problem solving task. Sometimes centralized problem solving is not possible as the problem involves multiple locations and slow communication lines or even restrictions on sharing (privacy sensitive) information to a centralized solver (Lau et al., 2006). In other approaches, cutting up the problem into smaller sized parts is a means of dealing with complexity. Processing the smaller parts in parallel will always be faster than doing so sequentially. Example 2.16. Sprave (1999) has described an approach where multiple EAs run in parallel on islands, an example of a homogeneous hybridization. The EAs ‘exchange ideas’ every now and then, by sending their best chromosomes out, to 3 According to Talbi (2002), it is also possible to have a Low Level Teamwork approach. In his article, this is illustrated by an example in which parts of an evolutionary algorithm are augmented by a greedy hill climber. However, the order in which this happens is fixed, and the algorithmic approach works in a stovepipe manner, thereby rendering it a relay setting, not a teamwork setting. The arrangement in which algorithmic parts have their place define an algorithm. If different algorithmic parts would work in a teamwork fashion, this would have to be allowed and regulated by the containing algorithm. In turn, this would make the teamwork-setting part of the algorithmic setup, effectively making it a Low Level Relay approach.

2.3. Hybrid heuristics

35

be injected into the populations of neighboring EAs. This way, multiple populations evolve simultaneously, thereby possibly converging to different spots. The exchange of chromosomes provides the individual EAs with fresh input. Most hybrids, however, are heterogeneous4 . The problem solver consists of multiple types of algorithms or algorithmic parts. The algorithms in a heterogeneous setup can differ to various extents, as the previous examples show. Apart from the Island EA example, all examples used in this section are heterogeneous approaches.

2.3.4

Global vs. Partial

Definition 2.19. In a global approach, each algorithm tries to solve the same, complete problem. In a partial approach, each algorithm works on a partial problem, producing partial solutions. The global approach is the most straightforward form of hybridizing. In the partial approach, the problem is divided into chunks, which are then solved. Example 2.17. Taillard (1993) describes an approach where large Vehicle Routing Problems (VRP - of which VRPTW is a more constrained variant) are solved. A truck has to deliver goods from a depot to a number of cities. The amount of goods the truck can carry is limited, so it has to make multiple rounds. In this approach, the number of cities is subdivided by an algorithm specially created for that purpose, after which a tabu search approach solves the remaining routing problem for each specific round. The advantage of a partial setting could be the fact that dedicated algorithms may provide better solutions to a smaller, or more specific, problem. However, the question of how to divide the problem into chunks first, and concatenating the partial solutions in the end, adds a new layer of complexity to the problem solving process. This is, analogous to what was said on homogeneous vs. heterogeneous setups, again a topic of study in itself - which is also covered by researchers working on parallel & distributed systems.

2.3.5

Specialist vs. General

Definition 2.20. In a specialist approach, algorithms perform different types of problem solving in cooperation. In a general approach, all algorithms work on the same 4 The fact that homogeneous systems are mentioned in a taxonomy of hybrid heuristics, suggests that parallel processing is a subset of hybrid systems. In contrast to this, Crainic and Toulouse (2003) classify hybrid systems under the hood of parallel systems. However, the latter systems are a broad topic of research for themselves and widely acknowledged under the hood of ‘parallel & distributed systems’. Therefore, what in the remainder of this dissertation is called ‘hybrid’, refers only to those systems that are heterogeneous in nature.

Scheduling and heuristics

36 type of problem.

Algorithms can be applied for a variety of problems. In complex problems, different types of problems may have to be solved. For example, a problem may be so large that in order to solve it efficiently, it first has to be divided in chunks. The problem chunks are then sent to the various problem solvers, whose results are later concatenated to form a complete solution. The problems of (1) subdividing the problem into chunks, (2) solving the problem chunks, and (3) concatenating the results are of different type. Only step 2 relates to the problem solving as we have seen it before. In 1 and 3, special operations are performed that are of different nature. We have seen this type of problem solving previously under “Partial vs. Global” a partial problem is always a specialist approach. This lies in the fact that multiple algorithms operate on a different kind of problem: there are algorithms that have to do the division of the problem, and the concatenation of the partial solutions (1 and 3), and those that solve the actual problem (2). Example 2.18. Another example of a specialist approach is given in Shahookar and Mazumder (1990). They use an evolutionary algorithm for an optimization problem. Some parameter settings of this algorithm - population size, inversion rate and mutation rate - are set by a second EA. The objective function of this second EA consists of running the first EA with a certain chromosome’s parameter settings - and take the objective value of the best result produced using these settings. In contrast to this specialist approach, most hybrid systems use a general approach, where each of the constituting algorithms works on (a part of) the actual problem. All examples from this section, apart from the parameter-setting example, follow the general approach. We have seen that heuristics are used when problems are difficult to solve, and hybrids are used when straightforward heuristics still fall short. The added layer of complexity is the price to be paid. When one heuristic is controlling another heuristic, we have encountered a problem of squared complexity. For practical applications, limited time is usually an essential factor in the design considerations. Therefore, specialist approaches are not likely to meet the demands.

2.3.6

Static vs. Adaptive

Definition 2.21. In an adaptive hybridization, the mixture of algorithms and algorithmic parts, as well as the processing capacity given to each algorithm, can be varied during the problem solving process. In a static hybridization, this mixture and time allocation is fixed at compile-time.

2.3. Hybrid heuristics

37

Most heuristics run until some stopping criterion has been met. Some heuristics can be asked to produce their current best solution at any time during the search process (anytime algorithms). In a hybrid setting, those timings or stopping criteria can be tuned to allocate different amounts of processing power to the various algorithms running. In a multi-processor system or networked set of systems, this may not be a problem as each algorithm has a processor of its own. However, in implementations meant for a single processor, the percentage of time available for each algorithm can range from 0 to 100%. When all stopping criteria are fixed, and the amount of attention paid to each algorithm is known at compile-time, the hybridization is said to be static. Most of the cases described in the literature, and all of the examples referenced in the previous subsections, are static approaches. Even the warehouse example from Section 2.3.2 can be considered static, since the attention that is given to each of the algorithms is not dynamically altered during run-time: each algorithm simply runs as much as possible in his allocated processing time. When multiple algorithms coexist, a portfolio of algorithms is created. In an adaptive setting, algorithms can be chosen from this portfolio to run for a while, or they can be chosen to be discarded for a while. The choice of algorithms to be used and the time allocated to each of them are parameters that are changed at run time.

Example 2.19. Burke c.s. (Burke et al., 2003a,b; Qu and Burke, 2005) have developed systems called hyperheuristics. In these systems, the coordination of which algorithms are used for a certain problem is done by another heuristic - tabu search. The problem solver itself is hybrid in a stovepipe sense: different heuristic approaches which are contained in the portfolio are tried on a trial-and-error basis. When a heuristic approach improves the current solution, it receives a higher ranking in the portfolio, and vice versa. A heuristic approach is run for one iteration, after which the coordination algorithm chooses the heuristic approach for the next step. The system as a whole is also hybrid in a specialist sense: Tabu search performs the coordination of the approaches that actually solve the problem, but it does not solve the problem itself. Different algorithms do not actually cooperate, as only one algorithm runs at a time, and there is no knowledge available on the advantage of the combination of different algorithms. For instance, two algorithms may not rank high in the portfolio, but might very well make a winner when they would iteratively take turns, and enhance each other’s outcomes.

Such an adaptive approach adds a new layer of complexity to the hybridization. The extent to which a hybrid system is adaptive varies, and all of the adaptive systems currently found in literature still only have a limited amount of adaptivity.

Scheduling and heuristics

38

2.4

Discussion

This chapter introduces the static scheduling problem and solutions that may be applied to them. We have seen that for many instances, an exact problem solver - that always produces the optimal result - is not available. For those problems, the use of heuristics is discussed. Heuristics aim at finding a good solution, without giving any guarantee on the performance of the end result. We have seen that simple constructive or local search heuristics are prone to get stuck in local optima: solutions that are better than slightly different solutions, but that may not come near the performance of the global optimum. Metaheuristics are an attempt to solve this problem. Metaheuristics combine exploration and exploitation qualities. Exploration makes them escape local optima, whereas exploitation helps them find an optimum in a promising region of the search space. However, as it appears to be difficult to have exploration and exploitation in well-balanced fashion, most metaheuristics focus on one of those two virtues. This has led to the creation of hybrids: approaches in which two or more algorithms are set to cooperate, hopefully complementing each other on the other’s weak spots. However, using metaheuristics and hybrids has some disadvantages: 1. Added algorithmic complexity. Most metaheuristics cannot be run straightforwardly, but all kinds of parameters have to be set. For example, in the case of evolutionary algorithms, the population size, the crossover method, the mutation rate, and the ranking mechanism are some of the choices that have to be made before the algorithm can be run. 2. Added architectural complexity. Hybrids mix algorithms or algorithmic parts in the hope of creating a ‘whole’ that performs better than the ‘sum of parts’. Nevertheless, the way in which the cooperation takes place, the amount of attention given to each hybrid element, the yet-unknown influence that hybrid elements have on each other, are among the problems the engineer faces when creating a hybrid problem solver. 3. Shifting attention to the algorithm. All metaheuristics and most hybrids are based on the local search paradigm. Within local search, the algorithm is only one part of a triangle that consists of algorithm, a neighborhood function and an objective function. Careful consideration of all three aspects is vital to create a well-performing solution provider. However, literature describing metaheuristics and, even more, hybrids, have a tendency towards focusing on the algorithm. This might lead to an overly complex problem solver, which could have been avoided by paying more attention to neighborhood function and objective function.

3 Dynamic Scheduling In Chapter 2, we have seen aspects related to scheduling in general. In this chapter, dynamic scheduling is discussed. In dynamic scheduling, the scheduling problem changes over time. In Section 3.1, we see that the nature of these changes, and the severity of the disruptions vary greatly. The section ends with a number of challenges that have to be addressed when creating dynamic problem solvers. Various techniques to cope with dynamic scheduling problems are discussed in Section 3.2. Section 3.3 closes the chapter with a discussion.

3.1

Dynamic aspects

A large portion of scheduling problems can be discussed in terms that are introduced in Chapter 2. However, in the remaining part of this dissertation, we will deal with a particular branch of scheduling, dynamic scheduling. Within the literature, there is no consensus on a definition of dynamic scheduling, or of a common taxonomy to characterize such problems Ouelhadj and Petrovic (2009); Branke and Mattfeld (2005). Even more, terms denoting the same concepts are different. Dynamic scheduling, for example, may as well be referred to as non-deterministic scheduling, or stochastic scheduling (Branke and Mattfeld, 2005). The following definition is therefore a generic working definition: Definition 3.1. A scheduling problem is dynamic if changes in the problem properties or in the problem environment cause a previously produced schedule to be invalidated. The working definition given here applies to all kinds of dynamicity, even if it is very low. The nature and severity of the disruptions in dynamic problem solving

Dynamic Scheduling

40

do indeed vary greatly among dynamic scheduling problems. In this section, the different aspects that play a role in dynamic scheduling are discussed, in contrast to static scheduling.

3.1.1

Direct change events

Within a dynamic scheduling environment, various change aspects can play a role. Consider the following elaborate example: Example 3.1. In a city, four taxis T1 ..T4 are currently active. From 13:30-16:30, the operations ran normally. During this period, at least one of the taxis has always been active, sometimes even all four taxis. However, no situations occurred in which a passenger has been told to wait due to the unavailability of a taxi. At 16:45, the afternoon rush-hour begins, during which it is allowed to carry multiple passengers in a taxi at the same time to increase throughput. At 17:00, none of the taxis is idle. At this time, a passenger begins waiting at the taxi stop in front of the main station, after which more passengers queue there. At 17:05, taxi T1 is busy driving a passenger to the main station, but is stuck in a traffic jam caused by an accident that just happened on the way there. At 17:10, a new taxi T5 is added to the system, to cope with increased travel demands during the afternoon rush-hour. At 17:15, taxi T2 , who has just delivered a passenger, experiences a mechanical failure and has to be taken back to the garage. At 17:20, a passenger driving in taxi T3, who does not know his destination’s address, but said he would guide the driver to it himself, gets lost in the maze of small streets in the city center, increasing his trip duration. At 17:25, the fog has become so thick that driving becomes more difficult, and dusk sets in. Between 17:00 and 19:30, all taxis are always busy driving passengers around, or driving to passenger pick-up locations. On average, new passengers call for a taxi every 2.5 minutes. The scheduler controls which taxis are doing which tasks, and makes a schedule accordingly. This schedule is, on average, 30 minutes long until all tasks are finished. From 19:30 until 23:00, the problem relaxes so that passengers, again, only have to wait for as long as it takes a taxi to reach them. After 24:00, a new passenger comes in every 30 minutes, on average. The scheduler makes a schedule that runs for at most 15 minutes, until all tasks are finished.

Task changes In the example, we see many task changes: at 17:00, new passengers are queueing at the station, at 17:05, an estimated task duration has to be revised due to the traffic jam, at 17:15, a passenger is delivered at his destination, and at 17:20, a passenger

3.1. Dynamic aspects

41

loses his way, thereby increasing his task duration. Task changes are the most obvious cause for schedule disruption (Vieira et al., 2003; Ouelhadj and Petrovic, 2009). During the execution of a schedule, new tasks may arrive that have to be fit into a schedule. Tasks currently scheduled may be canceled prior to execution. More subtly, the parameters of the jobs themselves may change: due dates, earliest starting times, task priority, task durations. Most of the literature used in this dissertation on the topic of dynamic scheduling primarily deals with the problem of changing tasks (Bianco et al., 2006; Ye and Zhang, 2007; Muñoz et al., 2008; Wang et al., 2009; Nikovski and Brand, 2003a; Kim et al., 1998; Goldwasser and Kerbikov, 2003; Branke and Mattfeld, 2005; Holthaus and Rajendran, 1997, 2002; Rajendran and Holthaus, 1999).

Resource changes The example also shows resource changes: At 17:10, a taxi is added to the system, and shortly afterwards, at 17:15, a taxi is taken out due to failure. More generally, there may be shortage of materials causing task delay, as well as materials becoming available enabling tasks to be executed earlier. Machines on which tasks had to be carried out may be added to the system, or may break down. In fact, apart from job changes, machine breakdowns are one of the most popular benchmark problems in dynamic scheduling literature (Mehta and Uzsoy, 1999; Barlow and Smith, 2008; Bidot et al., 2009). Furthermore, the more subtle parameters may be subject to change. Production resources may work slower or faster than expected, especially when humans are involved.

Constraints, optimality criteria Other than the dynamicity that originates inside the problem environment, outside influences may play a role as well. In the taxi driver example, we have seen that the day-to-day pattern of relaxed and busy times has resulted in a policy change that occurred at 16:45, when the taxis are allowed to carry multiple independent passengers. This would violate the normal constraint that no more than one passenger (group) travels together in a taxi. Obviously, such a change may lead to revised schedules. Not visible in the example, the rules that decide on the optimality of a schedule may change as well, which in turn could lead to revised schedule. For example, during the rush hour, the scheduler might aim for high throughput, whereas during less busy times, he might choose to optimize fuel consumption.

Dynamic Scheduling

42

3.1.2

Second-order dynamicity

In the example, we see that some changes are not directly related to tasks or resources, but operate on a higher, more long-term level. Although this type of dynamicity is acknowledged in the literature, it is, to the best of my knowledge, not dealt with as such in contrast with direct change events. I therefore propose the following qualitative definition: Definition 3.2. Second-order dynamicity: changes in the level of dynamicity and in the problem characteristics change the nature of the dynamic scheduling problem, rather than the actual problem as it currently presents itself. Second-order dynamicity is an aspect orthogonal to the aspects discussed in Section 3.1.1. Two major aspects playing a role in second-order dynamicity are level of dynamicity and changes in character. Level of dynamicity In the example, we have seen that the passenger intensity changed between the 13:30-16:30 period and the afternoon rush hour (17:00-19:30). Before that, no passenger had to wait for longer than the time needed for a taxi to arrive. After 17:00, passengers also have to wait due to prior engagements of the taxis still being carried out. From 19:30-23:00, the relaxed situation re-occurs. After 24:00, there is so little traffic, that the operating taxis are idle most of the time. (Quasi) static current time

planning horizon

change event

Lowly dynamic, disruptions

(Highly) dynamic

Figure 3.1: Levels of dynamicity

What we see here is that the level of dynamicity changes. The time interval between change events (Fig. 3.1) is an important aspect of dynamic scheduling problems. If this interval is larger than the time period for which a schedule is to be made, the problem falls outside the range of dynamic scheduling problems. In such a case, the problem can be seen as a series of static problems that can be solved individually and independently. This is true for the taxi scheduling problem after 24:00. As soon as the time between disruptions drops below the scheduling horizon, the problem

3.1. Dynamic aspects

43

becomes dynamic. This has been true for anytime between 13:30 and 23:00. If the number of change events within the scheduling environment is large, the problem could be called ‘highly dynamic’. However, such notions are only qualitative, and no formula can be given for them. The circumstances which are considered highly dynamic strongly depend on the actual problem at hand. In the taxi driver example, the situation between 17:00 and 19:30 can be considered highly dynamic, with a change event occurring every 2.5 minutes, and a scheduling horizon of 30 minutes. Changes in character The character of the problem may change over time, which may be reflected in all types of direct change events discussed in Section 3.1.1. We have seen the level of dynamicity change, but the task characteristics may change as well. For example, during the day, people more often travel between office locations, whereas at night, travellers are more confined to the city center, travelling between hotels and restaurants. We have already seen a constraint change due to second-order dynamicity (at 16:45, when passengers have to accept others on the same ride). The resources (taxis, taxi drivers) may change over time, possibly with different resource characteristics. Lastly, the environment may change: At 17:20, fog and darkness increase to the point that it slows down traffic. This leads to longer durations of all tasks, and thereby a lower throughput of the system as a whole, and an increased buffer of passengers waiting to be picked up. Character changes do not result from direct changes within the system, but influence the behavior of the system as a whole. Analogous to levels of dynamicity, character changes are a source of second-order dynamicity.

3.1.3

Issues and challenges

In this section, we have seen how direct changes within the scheduling system lead to dynamicity. Tasks, task properties, resources, constraints and optimality criteria may alter the scheduling problem as it presents itself. Furthermore, second-order dynamicity may be induced when the level of dynamicity or the character changes. This leads to important changes in how the scheduling problem is perceived and should be dealt with: 1. In dynamic scheduling literature, the change intervals are usually small, requiring constant scheduling attention. Short change intervals may pose constraints on the scheduler itself: Whereas in static scheduling problems the scheduler has virtually infinite time to come up with a schedule, in dynamic scheduling this processing time is very much restricted. Often, a new solution has to be found within a second or even millisecond scale (Bianco et al., 2006).

44

Dynamic Scheduling

2. Objective functions - that measure how well optimality criteria are met - have a different meaning in dynamic scheduling than in static scheduling. Normally, an objective function provides an objective value, a performance indicator for a given solution. This value is valid only under the assumption that the problem does not change, and that the system behaves as expected. In dynamic scheduling, the scheduling problem changes during the execution of a schedule (in the example given, this happens already after 2.5 minutes into a 30minute schedule). Therefore, the schedule will have to be modified, making the old schedule obsolete. The expected performance of that original schedule was never met, since it will never be completely executed. Therefore, what seems optimal at a certain point in time, may devaluate in the near future and become sub-optimal. 3. A human or automated scheduler may be well-prepared for certain specific scheduling situations. However, second-order changes may change the nature of the problem to such an extent that the scheduler can no longer effectively deal with them (Wolpert and Macready, 1997). 4. If schedules are constantly changed, due to direct and second-order changes, the resources that are used may have to constantly switch tasks. Especially in the case of human operator, this may lead to ‘shopfloor nervousness’ (Vieira et al., 2003). As a result, static scheduling theory and practice would fall short when it comes to dynamic scheduling, and literature shows that there is limited overlap between static and dynamic scheduling (MacCarthy and Liu, 1993; Shukla and Chen, 1996). In view of the two mentioned problems, a number of challenges should be addressed in order to move from static to dynamic scheduling: 1. Since the processing time is so limited, to what extent are the ‘usual’ methods for static scheduling still usable? Are quicker techniques available to solve dynamic problems? 2. How can an objective value be a real estimation of a solution’s value, rather than a short-lived estimation that is based on a static assumption? 3. How to adapt the scheduler to suit the scheduling problem in the case of second-order changes? 4. Constantly revised schedules due to direct and second-order changes may have an adverse affect on the efficient execution of tasks - how can this ‘schedule nervousness’ be dealt with?

3.2. Solution approaches for dynamic scheduling

3.2

45

Solution approaches for dynamic scheduling

The previous section states a number of challenges. This section discusses those challenges in the same order. In Subsection 3.2.1, the two generic methods for dynamic scheduling are introduced. Subsection 3.2.2 discusses anticipation methods, to deal with future change events. Adaptivity to second-order changes is discussed in Subsection 3.2.3. Lastly, reduction of nervousness is discussed in Subsection 3.2.4.

3.2.1

Different problem solving modes

Actual dynamic scheduling takes place in one of two basic forms: 1. In the first, complete schedules are created, just like with static scheduling. An important added service constraint is that the schedule usually has to be created within a short time span. This scheduling happens ‘off-line’ - hence the name off-line scheduling. This schedule is applied ‘on-line’, and whenever a change occurs, the original schedule is repaired (schedule repair, Section 3.2.1.1) or completely renewed (complete rescheduling, Section 3.2.1.2). 2. The other basic form is on-line scheduling. In this case, an instant decision is made each time some change occurs in the on-line world, such as a machine becoming available after a task has been carried out, or any other change event described previously. These ad hoc decisions do not lead to a complete schedule, but rather govern the system as it goes. This form is called ad hoc scheduling, it is described in Section 3.2.1.3. 3.2.1.1

Schedule repair

Off-line dynamic scheduling is based on the principles of static scheduling, loosely stated: given the problem parameters, create a complete schedule that satisfies the constraints and the objective function as best as possible. Definition 3.3. A schedule repair approach reacts to a change event by adapting the active schedule to accommodate the change. Schedule repair deals with problems where disruptions typically occur on a lessfrequent basis, or have a marginal effect on the whole of the operations. Given the example from Section 3.1, schedule repair could well be applied between 13:30 and 16:30 and from 19:30 to 23:00: Example 3.2. Consider the same situation as the example in Section 3.1. It is 15:00, T1 is delivering a passenger from the main station to location A, after which it is to go back to the main station. T2 is driving from location B, where it has just

Dynamic Scheduling

46

delivered a passenger, to location C, where a passenger is to be picked up. T3 and T4 are waiting for new passengers at the station. At 15:01, a call comes in from a new passenger who wants to go from location D to location E. The scheduler notices that D is close to location B, where T2 just left, and E is close to location C, where a passenger is waiting to be picked up by T2 . Therefore, T2 is rerouted to D, to pick up the new passenger and deliver him to E, after which it is to bring the waiting passenger from C to the main station. The other taxis hear nothing of the changes, and continue according to the original plan. In the case of schedule repair, an additional optimality criterion may be applied that penalizes scheduling options that lie far from the original schedule (Abbink et al., 2009). Schedule repair is an often chosen method in the area where a change event is typically seen as a disruption, an anomaly - something that should not have occurred in the first place. Machine breakdowns and lateness are typical examples of such anomalies (Bidot et al., 2009). Furthermore, schedule repair is applied when creating a new schedule is infeasible, for example because of the large cost involved. Local schedule repair has the advantage of being quick when compared to creating a completely new schedule. However, the risk exists that the repaired schedule has a lower performance than what would have been achievable using a newly created schedule. 3.2.1.2

Full rescheduling

Apart from schedule repair as a form of off-line scheduling, the other form is full rescheduling. Definition 3.4. Full rescheduling reacts to a change event by creating a new schedule, which is not necessarily based on the active schedule. In full rescheduling, after a change event occurs, a completely new schedule is created for the scheduling problem as it is currently known. Full rescheduling can be triggered by any change in the scheduling environment. Continuous full rescheduling even goes one step further: running off-line, this approach continuously searches for improvements over the active schedule. When such an improved schedule is found, it may be promoted to active schedule. When a change event occurs, the new optimal schedule might be very different from the active schedule. A local search procedure to find that new optimum could take much time. A specific example of a technique to cope with this problem maintains and updates a population of diverse schedules. Those schedules can be used as starting points on which a local search procedure could improve. This way, the processing time may be significantly decreased when compared to creating new schedules from scratch (Jin and Branke, 2005; Barlow and Smith, 2008; Goh and

3.2. Solution approaches for dynamic scheduling

47

Tan, 2009). (Ouelhadj and Petrovic, 2009) even see schedule repair as a form of full rescheduling. The only difference is the choice of starting point: in full rescheduling, this can be anything, whereas in schedule repair, it is the active schedule. Full rescheduling has the advantage of possibly creating better solutions than schedule repair, but that would probably come at the cost of more processing time. For specific applications, this may not be a problem, or it might be dealt with using some technique. For some applications, complete schedules are required (resulting from either schedule repair or full rescheduling). For example, in a vehicle routing problem with time windows, it is important to have complete schedules, so truck drivers know exactly what goods to load, and in which order to deliver them. Also, the recipients of those goods have to know when they can expect deliveries. 3.2.1.3

Ad hoc scheduling

The other of the two generic dynamic scheduling options is ad hoc scheduling. This is alternatively called: on line scheduling (Feuerstein et al., 2003), dispatching (Holthaus and Rajendran, 2002), reactive scheduling (Ouelhadj and Petrovic, 2009), policy based scheduling (Bender et al., 2008), or priority based scheduling (Branke and Mattfeld, 2005). Definition 3.5. Ad hoc scheduling reacts to a change event with an immediate decision on how to cope with that particular change. Each time a scheduling decision has to be made, the scheduler makes the decision based on (heuristic) rules. Consider the taxi example again: Example 3.3. The situation is exactly the same as the one presented in Section 3.2.1.1. At 17:01 a change event occurs: a new passenger is at location D, wanting to go to E. The dispatcher has two rules: 1. When a new passenger calls for a taxi, assign the vacant taxi that is closest by, if such a taxi is available. 2. When a taxi becomes available, assign it to the passenger that is waiting for the longest time, if such a passenger is available. This two-rule scheme is driven by two change events: passengers becoming known, and taxis becoming available. In the example, taxi T2 is not available anymore, as it has been assigned the passenger waiting at C. Therefore, taxi T3 is assigned to handle the new passenger. More elaborate schemes are also possible, in which tasks are waiting in one or more buffers. They are picked using some calculation whenever a resource that can handle them becomes available. Another possibility is that tasks are irrevocably put on the timeline upon arrival, thereby creating a complete schedule. Since this schedule is

Dynamic Scheduling

48

fixed, this method of scheduling is different than schedule repair or full rescheduling. First Come First Served (FCFS) and Earliest Deadline First (EDF, Liu and Layland (1973)) are two well-known ad hoc scheduling rules, alternatively called First In First Out (FIFO) and Earliest Due Date (EDD), respectively. Each time a machine becomes available, FCFS picks the oldest task in a buffer and EDF picks the task whose deadline is nearest 1 . A large number of known ad hoc schedulers and comparisons between them are discussed in (Holthaus and Rajendran, 1997; Rajendran and Holthaus, 1999; Holthaus and Rajendran, 2002; T’kindt and Billaut, 2002; Branke and Mattfeld, 2005). Ad hoc approaches lend themselves perfectly for highly dynamic problems for which rolling out longer schedules is hardly possible or adds nothing to the scheduling process. For example, in manufacturing flow lines, the plant is usually setup in exactly the way in which ad hoc schedulers work: various flow lines with buffers, machines that process one task at a time, no ordering difficulties or time constraints (Holthaus and Rajendran, 2002). In such circumstances, an ad hoc approach will be the quickest scheduling approach available. However, there are some drawbacks. 1. In a large number of scheduling problems, like routing problems, the specific task order and the feasibility of a complete schedule are important aspects. Ad hoc schedulers do not create complete schedules from scratch, but instead make short-term decisions on the go. Hence, the feasibility of a complete schedule cannot be tested. 2. In manufacturing environments, which are a major inspiration for developing scheduling methodology, people need to oversee the production schedule. This enables them to identify resource conflicts, ensure required raw materials are ordered on time, ensure delivery promises are met, and identify time windows for preventive maintenance (Vieira et al., 2003). Also, it becomes more common for companies to share their production schedules, in order to better match supply and demand (Aytug et al., 2005). 3.2.1.4

Mixed modes

The three scheduling modes described before are sometimes used in a mixed setup. Most full reschedulers apply schedule repair as well: they immediately incorporate a new task into the current schedule. The resulting schedule is promoted to be the 1 Interestingly, FCFS and EDF are in the literature depicted as heuristics - rules of thumb - to aid with the scheduling problem (T’kindt and Billaut, 2002). However, Holthaus and Rajendran (2002), without further ado, state that dispatchers are not heuristics - which they argue are the algorithms used for static scheduling. Nevertheless, as these ad hoc methods fit very well into the view on heuristics presented in Section 2.2.2, the heuristics notion will be used throughout the remainder of this dissertation.

3.2. Solution approaches for dynamic scheduling

49

active schedule. Afterwards, continuous optimization tries to further improve the active schedule (Vieira et al., 2003; Ouelhadj and Petrovic, 2009; Bianco et al., 2006). This mix addresses an issue raised earlier: full reschedulers may produce better results, but at the cost of longer processing times. Using this mix, a change event can quickly be addressed, with the possibility of more optimal results later on. Furthermore, off-line and on-line scheduling can also be hybridized. An ad hoc scheduling approach can be ’rolled out’, to create a full schedule. This is done by simulating the future: based on the current assignments, one can calculate when machines become available, and which tasks would be assigned to them then. The resulting full schedule can be the starting point upon which an off-line scheduling technique can improve. Branke and Mattfeld (2005) and also Barlow and Smith (2008) use ad hoc scheduling techniques in this way. Using priority rules (an ad hoc scheduling technique) they roll out complete schedules. They do not follow the priority rule strictly, but roll out plans using roulette wheel selection. When using priority rules, the next task to be picked is based on priority calculations on all tasks, the task with the highest priority being executed next. Roulette wheel selection places elements to be chosen on a simulated roulette wheel, with the size of the ’pie’ equal to the importance of that element. The wheel is spun, and any element may be chosen - but the chance of the more important elements being chosen is proportional to their importance. In this case, a schedule is rolled out using roulette wheel selection. Instead of picking the task with the highest priority, a task is picked randomly, with the chance of being selected proportional to its priority (roulette wheel). Doing this multiple times, this leads to a population of different schedules. Evolutionary algorithms are applied to this population afterwards for improvement. This mix combines the speed of ad hoc scheduling with the potential performance gain of a full rescheduler.

3.2.2

Anticipation

The second challenge mentioned in Section 3.1.3 relates to the fact that an objective function that provides an objective value for a schedule, based on the fact that nothing changes anymore, is seriously flawed. Indeed, no exact objective function exists for a dynamic problem - only estimations can be given. The challenge of dynamic scheduling is making decisions as if everything that will be happening in the future is known in advance. In reality, we can only decide what schedules would have been best afterwards. Assessing the performance of ad hoc scheduling algorithms can be done by probabilistic calculations, using the competitive ratio: Definition 3.6. For any problem instance I, an a posteriori performance value C A for algorithm A, and a performance value Copt for an optimal off-line algorithm, the

Dynamic Scheduling

50

competitive ratio of algorithm A is defined as CR A = sup I

n

CA ( I ) Copt ( I )

o

.

The competitive ratio is used as a performance indicator, it denotes the worst case performance of that algorithm compared to the performance of an optimal a posteriori algorithm. As the performance of the dynamic scheduler increases, the CR nears 1. The CR value is always a worst-case value. In practice however, this value may not determinable. An optimal algorithm for a given problem may not be known. In this case, analysis can be done by calculating a lower or upper bound for the performance. However, this may also not be possible for a given problem. In such a case, using heuristics for off line optimization might result in an estimated upper performance bound, to which the performance of the actual on line scheduler could be compared. Nevertheless, bridging the gap between the dynamic scheduler and the best available a posteriori scheduler (i.e., reducing the CR) constitutes the major challenge a dynamic scheduling engineer is confronted with. This involves finding a schedule that may not be the best for the current outlook, but that is robust and/or flexible as well: Definition 3.7. A schedule in which any change event can be incorporated advantageously for that change event, as compared to other schedules, is said to be flexible. Definition 3.8. A schedule in which the incorporation of a change event can be done while minimizing damage to the prior objectives, compared to other schedules, is said to be robust. Flexibility is important for future change events. Robustness is important for the current activities. The definitions given here are working definitions. Within the literature, there is no clear consensus on definitions. In his book, Pinedo (2008) states that “the more robust the original schedule is, the easier the rescheduling is”, which alludes mostly to what is called flexibility in our definition. The definitions 3.7 and 3.8 are most close to those of Jensen (2003), in which a robust schedule still performs well when a disruption occurs, and all tasks are right-shifted; and a flexible schedule still performs well with respect to a certain rescheduling method, when that method is used to overhaul the original schedule. Let us reconsider the taxi driver example: Example 3.4. One might say that an ideal approach would be to always put new passengers at the end of the schedule. Such an approach would have maximum robustness, since currently scheduled tasks will be carried out exactly as planned. It would also be flexible, since there is always room for new tasks at the end of the schedule. However, most objective functions will penalize long waiting times, so putting a new passenger at the end of the scheduler would severely compromise the objectives. In the example given in Section 3.2.1.1, a new passenger is fit into

3.2. Solution approaches for dynamic scheduling

51

the schedule in such a way that he hardly has to wait for the taxi (flexibility), and the waiting times for other passengers is hardly increased (robustness). Therefore, the objectives are only minimally compromised. Schedules that make such insertions possible are both flexible and robust. In ad hoc, schedule repair, and full reschedule approaches, various attempts at increasing flexibility or robustness have seen the light and will be discussed in the next two paragraphs. In ad hoc schedulers Most ad hoc schedulers are designed in such a way that they will immediately dispatch a task when a machine becomes available, if there is a task in that machine’s specific buffer. This is called non-delay scheduling (Pinedo, 2008). Some approaches to introduce flexibility or robustness have been found in the literature. Branke and Mattfeld (2005) present an approach where idle time in the schedule is penalized less where it possibly enhances flexibility. The main objective in their study is minimizing tardiness in a Job Shop Scheduling Problem (JSSP). The tardiness of a task τi is calculated as follows: tardiness(τi ) = max(0, ci − di ) with ci the completion time, and di the deadline of τi . The tardiness is the amount of time the task is finished past its deadline, and zero if the task is finished beforehand. The tardiness of a schedule is, consequently, the sum of the tardinesses of all tasks. A schedule where no task is finished past its deadline, has zero tardiness. Part of their objective function penalizes the introduction of idle-times: idle times shortly after the current moment in time are heavily penalized (they will probably not be of use anymore), whereas idle times far from now are lightly penalized (they may create the gaps needed to process more important, but yet unknown, tasks in the future). With the right parameters for weighing in this penalty in the total objective function, they find promising results. Mönch et al. (2006) present an approach in which a similar technique is used, combined with the Weighted Shortest Processing Time rule. This is a heuristic that, whenever a machine becomes available, prefers the task that has a high priority or a short duration. This rule increases robustness, since it is important to carry out high-priority tasks. It also increases flexibility, since preferring short over long tasks leaves much room for yet-unknown high priority tasks to be carried out quickly. Lastly, flexibility is increased by the idle-time introduction that is similar to Branke and Mattfeld’s. Nikovski and Brand (2003a) present an approach in which the yet-unknown du-

52

Dynamic Scheduling

ration of tasks is guessed prior to dispatching the task. They describe an elevator dispatching problem where the aim is to minimize the average traveling time for passengers. For each passenger (or group of passengers) that calls for an elevator, a fixed elevator-assignment is made. Making such an assignment would improve if the destination of the passenger is known, to estimate the number of stops the elevator will have to make during its ride. This destination is not known when the passenger calls for an elevator, so in their approach, the destination is guessed. An elevator assignment is based on this guess. Their system performs better than the identical system without the anticipation. Such an approach increases both robustness and flexibility: the better the task duration is guessed, the better it can be assigned. This leads to less unforeseen delays (increasing robustness), and to assignments that are better in accordance with the passenger’s need (increasing flexibility). In summary, the three approaches to increase flexibility or robustness in ad hoc scheduling that we have seen here focus on idle time, doing short or important things as quickly as possible, or estimating unknown tasks or task parameters. To the best of my knowledge, there is no research that investigates the actual introduction of idle time (rewarding it instead of more or less penalizing it). In full reschedulers In schedule repair settings, anticipating future events is usually taken into account in the method of creating a schedule: as much as possible room for disruptions is left open, and plan refinement procedures will deal with a disruption as locally as possible (Abbink et al., 2009). These methods aim at increasing flexibility, and with that, robustness as well. A second principle in increasing robustness and flexibility can be found in Cowling and Johansson (2002). They focus on increasing the situational awareness, to reduce the uncertainty about the future. In their study, a manufacturing plant is investigated. By overviewing the plant as a whole, instead of focusing on a small part of it, disruptions could be foreseen, and even avoided. A third principle lies in the Broad Peak hypothesis. In (Jensen, 2001, 2003; Jin and Branke, 2005; Paenke et al., 2006), robustness is associated with broad peaks in the fitness landscape (see 2.2.2.1 for more information on fitness landscapes). A broad peak in a fitness landscape means that solutions that are minimally different from the peak-solution have an almost as high objective value. The idea is that when a change event occurs, the current solution will only slightly be altered - and the new solution will therefore probably have a high objective value, too. A narrow peak in the fitness landscape may yield a higher objective value, but when a change event occurs, the objective value is likely to drop dramatically. Determining the broadness of a fitness landscape peak involves sufficient sampling of the neighborhood, which

3.2. Solution approaches for dynamic scheduling

53

can be computationally expensive. Paenke et al. (2006) solve this problem by modeling the fitness landscape and using this model to quickly estimate nearby objective values. In (Jensen, 2003), the RcMax-robustness measure is introduced, which explicitly defines the objective value of a certain point in the landscape to be the mean of that value with all the objective values of solutions that are reachable from that solution by applying one minimal change (distance k=1). The performance of these robustness measures was very satisfactory. He hypothesizes that the broad peak hypothesis works because of two underlying principles: 1. The slack hypothesis says that the robustness measure RcMax will value solutions that have slack in them. Slack is the amount of delay a task may have without compromising the objective value of the schedule (i.e., the inverse of tardiness: the amount of time the task is finished before its deadline). Solutions in a neighborhood whose performance does not change much despite swaps, must have slack built into them to allow for that forgivingness. 2. The conflicting arc hypothesis is based on Gantt charts and acyclic graph representation for schedules (Roy and Sussmann, 1964). It can be summarized as follows: flipping the ordering of two tasks may lead to an infeasible or bad schedule. When the RcMax robustness measure is used, those flipped orders would appear in the neighborhood, leading to a low average objective value. Therefore, a solution with a high robustness value will have a neighborhood in which reordering of tasks can easily be done without jeopardizing the objective value. When change events occur, this flexibility is highly appreciated. Jensen (2001) has an interesting conclusions section in his article, that discusses opportunities and pitfalls of the broad-peak philosophy. The main problem here is that the peak is only determined by ‘looking around’ the current fitness landscape. However, a change event could distort the fitness landscape to a large extent. In such cases, determining the broadness of the peak will have little to say about the robustness to typical changes. Jensen indicates that for large makespan problems, where minimizing the completion time is aimed at, the broad-peak approach will hardly work. When the level of dynamicity is still low, there is much freedom in moving tasks around, and new tasks can easily be accommodated. Schedules will likely be executed as they were created, without large modifications. In those cases minimizing the makespan is not very difficult - and involves other techniques than creating robust schedules. When the scheduling environment becomes busy, accommodating changes is a difficult task that involves moving a lot of tasks around. In those cases broad peaks are a bad predictor of prolonged high performance. In summary, we see that engineers focus on actively building in room for changes in their schedules. Furthermore, increasing situational awareness could be used to

Dynamic Scheduling

54

decrease uncertainty about the future. Lastly, aiming for broad peaks in the fitness landscape might increase robustness and flexibility. However, this depends greatly on the specific application. Focusing on the principles underlying the broad peak hypothesis might be more advisable.

3.2.3

Adaptivity

As described in Section 3.1.2, dynamic problems may have a second-order dynamicity in them. This may call for a scheduler that does not just solve a dynamic problem, but that is dynamic in itself: it adapts itself to suit the current scheduling circumstances best. In the literature, rule based systems are often used to cope with second-order dynamicity. Consider the following example: Example 3.5. In the taxi driver situation (Section 3.1), different scheduling scenarios occur. During the night, there are hardly any passengers. During the afternoon rush hour, new passengers call for a taxi every 2.5 minutes. A rule set could be used as follows: IF (number of passengers / 60 minutes ≤ 2) THEN {use rule based dispatcher from Section 3.2.1.3} ... IF (number of passengers / 60 minutes > 20) THEN {use full rescheduler with anticipation} The ‘full rescheduler with anticipation’ would be a scheduler that - in the course of execution of a schedule - always keeps the taxis evenly spread throughout the city. This ascertains that whenever a new passenger calls in a for a taxi, there is always a taxi nearby. This leads to low waiting times, and therefore high throughput in difficult scenarios. During the night, this rule base would fire the first rule mentioned. This leads to the simple ad hoc dispatcher being used, which is fine for that situation. However, during the rush hour, this dispatcher falls short of the ideal. For example, taxis may have to drive long distances when the longest waiting passenger is far away, instead of, for example, picking up a passenger that waits nearby and who could be handled while driving to the other end of the city. In such a situation, the full rescheduler with anticipation methods in place might do a better job. However, that scheduler may not be a good choice during the night: it would constantly keep taxis evenly spread throughout the city. So when a taxi handles a passenger, all taxis would be relocated to fill in the gaps, and regain the equilibrium. This would come at large fuel costs, whereas this approach is hardly necessary since waiting times are short anyway during the night.

3.2. Solution approaches for dynamic scheduling

55

In the literature, similar approaches are described: Shaw et al. (1990); Priore et al. (2006) describe an approach where machine learning is used throughout the whole of the scheduling discourse. Machine learning can be used to learn good ad hoc scheduling heuristics (they are usually stated as rules, and learning rules generally attracts much attention from the machine learning research field). They also use machine learning for what they call pattern directed scheduling (PDS). In that case, they learn a rule base that on the premise side has a number of current problem parameters (like number of jobs in queue, current average machine load, etc.) and on the conclusion side a specified scheduling heuristic to be used. They find that the resulting system by far outperforms a single heuristic scheduler, and also improves over time as new problem parameters are discovered to be of importance, whereas attributes with marginal inputs are left out. The same approach is used in (Jahangirian and Conroy, 2000), in which evolutionary algorithms are the machine learning vehicle. In Muñoz et al. (2008), the elevator dispatching problem is treated. In this area, the dynamic problem changes over time as well: in the morning, there is usually an up-peak (everybody going from the lobby to their working floors). During lunch hours there is an inter-floor-traffic peak, and in the afternoon, there is a down-peak. These and more classifications (Siikonen, 1997), are used to determine the current traffic pattern. In their study, each elevator has its own processing unit (called Field Programmable Gate Array, FPGA, a kind of logical board for elementary logical operations), which determines the order in which hall calls are to be served. To that purpose, the FPGAs have different scheduling heuristics aboard. The one that should currently be used is determined by a fuzzy logic rule base that connects traffic patterns to specific scheduling heuristics. Similar approaches have been described in (Kim et al., 1998; Peters et al., 2000).

3.2.4

Reducing nervousness

A fourth challenge mentioned in 3.1.3 was the nervousness that is inherent to dynamic scheduling: to what extent is it problematic and how can it be countered? Definition 3.9. Nervousness: the frequency and amount of change in a running schedule due to rescheduling activities. Stability is the inverse of nervousness. Adapting schedules or recreating schedules to accommodate to a new situation can lead to an unwanted by-effect called nervousness (originally attributed to Steele (1975)). Nervousness means that a large amount of scheduling decisions have to be revised upon a change event. For fully automated systems, such changes may not be a problem. However, it may be unwanted in environments that involve humans in the loop. Furthermore, there may be internal or external costs involved with moving

56

Dynamic Scheduling

from a schedule to a revised schedule. For example, orders may have been made for raw material, promises were made to customers, etc. (Branke and Mattfeld, 2005). Reconsidering the taxi driver example, we notice the importance of this notion as well: Example 3.6. In the example used in the section on schedule repair (Section 3.2.1.1), a change event occurs at 15:01. This leads to a taxi being rerouted: the taxi driver is called to make a detour, pick up a new passenger, deliver him, and then proceed with the original schedule. One such change can be very well handled by the taxi driver. But when in the case of busy traffic (between 16:45 and 19:30), a taxi driver is constantly called to change his current destination, this may lead to annoyance, a large amount of detours, and possibly mistakes being made. Waiting passengers that were given an estimated time of arrival of their taxi might have to wait longer. Furthermore, diverting from a route that was chosen for its optimality towards the original destination, may come at a cost of extra fuel and spent time. Branke and Mattfeld in their study focus on a stylized Job Shop Scheduling problem whose performance is analyzed using a benchmark problem. They observe that straightforward ad hoc scheduling methods are far less nervous than complete reschedulers like, in their case, evolutionary algorithms. However, this was an expected result, as ad hoc schedulers do not produce complete schedules. In ad hoc scheduling, when task assignments are made irrevocably, there will not even be any nervousness at all. However, even in the case of an ad hoc scheduler where tasks can be reassigned, this will probably happen less than with a full rescheduler. The evolutionary algorithms that were alternatively used, often produce a complete schedule overhaul. It should, however, be noted that in their article, reducing nervousness has not been an objective in itself - it was only measured afterwards for those interested. Cowling and Johansson (2002) handle the issue of nervousness by optimizing its counterpart, stability. In their experiments (on a n|1|C problem; n Jobs, 1 Machine, optimizing for average Completion time) they define measures for stability and utility. The utility difference is the objective value (in this case, average completion time) of the schedule that has been revised according to the change event, minus the value if nothing would be done. The stability is defined as the average absolute change in the starting and finishing times of all jobs. They consider a decision problem, where each time a change event occurs, a decision has to be made whether to do nothing, do a small schedule repair, or do a complete schedule overhaul. A large number of experiments is run to determine the weight factors that are applied to the stability and utility figures, using the function maximise( A × Utility − B × Stability). The a posteriori performance shows that, for their specific problem, they could find good

3.3. Discussion

57

A and B values where small disruptions are best left as is, while large disruptions call for repair/rescheduling. It should be noted that their studies are focused around a narrow type of problems (n|1|C), whereas most real world problems have multiple resources and different types of jobs with different job priorities. Also, they use a simple ad hoc scheduler (the Shortest Processing Time first rule, SPT). It would be interesting to try reproducing their findings on larger problems and more advanced algorithms. Nervousness may also play a role in adaptive problem solvers: when the problem has second-order dynamicity, different problem solving approaches may be used in different phases of the problem. Switching methods may lead to schedules being completely revised to the likings of the new commanding approach. When such switching often occurs, this may be a great source of scheduling nervousness. To the best of my knowledge, there is no literature that discusses this specific problem.

3.3

Discussion

In this chapter, dynamic scheduling is discussed in contrast to the Chapter 2 discussion on static scheduling, and heuristic problem solvers. Dynamic scheduling differs in several ways. First, tasks, resources, constraints, and objectives may be subject to changes on the fly. Orthogonal to that, second-order changes may be present as well: the dynamicity level of the problem may change over time, as well as other aspects that characterise the ‘nature’ of the scheduling problem. Dynamic scheduling poses challenges that have led to several solution directions. Schedule repair, full rescheduling and ad hoc scheduling are different modes to cope with the needs of dynamic scheduling, especially the demand of quick solutions. Robustness and flexibility may be introduced to cope with the problem that the outcome of each in a rapidly changing environment may be very different from what was estimated beforehand. Adaptivity of the solution provider may be introduced to cope with possible second-order dynamicity. Lastly, stability inducing methods may be introduced to cope with the adverse affects of ‘shopfloor nervousness’, due to continual schedule changes. Although several solutions or solution directions emerge in the literature, several issues remain: 1. Much of the literature studying Job Shop Scheduling Problems or related problems such as Elevator Dispatching base their analyses on benchmark studies (e.g., Barlow and Smith (2008); Branke and Mattfeld (2005); Cowling and Johansson (2002); Holthaus and Rajendran (1997); Jensen (2001); Nikovski and Brand (2003a)). However, the problems themselves are derived from actual problems, and the proposed solutions are aimed at being practically applicable.

58

Dynamic Scheduling

Although benchmark studies facilitate direct comparisons between techniques for that specific benchmark, the validity of such studies in actual applications is never analyzed, or even discussed. For the generic moving peak benchmark (Morrison and De Jong, 1999) that is used to study dynamic problems in general, there is no known connection to any practical dynamic problem. Moreover, as we have seen in Section 3.2.2, investigating the shape of peaks in the fitness landscape will most likely not lead to useful information regarding its robustness or flexibility (Jensen, 2001). The validity of studies in dynamic scheduling, or even of dynamic optimization in general, is therefore questionable. 2. Most of the discussed literature on dynamic scheduling discusses the problem in isolation of the scheduling environment. Some attempts have been made at increasing situational awareness of the scheduler, in order to better anticipate future events, and improve the sustainability of the schedules produced (Cowling and Johansson, 2002). However, increasing the informedness (or, alternatively, reducing the uncertainty) of the scheduler is mostly not addressed as such. 3. In this chapter, we have seen the added difficulty of coping with dynamic instead of static problems: decisions have to be taken more quickly, in a more uncertain environment. In Section 2.4, the growing inherent complexity of heuristic problem solvers was already mentioned as a challenge. These two factors combined will pose a challenge to dynamic scheduling. 4. We have seen literature focusing on robustness or flexibility. We have only sparsely seen literature that discusses both as two sides of the same medal (e.g., (Jensen, 2003)). Sometimes these two virtues counteract each other, sometimes they cooperate towards achieving each other’s goals. Moreover, the use of flexibility and robustness measures is not yet ubiquitous in literature discussing dynamic problems, leading to dynamic problems being treated as static (MacCarthy and Liu, 1993). 5. In Chapter 2, we have seen how hybrids can form adaptive problem solvers. In this chapter, we have seen the need for adaptive problem solving to cope with second-order dynamicity. This naturally leads to the question how hybrid heuristics can best be applied to dynamic problems with second-order dynamicity in them.

4 Designing heuristics for dynamic scheduling In Chapter 2 and 3, we have seen the outlines of the generic scheduling problem, generic solution types, dynamic scheduling, and how dynamic scheduling works in contrast to static scheduling. Various topics of discussion have been raised in the respective last sections. In the first section of this chapter, these topics will be revisited in more detail, leading to a number of generic research questions. In Section 4.2, a number of techniques is proposed to, at least partially, answer those questions. These tools do not have a 1-to-1 relationship to the questions, but rather a many-to-many relationship. In further investigating these research questions, a case study is used in the remainder of this dissertation. Section 3 shortly introduces that case study.

4.1

Research questions

This section distills six issues from the conclusions drawn in Chapter 2 and 3. These issues are grouped in three categories: 1. Issues related to the problem solver. This concerns problems ‘under the hood’ of the heuristic problem solver: The over-complexity of solutions and the combination of hybridization & dynamicity. 2. Issues related to the problem itself. This concerns particular difficulties with dynamic scheduling: the high uncertainty of dynamic scheduling, and the demands on robustness and flexibility.

Designing heuristics for dynamic scheduling

60

3. Issues related to experimental results: the validity of experimental research findings in (particularly) dynamic scheduling.

4.1.1

Issues related to the problem solver

4.1.1.1

Solution over-complexity

Apart from constructive approaches or ad hoc approaches, most approaches in the area of heuristic (dynamic) scheduling make use of the local search paradigm. Especially metaheuristics consist only of local search algorithms. Section 2.2.1.2 shows that, in local search, a triangle of algorithm, neighborhood and objective function plays an important role. In Section 2.4, we have seen that the inclination to use metaheuristics and hybrids may lead to overemphasis of the algorithm, and to underexposure of the neighborhood and fitness function: 1. In the field of scheduling the value of good neighborhood design seems to be underestimated. This is the case when, as in many examples, the neighborhood structure is very much directed by the (output) solution structure. Depending on the specific domain, that structure is often some permutation: an ordering of tasks annotated with begin and end times. However, scheduling solutions have a strong internal coherence. In such a case, tasks orderings often cannot simply be swapped since that would produce an infeasible schedule. If the new solution is not infeasible, it may be suboptimal. This roots in the fact that the individual tasks that were swapped have an important relation to the (former) adjacent tasks. Taking these tasks out of that context will likely lead to suboptimality. Therefore, a neighborhood design strongly rooted in the permutation representation, could lead to neighborhoods in which many of the solutions are likely to be infeasible or suboptimal. This hampers the scheduler in finding a desirable solution. 2. With the increasing use of metaheuristics, the focus seems to shift more and more towards the algorithm. For example, evolutionary algorithms are often used without contemplating the specific downsides of that approach. It then seems that the choice of algorithm is more important than the coherence of algorithm, neighborhood and objective function. The sometimes ‘automatic’ choice for a metaheuristic algorithm may be ill-advised, as use of metaheuristics comes at a price: added complexity. All metaheuristics have extra parameters to be set, a setting that may not even be fixed throughout all usage phases of the system. Added complexity may very well lead to suboptimal performance. 3. With the increasing attention paid to hybrids, the focus on algorithms seems to

4.1. Research questions

61

become even stronger. In nearly all hybrid heuristics literature, the focus is on the algorithm only. Wrongly balanced attention may especially lead to suboptimal results in the case of dynamic scheduling (see Section 3.3). This leads to the following research question: RQ 1: Can improved neighborhoods and objective functions reduce the need for a complex metaheuristic while maintaining the same overall quality? The attention shift towards an algorithm is especially visible in the case of evolutionary algorithms. Throughout the literature, many applications of EAs are given in which discussion on the specific downsides of using such a complex algorithm is mostly lacking. Since the widespread application of EAs is in sharp contrast to the potential disadvantages of them, an extra research question is proposed regarding this issue: RQ 2: What are the advantages and pitfalls when applying evolutionary algorithms to dynamic scheduling? 4.1.1.2

Hybrid possibilities in dynamic scheduling

Several issues have been mentioned in which hybridization might be helpful: 1. We have seen (in Section 3.2.1) that different methods exist to cope with dynamic scheduling problems. Apart from a few exceptions, ad hoc and full rescheduling often lead separate lives. Since much research effort has been involved in both of them, the question arises whether these approaches have qualities that the other lacks. If this is indeed the case, hybridization might be advantageous. 2. In Section 3.1.2, we have seen how second-order dynamicity may play a role in dynamic scheduling. Since different algorithms or algorithmic setups might be favorable for use in different phases of the process, using a single, fixed, setup may lead to suboptimality. Adaptive hybridization, in which the algorithmic setup is adapted according to the changed circumstances, may be helpful in this respect. 3. Most metaheuristics are specialized in either exploration or exploitation (see Section 2.4). There are no metaheuristics that have both in well-balanced form. In actual implementations, much work is done on fine-tuning the parameters to get a more balanced exploitation/exploration balance (Blum and Roli, 2003; Liu and Ranji Ranjithan, 2010), but this appears to be difficult. Again, this issue

Designing heuristics for dynamic scheduling

62

might be an incentive for the use of hybrids, where algorithms are put together that each have one of these virtues. The possibilities notwithstanding, hybrids introduce much complexity to the problem solver (see Section 2.4), an issue we have already spotted in the previous subsection. Therefore, using them in highly randomized fashion, such as hyperheuristics (Burke et al., 2003a), might not easily lead to systems that are well usable in practical environments. Better opportunities are expected when the strong points and weaknesses of individual elements are actually known. In those cases, a well-designed, more simple, hybrid setting can make heuristics compensate, and thus benefit from, each other. RQ 3: How could a simple hybrid approach increase the performance of a dynamic scheduler, both in the case of short-term and second-order dynamicity?

4.1.2

Issues related to the dynamic scheduling problem

4.1.2.1

Informedness of the dynamic scheduler

In Sections 3.1.3 and 3.3, we have seen how in dynamic scheduling, timeliness of the decision making process becomes an important quality-of-service issue. Decisions or schedules should not only be good, they should be delivered quickly as well. This puts much pressure on problem solving methods, in particular those that have an added complexity by themselves, such as metaheuristics and hybrids (see Section 4.1.1). This pressure is even further increased when information on situation changes is provided late by the system. For difficult problems, where a large amount of solution possibilities exist, this pressure may lead to suboptimal results. The time needed for careful consideration simply is not available. Reducing this pressure from the perspective of the system is expected to offer interesting advantages that are usually not covered by literature on such schedulers. RQ 4: To what extent could modifications in the environment increase the performance of dynamic schedulers? 4.1.2.2

Flexibility and robustness

In earlier dynamic scheduling literature (McKay et al., 1989; Mehta and Uzsoy, 1999), three types of uncertainties are identified, in decreasing order of severity: • complete unknowns, where change events occur in a way that is completely unpredictable,

4.1. Research questions

63

• suspicions about the future, where some knowledge on the dynamicity is available from (human) experience - however hard to extract or quantify, and, • ‘known uncertainties’ - for example when machine breakdown frequencies are well-known. Much of the literature discussed in Chapter 3 treats the subject as if all scheduling problems fall into the first category. Trying to understand the nature of the dynamics of a given problem was seldom found. In some approaches, only the second-order dynamicity was acknowledged. This lead to adaptive schedulers, in which the active scheduler is continually changed according to the current circumstances. However, understanding the typicalities of a specific scheduling problem on short-term level, and using that information to increase robustness and flexibility is something that is often lacking. Section 3.2.2 shows that used robustness or flexibility measures are often generic, such as adding slack or measuring the width of fitness landscape peaks. Such methods are already disputed, and are not applicable to many scheduling problems. By not actively focusing on the short-term dynamics of a problem, and capturing the resulting knowledge in the algorithmic setup, suboptimal results are expected. RQ 5: How could flexibility and robustness measures increase the performance of a dynamic scheduler?

4.1.3

Issues related to experimenting

4.1.3.1

Experimental validity

As discussed in Section 3.3, most of the articles discussed study benchmark problems or use self-generated test data on a model of an actual problem. Such test data may very well not be as predictable as real life situations. On the one hand, the test data may be far more complex or dynamic as would be realistic in real life. On the other hand, they can also exhibit more regularity than problems in the real world, e.g., they have machine breakdowns for all machines at some Gaussian interval, whereas in reality the likelihood of machine breakdowns is not evenly spread over machines and time. RQ 6: What is the external validity of research findings obtained by benchmarks or self-generated test data?

4.1.4

Conclusion

The previous three subsections have introduced a number of research questions related to dynamic scheduling in general. In order to answer these questions, a number

Designing heuristics for dynamic scheduling

64

of building blocks is proposed in the next section. In the last section, we will see that these research questions and those building blocks are highly applicable to a specific case study, elevator dispatching. The next chapter introduces that case study more elaborately, also giving a number of research hypotheses for that case study. These research hypotheses are rooted in the, more generic, research questions we have seen here.

4.2

Building blocks

In the next subsections, a number of building blocks is proposed. They are related to the research questions, forming, at least in part, answers to those questions. Five partial solutions are distinguished: 1. System design enhancements (BB 1) 2. Realism measures (BB 2) 3. Abstract solution encoding (BB 3) 4. Hybridization (BB 4) 5. Heuristic interaction (BB 5) They can be seen as tools. One job may require multiple tools, and one tool may be applicable to multiple jobs. Each subsection explains how the building blocks are related to the research questions. These five building blocks are generally aimed at reducing the internal complexity of the problem solver, which would allow refraining from using more complex methods such as evolutionary algorithms. However, since the latter are often used in the area of dynamic problem solving, a separate subsection, BB 6: Evolutionary algorithms, discussing their usefulness in such a context, is included at the end of this section.

4.2.1

BB 1: System design enhancements

Most research questions addressed in Section 4.1 treat the actual problem as a given: the real world presents itself in a certain manner, and only by carefully designing a good scheduler can we cope with the situation best. RQ 4 focuses on the system surrounding the scheduler: Its design plays an important role in the schedulability of the problem it presents, especially (early) availability of provided information and desired results. A system design that is helpful to its scheduler boasts two qualities as much as possible:

4.2. Building blocks

65

• providing information early, • allowing for late decisions. Hardware setup In scheduling, tasks become known at a certain point in time (which often cannot be altered), and then have to be processed as quickly as possible. For example, production environments in which different production teams work as islands, delivering a half-product to another group without warning, leads to such unexpected tasks. When the production teams would operate in a more coordinated manner, tasks can be foreseen as teams can estimate the time of release of their half-product (Cowling and Johansson, 2002). Bringing forward such information makes it possible for the receiving team to anticipate the task, and to better prepare their production schedules. As a rule, getting information as early as possible, even if there is still some uncertainty to it, will increase the performance of the scheduler. Similarly, a schedule that is very much fixed will have difficulties in accommodating new tasks. When the execution time, or the execution order, or even the execution manner (e.g., which machine has to run it) is fixed long before the task is carried out, there is little room for adaptions. Whereas leaving tasks as is, and deciding as late as possible prior to execution on the execution specifics, leads to a flexible scheduler, and in turn this leads to a higher scheduling performance. A general building block for the system engineer, therefore, is to adopt the system design in such a way that information can be obtained as early as possible, and fixing decisions can be postponed as long as possible. Simulation setup If making changes to the actual systems is not possible, the two basic principles (provide information early, decide late) are still valuable for research purposes. In some dynamic scheduling problems, it is possible to derive a ‘best bound’ on the performance. This best bound could be calculated by running an off-line, static, scheduler afterwards. That off-line scheduler has no search time restrictions, and it oversees the timeline as a whole. It ‘knows’ the future. Comparing the on-line and off-line performances results in a Competitive Ratio (CR; a fraction (>1) of the optimal result, see Section 3.2.2). Often, an optimal schedule cannot be calculated in reasonable time. However, an estimation of the CR can still be made by ‘cheating’: similar (on-line) simulations are run, exploiting the two mentioned principles as much as possible. That means: the cheating scheduler can ‘know all’ and ‘look into the future’, thus increasing the informedness of its objective function. Furthermore, it can delay its decisions, thus minimizing the risk of scheduling suboptimally. The results can, again, be compared

Designing heuristics for dynamic scheduling

66

to the non-cheating simulation. Obtaining such a CR will give a crude estimate of the distance from optimality, a gap that should be bridged as best as possible.

4.2.2

BB 2: Realism measures

RQ 6 is a practical issue: To what extent are research findings usable in a real world application? There are two aspects to this. 1. The designer has to ensure that the system will perform predictably in the real world. Scheduling research is above all practical research, that aims at solving real world problems. This point is exemplified by the abundant amount of claims to practical applicability that are made in almost all of scheduling literature. These claims must be justified. To make this possible, it is of the greatest importance to investigate the real problem as close as possible. Usually, simulations will be used to conduct research. They should reflect the real world as best as possible. Therefore, test data should be real-world data, or modeled closely to real-world data. Hence, research that aims at practical applicability should avoid generic benchmarks. Test data derived from the actual problem are preferred. 2. Using test data derived from the actual problem, or modeled most closely to that problem, also has an effect on the analysis of test results. Often, algorithms are compared by running them once on a test problem, or a few times when randomness is involved in the algorithm, and simply averaging. The better performing algorithm is claimed to be the winner. This may be a good choice for benchmark problems, but for real world data, statistics have to be used to determine whether differences in results are significant. Studies omitting such analysis, lead to findings whose use in actual implementation may be questionable1 . In summary, the engineer should refrain to using only test data derived from, or as close as possible to, the actual problem. Furthermore, by using statistical analysis can the engineer ensure usability in a real world setting.

4.2.3

BB 3: Abstract solution encoding

In Section 4.1.1.1, we have discussed how bad solution encodings may hamper the performance of a scheduler (leading to RQ 1). This subsection discusses and exemplifies abstract encoding, to partially answer that issue. Transcending from the actual 1 Out of 13 articles discussing comparisons between elevator dispatching algorithms, referenced in this dissertation, none used statistical methods to analyze the significance of differences between outcomes. Instead, all articles relied on averages and graphs to discuss differences and trends.

4.2. Building blocks

67

solution output into a more abstract view of the solution could help problem solving, especially in the case of solutions with great internal coherence, like scheduling. To illustrate the problem and the solution, we will first have a look at the combination of evolutionary algorithms and ordering problems. Example 4.1. Evolutionary algorithms and ordering problems In evoluationary algorithms, the neighborhood design is largely defined by the chromosome design. Bad chromosome design will lead to the creation of almost guaranteed weak individuals: the parent solutions cannot convey their ‘winning parts’ towards their children. This risk is especially large for ordering problems, like scheduling. Goldberg (1989) describes the chromosome problem using the Traveling Salesman Problem (TSP) as an example: a set of locations has to be ordered to form a shortest path that visits each city once. When the solution-chromosome mapping simply consists of an array of city-identifiers (socalled ‘Permutation Representation’), a straightforward crossover operation leads to cities being visited twice, while others remain unvisited - a solution that violates the constraints, which is therefore invalid. To cope with this problem, Goldberg describes the Partially Matched Crossover (PMX) approach that repairs solutions during or after the crossover operations. However, such an approach still leaves us with problems like the fact that the EA cannot distinguish between two equal solutions that have a different starting point: they look completely different, and a crossover between those equal solutions will produce complete nonsense. To cope with such problems, Grefenstette et al. (1985) introduce Ordinal Representation (OR), that does not suffer from these crossover and mutation problems. OR is a more abstract way of describing the solution, in which the chromosome elements do not directly reference locations. Instead, they indirectly reference a location by pointing to the nth still available city. A TSP tour is built up by picking cities that have not yet been visited, as indicated by the chromosome elements. However, the problem with this representation is that a small change in a chromosome, could lead to a completely different set of available cities, because for each still available city, its position in the list of available cities has changed. Therefore, even though the remainder of the chromosome stays the same, the resulting end-solution will be a complete overhaul. In a previous study, Swapping Representation (SR) was introduced as an alternative to PMX and OR (de Jong, 2000). In this representation, each chromosome element defines a swap of two elements in a working-array. The working-array is initially filled with all cities, then the swaps defined by the chromosome are carried out. The resulting set of cities after all the swaps have been carried out represents the solution. Although the approach seemed far-fetched, it could create every possible ordering of cities, while remaining true to the original EA princi-

68

Designing heuristics for dynamic scheduling ples of crossover and mutation, and a single element flip did only slightly change the end solution (as it is meant to do). Pilot studies unexpectedly showed that the results were outperforming the established OR approach. Therefore, the swapping representation was used in a later study on radar scheduling (de Jong and van Norden, 2007). In that particular study, the encoding was used for a highly dynamic scheduling problem. The encoding facilitated easy incorporation of other algorithms (in this case, EA’s and ad hoc scheduling algorithms) in a final hybrid solution. This latter article again showed that (1) the solution encoding used for the algorithms, need not necessarily be a direct copy of the output representation; (2) a problem avoiding representation may call for good neighborhoods in different algorithmic approaches; (3) an abstract representation could easily cope with change due to dynamicity; (4) such a representation is an ideal rotation point for hybrid solutions.

In this elaborate practical example, we see that a more abstract encoding may provide a good instrument to harness the power of diverse algorithms, without being distracted by infeasible solutions, translation issues or dynamic disturbances. To understand what an abstract encoding is, we will first introduce two notions that are important in the categorization of solution encodings: direct vs. indirect and traditional vs. non-traditional: Indirect encodings (Michiels et al., 2006; Talbi, 2009) constitute an incomplete solution, that has to be finished by some decoder. The decoding task involves using polynomial time algorithms that will create a complete, functional solution. In such a case, the local search algorithm working on the encoded solutions does not solve the complete problem, it leaves part of the problem solving to the decoder. In a direct encoding, the decoder performs a straightforward translation from encoded solution to output solution. A given encoded solution will always lead to the same output. In traditional encodings (Talbi, 2009), the encoding corresponds directly to the output solution, no translation has to be done - the problem solver works directly on the output solution format. The permutation representation in the above example is a typical case of such an encoding, and dominant in routing and scheduling. In a non-traditional encoding, a decoder is necessary to convert encoded solutions to output solutions. The Ordinal and Swapping representations are examples of the nontraditional encodings. Definition 4.1. An abstract encoding is a non-traditional direct encoding. An abstract encoding seeks to obscure the final solution format for the algorithm, enabling it to browse the search space more efficiently. The encoding/decoding is fixed in a many-to-one relationship: an output solution can be encoded by multiple abstract encodings, but a single encoding will always lead to the same output so-

4.2. Building blocks

69

lution. The decoded output solutions may be used for calculating objective values, and will eventually be used for execution2 . The designer creates the encoding/decoding scheme. No generic method can be provided to create a good encoding. In the above example, we have seen two such abstract encodings (OR and SR), that differed completely in approach. Nevertheless, three demands can be distinguished, meeting which enables creation of a good abstract encoding: 1. Neighborhood demands 2. Broad applicability demands 3. Adaptivity demands These three demands are discussed in the next three paragraphs. Neighborhood demands The neighborhood of a solution (see Section 2.2.1.2) may be totally unrelated to the way in which the solution is encoded. However, the neighborhood structure is strongly related to the solution encoding, which often is derived from the output encoding. In the evolutionary algorithm & ordering example, we have seen that for ordering problems, a permutation representation would be most straightforward. In the case of EAs, when new solutions are formed by cutting and pasting of parent solutions, this leads to some problems: • the same task may occur twice, or not at all, in a child solution, • mutation by flipping a single element is not possible, as it would (again) lead to the omission of one task, whereas another task will occur twice. The more abstract encoding that was discussed, ordinal representation, did not suffer from this problem. However, using that representation leads to other problems: • when cutting and pasting parts of a parent solution into a new solution, those parts are moved out of context, since their working strongly depended on the structure of the rest of the parent solution. • flipping a single element of the encoded solution may lead to a large change in the (decoded) output solution. 2 Abstract

encodings should not be confused with abstract data types (ADT), from the world of Software Engineering. ADTs seek to obscure implementation details for the programmer. Accessing data, memory management, etc. are handled by the ADT. The only thing the programmer needs to know is the function calls necessary to access the data. The actual implementation of the ADT can differ, and so will the way in which the data is stored and retrieved. This can be done to optimize the performance of the system. To the programmer, however, this is of no consequence. Abstract encodings, on the other hand, are applied in the field of optimization techniques.

70

Designing heuristics for dynamic scheduling

The last encoding mentioned, swapping representation, did not suffer from any of these problems. Therefore, when constructing an abstract encoding, the engineer should ascertain that the encoding facilitates neighborhoods that boasts these three qualities: 1. Exchanging solution parts between two encoded solutions, or mutating an encoded solution, should lead to feasible solutions. 2. Exchanging parts of the encoded solution to create a new solution should convey the resulting output solution structures of those parts to the new solution. 3. Mutating an encoded solution by randomly altering a few solution elements should only have a small effect on the underlying output solution. When these three qualities are met, it almost automatically leads to an encoding that is broadly applicable and adaptive as well.

Broad applicability demands We have seen how solution encoding, involuntarily, directs the design of the neighborhood structure. For that reason, a versatile solution encoding that guides nor restricts the neighborhood structure too much is proclaimed. This is not just good for neighborhood design, it leaves algorithmic choices open as well: when algorithmic and search space choices are not restricted by the neighborhood, the risk of sticking to a suboptimal heuristic approach is reduced, and hybridization is made easy as well. Since algorithm and neighborhood structure are often implemented in an interweaved manner, it is difficult to disentangle them when implementing a hybrid setup. Therefore, the solution encoding design should be done completely independent from the algorithm or objective function implementation.

Adaptivity demands For search spaces in dynamic schedulers, and specifically, solution encoding, it is important that situation changes can be easily incorporated into the solution structure. This means that inclusion of additional tasks can be done without much searching to find the ideal spot for such a task, and without much shuffling that involves a lot of other tasks as well. For example, a structure in which a new task can easily be put at the end of the schedule, and be advanced from there, meets this case. Furthermore, the feasibility of the solution should not easily be hampered by including or excluding elements. When the search space can easily adapt to the new situation, the search approach will have less difficulty and need less time to reach optimality again.

4.2. Building blocks

71

Create hybrid engine

Relay constructive and local search

Dynamic problem?

Distinguish and quantify problem characteristics yes

Problemsolution mapping

no

Create adaptive hybridization

Heuristic weaknesses?

yes

Create low-level hybridizations

no

Figure 4.1: Flowchart of the hybridization framework.

4.2.4

BB 4: Hybridization

Hybridization is often thought of as cooperating algorithms: two or more algorithms solving the problem together. However, this viewpoint should be extended to all algorithmic parts: neighborhood functions, selection mechanisms, objective functions, etc. An approach in which one algorithm is connected to different neighborhood functions, or to different objective functions, is a hybridization as well. Consequently, multi-objective problem solving is a hybridization per definition, since different objectives are ‘married’ into the final objective function. The downside of any hybridization is added complexity. The division of tasks over problem solving subparts, the choice of which objective function to use when, etc., makes a hybrid setup more difficult to implement than a single straightforward solution. Noting the drawbacks of hybridization, RQ 3 asks how hybridizations can be successful in dynamic environments. To begin answering this question, we note that the amount of complexity varies with the hybridization method chosen. Since dynamic problem solving is already complex in itself, the benefits of hybridization are expected to outweigh the disadvantages only by aiming at less complex hybrid setups. Therefore, this subsection proposes an approach that exploits the promising features of hybridization while avoiding the complexity pitfalls. In the first step of this framework (Fig. 4.1), a hybrid engine is created. This

Designing heuristics for dynamic scheduling

72

engine functions as a turntable for different algorithms, neighborhoods, and fitness functions. Part of this phase comprises the creation of a versatile solution encoding, as stressed in Section 4.2.3. From this point on, three consecutive steps are proposed to make hybridization work in a dynamic system. Implementation of these steps will prove increasingly difficult: 1. Relaying of constructive and local search. 2. Deal with second-order changes by adaptive hybridization. 3. When specific weaknesses in the heuristic setup can be identified, low level hybridizations may help. Creation of the engine, and the three steps mentioned, are discussed in the next four paragraphs. Hybrid engine Software that has been used for a longer period of time, has a tendency of degenerating. The software itself does not degenerate, of course, but additions, bug fixes, or other changes lead to what is generally known as ‘spaghetti code’, or, more scientifically, ‘code decay’ (Eick et al., 2001). When a scheduler has been engineered with a specific algorithm in mind, and it has been optimized, the various parts of the software will become strongly entangled. This will make it difficult to replace the algorithm with an alternative approach, or to use a hybrid algorithm. Even an originally installed, fixed hybridization may become difficult to disentangle. Therefore, hybridization is not easily added after the system is created. A hybrid engine as an enabler for hybrid systems should be created beforehand. When second-order dynamicity comes into play, multiple algorithmic setups may prove superior during different phases of system usage. The hybrid engine must therefore be able to hold multiple algorithms, multiple neighborhood structures and multiple objective functions. The mixture of these subparts is in the parameters of the engine, which may be a fixed setting for specific experiments or setups. It should also be possible to set these parameters dynamically, adapting the mix based on current system observations. The hybrid engine is a generic piece of software (a class or unit), depending on the development environment. It glues together solution elements, so that different mixtures of algorithm, neighborhood and objective function can be selected on the fly. The actual algorithms, neighborhoods and objective functions are descendants of generic classes that the engine can work with, without knowing the design details of each element.

4.2. Building blocks

73

Relaying constructive and local search Constructive algorithms (Section 2.2.1.1) can quickly build initial solution that local search algorithms (Section 2.2.1.2) can further optimize. In the case of dynamic scheduling, ‘ad hoc’ or ‘on line’ algorithms are often used (Section 3.2.1.3). These mechanisms can provide solutions quickly, which is an advantage in highly dynamic problems. These solutions can easily be further optimized using a local search algorithm. To make such an hybridization, the ad hoc scheduler has to roll out a complete scheduler, by consecutively placing those tasks on the timeline that would be dispatched in ad-hoc manner at those points in time. Afterwards, the resulting complete schedule can be used as a starting point by a local search algorithm. Variations on the ad hoc scheduler may be considered. In (Branke and Mattfeld, 2005), an approach is described in which the ad hoc approach is augmented with some randomization. This leads to a number of different roll-out schedules that were all quite good. These could even be used as starting points for populationbased metaheuristics to build upon. Also, ad hoc schemes can incorporate change events into a running schedule - thus enabling continuous system operation - after which a more time consuming local search can take place to find a new optimum. Therefore, this basic scheme is useful for dynamic scheduling as well. For the local search algorithm, even a simple greedy ascent local searcher may prove valuable. If sticking to local optima of insufficient quality appears to be a great risk for a specific problem, a more elaborate local search algorithm may be used, such as tabu search and simulated annealing. Only when such approaches fail to converge to good enough solutions, should more complex heuristics be considered. As an alternative to using more complex heuristics, the initial solutions provided by the constructive algorithm may be considered ‘too optimal’. It may be difficult for the local search algorithm to escape that optimum. In that case, applying randomization such as described before could be an option. Furthermore, in specific cases, abandoning the constructive approach altogether and only using completely randomized initial solutions have led to better final solutions (Johnson and McGeoch, 1997). In summary, hybridizing ad hoc and local search algorithms is a relatively easy means to either increase the performance of an ad hoc scheduler, or to enhance a local search approach by ‘seeding’ the algorithm with relatively fit solutions. Example 4.2. Hybridizing ad hoc & evolutionary algorithms In an earlier study, (de Jong and van Norden, 2007) have presented a hybridization of a specific ad hoc algorithm and an evolutionary algorithm to solve a (highly dynamic) radar scheduling problem. The results indicated that both of the constituents were outperformed by the hybrid. The ad hoc algorithm on average

74

Designing heuristics for dynamic scheduling performed much better than the EA. The EA, however, benefited from seeding by the ad hoc algorithm, and the combination of both gave the best results, especially under extreme stress. In that scenario, the ad hoc algorithm indeed made short-sighted choices that appeared suboptimal later on. It is expected that more suitable complete reschedulers than EAs would even yield better results in this case. In that particular study, EAs were mostly interesting from a scientific point of view, especially as regards the Swapping Representation that was used for chromosome mapping (de Jong, 2000).

Adaptive hybridizations for second-order dynamicity In the case of second-order dynamicity, problem characteristics change over time (see Section 3.1.2). Determining which approach suits which situation best is a process that can be done automatically or by hand. Either way, the system designers will have to distinguish the characterizing factors, which have to be measured to assess the current problem type. For this, no generic recipe can be given, as it is very problem dependent (see also Section 3.2.3). Also, knowledge on this part grows with experimenting on the system, more than by analysis in advance. Typical examples of such factors are current crowdedness and current task priority settings. When the characterizing factors are determined, a rule base can be generated that maps current problem characteristics on algorithmic setups. This can be done by analyzing ranges of experiments, focusing on problem solving episodes that correspond to a specific problem characterization. The algorithmic approach that performs best for a certain problem character is then mapped onto that problem type. The size of the rule base has to be determined by pilot experimentation. When the problem characteristics are categorized in a fine-grained manner, the set of rules will consequently be large. The engineer will want to refrain to a set of rules that is distinctive enough with respect to the problem type, but not more than that. A downside to algorithm-switching on the fly, is that the switching itself may have some impact on the problem solving process. The switch may be small, e.g., when only a parameter setting is slightly changed, or large, e.g., when a completely different type of algorithm is chosen. In the case of scheduling, such transitions may be problematic. Tasks that are still waiting to be run, and that have been scheduled using the first approach, may in view of the now used second approach be completely misplaced. Therefore, in the transition phase the new algorithmic setup may have to cope with some heritage from the former setup. The extent to which this is problematic is heavily dependent on the difference between the approaches, and on the specific problem that is studied. However, as a rule, switching a lot may lead to much ‘shop floor nervousness’ - meaning that tasks are rescheduled often (see Section 3.2.4). The switching of algorithmic approaches itself may also become nervous:

4.2. Building blocks

75

when the current problem characteristics border on two predefined problem types in the rule base, the approaches may keep constantly switching back and forward. To reduce such potential disadvantages, the approach-choosing control system can be set to use the same technique used in thermostats (e.g., turn the heater on at 19.8ºC, turn it off at 20.2ºC, for a setting of 20ºC). As a side advantage to adaptive hybridization, applying this approach creates an opportunity for the engineer to learn from the system. By observing the mapping that the analyzing system produces, one may be able to find regularities in the problem that could be incorporated into newer versions of the heuristic approach at work. Other possible hybridizations In Section 2.3, several other options for hybridizing metaheuristics are discussed. In most cases, randomization and teamwork play a large role. Randomization is used when different algorithms (or algorithmic parts) are put in a portfolio and are randomly picked during runtime. This can be done in the hope of automatically learning system behavior. However, if the studied system is large, or itself contains a large number of parameters to be set, the learning curve is likely to be shallow. For dynamic systems, which are complex in themselves already, it will likely not be easy to tune such an approach to the level where the performance of the whole will increase. Likewise, for teamwork settings, the specific mixture of the team, and the processing time that is given to each member of the team, are delicate optimization parameters. Since for a dynamic system, these settings are likely to be different under different circumstances (second-order dynamicity), such a system will likely be difficult to implement. Therefore, attempts at such hybridizations are discouraged. However, on closer observation during pilot experimentation or actual use of the system, specific regularities in the problem solving process, or in the search space structure, may be found. When the approach that is used is not well suited to exploit these regularities, the engineer might consider specific hybridization designs to address those. These hybridizations will be very much tuned towards the specific problem at hand. They will often be low-level hybridizations, where subparts of an algorithmic setup are augmented by alternative approaches. For example, the neighborhood and objective function can be tuned to not consider unpromising solution options, which saves computational effort. Summary RQ 3 is “How could a simple hybrid approach increase the performance of a dynamic scheduler, both in the case of short-term and second-order dynamicity?”. In

Designing heuristics for dynamic scheduling

76

answering it, we have seen that implementing the system around a hybrid engine, and incorporating a good abstract solution encoding, greatly reduces the implementation difficulties of later hybridization efforts. Furthermore, a serial hybridization of ad hoc and local search schedulers should be used as an easy and straightforward method to increase each other’s potential, especially in the case of scheduling. Whereas that method focuses on first-order dynamicity, adaptive hybridizations are aimed at second-order dynamicity. They may relatively easily be implemented, especially when the hybrid engine is already in place. Lastly, only low-level hybridizations that are directly aimed at algorithmic weaknesses, found for the specific scheduling problem at hand, should be used. These steps ensure minimal added algorithmic weight, while maximizing the potential benefits of hybridization.

4.2.5

BB 5: Heuristic interaction

Different problem solving elements in the triangle algorithm, neighborhood and objective function may independently be added to the system. However, only a balanced consideration of those aspects will lead to a successful problem solver, especially when processing time is limited. Example 4.3. An already computationally expensive approach like evolutionary algorithms, combined with an objective function that takes a relatively long time to calculate the objective value for a solution, requires a long time to converge to an optimum. Switching to another algorithmic approach, or reducing the cost of the objective function could help, although it may come at the price of increased difficulty in finding promising regions in the search space. Example 4.4. A certain combination of a small neighborhood and a simple objective function may lead to an algorithm having difficulty to escape a local optimum. In that case, enlarging the neighborhood or increasing the informedness of the fitness function could help, although that may come at a price of greater computational effort needed. The examples show that the engineer will have to carefully balance the cost and benefits of the algorithmic parts used in combination. Checking the interaction between these elements is therefore important. Such interaction may be found by careful analysis of the problem particularities. More often, it will be distinguished based on (pilot) experiments. All three aspects move in a continuum between simple and complex. As we have noted in Section 2.4 and 3.3, proposed solutions have a tendency towards more complex algorithms and algorithmic parts. This may not prove problematic in environments where time is abundantly available. However, for dynamic

4.2. Building blocks

Constructive algorithm Algorithm / Neighborhood Objective function Exact objective function

77

Increasing horizons

Greedy ascent

Check interaction

Multiple objectives, dynamicity

Increasing information, reducing cost

Figure 4.2: Interaction framework. Algorithm, neighborhood and objective function move along similar lines to increasing complexity, always acknowledging heuristic interactions.

systems, restricted processing time is an important issue. RQ 1 asks for improved neighborhoods and objective functions, to counteract the tendency to use more complex algorithms. In answering this RQ, it is proposed to take a route analogous to what was said for hybridization (Section 4.2.4): start simple with each aspect, and move to more elaborate processing schemes as the environment demands it. This is proposed for both algorithm/neighborhood engineering, and for objective function engineering - which are covered by the next two subsections, respectively. Furthermore, RQ 5 focuses on robustness and flexibility, which is addressed by objective function engineering (second subsection). The remainder of this section treats the blocks that are depicted in Fig. 4.2. 4.2.5.1

Algorithm and neighborhood

An elaborate overview that focuses on the algorithmic aspect of heuristics is presented in Chapter 2. The information presented there should be ample to make an informed decision on the preferred candidates for the algorithmic approach. As we have seen there, there is a tendency towards using algorithms with great induced complexity. However, as a rule, it is proposed that the process starts with a constructive approach, quickly followed by a collaboration with a simple hill climbing local searcher. This is already discussed in Section 4.2.4. Depending on the objective function and neighborhood structure used, this setup alone might prove extremely valuable. When the performance of this system is below expectations, or the problem appears more complex and less understood, or more search time is available than currently used, more elaborate search procedures may come into play. Constructive approach & Greedy ascent When the search space of possible complete solutions is small, a systematic (exhaustive) search might be feasible. This option might be overlooked, as the generic type of problem being NP-complete or NP-hard, seems to call for heuristic instead of systematic search. However, the search space is often beyond the bounds of exhaustive search. For

78

Designing heuristics for dynamic scheduling

most problems, a smart constructive approach provides fairly good results in virtually no time. Furthermore, in a dynamic system, such an approach could make a good initial step in changing the solution once a change event occurs. A constructive approach can also provide a good seed to start a local search procedure on (as more closely discussed in Section 4.2.4). As long as the search space is relatively small or the fitness landscape is relatively simple in form, a simple greedy ascent hill climber will prove valuable: 1. It is preferred when a solution has to be found within small distance from the current solution. This might be the case when shop floor nervousness should be reduced. A new solution that is close to the original, will incorporate less changes compared to a solution further away. 2. It is preferred when solutions need to be found extremely fast and ‘good is good enough’. 3. As it is fast, and easy to implement, it may be worthwhile to enhance the objective function and search space structure, rather than upscaling to more complex, costly and often randomized algorithms. With good understanding of the problem at hand, objective function and search space can be tuned to the point that a relatively small neighborhood provides promising solutions, rendering greedy ascent a useful approach. Also, the objective function can be tuned to give more informed results, turning a possibly ‘flat’ fitness landscape into a field that is better ‘curved’ towards optimality. Increasing the search space horizon When a pragmatic combination of constructive approach and greedy ascent falls short of the needs for a particular system, algorithms of increased internal complexity can be used. First, the ‘usual’ metaheuristics like tabu search and simulated annealing can be tried. Those metaheuristics may increase the search horizon beyond the border of local suboptimality. This may come at the cost of longer search times or a higher number of expensive objective function calls. Therefore, the search space structure should be designed with an emphasis on avoiding double work, and the objective function should be as cheap as possible. When the search space is extremely ill-understood and large, population based metaheuristics may come into play. They can do exploration with a wide search horizon. The extra cost may be decreased by running such an approach distributedly. As discussed in Section 4.2.3, success of a population based metaheuristic is largely dependent on a well-designed search space structure. Hybridization with a fast local search algorithm is always advisable, to overcome the difficulties population based methods have in converging to optimality.

4.2. Building blocks 4.2.5.2

79

Objective function

While the algorithmic approach might be seen as an adjustable vehicle and the search space as the road or terrain to drive on, the objective function may be seen as the elevation of any location visited. This is often regarded as a given: the objective value will directly correspond to time that is needed or spared, costs that are made or saved, etc. However, this value may be as adjustable as the previous two aspects. As a roadmap to designing objective functions, it is proposed start with a ‘clean’ or ‘exact’ objective function. This starting point can serve as a base to build upon, by adding other objectives and acknowledging dynamicity. Furthermore, the objective function can be optimized by increasing its informedness, and reducing its cost. These aspects are discussed in the next few paragraphs. Exact starting point For most problems there is a single value that is the most likely performance measurement: makespan, cost, machine availability, etc. This single value is a good starting point to build upon. During subsequent experiments, shortcomings in the objective function may come to light, as may particular difficulties with the neighborhood or the algorithm because of this objective function. Building upon this experience, the setup of the whole heuristic triangle may even change. Multiple objectives Other features that play an important role in deriving the objective value of candidate solutions are added later on. In a multi-objective environment, values have to be combined in order to form a final objective value. The function that combines different values that are different in nature as well, will usually be more complex than a simple addition. A good understanding of the value ranges of the diverse factors, plus the impact they should have on the final outcome, is vital to finding the right mixing formula. In practice, this can only be determined by pilot experimentation. Another issue with dynamic problems, discussed in more detail in Section 4.2.4, is the fact that during different phases of the problem solving process, the priority of individual objectives may change. Therefore, the multi-objective mixture may have to change on the fly, without necessarily having to change the neighborhood structure or algorithmic approach. Dynamicity: robustness and flexibility Dynamicity (RQ 5) is addressed as a special case of multi-objectivity. In dynamic problem solving, an exact objective calculation is never possible. The objective function should produce an estimate of the future worth of a solution, which may turn out wrong in the actual future. Therefore, research in dynamic scheduling should not focus on NP-hardness assessments, as if

80

Designing heuristics for dynamic scheduling

having unlimited time could provide the optimal solution, since this cannot be determined without being able to look into the future. Instead, emphasis should be given to bridging the gap between objective value estimations and actual processing results. An easy approach is to start with taking the ‘standard’ objective function, as if the world wouldn’t change anymore after the current moment. Later on, this function should be augmented by factors that incorporate the flexibility or the robustness of the schedule (see discussion on these terms in Section 3.2.2). Increased flexibility and increased robustness would then coincide with a better objective value. There are no ready-made designs for the calculation of flexibility or robustness; and factoring in these values will always lead to a multi-objective problem - in which a careful balance has to be sought between the underlying objective calculation and the flexibility/robustness factors. Furthermore, implementing flexibility or robustness measures will always be an iterative approach: weighing in such factors will change the behavior of the scheduler, as a result of which other (lower) flexibility/robustness factors will prove better, etc. Experimenting with ranges of weight factors for taking the robustness into account will have to be carried out. In general, one could say that discouraging delay or introducing slack may already be coarse attempts at producing better dynamic schedules (see Section 3.2.2). Analysis of the actual problem at hand, preferably by assessing experiments rather than studying the generic features, helps gain insight into the possible options for applying flexibility/robustness measures.

Optimization: Increasing informedness, reducing cost Similar to what was mentioned about search spaces, objective functions help in paving the way toward a desired outcome. When a simple objective function is coarse-grained, it may give equal values for different solutions, making it impossible for the search approach to distinguish between those solutions. Knowledge about the problem structure may then be incorporated into the objective function, to create a ‘royal road’ towards optimality. This knowledge could distinguish between results that are ‘equal’ in terms of distance to the desired goal, but different in how promising they are as a stepping stone towards that goal. Incorporating such knowledge can have an impact on the algorithmic and neighborhood designs: when the fitness landscape was still ‘flat’, the search horizon may have had to be broadened by means of enlarging the neighborhood or setting the algorithm to look further ahead. Now that the objective function is better informed, computational costs can be saved there. This comes at the price of a more expensive objective function. Making this trade-off is typically done by overseeing the whole heuristic triangle, trying to optimize the problem solving performance where it is most cheap. Objective function calls may already be an expensive factor in ‘ordinary’ meta-

4.2. Building blocks

81

heuristics, in population based heuristics, the cost of these calls may become impractically large (Paenke et al., 2006). Population based metaheuristics, therefore, are the one approach family where reducing the cost of the objective function pays off most. This can be done either lossless or lossy: • Lossless cost reduction may be obtained by smartly reusing previously made calculations: in a local search algorithm, a solution under consideration is usually only a slightly adapted version of another (or previous) solution. In such situations, only the difference with the previous solution has to be calculated, saving much effort. Alternatively, tables can be used to store frequently-used intermediate results. • Lossy cost reduction can be done when the objective function is very costly, or even impossible, to calculate, or when speed is preferred over accuracy. In such situations, using heuristic estimations of the actual objective function may be advisable (Branke and Schmidt, 2005; Paenke et al., 2006).

4.2.6

BB 6: Evolutionary algorithms

In the previous subsections, a number of building blocks is proposed to facilitate engineering systems for dynamic problem solving. Contrary to those proposals, this subsection generally advices against a certain technique, evolutionary algorithms (EA), thereby answering RQ 2 (see Section 4.1.1.1). The need for such an advice stems from the abundant use of EAs in a wide range of problems, including dynamic (scheduling) problems. However, the building blocks described above are aimed at reducing the need for overly complex methods such as EAs. Evolutionary algorithms (EAs) can have great capabilities of exploring an illunderstood fitness landscape. However, the structure of the search space (which is directly linked to the chromosome structure) should enable cutting and pasting solution parts in a manner that probably creates good candidates. When, as is the case in routing or scheduling environments, the order of elements in the chromosome is of great importance, the EA can have great difficulty in obtaining feasible solutions at all. In such cases, special crossover and mutation operators are usually created to bypass these problems, which may take away the original vision behind EAs. Only by carefully designing a good chromosome structure can EAs help in better solving the problem (see the building block on abstract solution encoding (BB 3, Section 4.2.3) for a more elaborate discussion on this topic). However, even if such an encoding is in place, the choice for EA may still be illadvised, and indeed, ill-argued as well (Craenen and Eiben, 2005). The fact that a problem is NP-hard in nature, does not per se justify using EAs:

82

Designing heuristics for dynamic scheduling

1. The actual problem may be relatively small, in which case even exhaustive search is feasible. Using the building blocks proposed before, this would always be a first step, before large scale search space exploration is even tried. 2. The problem may have regularities that facilitate rapid and efficient neighborhood browsing, whereas EAs are very course-grained. In the building blocks, the regularities are taken into account in the design of the right solution encoding, neighborhood and later the objective function. After this is done, less erratic search algorithms will usually be better suited to solve the problem than EAs. 3. Desirable solutions often have a large internal coherence: they are not just concatenations of ‘promising bits’. In such cases, it can be unlikely for an EA to efficiently reach optimality: good parts of a solution hidden between bad parts will not excel, since they only work in combination with the whole of the solution. Therefore, those otherwise bad solutions have a very small chance of reproduction, will not survive in the population, and will therefore not contribute their ‘ideal part’ to the eventual optimal solution. Using the presented building blocks, such internal coherences are taken care of firstly in the solution encoding. After that, specific heuristic elements can be created that can very well distinguish between promising bits and ‘waste’. Doing so will produce much more efficient problem solvers. 4. When applying EAs, a layer of complexity is added. In addition to carefully designing the chromosome-solution mapping, a number of parameters has to be set. The population size, the type of crossover, the way in which mutation is performed, the mutation rate, the solution acceptance criteria, to name some. The ideal setting of these parameters is in itself a difficult problem (Eiben et al., 1999), which may take the designers attention away from the actual problem. Furthermore, ‘the ideal setting’ may not even exist, as different problem scenarios may call for different settings. In the proposed framework, more straightforward problem solving techniques or even alternative metaheuristics are preferred, that have less added complexity of their own. 5. Running an EA is notably processor intensive. That is a large price to pay, especially when problem solving speed is important, as is the case in (highly) dynamic scheduling. On the other hand, two strong points speak in favor of using EAs: 1. Unlike, for example, Neural Networks, the internal solution structure of EAs is well accessible. This means that the researcher can actually ‘learn’ from EAs

4.3. Elevator dispatching case study

83

by following the problem solving process: What evolutionary leaps can be observed? Where are EAs lagging behind? In thus skillfully playing with EAs, the researcher gains insight into the actual problem, possibly leading to a better (non EA) problem solver in the future. Nevertheless, such judicious tinkering can also be applied when learning from other kinds of algorithmic approaches, not just EAs. 2. Considering the above one could argue that expensive, complexity inducing procedures like EAs perform even worse in dynamic scheduling. The time needed to create new populations simply is not there, and the time needed for the algorithm to converge may be larger than the change interval that constitutes the dynamicity. There is, however, one particular quality of these approaches, namely their innate robust tendencies, that may make them interesting for dynamic problems. As soon as the situation changes, the variety of solutions that are stored in a population could make it possible to quickly adjust to the new situation. In such attempts, special consideration should be taken in maintaining population diversity. Normally, the population as a whole tends to converge towards the alleged optimum. When not only optimality, but also diversity is used as a deciding factor in creating new populations from previous ones, a diverse population can be maintained that will have several ‘islands’ of solutions that are more closely grouped, but at greater distance from other near-optimal islands (Liu and Ranji Ranjithan, 2010). In summary, the difficulties that arise when making EAs suitable for problem solving at all, especially in the case of scheduling, and even more so in the case of dynamic scheduling, in addition to the difficulties with an added complexity layer make EAs an unlikely candidate for at least dynamic scheduling, but likely for other constraint satisfaction problems as well. However, when wisely used and carefully justified, they may play a useful role in pilot studies and in obtaining flexibility.

4.3

Elevator dispatching case study

In order to investigate the Research Questions and the usability of the building blocks in the domain of highly dynamic scheduling problems, the elevator dispatching problem was chosen as the topic for a case study. The elevator dispatching problem is an ideal candidate for such studies for a number of reasons: 1. First, it is a computationally complex problem. It has been proven NP-hard (Seckinger and Koehler, 1999), and during busy periods of the day (morning up-peak, lunchtime-peak and afternoon down-peak), the number of possible elevator assignments for tasks currently known greatly exceeds the limits of

Designing heuristics for dynamic scheduling

84

efficient computability. This has lead to the use of complex algorithms such as evolutionary algorithms and hybrids, giving rise to RQ’s 1 (neighborhoods and objective functions), 2 (evolutionary algorithms) and 3 (hybrids). The building blocks 3 (on solution encoding), 4 (on hybridization), 5 (on heuristic interaction), and the advice on evolutionary algorithms (‘BB 6’) are expected to play a large role in engineering a good elevator dispatcher. 2. Computational complexity notwithstanding, the real difficulty lies in the fact that the problem is highly dynamic. During the execution of a plan, numerous change events occur that can hardly be foreseen (de Jong, 2002). Such a situation gives rise to RQ 5 (flexibility and robustness), and the use of BB 5 on heuristic interaction. 3. On a second-order level, the problem is also dynamic in the sense that its nature changes over the day. The time between passenger arrivals varies greatly over the day, and various traffic patterns occur. Siikonen (1997) distinguishes 36 different traveling patterns where the type of traffic is combined with the intensity of the traffic. This gives rise to RQ 3 (hybrids) and the use of BB 3 on hybridization. 4. Elevator dispatching can be simulated accurately. However, in many studies3 , self-generated passengers are used to assess the performance of a proposed dispatching scheme. This gives rise to RQ 6 (benchmarks), and the use of BB 2 (realism measures). 5. Different setups exist for elevator systems. In conventional control, elevators are hailed using up and down buttons. In destination control, the passenger asks for vertical transport by stating his desired destination immediately, which has been shown to increase performance (Koehler and Ottiger, 2002). Apparently, the scheduling environment can be altered to change the behavior and performance of the system, giving rise to RQ 4 (environment). BB 1 (on system design enhancements) can therefore play a role in the setup of an elevator system. 6. Since destination control makes it possible to individually assign passengers to elevators, this setup resembles generic job shop scheduling problems (JSSP, Section 2.1.1), in which individual tasks can be allocated to individual machines. Much like in JSSPs, this process is subject to various constraints and aims to satisfy various possible optimality criteria. For this reason, results found using an elevator dispatching case study with destination control, may very well be usable in other scheduling areas as well. 3 Out

of 13 studies on elevator dispatching referenced, 11 used self-generated data.

Part II

Case study: Elevator dispatching

5 Introduction to elevator dispatching In the previous chapters, we have seen dynamic scheduling as a specific type of scheduling problem, requiring special attention. Chapter 4 connects open issues to generic research questions, that are addressed in a number of proposed building blocks. In Section 4.3, the elevator dispatching problem is introduced as a suitable topic for a case study in highly dynamic scheduling, to closer investigate the research questions and the use of the building blocks. This chapter presents the elevator dispatching problem in general, outlining its particularities in comparison to generic scheduling in Section 5.1. Section 5.2 presents research hypothesis that root in the research questions from the previous chapter, but are focused on the elevator dispatching problem. In the next chapter, the simulation environment and experimental methods will be described, after which Chapter 7 will present experiments that have been run, according to each of the research hypotheses presented in this chapter.

5.1

Background

The Elevator Dispatching Problem (EDP) consists of a number (≥1) of elevators that each serve multiple floors in the same building, and a number (≥1) of requests r. Requests r a tuples < t(r ), o (r ), d(r ) >with • τ (r ) the time at which r becomes known, the so-called hall-call time, • o (r )the origin floor of r, which becomes known at τ (r ),

Introduction to elevator dispatching

88

Figure 5.1: Schematic overview of a building with four elevators, serving eight floors (Ground Floor included). Some passengers are waiting and have indicated their desired travel direction. Some passengers are already in an elevator, and have indicated their destination (visible as circles along the path of the elevator).

• d(r )the destination floor of r, which may become known at a later time than τ (r ). Requests become known over time, and the transportation task is to carry r from origin to destination without pre-emption (generic problem description adapted from Friese and Rambau (2006)). This section outlines the EDP in more detail, by showing the different setups possible for elevator installation in the first subsection. From Subsection 5.1.2 on, we are discussing the EDP as an instance of generic scheduling. This involves a discussion on scheduling constraints (5.1.2), optimality criteria (5.1.3), followed by a discussion on how EDP can be described in the α| β|γ-notation of generic scheduling (5.1.4). Subsection 5.1.5 discusses the complexity of the EDP. Subsection 5.1.6 discusses similar studies. Lastly, Subsection 5.1.7 finalizes this section with conclusions: addressing gaps within current research, and challenges for the case study in this dissertation.

5.1.1

Elevator system setups

Everyday elevator systems follow the general setup depicted in Fig. 5.1. Passengers requiring vertical transportation make their wish known at a certain keypad, in this case an up- or a down-button. Once an elevator arrives in the right direction, the pas-

5.1. Background

89

senger enters and makes his destination known using a keypad inside the elevator. This setup is called Conventional Control (CC), and comprises the majority of elevator installations. Usually, all elevators have the same parameters (capacity, speed), and all passengers have the same priority. Larger buildings may have slightly different setups that still follow the general scheme, e.g., elevators A-D handle traffic for the Ground Floor and the first 20 floors, elevators E-H handle traffic for the Ground Floor and floors 20-40, etc. In this case, zoning is done by blocking access to certain floors. In other situations, large shuttle elevators bring groups of passengers to lobbies on a few locations in the building, where the passengers change elevators to go to their final destination (de Jong, 2008). In destination control (DC) on the other hand, the user calls an elevator by entering his destination instead of just his direction at the keypad of his origin floor. The dispatcher determines the elevator that will be serving the call, which is communicated to the passenger using a display near the keypad. The passenger enters only that particular elevator upon arrival, and is transported to his destination. Inside the elevator, there is no input device to enter destinations anymore. The elevator’s schedule is a little more constrained, since the elevator cannot visit a floor to deliver a passenger in one direction, and then continue in that direction, when a passenger wanting to travel in the opposite direction is waiting on that floor for that particular elevator as well. This is because the waiting passenger would get in, and inadvertently make a detour - which is not allowed. More specialized setups exist, e.g., when elevators in the same building may differ in speed and size, when passengers have different priorities, or when passengers are not allowed to travel together. The latter situation may be the case in hospitals, where such grouping approaches could be useful to give priority to patients being transported to operating rooms, and to separate groups like cleaning staff and carriers of sterile goods (Schindler, 2004). In more futuristic scenarios, more elevators can travel independently in the same shaft (Thyssen, 2010; Duenser et al., 2002). This leads to specific scheduling constraints, and elevators having to ‘negotiate’ their traveling wishes with each other.

5.1.2

Constraints

When placing the EDP in terms of generic scheduling, and to gain a better insight into the problem itself, this subsection discusses a number of (potential) EDP scheduling constraints: • The amount of passengers inside the elevator cannot exceed the elevator’s capacity. • The elevator cannot travel in another direction than the traveling direction of

90

Introduction to elevator dispatching

any passenger currently inside the elevator. This constraint encompasses similar constraints often seen, like: – There cannot be two passengers inside the elevator with opposite traveling directions. – A passenger cannot make a detour when traveling from origin to destination floor - only stopovers on the way there are allowed. • An elevator’s trip always ends with a stop on a floor in the current traveling direction. This constraint means that no elevator, not even an empty one, can change direction ‘in mid-air’, or just stop at any height. However, if there are no people inside the elevator, mid-air changes could be the fastest solution by far to begin executing other jobs than previously foreseen. Especially in the case of elevators that have no exit for a large number of floors, relaxing this constraint might be a good idea. When there are people inside the elevator, this constraint cannot be relaxed without violating the previous constraint. • An elevator that carries passengers will not remain at a certain stopover longer than necessary. This closely resembles the no-wait scheduling paradigm used in Job Shop Scheduling Problems. • The various studies involving passenger elevators that are referenced in this dissertation 1 , all assume an even stronger constraint: An elevator with a nonempty task list will not remain at a certain position longer than necessary. This means that once allocated a task, the elevator will as fast as possible execute that task. No studies have been found in which this constraint was relaxed. However, it would be an interesting addition to actually allow this, as it could possibly prevent the situation where a large part of the building cannot be serviced by an elevator on short term: wait until another elevator is nearby to take over, before carrying out the next task. • (For DC systems:) Passengers once allocated, cannot be reallocated to another elevator. • All studies found also assume a speed constraint: an elevator will always move as quickly as possible to its next destination. 1 Crites and Barto (1996); Duenser et al. (2002); Hakonen et al. (2004); Jamaludin et al. (2009); de Jong (2002, 2008); Kim et al. (1998); Koehler and Ottiger (2002); Miravete (1999); Muñoz et al. (2008); Nikovski and Brand (2003a,b); Peters et al. (2000); Sachs (2005); Schindler (2004); Seckinger and Koehler (1999); Siikonen (1997); Smith and Peters (2004); Sorsa et al. (2003); Thyssen (2010); Tyni and Ylinen (2006)

5.1. Background

91

This means that for a moving elevator, either the current jerk is maximal, or the acceleration/deceleration is maximal, or the speed is maximal. To the best of my knowledge, I have not encountered a relaxation of this constraint. Still, that would be an interesting move: empty elevators heading towards a parking floor or towards a pickup floor in light traffic conditions, could save energy by reducing acceleration or speed. Even the acceleration and speed with passengers on board under light traffic conditions might be reduced. However, such a scenario is unlikely: the passengers might get the feeling that ‘something is wrong’ - and start pressing the alarm button, or they will at least be annoyed. • (For multimobil systems:) Elevators are not allowed to move within a certain safety distance of each other. The situation of multiple elevators in one shaft is fairly new (Duenser et al., 2002; Thyssen, 2010), and poses both control and mechanical safety challenges. The safety distance may be speed dependent, e.g., elevators are not allowed to move in a manner in which breaching the safety distance is unavoidable. This means that although the elevators may be allowed to stop at adjacent floors, maneuvers at a much greater distance but speeding towards each other could be disallowed. • (For multigroup ID systems:) Elevators are not allowed to stop at a floor that is not in the intersection of allowed floors of all passengers in the elevator (Schindler, 2004). Some of the constraints are typical for scheduling problems in general, e.g., the fact that an elevator cannot be overloaded. Some are closely related to well-known constraints. The constraint that an elevator cannot change direction while serving passengers could be seen as a variant of no-preemption allowed. Some are specific for elevators, such as the high-speed constraint, and the no-reallocation constraint. In general, however, the elevator dispatching can easily be understood in scheduling terms.

5.1.3

Optimality criteria

Several objectives can play a role when dispatching elevators. Due to the dynamic nature of the problem, the extent to which these objectives have been met can only be fully assessed afterwards, off-line. What constitutes optimality may differ for different elevator installations, or different customers, and will consist of a combination of the objectives that are discussed here. The first two objectives focus on the traveling passenger. Although the passenger may be the primary user, he is not the customer,

Introduction to elevator dispatching

92

which is usually a building owner. The last two objectives are only important from the viewpoint of the customer of an elevator system. However, when it comes to performance evaluations and comparisons in literature, they are always evaluated using the first objective: average total time. Chapter 6 will detail how such comparisons are made in the context of the present study.

Objective 1: Minimize average waiting/completion time

300

600

250

500

200

400

150

300

100

200

50

100

0

Number of passengers

Time (s)

Elevator system performance, 1 day.

av waiting w10% waiting av total w10% total #passengers

0 0

3

6

9

12

15

18

21

24

Time (hours)

Figure 5.2: Traveling times over a day. The day is split up in 96 15-minute blocks, for each of which all values are shown. In this example, during lunch-peak, about one passenger per 1.5 seconds registered a call.

Although the average waiting time and the average total time can both be given as a single number, these values are often depicted over a full day of simulation (see Fig. 5.2). This shows the performance under variable circumstances, as the traffic type and the crowdedness will vary over the day. Average times are the single most used evaluation criteria found in literature (Crites and Barto, 1996; Friese and Rambau, 2006; Hakonen et al., 2004; Jamaludin et al., 2009; de Jong, 2008; Kim et al., 1998; Koehler and Ottiger, 2002; Nikovski and Brand, 2003a,b; Siikonen, 1997; Smith and Peters, 2004; Sorsa et al., 2003; Tyni and Ylinen, 2006). Most of the articles use both waiting and total time, although some focus on waiting time only. The total time (waiting time + ride time) is sometimes dubbed ‘journey time’ (Sorsa et al., 2003), or even, confusingly, ‘call time’ (Siikonen, 1997; Tyni and Ylinen, 2006).

5.1. Background

93

Objective 2: Minimize extreme times Apart from the averages, building owners may be interested in worst-case scenarios. Better averages may be reached by ‘sacrificing’ the performance for a small number of passengers that were difficult to schedule, however, the chances of that happening should be kept to a minimum. Keeping track of the worst-off passenger may not be useful, since a typical elevator-day, such as the one used in this study, contains over 10000 passengers. In such circumstances, there will always be several extreme cases. Nevertheless, this is sometimes done (e.g., Friese and Rambau (2006)). A more tempered measure is used in some articles that measure the percentage of passengers waiting more than 60 seconds, sometimes dubbed Long Waiting Percentage (LWP) (Crites and Barto, 1996; Hakonen et al., 2004; Kim et al., 1998). Alternatively, average squared waiting times are sometimes measured alongside average waiting times. Extreme values become more clearly apparent when values are squared (Crites and Barto, 1996; Friese and Rambau, 2006). Minimal waiting and total times are not of much consequence, as there will probably always be lucky passengers that could enter immediately (zero waiting time) and where transported to their destination without stops (shortest possible traveling time), even in crowded situations. An example graph of traveling times over the day is given in Fig. 5.2. Spreading of total travelling times 2500

Number of passengers

2000

1500

1000

500

0 10-20 20-30 30-40 40-50 50-60 60-70 70-80 80-90

90100

100110

110120

120130

130140

140150

150160

160170

170180

180190

190200

200+

Time category (seconds)

Figure 5.3: Spreading of total times, the time it takes from registering a hall call to arriving at the destination floor. When comparing histograms of this type, an peak value more to the left and a shorter, less thick, ‘tail’ are preferred.

Introduction to elevator dispatching

94

Since a 60 seconds waiting time appears to an arbitrary value, that might be considered more or less acceptable depending on the size of the building, this study uses average Worst 10 Percent (W10%) times: the average waiting or total time for the 10% of passengers that were worst-off. This measurement, however, has not been found in the literature. The W10% times have been added to the graph in Fig. 5.2, showing the spreading of traveling times of passengers. This spreading can even better be depicted using a histogram that shows the amount of passengers served within certain timewindows. When the number of passengers is large enough, this leads to a curve as depicted in Fig. 5.3. A diagram with a higher peak that is located more to the left is preferable, as is a diagram with a short ‘tail’. Such diagrams can alternatively be made for a range of specific situations, to evaluate the system’s performance in that particular circumstance. Note that leftish-peaks and short tails correspond to low-averages and low-worst-10% values, respectively. This type of graph can also be found in the literature (Miravete, 1999; Siikonen, 1997). Objective 3: Maximize passenger handling capacity Elevator system's performance, times vs. crowdedness 600

500

Time (s)

400 av waiting max waiting av total max total

300

200

100

0 0

20

40

60

80

100

120

140

160

180

200

Crowdedness (#passengers / 5 minutes)

Figure 5.4: Performance vs. crowdedness: the day is subdivided in 5-minute blocks. Those in which at least five passengers have travelled, are used to calculate the different values. In this graph, next to averages, maximum values were used instead of worst-10% values. Especially maximum values increase sharply when saturation is reached. When comparing graphs of this type, lower trendlines, less-steep trendlines and later upswings are preferred.

Whereas a normal day-chart shows averages over the day, it can also be interest-

5.1. Background

95

ing to offset the averages to the crowdedness (number of passengers per time unit) in the building (see Fig. 5.4 for an example) (de Jong, 2002, 2008; Siikonen, 1997; Sorsa et al., 2003; Tyni and Ylinen, 2006). This way, the stability of the system under different levels of pressure can be measured. A lower regression line is preferred, but maybe even more important than that is a less-steep regression line, as this indicates that the system has a more equal performance under various circumstances. Another important evaluation criterion that can be drawn from such a graph is the over-crowdedness threshold. This is the maximum amount of passengers per time unit for which the averages progress in a predictable manner. After this threshold, the averages increase sharply. The capacity of the elevator system’s performance has been reached. The further this moment is on the right side of the graph, the better. It can be used to compare the performance of different schedulers or dispatching situations. For the building owner, maximum throughput under acceptable traveling times is important. More important may be the footprint of the elevators in the building: the amount of (expensive) floor space occupied by elevator shafts. The question is then: what is the minimum amount of elevators needed to guarantee acceptable performance? For most installations, however, the saturation point depicted in the graph has a more academic importance in comparing scheduling approaches than it is of practical use: average values around this point tend to be far above the desired maxima for the building during the most crowded periods. Objective 4: Minimize energy usage Elevators in a large office building consume about 5% of a the total building’s electricity usage. There are a number of measures to counteract this, mostly in the mechanical domain, some in the control domain. Up to 30% energy decrease can be reached by using appropriate motors, regenerative breaking, turning off the interior lights when the elevator is not used, etc. Another 5% energy decrease can be reached by smart controls (Sachs, 2005). Tyni and Ylinen (2006) of KONE research describe an approach where the energy needed to transport a number of passengers between two floors is exactly known. A Pareto-trade-off is then made between speed of operation and energy consumption. Much of these schemes result in letting less elevators do more, while this is acceptable with respect to performance. Such a scheme will likely save most energy in less crowded times, when some elevators can be left idle and all of the traffic can be handled by a subset of the elevator group.

5.1.4

Classification within generic scheduling

The elevator dispatching problem consists of allocating passengers to elevators, and ordering the allocated tasks (passenger rides) within a specific elevator. This may

Introduction to elevator dispatching

96

be seen as a strict planning problem. However, the timing aspect of the operations added to the dynamicity of the problem make it more of a dynamic scheduling problem. Apart from naming conventions, it is difficult to pinpoint the elevator dispatching problem in standard scheduling terms, like the α| β|γ notation (see Section 2.1). The problem would most straightforwardly be notated as:

Pm|r j s jk p jk batch(cap)| ∑ C2j where • Pm indicates m parallel, identical machines on which the tasks are to be performed. The machines would in this case be the elevators, and indeed they are often, but not always, identical. • r j indicates the fact that job j has a release date. Before the passenger arrives and makes his traveling wish known, he cannot be served. However, not only has a job a certain release date, it is not even known before that moment. • s jk indicates setup-times between jobs j and k. It is true that an elevator needs a setup time before it can begin processing a passenger: it has to travel to the origin floor and open its doors first. However, as more than one passenger, or job, can be processed at the same time, these setup times do not depend on the sequence of the jobs alone. Furthermore, as more jobs are processed at the same time, setup times increase (e.g., doors have to be open for a longer period of time). • p jk is a non-existent notation, used here to denote the fact that the processing time of job j depends on another job k that is carried out simultaneously. For example: a stop-over during the ride from origin floor to destination floor to pick up another passenger will increase the processing time. The fact that other passengers exiting on the same floor have to get out as well, increases the time needed to get out of the elevator (and, hence, to finish the trip). • batch(cap) indicates that multiple jobs can be executed at the same time, in this case the capacity cap of the elevator. They do not even have to finish synchronously. The batch is finished when the last job in the batch is finished. However, with elevator dispatching, the batches are not constant groups of jobs: passengers may leave the elevator while others continue their travel, and new passengers may enter an elevator that is already carrying other passengers. Seen this way, the batch could be a very large group of passengers that are only in the batch for a relatively short period of time. This is not the type

5.1. Background

97

of grouping for which the notion batch was created, and it will not help us find similar research that is also applicable to the elevator case. • ∑ C2j denotes the objective to be optimized. Squared completion times are used to increasingly penalize schedules where waiting and processing times increase, with the objective to lower the extreme values as they are considered unacceptable. Also, it could reflect the psychological assumption that the amount of frustration in a waiting passenger increases nonlinearly as time goes by. In this case, waiting twice as long will make someone four times as frustrated (Smith and Peters, 2004; Crites and Barto, 1996). In summary, fitting the elevator dispatching problem in standard scheduling terms is possible, but it is only a partial fit. Moreover, since elevator dispatching has some particularities and most of the difficulty lies in its dynamicity (the fact that future passenger calls can hardly be foreseen), such a fit is hardly helpful. Therefore, dynamic scheduling problems like the elevator dispatching problem are not typically described in α| β|γ form. But even if it were possible, closely resembling the above used notation, there would to the best of my knowledge not be any standard problem solvers available that would fit this scheme.

5.1.5

Complexity

In the previous few subsections, we have seen the elevator dispatching problem described in terms of constraints, optimality criteria and generic scheduling notation. An important quality of any scheduling problem is its complexity, which is the topic of this subsection. Seckinger and Koehler (1999) have proven the DC Elevator Dispatching Problem to be NP-hard. This means that, treated as a series of static scheduling problems, no efficient algorithm is known to solve it. Exhaustive search is the only option to guarantee optimality. For single elevator setups, or little-used elevators in, for example, apartment blocks, such is perfectly well possible. However, for more demanding installations in office buildings, this is infeasible. To showcase the infeasibility of exhaustive search, the notion of circles is introduced to describe elevator schedules. The circle representation as depicted in Fig. 5.5 maps passengers to circles, thereby completely defining the elevator’s schedule. As each mapping of passengers to circles produces a unique elevator plan, it is now possible to calculate the number of possible plans as a function of the number of passengers. Each passenger’s mapping to a circle corresponds to putting him in a certain group. The number of possible groupings of n passengers is given by the Bell number:

Introduction to elevator dispatching

98

1

2

1

3 ...

1

2

Figure 5.5: Elevators run in ‘circles’: a leg in upward direction followed by a downward leg. The legs do not necessarily start or end at the extreme floors. The floor that changes direction belongs to the new leg. Therefore, the lowest and the highest floor can only belong to an upward and a downward leg, respectively. Groups of one or more passengers that are waiting on the same floor and traveling in the same direction can be allocated to a certain circle. Any mapping of passenger groups to circles completely defines an elevator’s schedule. The graph on the right shows two possible mappings, the right mapping having two stop-overs less than the left mapping.

n

Bn =

∑ S(n, k)

k =0

With S(n, k ) the second kind Stirling number, denoting the possible number of ways to group n individuals in exactly k groups. For k groups there are k! different orderings. So for any number of passengers, the possible number of schedules is n

∑ k! · S(n, k)

k =0

with 1 S(n, k ) = k!

k

∑ (−1)

k i

i

i =0

!

(k − i )n

this results in a total number of possible plans equal to n

k

∑ ∑ (−1)i

k =0 i =0

k i

!

(k − i )n

The number of possible plans for the example in Fig. 5.5 alone amounts to 7087261, a number that makes exhaustive searching impossible. Given the time

5.1. Background

99 Number of concurrently waiting passengers per timeslot

60

600

55 50 45

#waiting passengers

40

400

35 30

300

25 20

200

15 10

#total passengers within that timeslot

500

Maximum Average Minimum Total

100

5 0

0 0

3

6

9

12

15

18

21

24

Time (hours)

Figure 5.6: Example of the number of waiting passengers over the day, using a DC setup. The lowest circle-marked line indicates that within each 15-minute time frame, there were never less than that amount of waiting passengers. The block-marked line (below the total amount of passengers line) means that within a particular time frame there has been at least one time interval during which that amount of passengers has been waiting. The triangle-marked line in the middle indicates the average amount of waiting passengers during that time interval.

needed to calculate the objective value of a certain route, the threshold amount for exhaustively searching possible schedules within a 0.1 second time frame, is in the order of 1000 schedules. Only with five or less waiting passengers, this criterion is met (541 possible plans). Starting from six passengers (4683 plans), the number becomes too large, and grows exponentially. Fig. 5.6 shows a day overview of the log file used in this study. We see that between 9am and 15pm, give and take, the average amount of waiting passengers was at least 5. Between 11:15am and 1:30pm, it was only occasionally less than that, with a peak of 45 waiting passengers somewhere between 11:15am and 11:30am. These figures show that a large majority of the passengers are transported during a time where exhaustive search is infeasible. When comparing to Fig. 5.2, this also appears to be the time for which optimization is most needed. The numbers are only valid for DC. For CC, the number of possibilities will be lower, as passengers waiting on the same floor to travel in the same direction cannot be distinguished. An exhaustive comparison of plan options will be possible for a longer period of time. On the other hand, this comes at the cost of greater uncertainty: whereas DC has full knowledge of each passenger’s destination, in CC this can only be guessed at. Heuristics will still have to be used to make informed

Introduction to elevator dispatching

100 decisions on elevator dispatching.

However, even if finding the exact best solution would be possible for sufficiently small instances, it would still be impractical as for those situations that we aim to better solve, the schedule will always be outdated before its running horizon is over - rendering the notion of ‘optimality’ void (see Section 3.1.3). In summary, therefore, the elevator dispatching problem proves to be a processor intensive problem, in which considering all possible passenger-elevator-circle combination is not possible during the large periods of the day with medium to high traffic intensity. Moreover, the real complexity lies in the fact that future passenger calls cannot be forecasted. This leads to schedules that are outdated long before they are finished executing.

5.1.6

Existing studies

The previous subsections show a number of challenges: shorter waiting/traveling times, less extreme waiting/traveling times, higher passenger throughput, lower energy consumption, lower building footprint, all combined with a high problem complexity. Several recent attempts try to answer to these challenges. However, since the passenger throughput of an elevator installation is an important (selling) quality, the majority of research performed on elevator dispatching is not publicly available. Comparing the performance of any dispatching algorithm to a ‘currentlyknown-best’ solution is therefore impossible. Nevertheless, several hints are given at current approaches, and approaches by researchers that are independent from an elevator manufacturer (such as this study) can be accessed. The studies discussed in this subsection are connected to various key topics from dynamic scheduling that have already been distinguished in Chapter 4.

Alternative hardware In some of the studies found, the elevator installation itself was changed. In a Schindler study, Duenser et al. (2002) propose a system, MultiMobil, in which multiple elevators can ride in the same shaft, and are able to change shafts. The elevator cars are independently driven by linear motors, both vertically and horizontally. Although technically possible, as of yet (2012) no such installation has been in operation. The major benefit of such a system would be a higher throughput utilizing a smaller footprint within the building (less shafts). ThyssenKrupp currently manufactures a system, called TWIN, in which two elevators move within the same shaft (Thyssen, 2010). Since the system uses conventional ropes for the elevator cars, putting it to operation is less of a revolution than MultiMobil would be. Although

5.1. Background

101

promising approaches, in this dissertation, such alternative setups will not be focused on. Informedness Schindler has pioneered in increasing the informedness of the elevator group control system, with the creation of the Miconic 10 DC system and the SchindlerID system (Schindler, 2004). The DC system is explained in Section 5.1.1. Being able to individually direct passengers to elevators increases system performance, especially in up-peak circumstances. SchindlerID elaborates on this scheme by discriminating passenger groups. This enhances building security, by not allowing unauthorized passengers to move to certain floors. Furthermore, special groups can be given priority (e.g., hospital personnel hurrying to an operation room), and groups can be separated so that they do not travel together (e.g., cleaners and carriers of sterile goods). The one typical disadvantage of DC is the fact that a passenger-elevator allocation is to be made immediately upon hall call. Such early decisions may hamper the scheduling performance (Section 4.2.1). Evolutionary algorithms Evolutionary algorithms often play a role in studies that have been made public (Sorsa et al., 2003; Miravete, 1999; Tyni and Ylinen, 2006). All of these studies concern CC systems, in which more time is available for calculation than in DC. Also, fairly straightforward chromosome-mappings are used, that map hall-calls to elevators. In these experiments, the order in which to handle the hall calls is not dealt with: an elevator will simply move to the first assigned hall-call or landing-call in its current traveling direction, or it will change direction. These studies are therefore in conflict with the statements made in Sections 4.2.3 (on solution encodings) and 4.2.6 (on evolutionary algorithms). Robust schedulers (first-order dynamicity) In recent years there has been some interest in trying to factor in yet-unknown information. In a previous study (de Jong, 2002), the destinations of passengers behind a hall call were forecasted, so as to enable a DC scheduler to operate a CC installation, or create a hybrid DC/CC system. Nikovski and Brand (2003a,b) perform a similar study (guessing destination of passengers that have not yet entered), however, with a different goal. Their aim is to estimate the amount of extra stopovers the elevator will have to make because of these passengers. This estimation is used to calculate traveling times for the elevator, which in turn is used to determine the most profitable elevator when a new hall-call comes in. Hakonen et al. (2004) take a

102

Introduction to elevator dispatching

more broad view, calculating Estimated Times of Arrival (ETA) using a degrade coefficient. The predicted waiting times for passengers that are not yet being served are multiplied by this (constant) factor. The first study (de Jong, 2002) is in conflict with the studies by Nikovski and Brand: the former shows that passenger destinations can hardly be forecasted, which would make it difficult to use them in an algorithm, as it is done in the latter studies. Furthermore, since the EDP has a high second-order dynamicity, it is questionable whether a constant degrade coefficient would suffice to predict waiting times under various traffic situations. However, most of the articles referenced do not take robustness or flexibility into account (Crites and Barto, 1996; Jamaludin et al., 2009; Kim et al., 1998; Koehler and Ottiger, 2002; Miravete, 1999; Siikonen, 1997; Sorsa et al., 2003; Tyni and Ylinen, 2006). Adaptive schedulers (second-order dynamicity) Several articles focus on second-order dynamicity (Muñoz et al., 2008; Kim et al., 1998; Jamaludin et al., 2009). Each of these studies use a fuzzy rule-base that distinguishes the current traffic type, and applies a matching scheduling scheme accordingly. The articles use similar discriminating criteria for the rule base, which suggests consensus on this point. The adaptive system that results is a promising approach to handle second-order dynamicity. Nevertheless, none of these articles focus on potential drawbacks such as switching artifacts that are expected when hot-changing of algorithmic approaches, or on the complementary qualities of the various basic algorithms in the pool (Section 4.2.4). Testing Only one of the articles referenced from the field of elevator dispatching used real passenger data to perform experiments on (Koehler and Ottiger, 2002). Most of the articles do make an effort of modeling traffic patterns to observations (diverse traffic patterns, diverse crowdedness), but they all strongly rely on Gaussian arrival rates of self-created passengers (e.g., Muñoz et al. (2008); Nikovski and Brand (2003a); Kim et al. (1998); Crites and Barto (1996)). Another article even mentioned that “it is not possible to obtain comprehensive data in a controlled manner from elevators running in a real building” (Tyni and Ylinen, 2006). The latter statement is clearly falsified by the first-mentioned article. Nevertheless, most of the research in this field relies on self-generated test data, of which it is unclear to what extent it resembles actual passenger flows in real buildings. Furthermore, all of the articles referenced on elevator dispatching used average

5.1. Background

103

values over a varying number of experiments to assess results. None of the articles used statistic measures to assess the significance of differences found, even though these were sometimes very small (e.g., Hakonen et al. (2004)).

5.1.7

Discussion

In this section, the elevator dispatching problem is introduced as a hard, highly dynamic scheduling problem. The most common installation setups were outlined, typical constraints on the system, and how optimality is assessed. Elevator dispatching has strong timing issues and specific constraints, it does not closely resemble any well-known scheduling problem. The problem is NP-hard, and exhaustive search is infeasible even under comparatively ‘light’ scenarios. Moreover, the dynamic aspect of the elevator dispatching problem makes it notoriously hard to solve. Although corporate research is not publicly available, some research directions can be deducted from generic publications or independent research. However, some gaps and potential disadvantages have been indicated. Combined with the more generic Research Questions posed in Chapter 4, this leads to the distinction of several issues: 1. Most studies by far use self-generated test data to perform experiments on, which had been noticed for scheduling research in general as well. None of the studies used proper statistic tests to assess the significance of performance differences that were found, which had also been noticed for generic scheduling. These observations had led to RQ 6 (Section 4.1.3.1). The building block on realism (BB 2, Section 4.2.2) prescribes the use of actual data as much as possible, and the use of proper tests to assess the significance. As a prerequisite to the experiments described in Chapter 7, Chapter 6 will outline how these issues are dealt with in the current case study in Section 6.2. 2. Two major control modes coexist (CC and DC). Their major differences lie in the area of informedness and the timing of scheduling decisions. These issues have already been distinguished as important in scheduling research in general, leading to RQ 4 on the scheduling environment (Section 4.1.2.1) and the building block on system design (BB 1, Section 4.2.1). The building block states that early information and late decisions are profitable for a scheduling system. It would therefore be interesting to know what the performance difference between these two under typical elevator circumstances is. Furthermore, we have seen that a disadvantage of DC is that it has to take decisions early, which cannot be changed anymore. What more performance increase is to be expected when the decision timing in DC can be stretched?

104

Introduction to elevator dispatching

3. Complex algorithms such as evolutionary algorithms are regularly used for elevator dispatching. However, none of the research articles mentioned compares them with well-performing straightforward algorithms, nor are the specific downsides of using EAs discussed. The same is true for dynamic scheduling in general, leading to RQ 1 and 2 (Section 4.1.1.1). The building block on heuristic interaction (BB 5, Section 4.2.5) focuses on using algorithms and algorithmic subparts that are less complexity inducing. The building block on evolutionary algorithms (BB 6, Section 4.2.6) even goes so far as to discourage their use in such an environment. The question arises, therefore, what the best suitable algorithmic setup for elevator dispatching is, and what the performance difference between EAs and less complexity-inducing algorithms is? 4. The observed robustness and flexibility measures for first-order dynamicity are still rude: they leave out unknown future passengers, or assume a constant passenger rate throughout the day. In most articles, the issue is not even acknowledged. Not acknowledging the importance of robust and flexible scheduling was already observed in generic scheduling, leading to RQ 5 (Section 4.1.2.2). The building block on heuristic interaction (BB 5, Section 4.2.5) aims at carefully incorporating robustness and flexibility measures into a highly dynamic system, since much performance gain is expected when doing so. In the case of elevators: what performance increase is to be expected by investing more attention in this area? 5. Several hybridization attempts are made in the case of scheduling, always to cope with second-order dynamicity. However, the downsides of such a hybridization (increased complexity, switching artifacts) were not given much attention, comparable to what was found in generic scheduling (RQ 3, Section 4.1.1.2). The building block on hybridization (BB 4, Section 4.2.4) primarily aims at combining ad hoc and full reschedulers and combining complementary algorithms in an adaptive hybridization. However, in none of the articles, ad hoc and full rescheduling were combined. In the articles discussing adaptive hybridizations, the actual dispatchers that were combined were rather simple, ad hoc methods. Also, these hybridizations focused on CC, paid no attention to switching artifacts, the choice of cross-over points in the fuzzy rule base, and the complementary qualities of the algorithms in the pool. The question arises how ad hoc and full rescheduling can be combined in the case of elevator dispatching, and what performance increase is to be expected when using such fuzzy rule systems to switch between well-tuned full schedulers in the case of DC? From the issues mentioned above, issue one relates to a experimentation prerequi-

5.2. Research hypotheses

105

site, and is dealt with in Section 6.2, prior to the chapter on experiments. The issues two-five are elaborated on in the next section, leading to four generic research hypotheses.

5.2

Research hypotheses

The four generic questions asked in Section 5.1.7 lead to a number of research hypotheses that are discussed in this section. These hypotheses are broadly formulated. In Chapter 7, these hypotheses are closer investigated in the same order as presented here. To focus the study, operational hypotheses will then be distilled out of them.

5.2.1

Scheduling environment

In Chapter 4, especially Section 4.2.1, we have seen how design considerations normally outside the scope of the scheduling engineer have an important impact on the performance of the system as a whole. The generic rule “get information early, decide late” could be applied to elevator dispatching as well: Conventional control deals with elevator systems where the traveler calls an elevator by pressing a button corresponding to the desired travel direction. In destination control, the traveler calls an elevator by indicating his desired destination floor; he is then immediately directed to a specific elevator by the dispatching system. Conventional control allows for late decisions: the passenger does not wait for a specific elevator, so all elevators are eligible to handle this passenger. Decisions upon a specific assignment can be altered until an elevator finally brakes to pick up the passenger, by which time the assignment cannot be canceled anymore. Destination control, on the other hand, facilitates getting information early. This leads to a better informed system. An alternative could be a combination in which a conventional control system is augmented by destination control keypads. This is not implemented in reality as of yet. The resulting system would benefit from both early information and late decisions, but not from individual car assignments. Future systems, in which the passenger could be assigned to a specific elevator at the latest possible moment, just prior to boarding (e.g., via a smartphone) might increase the performance even further. Other possible future systems could try to be even earlier-informed than destination control. For example, personal tags that people have with them - e.g., for building security - may be read by devices in the corridors and halls. This could allow the elevator system to make guesses about hall calls in the near future, as well as likely destinations for the people behind those calls. The particular advantages of alternative setups are expected to play a larger role as the traffic intensity increases. In heavier traffic, elevators will become more

Introduction to elevator dispatching

106

crowded, and the disability to group people will hamper performance increasingly. Also, in heavier traffic, waiting times are longer, which increases the chance that an assignment recall would be profitable. This will disadvantage setups in which decisions have to be made early. The first general research hypothesis is: RH1: Elevator performance increases when information is provided earlier or more detailed, and when the timing of assignment decisions is more flexible. This plays a larger role as traffic pressure increases.

5.2.2

Heuristic interaction

When heuristics are used for problem solving, there is an intricate relationship between the algorithm, the design of the search space and the objective function. This is the main concern of the building block about heuristic interaction (BB 5, Section 4.2.5). In Section 5.1.5 we have seen that for elevator dispatching, the set of all possible solutions in the case of medium to heavy task pressure, cannot be exhaustively searched. Fine-grained local searchers like greedy ascent, 2/3-opt and tabu search typically stay close to the current solution. On the other hand, a coarsegrained heuristic like evolutionary algorithms, can take a broad sample of the search space. Even with limited search time, final solutions obtained with such approaches can lie far from the current solution. In elevator dispatching, little time is present to perform searching, which makes successfully applying EAs unlikely. Literature, however, suggests that EAs have great benefits for elevator dispatching (Miravete, 1999; Sorsa et al., 2003; Tyni and Ylinen, 2006). The search space is greatly shaped by the objective function. We have seen how it is of utmost importance to incorporate dynamic aspects in the objective functions. However, more aspects play a role elevator dispatching. First, how to balance the tradeoff between focusing on the elimination of extreme traveling times vs. the average performance. Second, some objective functions in the literature focus on the elevator (e.g., using ‘round trip times’ - the time needed for an elevator to finish a circle), others focus on the passenger (e.g., by using average traveling times of individual passengers). RH2: Elevator performance increases when using quick, fine-grained algorithms and neighborhoods, rather than slow, coarse-grained algorithms such as evolutionary algorithms. Likewise, the performance increases using fine-grained objective functions, that are multi-objective, well-balanced, focusing on the individual passenger.

5.2. Research hypotheses

5.2.3

107

Flexibility and robustness

In the building block on heuristic interaction (BB 5, Section 4.2.5), we see that a good schedule should not just be good from the current viewpoint - as if nothing would change anymore. It should in addition be robust and flexible. Robust schedules withstand change events without having to lose performance. Flexible schedules can easily adopt to change events. Since elevator dispatching is a dynamic problem, performance increases are expected when employing such dynamic strategies. For CC, new hall calls and destination calls (when passengers enter their destination) cannot be foreseen. For DC, a hall call is also a destination call, but it’s nature and timing cannot be foreseen. Flexible schedules result in an elevator system that is always ready to pick up and deliver new passengers as quickly as possible. Robust schedules result in currently waiting or traveling passengers that are delayed as little as possible because of new passengers entering the system. Tuning the elevator dispatcher towards more flexible and robust schedules is expected to pay off mostly in the case of medium to high traffic load, since that is the area in which previous schedules are challenged most (Koehler and Ottiger, 2002). Nevertheless, improvement is also expected under low traffic pressure circumstances, since smartly parking idle elevators results in a flexible system that always has a waiting elevator nearby. RH3: Elevator performance increases when the scheduler produces flexible or robust schedules, primarily under medium to heavy traffic pressure.

5.2.4

Hybridization

Approaches that appear advantageous under certain scheduling circumstances, may be outperformed by other in different conditions. It is expected that no single algorithmic setup will outperform all others on all possible cases. The elevator dispatching problem is a typical example of a problem that presents itself in a dynamic manner. Not only do passengers enter the system continually (first-order dynamicity), the traffic patterns of passengers vary over the day (second-order dynamicity). Therefore, no single algorithmic setup can be expected to outperform all others on all specific traffic patterns that present themselves over a day (Muñoz et al., 2008; Kim et al., 1998). RH4: Elevator performance increases when hybridization takes care of second-order dynamicity.

6 Experimental setup Chapter 5 introduced the elevator dispatching problem that is used in this case study. To investigate the research hypotheses that were stated in its last section (5.2), an experimental setup is needed. The first section describes the simulation setup that was used in the experiments. In order to perform realistic experiments, real world traffic data were used in the experiments, and the experimental results had to statistically analyzed. The input data and the analysis are the topic of the last section. In the next chapter (7), the actual experiments are described.

6.1

Elevator simulation setup

To perform elevator dispatching experiments, a simulation environment is needed. A generic simulation environment was programmed in Delphi 1 , which was extended to do elevator simulations. The simulations run on a single processor. Multiple simulations have been run simultaneously during the experimentation phase, using up to 48 processors at the same time. The hardware used consisted of Windows PC’s, with 2.4Ghz Intel Core 2 Quad CPU’s (four CPU’s per computer). The simulation framework was set up as a more or less straightforward discrete event simulation system, in which the operation of a system is represented as a chronological sequence of events. Such systems basically consist of a time line and a number of events. After an event has been handled, the simulator skips instantaneously to the next event - regardless of the simulated time that is between the events (see Fig. 6.1). The building blocks of the system used are: 1 Delphi is an integrated development environment (IDE), using a specific Object Pascal dialect, creating native code for various operating systems. Delphi was formerly developed by Borland, and currently by Embarcadero Technologies.

Experimental setup

110 Initialize SimObjects

Define running time horizon

Delay

Desired run speed Visualization framerate Observed simulation speed

Process time line event Update current time

CurrentTime > horizon

CurrentTime < horizon

(Re)draw SimObjects

Finish simulation

Figure 6.1: Flowchart of the discrete event simulation with visualization. The events on the time line are processed in chunks, delimited by a certain running time horizon. This horizon is the result of a calculation that takes the visualization frame rate and desired running speed into account.

• Simulator - this is the central building block, around which everything is organized. It keeps track off the current time, and calls SimObjects whenever it is their time to ‘wake up’. A while-do loop runs events and updates the simulation time until the simulation is finished. • SimObject - this is the (object oriented) building block that can be any entity that plays a role in the simulation. It can be a physical entity, like an elevator car, or a virtual entity, like a scheduler. SimObjects can post wake-up events for themselves on the time line, after which they sleep until woken up by the simulator. A SimObject can also be woken up by specific calls send from other SimObjects. A SimObject can be in a certain state, and can alter its state. A SimObject can also announce events. Usually, a SimObject performs some operations, then sets a new wake-up event, and goes to sleep. The time needed to perform those operations, however, can be long. In realistic scenarios where processing time is restricted, the SimObject can be set to run for a maximum amount of time after which it can post a new wake-up event that will be at least that maximum amount of time later to continue its operations. By smartly adjusting these parameters, the lower or higher speed of the computer in the actual applica-

6.1. Elevator simulation setup

111

tion that is now simulated, can be accounted for. Using the same mechanism, and by choosing small-enough maximum processing times, parallel processing systems can be simulated using this (single-threaded) framework as well. • Triggers - SimObjects can communicate via a Publish-Subscribe mechanism: They can subscribe to events and state-changes of other SimObjects. When these occur, they are ‘published’, and the event-handlers of subscribing SimObjects are triggered. • Direct calls - in the standard situation, SimObjects don’t (have to) know of each other’s existence, only answering to wake-up calls and subscribed triggers. In specific simulation setups, SimObjects can also directly be linked to optimize their interaction by allowing them to call each other’s functions and procedures, which in some cases is more efficient than Publish/Subscribe. • Visualization - useful for fault-finding and presentations, SimObjects can visualize themselves on a drawing canvas provided by the simulator (see Fig. 6.1, 6.3). To be of any usefulness, this has to be done in a naturally flowing manner: the SimObjects redraw themselves a number of times per second, instead of only answering to wake-up calls. The simulated time can still progress as quickly as possible (hence, only restricted by the processing power of the computer), or it can be set to run at a user-chosen speed lower than the maximum speed, like real-time speed or even slower than that. The visualization can be completely turned off, resulting in a true discrete event simulator that runs as quickly as possible. Running an elevator simulation follows the general rules from the simulation framework, see Fig. 6.2. The building blocks and properties that are important for elevator simulation are implemented as descendants of ‘SimObject’ - but their behavior depends on their specific function. Their specific parameters can be obtained from a log file. The following subsections discuss the various building blocks that are necessary for elevator simulation: the building that contains the elevator group, the elevator car, the elevator doors, the passenger, and the scheduler.

6.1.1

Office building

The Building object is basically a placeholder for elevators and the building-specific information. All elevators will be connected to the building, and via the building to each other. The building also stores the heights of all floors (and thereby automatically the number of floors), and is used for visualization purposes (see Fig. 6.3).

Experimental setup

112 Create SimObjects Create Building, Elevators, Elevator Doors Log file (xml) Create Passengers

Create Scheduler

Initialize SimObjects

Run Simulation (fig. 5.1) calc horizon

Connect SimObjects

event delay

Put passenger SimObjects on time line

parameters update time horizon? (re)draw

Finalize (write analysis files etc.)

Figure 6.2: Flowchart of an elevator simulation run

6.1.2

Elevator car

The elevator car is, next to the scheduler, the most complex simulation object. The parameters for all elevators, which may be different per elevator, are: • The capacity, i.e., the maximum number of people allowed inside the elevator • The jerk of the elevator (change ratio of acceleration) in ms−3 • The maximum acceleration of the elevator in ms−2 • The maximum speed of the elevator in ms−1 • A list of floors that are serviceable by the elevator The speed characteristics of an elevator are depicted in Fig. 6.4. To speed up the simulation, each elevator car calculates a table with the precise durations of travel between any two floors. In the simulation, the elevator SimObject that starts to move can simply post a wake up-event to the simulator that is exactly the duration of travel - after which it can go to ‘sleep’.

6.1. Elevator simulation setup

113

Elevator Simulation Form Pause

Frames/sec:

20

Speedfactor:

1

Visualize Simulated time (h:mm:ss):

9:43:30

Simulated time (s):

35010

Run to:

172800

Speed

Figure 6.3: The actual application with visualization turned on - which plays an important role in verifying the correctness of the simulation. Elevators may be traveling or stopped, doors may be anything between open and closed, while the elevator is at a floor. Diamonds indicate destination floors to be visited by an elevator, hall call floors are indicated by a grey box, both situations coinciding by a black star. The Xs indicate forbidden floors for an elevator. Various visualization options are indicated on the right. Detailed information on the current plan can be obtained by hovering the mouse over an elevator.

A

B

C

D

E

F

G

1 2 3 Time

Figure 6.4: Elevator speed. A normal elevator ride (line 1) between two floors starts with acceleration buildup with maximum jerk (A). The elevator is in maximum acceleration for a while (B), before decreasing acceleration with maximum negative jerk (C). Then it rides a while at top speed (D), after which the same processes run again for deceleration (E, F, G) and the elevator comes to a full stop again. When a fast elevator makes a short ride (line 2), it may not even reach the maximum speed (D) - it will at a lower speed have a longer period of jerk (C and E immediately after each other) where the acceleration is reversed into deceleration. The ride could even be so short that the elevator does not reach maximum acceleration (line 3), and only experiences (parts of) the four jerk periods A, C, E and G. With a typical jerk of 1ms−3 and a maximum acceleration of 1 ms−2 , this would amount to a travelled distance of 2 meters - which is below the normal distance between two floors. Note that in this diagram, the distance travelled corresponds to the area below the line.

Experimental setup

114

In addition to the travel times table, decision moments are calculated that for any two floors determine the point in time after the movement has been started that a decision has to be made whether or not to stop at a certain floor. Often during an elevator ride, the elevator will stop at a floor that was not its original intention when starting the movement. If an elevator has to make an early stop, this decision has to be taken before the decision moment for that particular floor. After that, even when applying full deceleration, the elevator will overshoot that floor. Analogously, the decision of making a longer ride than originally intended also has to be made before the decision point of the original destination. After that moment, the elevator has started braking, and it will have to complete its original trip before being able to move elsewhere. Floors in the building may only be served by a subset of elevators. More complex schemes may exist where elevators have doors on more sides, and access to parts of the floor reachable by that specific door may be restricted. So for each elevator, a table of possible stopping sides and positions is loaded prior to starting the simulation. The elevator car SimObject is connected to the scheduler, from which it receives its assignments. The scheduler can also ask the elevator car to provide its current whereabouts and the first possible floor at which a stop is possible. The elevator car SimObject has subscriptions to entering and exiting events of all passengers that are allocated to that elevator. Each time it receives such an entering/exiting signal, it will make the doors stay open for a longer period of time, and it will update its current passenger count. The elevator has a subscription to its doors to receive a message when the doors have been fully closed - when the elevator could start moving to its next floor, if any.

6.1.3

Elevator doors

The doors of the elevator open upon arrival, stay open for some period of time, then close. For each set of doors for each elevator, parameters are loaded from the log file that specifies • The time needed to open the doors. • The minimal amount of time the doors will stay open, • The time needed to close the doors. In addition to this, the doors will stay open an extra amount of time for each passenger that enters or leaves the elevator. For this simulation, that amount of time was set to 1 second. The elevator notices passengers entering and exiting the elevator, and will postpone the time at which the doors will start closing accordingly.

6.1. Elevator simulation setup

6.1.4

115

Passenger

A passenger SimObject is created at the start of the simulation for each individual that is listed in the log file. For each passenger, the log file specifies the call time (with an accuracy of 0.1 second), the origin floor and the destination floor. The passenger will post a wake-up event to the simulator’s timeline for his call time. He ‘goes to sleep’ until then. All passengers are linked to the scheduler. When woken up, the passenger will send his travel request to the scheduler, change his status to ‘waiting’, and go to sleep again. The scheduler, after having decided the allocation of that particular passenger to an elevator, will connect passenger and elevator. The passenger subscribes to the arrival events of the elevator, and when the floor matches his origin or destination floor, he will enter or exit the elevator. Upon entering, the passenger changes his state to ‘traveling’, and after exiting to ‘finished’. The passenger keeps track of the times on which he enters and exits the elevator. At the end of the simulation, this information is gathered and written to result-files that can later be analyzed.

6.1.5

Scheduler

The scheduler is the most important SimObject of this study. The scheduler has to, most optimally, allocate passengers to elevators and orchestrate elevator rides. Passengers connect to the scheduler directly to make their traveling wish known. The scheduler is connected to all elevators, and also keeps track of their (current) schedules internally. The scheduler could be set to use a maximum amount of scheduling time, such as 0.1 second. After the 0.1 second, the scheduler has to return control to the simulator. When the calculations have not been finished, it can post a wake-up event exactly 0.1 second later. The scheduler can then continue its calculations. However, the world may have changed since the previous time slot: elevators may have moved, passengers may have called, entered or exited elevators, etc. In Destination Control (Section 5.1.1), passengers enter their destination on a keypad instead of pressing an up or down button. The scheduler then has to communicate an allocation to the passenger within a very short period of time, that has been set at 100 milliseconds according to the literature (Koehler and Ottiger, 2002). Of course, the order in which that elevator will serve its calls may change while the passenger is waiting, but the scheduler has to move within the play field that results from the fixed passenger allocations. For a few experiments that will be marked as such in the following chapter, the 0.1 second restriction has been relaxed.

Experimental setup

116 Original

Alt. A

Alt. B

9 8 P4

7 6 1

2

P3 P2

3 ...

5 4 3 2 1 0

P1

Figure 6.5: Example: Elevator circles as a form of abstract encoding. An elevator moves in imaginary circles when picking up and delivering passengers. Passengers P1 , P2 , P3 were already known, and were served using the original plan, all in one circle. Passenger P4 is a newcomer. Plans A and B serve as alternatives to the original plan, and are discussed in the text.

Encoding Within the scheduler SimObject, an important role is played by the encoding of the solution. In Chapter 4, in the building block on abstract solution encoding (BB 3, Section 4.2.3), designing a good, abstract solution encoding was stated as an important prerequisite to creating a good scheduling system. As we have seen in that building block, such an encoding facilitates scheduling in general by enabling the design of better neighborhood structures. Also, it facilitates the use of different scheduling algorithms. Therefore, the design of the solution encoding for elevator dispatching receives extra attention here. In the example depicted in Fig. 6.5, we see one elevator that is currently serving three passengers, P1 , P2 , P3 . P1 goes from 0 to 5, P2 goes from 3 to 9, and P3 goes from 4 to 6. In the original plan, those passengers are all served in one round. Using ‘permutation representation’, this plan is represented as a string of locations: [0, 3, 4, 5, 6, 9] When a new passenger P4 calls for the elevator to go from 7 to 3, an alternative plan has to be created. The most easy way to do this is put the passenger behind the previous passengers, resulting in alternative plan A: [0, 3, 4, 5, 6, 9, 7, 3] We could also start with P1 , then do the new passenger P4 - doing the remaining P2 and P3 afterwards. This results in plan B:

6.1. Elevator simulation setup

117

[0, 5, 7, 3, 4, 6, 9] which has actually fewer stops. The example shows that inserting a new passenger into an elevator plan takes some work: we have to determine when the elevator in its current plans is going in the same direction (it may have multiple legs). Then the correct insertion point for the origin floor has to be determined. After that, the correct insertion point for the destination floor must be determined. Overseeing the plan to gather the different possibilities of inserting a passenger is not straightforward. One can quickly see that if insertion of a new task costs all this effort, certainly determining a neighborhood of solutions in which passengers are shuffled to other positions in the plan might cost a large amount of calculations. Nevertheless, permutation representation is the chosen method for the majority of solutions found in the literature (Miravete, 1999; Koehler and Ottiger, 2002). In this study, however, a new circle representation was used. It consists of a mapping from passenger to circles. As the figure shows, an elevator moves up and down in imaginary circles. When passengers are mapped to circles, the original plan takes the following form: [P1 : 1; P2 : 1; P3 : 1] The alternative plan A would be [P1 : 1; P2 : 1; P3 : 1; P4 : 1] and the second alternative plan B would postpone 2 and 3 to the next circle: [P1 : 1; P2 : 2; P3 : 2; P4 : 1] Using this encoding, plan modifications can easily be made, at lower computational cost. Converting such a plan to the actual output encoding that is needed by the elevator system (a permutation representation), is a straightforward process. Furthermore, this passenger-circle mapping led to an ideal chromosome mapping for use in evolutionary algorithms, next to being straightforward for use in other search algorithms. Using the circle representation, no specific evolutionary operators had to be designed in order to fix the errors introduced by the evolutionary process (see Section 4.2.6 for an elaborate discussion on this topic). This makes the circle representation fit very well into a multiple-algorithm system. An added, unintended, advantage of the circle representation is that is easy to comprehend for a human observer, unlike the permutation representation. This greatly helped in run-time analysis of the simulation by hand, especially when compared to the permutation representation that had also been implemented in an earlier phase of the study.

Experimental setup

118

Incoming, internal and outgoing passengers per 15-minute time slots 600

Number of passengers

500

400

Out Intern In

300

200

100

0 0

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

Time (hours)

Figure 6.6: Overview of passenger amounts in the Paris log file used over the day, per traffic type. The passenger amounts are given per 15-minute time slot.

6.2

Data and analysis

The company Schindler Elevators Ltd. (Ebikon, Switzerland) was kind enough to provide full information on a specific (non-disclosed) building in Paris, France. This log file is introduced in the first subsection. The experimental design is pairwise comparison. For that purpose, specific methods for statistical analysis are needed, which are discussed in the second subsection. This chosen method demands a larger data set than the single log file provides. Therefore, several methods were investigated to increase the data set, which is discussed in the third subsection.

6.2.1

Input data

The study was carried out using a log file that was generated by the Schindler Miconic 10 Destination Control installation present in an undisclosed Paris building. As a destination control system, it has precise knowledge of all passenger movements. The log file specifics are outlined in Table 6.1. Fig. 6.6 gives an overview of passenger amounts during the day per traffic type. Incoming traffic enters the building using the main lobby, and goes to any floor from there. Outgoing traffic comes from any floor, and goes to the main lobby. Inter-floor traffic is all other traffic. As stressed in the proposed building block on Realism (BB 2, Section 4.2.2), such a log file provides us with a building scenario that is more realistic than self-generated

6.2. Data and analysis

119

Table 6.1: Overview of Schindler log file specifics

building location number of passengers number of elevators elevator speed elevator acceleration elevator jerk door opening time door closing time min door open time max passengers / car floor height (all floors) number of floors specialities

saturation point (see text)

Paris 11524 6 2.5 ms−1 0.9 ms−2 1.0 ms−3 2.5 s 3s 1s 19 3.5 m 17 only 2 of the 6 elevators serve the 2nd floor; the main lobby is the 3rd floor instead of the ground floor. 270 passengers / 5 minutes.

passenger files often found in elevator scheduling literature (Muñoz et al., 2008; Nikovski and Brand, 2003a; Kim et al., 1998; Crites and Barto, 1996). The figure on the loose insert coming with this dissertation (original vs. equal traffic types) shows how incoming passengers do not present themselves in a Gaussian fashion. Except for the main lobby (3rd floor in this case), passengers often present themselves in groups, which can be seen as sudden bursts of waiting passengers, preceding and preceded by long periods of an almost constant amount of waiting passengers. The Schindler log file represents a large office building during a normal workday. For such a building, seasonal differences do not play a large role: the same amount of people require vertical transport both in winter and summer. Furthermore, days with more traffic may be possible, due to meetings or conferences; and days with less traffic are possible, for example in the weekend. However, the log file represents the typical situation, for which it is important that the scheduler yields a good performance. In personal correspondence, a Schindler representative stated the traffic pressure around noon as ‘very challenging’. Figure 6.6 shows that the log file poses a variety of traffic mixtures, under varying traffic loads. In this case, it can easily be seen that the morning is dominated by incoming traffic, the afternoon by outgoing traffic. Between about 11am and 1pm, there is intense mixed traffic. Lighter traffic conditions are before 8am and after 6pm. In between those periods, the traffic has medium pressure, of varying mixture. Therefore, the log file as a whole does not just represent a typical full day, but various periods during that day can represent specific traffic types. This makes it possible to analyze the performance of schedulers under a widely varying set of circumstances.

Experimental setup

120

Performance vs. crowdedness Comparison between conventional control and destination control 60

40

20

0 0

50

100

-20

150

200

av waiting av total W10% waiting W10% total av waiting av total W10% waiting W10% total

-40

-60

-80

Figure 6.7: Comparison graph for two approaches. This figure is similar to Fig. 5.4, but in this case the respective values taken from two approaches are subtracted. Values above the line y = 0 indicate a better performance for conventional control, and vice versa. A further enhancement of this graph is to show the differences in percentages, which tend to be more constant in a performance vs. crowdedness graph (not shown).

6.2.2

Performance evaluation

In order to know whether a certain approach yields a performance increase as compared to another approach, pairwise comparison is done, and is introduced in the first subsection. To assess the performance of an approach for specific traffic circumstances, one has to somehow zoom in on those circumstances, which is discussed in the second subsection. 6.2.2.1

Pairwise comparison

Obviously, the performance of a certain scheduler can best be assessed by comparing it to another approach. Such a comparison can be made by subtracting the relevant values: scheduler 2 minus scheduler 1; or by dividing approaches, to get a fractional increase or decrease: scheduler 2 divided by scheduler 1. The ‘relevant values’ can be anything mentioned in Section 5.1.3 on optimality criteria: average total time, worst10-percent averages, etc. It could also result in any one of the graphs mentioned there. However, in this case, the subtracted values zero out on equal performance. Values below zero indicate a better performance for scheduler 2, and vice versa. Fig. 6.7 gives an example of such a graph, in analogy to Fig. 5.4.

6.2. Data and analysis

121

Total travelling times, comparison between Conventional and Destination Control

300

Conventional Control, total time (s)

250

200

150

100

50

0 0

50

100

150

200

250

300

Destination Control, total time (s)

Figure 6.8: Cloud of dots depicting the difference in performance of two scheduling approaches. Each dot represents an individual passenger. On the Y-axis is the passenger’s total time when traveling with a conventional control system, the X-value is the total time when traveling with a destination control system. A dot on the line x=y shows a passenger with equal traveling times in both systems. The other lines shown represent 10% deviations from neighboring lines. As the (broken) regression line shows, the performance of the destination control system was on average almost 20% better than the conventional control setting.

Experimental setup

122

Other than calculating averages to assess the performance, all passengers can be treated individually, depicted in a cloud of dots, where the x-axis represents the passenger’s value under the regime of the first approach, and the y-axis to the value from the second approach (e.g., Nikovski and Brand (2003b)). Any dot on the line x=y represents equal performance: the passenger travelled equally long under both regimes. Below the line is better for the second scheduler and vice versa. Such a graph gives an intuitive presentation of the differences between two schedulers (see Fig. 6.8). However, as the example shows, the performance for a single passenger can differ greatly between two scheduling approaches. Moreover, a dot cloud with >10000 dots makes it difficult to see that the bulk of the passengers are in the central area, and only the ‘few’ separately distinguishable passengers attract attention. Therefore, only by using regression analysis can the real differences been obtained, which makes this method less practical than the type of graph as shown in Fig. 6.7. 6.2.2.2

Evaluating types of traffic

Since a passenger log file is used that poses a variety of traffic circumstances, evaluations can be made that zoom in on specific circumstances. This not only facilitates the analysis of schedulers, it also helps in finding the best scheduler for a specific type of traffic. Literature suggests that different schedulers may perform best in different circumstances (Muñoz et al., 2008). When the ideal scheduler for any type of traffic is known, a dynamic hybridization can be created in a manner proposed in Section 4.2.4. Such a hybridization switches algorithmic approaches on the fly, to always use the most appropriate approach under any given circumstance. Within the elevator scheduling literature, there is a general consensus on ways to characterize traffic patterns (see Section 4.3). In this study, comparisons were made on various levels: • Using the average waiting or total time, for the entire day; using the worst-10percent average waiting and total times for the entire day. • Splitting out these values for Low, Medium and High traffic pressure. • Splitting out these values for traffic episodes that can be distinguished using a tuple . For each of the values, again, a value of Low, Medium, and High is possible. This leads to 27 possible traffic situations, e.g., . The distinction between Low, Medium and High varies for each building and elevator system. For the building and system used in this study, pilot experimentation was performed to obtain these values. A stress-test was conducted in which the

6.2. Data and analysis

123

amount of passengers was gradually increased over time. The crowdedness would be constant for 30 minutes, after which it would be increased with 10 passengers per 5 minutes2 . The scheduling algorithm used in this test is one of the best destination control schedulers found in this study. Passengers were generated randomly at an interval according to the current rate, with 1/3 of the passengers incoming, 1/3 outgoing, and the remaining 1/3 inter-floor. All restrictions where in place, and the floor populations where equal to those found in the Schindler log file. Although passengers do not normally present themselves in Gaussian intervals (see Section 6.2.1), this test gives a rough estimation of the transportation capacity of the elevator group. The stress-test would continue until a traffic density occurred in which more passengers arrive than can be handled by the system. This is characterized by a sharp increase in the amount of passengers that have to re-issue their hall call as they are left behind when full elevators leave, and consequently a sharp increase in passenger waiting times. The saturation point thus found was 270 pass/5min. The boundaries between Low, Medium, and High were set at 1/3 and 2/3 of this point, respectively (i.e., 90 and 180 pass/5min, respectively). These boundaries are useful for a general distinction of Low, Medium and High traffic, and were used as such. However, it is unlikely that a specific traffic direction, such as outgoing traffic, ever reaches such a High level. Therefore, the traffic boundaries that were used in the tuples were again divided by 3, resulting in boundaries that were at 1/9 and 2/9 of the saturation point (i.e., 30 and 60 pass/5min, respectively). Preliminary experiments have shown that these values were appropriately distinctive.

6.2.3

Statistical significance

The proposed building block on realism measures (BB 2, Section 4.2.2) not only prescribes using real world data instead of benchmarks, but experimental results should be provided that are statistically relevant. In order to state that a certain algorithmic setup ‘performs better’ than another one, statistical tests have to be performed. This subsection shows that a number of problems might occur when just using the single obtained passenger log file. An alternative test method uses a set of data consisting of 30 different building days, each simulating the arrival times, origins and destinations for a large number of passengers. The method used to simulate these 30 days, based on the original log file, is described in the second paragraph. The last paragraph discusses what constitutes statistical significance in this study. 2 The crowdedness measure used throughout this dissertation states passengers per 5 minutes, #pass/5min

Experimental setup

124 Passenger frequency vs. time difference

3000

Number of passengers within range

2500

2000

1500

1000

500

0 -200

-150

-100

-50

0

50

100

150

200

Total time difference (s)

Figure 6.9: Histogram depicting performance difference frequencies. The total time for all (simulated) passengers in a conventional control (CC) setting are subtracted from the time in a destination control (DC) setting. The results are put in 10-second ranges. The number of passengers in a certain range is shown. The average difference is -10.3 seconds (the destination control setting being the better). The standard deviation (SD) is 32.6 seconds.

Statistical test with a single log file In this study, a large number of experiments has been carried out. Statistical significance is usually indicated by posing a binary statement and an expression like ‘p < 0.05’, indicating that the probability of the statement being attributable only to chance is smaller than 5%, which is, by consensus, considered statistically significant. Using a single passenger log file, a straightforward paired t-test can be performed. The same log file day is then run through the simulator using two different scheduling algorithms, say A and B. Afterwards, for each passenger in the logfile, two total time values are known, one for A and one for B. These paired values are input for the paired t-test. However, there may be some problems with performing this test: 1. As shown in Fig. 5.3, the values from which the average is obtained are not normally distributed. When comparing the individual passenger’s performances on the two schedulers, a histogram can be created as depicted in Fig. 6.9. However, this again results in a non-normal distribution. The same also followed from analysis of the amount of values that fell within the two and three SD range. 2. Although passengers by themselves are independent, their performance values may be dependent on other passengers (e.g., your performance in a crowded period is dependent on all those other passengers). Independency of samples is another requirement for significance tests.

6.2. Data and analysis

125

3. When subtracting the values for individual passengers using different schedulers, to obtain a distribution such as seen in Fig. 6.9, it would be impossible to perform calculations on the worst-10-percent values. Those cannot be compared using a within-subject measurement: passengers that were in the worst10-percent group using scheduler A, may have had a good performance with Scheduler B and vice versa. The first two problems would pose a problem to using a standard t-test. However, the dependency of passengers over the day as a whole is very small, and the data set is very large (11000+ passengers). The central limit theorem states that, under these circumstances, a normal distribution can be assumed and the standard t-test can still be performed. However, the last problem shows that using a single passenger log file is insufficient to assess the statistical significance of all the differences we want to assess. The worst-10-percent values can only be calculated by running simulations over a larger number of different simulation days. Furthermore, such an alternative test would back up the analyses that are performed using the single logfile test. If we had 30 different building-days, that could be tried both on scheduler A and B, a paired t-test can be performed as usual: For each day, average performance differences are calculated, leading to 30 pairs of average values, that are indeed normally distributed. In this case, the null-hypothesis is that algorithm A and B perform equally well. This hypothesis can be rejected if the average performance difference of A and B is sufficiently far away from 0. ‘Sufficiently’ meaning that it is unlikely (p < 0.05) that the difference found can be attributed to chance3 . Realistically simulating passengers The dataset of one simulation day was used as a basis to create 30 different simulated days, that are somehow based on this original log file. The number 30 was chosen since it was large enough for statistical relevancy, yet small enough to make running the desired experiments computationally viable. A number of operations on the original log file was tried to create the 30 different (new) passenger log files. Since no such operations are described in the literature, the methods were still to be 3 The more colloquial notion of ‘significance’ relates to the size of the difference found, not to the question whether this difference is attributable to chance. For some experiments in the next chapter, only small performance differences were found, but of statistical significance. One could state a certain threshold that deems performance differences of, e.g., below 1%, ‘insignificant’. However, all such values are highly arbitrary. Moreover, for the field of elevator dispatching, no such value can be found in the literature. Actually, from personal communication with elevator experts at Schindler, I have found that even small (≈1%) differences are hailed as successes within this field. These differences are considered the stepping stones upon which to further innovate. Also, combining techniques that in themselves lead to only small differences can make a large difference together. Because of this, no minimum performance difference is used throughout this research. However, in cases where the difference is very small or large, it will be remarked.

126

Experimental setup

designed. 4 methods were investigated, for which algorithmic pseudocode is given in Appendix A, in Section A.1: • Shuffle all: From an original passenger log file, a new file is created by changing the call time of all passengers. The call time was randomly shifted to a new value within a interval. The advantage of this method is that the character of the day is maintained (same peaks, same origin-destination pairs, same types of traffic at the same times). The disadvantage is that groups of passengers traveling together are diffused over a longer period of time. The typical ‘bursts’ of passengers seen in the original files are gone (for examples of such bursts, compare ‘shuffle all’ and ’original’ in the figure in Appendix ??). • Shuffle 1%: This method is the same as shuffle all, except that for only 1% of (randomly selected) passengers, the call time is changed. The advantage is that the bursts are maintained as well, the disadvantage is that the days are very similar. However, it is expected that a small disturbance at the beginning of a simulation, causes very different elevator runs for the rest of the simulation. This would still result in very different simulation days. • Modeling: a new log file is created in which an equal number of passengers occurred as in the original. The original file can be seen as a set of time intervals that start at the call time of one passenger and end at the call time of the next passenger. When creating new passengers, one such interval was selected at random, and a call time was picked at random within this interval. For this passenger, an origin and destination were selected by randomly selecting a passenger from the original file, that occurred within a interval of the newly created call time. This way, a completely new file was created, that nevertheless resembles the original strongly. The advantage is greater randomness than with shuffling methods, the disadvantage is that still no passenger bursts occur. Attempts at realistically modeling such bursts did not succeed, nor were descriptions of similar attempts found in the literature. • Equal Traffic Types: same as Modeling in the choosing of call times, but the origin and destination of the newly created passenger is picked at random, such that one third of the passengers was incoming (entering the building via the main lobby, going to any other floor), one third was outgoing (exiting the building via the main lobby), and one third was inter-floor (between any two floors except the main lobby). This is the method of which variants are mostly seen in literature, and that was hypothesized to be of less use than realistic data.

6.2. Data and analysis

127

A graph depicting a small portion that resulted from these approaches, including the original donor log file, is included as a loose insert. Evaluation To test the methods described, for each of these approaches, 100 new log files were created, that were used for a small number of experiments, using two pairs of different schedulers. The first pair differed heavily, so that clear differences had to be found. The second pair differed slightly, and only differences on the border of being statistically significant were expected to be found. The elevator movements of one such experiment are visible in the figure on the loose insert as well, as colored diagonals running along the graph. These pilot experiments resulted in the following observations: • The shuffle all, shuffle 1% and modeling approach were similar in results: the averages for diverse traffic types were similar, as were the standard deviations from the mean, and the same significancies or insignificancies were found in all of these experiments. • Using the equal traffic types approach, the same algorithmic approaches were found to be significantly equal or different, compared to the results obtained with the former three approaches. However, the averages that were found when splitting out traffic types as described in Section 6.2.2.2, were different from the other three, and the statistical tests performed to obtain significancies on these specific traffic types differed greatly from those found using the shuffled or modeled files. Furthermore, visual inspection of the graph (see the loose insert) clearly shows a completely different pattern of elevator movements. Instead of elevators making both small and large jumps, overtaking each other, etc., the elevators seem to run up and down as ‘all stations services’, even more or less staying in the same position with regard to each other. • For the modeling and shuffle all approaches, visual inspection of the elevator movements using graphs such as the one given shows that they were similar. • For the shuffle 1% and original file, visual inspection shows a great similarity in type of elevator movements. The disturbances created by the relatively small amount of passenger disruptions in the shuffle 1% approach are apparently so big that completely different ‘elevator days’ are obtained: the spreading in performances corresponds to those found when using randomized data (equal traffic types). However, the original characteristics of the log file provided by Schindler were preserved as much as possible, including the

128

Experimental setup

‘passenger bursts’: a group of passengers travelling together, leading to a sudden, sharp increase in waiting passengers, see the Appendix figure for original and shuffle 1%. These findings have led to the use of the shuffle 1% option to create 30 new passenger files to use in the statistical significance tests in the next chapter. Summary Performing a paired t-test using a single passenger log file that has been used as input for simulations of two different schedulers, is argued to provide useful results. In order to back these results, and to perform tests on specific traffic types and measurements (such as the worst-10-percent values), a large dataset consisting of more passenger log files is needed. From various methods to simulate passengers based on the original Schindler log file, the Shuffle 1% method was chosen. This methods produces log files that lead to test results that are sufficiently spreaded, yet maintaining the characteristics of the original file best. Using this method, 30 different new log files were created. Averaged results from running these logfiles on different schedulers, again are used in paired t-tests throughout the next chapter.

7 Experiments In Section 5.2, four research hypotheses (RH) have been stated for the elevator dispatching domain. This chapter presents their refinements (operational hypotheses), experiments and results. For each of these four research hypotheses, this is done in a separate section in this chapter. 1. Section 7.1 addresses alternative control paradigms in elevator dispatching, thereby addressing RH 1. 2. Section 7.2 addresses the balance in the heuristic triangle, paying particular attention to evolutionary algorithms (RH 2). 3. Section 7.3 addresses robustness and flexibility (RH 3). 4. Section 7.4 addresses hybridization (RH 4). These sections all have the same structure: after an introduction, the subsequent subsections cover operational hypotheses, experimental setup, results and discussion. Chapter 8 will provide a more general discussion based on the findings in this chapter.

7.1

Alternative control paradigms in elevator dispatching

In Section 4.1.2.1, we have seen how information that is provided by the scheduling environment, and the timing of decision making, plays an important role in the scheduling process. Research Question 4 (Section 4.1.2.1) asks to what extent changes in the environment play a role in the scheduling performance. Section 5.2.1 specializes this for elevator dispatching in particular. Research Hypothesis 1 states that

Experiments

130

“Elevator performance increases when information is provided earlier or more detailed, and when the timing of assignment decisions is more flexible” This hypothesis can be tested by investigating three different elevator dispatching modes, that differ in the timing of information and decision: • In Conventional Control (CC) the decision can be made late, but the information is late as well. • In Destination Control (DC) the decision has to be made early, but the information arrives early as well. • In a special Cheating Destination Control (CDC) setup, the decision can be made late, and the information arrives early. These dispatching modes are used to derive operational hypothesis. The next four subsections outline the operational hypotheses for the tests, the experimental setup, the results and the last subsection discusses the findings.

7.1.1

Operational hypotheses

7.1.1.1

Destination control vs. conventional control

The difference between CC and DC, from the viewpoint of Research Hypothesis 1, is mixed: on the one hand, CC is free to decide late, but has information coming in late as well. However, there is another difference: DC is able to address passengers individually. The possibility to recall an earlier decision - which is impossible in DC - is expected to only play a role in heavier traffic. In these circumstances, the waiting time for a passenger increases, and thereby the chance that the scheduler would like to reconsider the earlier assignment. However, in heavy traffic, CC will often pick up multiple passengers at a hall call floor, who will only then make their destination known. This leads to many unforeseen extra stops, which in turn makes it likely that earlier assignments become suboptimal. In short, the possibility to recall earlier assignments is needed much more in CC than in DC, to cover up the lack of information availability. Furthermore, especially in heavy traffic, DC has the unique availability to group similar passengers, thereby reducing the number of stopovers the system as a whole has to make, as well as the round-trip-time (RTT) for all elevators. Combined, therefore, the early information and the individual handling of passengers of DC, are expected to outweigh the possibility to make late decisions

7.1. Alternative control paradigms in elevator dispatching

131

in CC. In this case, we do not just expect statistical significance in the performance differences, but a large performance increase (≥5%) as well1 : OH1.1: DC outperforms CC, by at least 5%. OH1.2: DC outperforms CC increasingly as traffic pressure increases. On a side note, worse waiting times are expected for DC when compared to CC. This is due to the fact that in CC, any elevator that serves a certain floor in the right direction is a candidate for waiting passengers to get in, thereby increasing the chances for a passenger to be picked up quickly. In DC, on the other hand, they have to wait for their one dedicated elevator. Once inside, however, they travel to their destination faster. OH1.3: CC outperforms DC with respect to waiting times. 7.1.1.2

Cheating destination control vs. standard destination control

Being able to decide late increases scheduling flexibility. To test just this effect, a cheating destination control (CDC) setting can be used. In that setting, the passenger gets his elevator assignment just prior to boarding, instead of immediately. Although the previous paragraph argues this positive effect of such a postponed decision to be much larger for CC, it will play a role in DC as well. The effect, again, is expected to increase as the traffic pressure increases: in those situations, an assignment choice made at hall-call time is challenged more heavily as it will usually be challenged for a longer period of time, and it will also be challenged more often as the rate of change events (new passengers entering the system) increases. The more heavily challenged, the bigger the chance that the original assignment is found to be less preferable. When this assignment can be undone, such as in the CDC case, it is expected to yield better performance values. Again, the difference is not just hypothesized to be statistically significant, but large as well (≥5%), especially in the case of heavy traffic: OH1.4: CDC outperforms DC, by at least 5%. OH1.5: CDC outperforms DC increasingly as traffic pressure increases.

7.1.2

Experimental setup

To test the operational hypotheses, a number of experiments has been set up. In the next four subsections the independent variables, dependent variables, experimental 1 ‘Large’: In personal contact, during an internship at Schindler Elevators, colleagues commented that 1-2% performance increases were already considered important. More than 5% can therefore be regarded as large. Furthermore, most of the more than 3000 scheduling approaches discussed in this dissertation fall within a 25% range from the best performing elevator dispatcher (Table 7.20). Statistically relevant differences started at performance differences of less than 1%, so 5% can from this perspective be regarded large as well.

Experiments

132 design, and the analysis of the results are discussed.

7.1.2.1

Independent variables

The dataset used for the experiments is detailed in Section 6.2. It consists of 30 different days of passenger movements, that have been constructed based on the original log file provided by Schindler elevators, using the method described in Section 6.2.3.

7.1.2.2

Dependent variables

The operational hypotheses ask for an average performance difference in total time (waiting time + traveling time), but also for comparisons of the approaches under varying traffic loads. The classification of various episodes as low, medium, or high traffic is described in Section 6.2.2. Furthermore, since different waiting times were expected to influence the results, the average waiting times over various traffic loads are measured as well. To grasp the improvement of one approach over another, a percentual difference is given with these values as well, as a 95% confidence interval: BestApproach −( WorstApproach − 1) · 100%. 7.1.2.3

Experimental design

To test the operational hypotheses, the simulation test bed described in Section 6.1 has been used in all of the experiments. Three different schedulers have been implemented, for each of the different control paradigms. The design consists of pairwise comparison: two pairs of setups (CC and DC; DC and CDC) are compared. All three setups were kept as basic as possible, closely following literature on the topic. By not applying any algorithmic fine-tuning, the experiments were kept as clean as possible, without the introduction of confounding variables. The three actual algorithmic setups for CC, DC and CDC are discussed in the next three paragraphs.

Conventional control CC has been outlined in Section 5.1.1. When an elevator arrives, as much passengers as will fit in, enter the elevator, provided it is headed for the right direction. Eventual passengers that were left behind will re-issue their hall call. Upon boarding, the passengers enter their destination. The elevator will drop off passengers without detour. The scheduler decides which elevator picks up which passenger group. However, since drop-off floors may coincide with pick-up floors, this decision is sometimes made for the schedulers by the passengers themselves. The allocation of elevators to hall-call floors can be changed at any time, as long as elevators are not already braking for such a floor.

7.1. Alternative control paradigms in elevator dispatching

133

The algorithms in Section A.2 (Appendix), outline the major procedures in the CC scheduler. Obviously, additional constraint checks are carried out as well, such as capacity checks for elevator cars.

Figure 7.1: Elevator distance to hall call (2, 6, and 13, respectively)

The only actual design choice in this setup concerns the fact that a hall call is served by the ‘closest elevator’ (see code), and how that closeness is calculated. This is explained in Fig. 7.1: For each elevator, the current traveling direction and earliest possible stopover are taken into account, from where the distance (in number of floors) to the call is calculated. This is done using extreme values of the building, which is actually a worst-case scenario. For each stop-over that has to be made in the meantime, the distance is increased by 4, which is about the same distance an elevator can travel in the minimum time it takes for a stop-over. Using the current plan of the elevator, the actual distance may be much shorter than this extreme. However, as future reallocations are uncertain, this distance may grow. Furthermore, passengers that still have to enter the elevator prior to serving that call, have an uncertain destination, which is never underestimated by opting for these extreme values. This basic setup was also found in the literature (Jamaludin et al., 2009). Destination control DC has been explained in Section 5.1.1. A passenger indicates his desired destination, and is (almost) immediately assigned an elevator. This assignment cannot be altered. Once the elevator arrives, the passenger enters, and is

Experiments

134

without detour delivered to his destination - with the possibility of extra stopovers to serve others. The algorithms in Section A.3 (Appendix) outline the most important aspects of the DC scheduler, again leaving out constraint checking details. The one design choice made here lies in what is called ‘CalculatePlanFitness’ (algorithm GetPassengerBid). A number of on line fitness value estimations is possible. For the basic setup, the concept of minimizing marginal cost was used. It is calculated for a single elevator: n

Cost =

∑ (ETAi − CallTimei ) f e

i =1

• n is the number of passengers, • ETAi is the Estimated Time of Arrival for passenger i, • CallTimei is the time at which passenger i registered a call, • f e is the fitness exponent, in the standard case this is 2. For the elevator, two plans are used: a new one containing the new passenger, and the original plan. Subtracting the Cost of the old plan from Cost of the new plan, results in the marginal cost for the new passenger if he were to use that elevator. For each elevator, this ‘bid’ is calculated, and the elevator with the lowest bid is assigned the passenger. In words, this bid is a measure of the total time for the new passenger, combined with the increase in total times for all the other passengers. The assignment is made first, since the passenger has to be informed immediately. After that, the optimization step may take time to perform a local search procedure to possibly find better circle assignments using the current building plan as a starting point. The addition of the newly added passenger may lead to another ideal circle assignment. For example, a passenger may be postponed to make room for a newly added group of passengers on his circle. Since the 2-opt local search optimization that was used for this purpose is one of the main topics of Section 7.2, it is treated in detail there. Cheating Destination Control The DC setting can be ‘cheated’ upon: the moment of telling a passenger which elevator to take is postponed until the moment that the elevator has actually arrived. In reality, this is not currently implemented as passengers receive their elevator assignment immediately, and it cannot be changed after-

7.1. Alternative control paradigms in elevator dispatching

135

wards. For research purposes, however, such a setup can easily be simulated2 . The CDC approach was set to ‘cheat honestly’: the approach only makes assignments that would have been possible from the beginning in a normal DC approach as well. This means that a passenger is immediately assigned an elevator, like in DC. This assignment may change. However, the only changes allowed, are those that would also have been possible as an immediate assignment. Example 7.1. Consider two elevators A and B and a new passenger traveling from 3 to 5. Elevator A is currently moving down, delivering passengers to 9, 3 and the Ground Floor. Elevator B is traveling up, currently at the 4th floor, moving upwards to 5, 9, and 13. Elevator B can pick up the new passenger in a future round, but elevator A cannot, since his first stop at 3 is prior to moving down. This would violate the constraint that a passenger cannot move in the wrong direction. In a scenario where the assignment to the passenger only becomes known just prior to boarding, elevator A could indeed pick up the passenger when moving up again. This might be advantageous for the passenger, as elevator B will probably take longer to arrive at 3 in upwards direction. However, in the current CDC approach, a reallocation to elevator A is not possible, since it would not have been possible as an immediate DC assignment. The algorithmic setup behind CDC is equal to the one described in Section 7.1.2.3, but in the optimization step after the assignment, not only alternative circles, but alternative elevators are investigated as well. Thereby, again, the most basic version of CDC has been implemented. 7.1.2.4

Testing

Comparing two different approaches is done using two methods. The first uses the single passenger log file that was provided by Schindler, for a paired t-test. The log file is run using both approaches, the results of which were thus compared. This could be done both for waiting and total time. The results from this test are found in the text. The second test uses the 30 simulated days that were created based on the single log file (Section 6.2.3).The performance differences are calculated performing the paired t-test on the average values that were found by running the 30-day test set on both approaches. Since the latter test has been used for various more specific analyses in this chapter (such as determining worst-10-percent values, Section 6.2.2), the results from this test is found in the tables, and discussed in the text. 2 This CDC approach enables obtaining a (near-)optimal performance characteristic, to which other approaches can be compared. This is useful, since an absolute optimum cannot be calculated (see Section 5.1.5).

Experiments

136

7.1.3

Results

7.1.3.1

Conventional control vs. destination control

A paired test for the original Schindler log file resulted in an average waiting time difference of -8.8 seconds (p < 1·10-232 ), and a total time difference of 4.7 seconds (p < 1·10-47 ). Similarly, a pairwise comparison of 30 simulation days using two different scheduling approaches produces results that are summarized in table 7.1. The first line states the average difference in seconds for each of the traffic types (waiting or total time; under all, low medium or high conditions). The p-value indicates the chance that the finding can be attributed to chance. To grasp the improvement of one approach over another, a percentual difference of the absolute values is given BestApproach as well, as a 95% confidence interval: −( WorstApproach − 1) · 100%. When comparing total times of the CC and DC approaches, CC is clearly outperformed. The average total time for CC was more than 8.0% worse than with the DC approach. However, the waiting times for CC were (much) better than for DC. When looking at traffic pressure, we see that the absolute performance differences increase with increased traffic pressure. However, the percentual difference more or less stays the same. These results do not indicate an increasing percentual performance increase when traffic pressure increases.

7.1.3.2

Destination control vs. cheating destination control

A paired test for the original Schindler log file resulted in an average waiting time difference of 5.1 seconds (p < 1·10-96 ), and a total time difference of 5.5 seconds (p < 1·10-111 ). Similarly, a pairwise comparison using the 30 simulated days produces results that are summarized in table 7.2. The performance differences between DC and CDC first increase from low to medium traffic load, but remain at the same level from medium to high traffic load. When looking at the (absolute) waiting times and total times, we see that almost all of that gain is made during the waiting time, not during traveling time, since the difference values for total time add little to the difference values for waiting time. Only in heavy traffic, a few seconds extra are gained while traveling (although they were first lost while waiting).

7.1.4

Discussion

Conventional control vs. destination control When looking at the results for CC vs. DC, we see that the average waiting times were significantly better in CC. This is consistent with expectations (OH1.3). However, the average total times are significantly better in DC (OH1.1). There is no doubt on the performance advantage of DC

-5.2