Elevator Simulation and Scheduling: Automated Guided Vehicles in a Hospital

Transcription

1 Elevator Simulation and Scheduling: Automated Guided Vehicles in a Hospital Johan M. M. van Rooij Guest Lecture Utrecht University, from x to u

2 The speaker 2 Johan van Rooij current: Consultants in Quantitative Methods (CQM Eindhoven) current: Teacher (Utrecht University) : PhD Computer Science - Algorithms (Utrecht University) : Computer Science / Mathematics (Utrecht University) Consultants in Quantitative Methods (CQM) - Fact based / quantitative approach to improve organization, process and product. - We enjoy QM and want to work in close cooperation with our clients to measurably improve their product or process. - 3 groups: planning, chain management, product and process improvement. - Employee owned - 40 Employees, 60% are in their first job, 35% PhD s - One job: client interaction, model building, and implementation. -.

3 A selection of our clients 3

4 Overview of the Talk Introduction to the client and the problem. A model of the elevator-scheduling problem. Scheduling algorithm 4

5

6 Frog AGV Systems Frog AGV Systems develops Automated Guided Vehicle systems (AGV systems) and navigation hardware and software. They help customers become more productive though logistic solutions that are flexible and reduce cost. Frog AGV Systems constructs the AGV system for a to-be-build university hospital (2016/2017). Experience gained from a similar project in Cleveland. - For this project, there is one important difference: elevators. - Potential bottleneck for the entire AGV system. 6

7 University Hospital Layout 15 January CQM b.v.

8 Some Examples of Material Flows 8

9 Our Solution: Simulation and Scheduling from x to u

10 Simulation and Scheduling Modules High level overview of the software that we produced: - Scheduler module - Simulation module (discrete event simulation) The simulation functions to verify the behaviour of the scheduler. - Scheduler doesn t know everything: only current system status, not what will happen. - Scheduler works in an on-line setting. - Verify the scheduler: are the schedules as expected, are KPI targets met? 10

11 The Model from x to u

12 The Model - Overview Model objects - Elevator tower - Queues Model dynamics - Dynamics for AGV traffic - Dynamics for Elevators - AGV Traffic Decisions made by the scheduler - AGV-queue assignments - Elevator schedules 12

13 The Model 1/7 Elevator Tower One elevator tower (elevator towers operate independently). - Model elements: elevators, floors, distances between floors. Per elevator: - One or two spots for AGVs (next to each other, not in front of one another). - Parameters: speed, acceleration time, deceleration time, time for opening doors, time for closing doors, only empty AGVs allowed yes/no, elevator operational yes/no. Per elevator and floor: - AGV allowed to enter the elevator, AGV allowed to exit the elevator. - If both, then both in one elevator-stop or not. - Parameters: enter time, exit time, time for both exiting and entering. Model s expressive capabilities: - Possible to model elevators that do not stop at all floors. - Possible to model dedicated elevators. 13

14 The Model 2/7 Queues (based on floor plans) Two different kinds of queues: For each floor, there is a queue for each AGV spot in the elevator. - Queue has bounded length (mostly 1 or 2). - For an AGV in the queue has been decided which elevator/spot will be used. - Matrix of travel times from departure points to the front of the queues is given. - When AGV cannot both enter and exit in one stop, the queue blocks exiting AGVs. For each floor, one floor queue. - All AGVs will enter this queue initially (though multiple departure points exist in practice). - Most of the time, AGVs will be directed to an elevator queue. - The front of the floor queue is the decision point for assignment to an elevator queue. - Only AGVs on (or passed) the decision point are known to the scheduler. AGVs cannot pass each other in a queue. 14

15 The Model 3/7 Traffic (based on the traffic matrix) AGV traffic is modelled as a long list of AGV movements. AGV movement: - Entry time (time when the AGV movement enters the model) - Floor of origin and destination floor. - Departure point on the floor of origin. - Cargo type (translated to priority by the simulation). - Empty is a cargo type. - Due time (time at which the AGV is desired to be on the destination floor). This data will be generated based on the traffic matrix. 15

16 Before we continue a little demonstration

17 The Model 4/7 AGV-Queue Assignment The system assigns an AGV to an elevator-queue, constrained by: - The elevator can be entered on the floor of origin and exited on the destination floor. - The elevator must accept non-empty AGVs if the AGV is non-empty. - When there are AGVs in the elevator for which the destination floors do not allow both entry and exit in a single elevator-stop, then no AGV can be assigned to a queue blocking the exit of an AGV in the elevator. An AGV is assigned to an elevator queue when it is on the decision point. - This assignment is permanent. - The scheduler can also assign no assignment. This causes the AGV to wait at the decision point retrying the request for an assignment after a fixed time period. - The scheduler can assign no assignment, only when: No elevator-queues are available (all queues are full, or using them will block AGVs inside the elevator). 17

18 The Model 5/7 Elevator Schedules Elevator schedules are recomputed with every AGV-queue assignment. - Elevator schedules change before they are fully executed. An elevator schedule is a list of elevator instructions: - Go to floor x. - Entry/exit of specific AGVs. The elevator schedule is constrained by: - AGVs only enter and exit the elevator on their floor of origin and destination floor. - AGV can only enter the elevator from the front of an elevator queue, and they can only reach the elevator spot corresponding to this queue. - Moving elevators never change direction. - Elevators containing AGVs never change direction, even after stopping. - Changing the destination floor of an elevator is only allowed when it is not decelerating. 18

19 The Model 6/7 Dynamics for AGV Traffic An AGV in the simulation consecutively has the following statuses: 1. Not yet in the simulation Until the entry time. 2. In the floor queue. Until the AGV is at the front of the floor queue. 3. At the decision point. Until the system assigns the AGV to an elevator. 4. In an elevator queue. At least the travel time. Until we reach the front of the queue. 5. At the front of the queue Until the elevator has open doors and an entry instruction. 6. Entering the elevator. For the duration of the entry (or exit and entry) time. 7. In the elevator. Until the elevator has open doors and an exit instruction. 8. Exiting the elevator. For the duration of the exit time. 9. Blocking the queue. Fixed duration; only if we cannot exit and enter in one stop. 10. Done. 19

20 The Model 7/7 Dynamics for Elevators An elevator can have the following statuses: 1. Standing still. As long as the elevator schedule is empty. 2. Moving vertically. Until the elevator arrives at the destination floor. 3. Opening doors. Fixed time period for opening doors. 4. Entry/exit Entry time, exit time, or exit and entry time. 5. Closing doors. Fixed time period for closing doors. 6. Out of order. Status transitions depend on (changing) elevator schedules. When communicating the elevator status, we include: the related floors (one or two), the time at which the elevator entered the status. Elevators with status 1 will not be repositioned. Elevators with status 6 will not be scheduled. This status will not be used in simulation. 20

21 The Two Modules and the Model The simulation simulates the single-elevator-tower model. The scheduler restricts itself to: - AGV request - System status - Elevator status. - AGVs in the elevator. - AGVs in elevator queues. 21

22 Separate modules, allow multiple uses We used the schedule in three settings 1. CQM one lift tower simulation 2. Transystems whole system simulation 3. Integrated in SuperFrog 22

23 Algorithms

24 Optimization Goals The client wants the system to be robust - Checked by means of simulation We want to maximise the AGV throughput of the system. - That is, get as many AGVs out as fast as possible. - We minimize the sum of the completion times. Furthermore, we want to make sure that AGVs are not late. - Add priority-weighted sum of AGV tardiness as a penalty function. - 1 second tardiness with priority 5 equal to 5 seconds tardiness with priority second tardiness equals 1 second additional processing time for one AGV. Ooh, and don t forget, this is a real-time problem. - We have 0.5 seconds computing time max! 24

25 Algorithms There are two decisions to be made: 1. AGV to queue assignment. 2. Elevator scheduling. - Assuming that all AGVs assigned to a queue (or in the elevator, or... ) We will focus on the elevator scheduling problem first. - Simplified by just computing the fastest schedule processing all AGVs. - Similar to Held/Karp or Bellman TSP algorithm. 25

26 What is an elevator schedule? An elevator schedule is a sequence in which the AGVs are processed. Every AGV once or twice in the sequence: once for loading, once for unloading. - Once if the AGV starts inside the elevator. Such a sequence exactly defines an elevator schedule. Example AGV schedule (AGVs are numbered): 1,2,2,3,4,4,5,3,5. - In this example, AGV 1 is in the elevator at the beginning of the sequence. - Then: unload AGV 1, load AGV 2, unload AGV 2, load AGV 3, load AGV 4, etc. We cannot consider all sequences, - There are simply too many sequences: at least Ω( n! ). 26

27 We consider partial elevator schedules. A partial elevator schedule is the first part of the sequence of an elevator schedule. - E.g., 1,2,2,3,4 instead of 1,2,2,3,4,4,5,3,5. We can extend such a partial schedule to a larger partial schedule by: Loading a new AGV, which is only allowed if: 1. That AGV is at the front of it s queue. 2. The corresponding position inside the elevator is unoccupied. 3. The elevator will not change directions while containing an AGV. 4. The corresponding queue at the destination floor is empty (if required by the layout). Unloading an AGV, is only possible for the AGV inside the elevator that is closest to its destination floor. 27

28 We can exchange equivalent/dominated partial schedules Two partial schedule are equivalent, with respect to what we can do afterwards, if: - The same AGV have been processed by the elevator. - The same AGVs are currently in the elevator. - The last load or unload action occurred at the same floor. Then: any completion of the first partial schedule can also complete the second partial schedule. Example: 1,2,2,3,4,4,5,3 and 1,4,4,2,2,5,3,3 could be equivalent. Observation: 1. We only need one partial schedule per equivalence class (the fastest one). 2. These partial schedules can be computed by bottom-up dynamic programming. 28

29 Dynamic Programming 1. Start with i = 1, and initialise a list with one empty partial schedule of length For every partial schedule of length i-1 in the list: - Compute all possible next actions for this partial schedule. - Add the resulting schedules of length i to the list, but make sure that if two partial schedules are equivalent, then we only save the fastest partial schedule. 3. Set i := i + 1 and repeat from step 2 until we have a list of complete schedules. 4. Choose the fastest schedule from the list. At most O( 2^n * n^2 * floors ) partial schedules -> in practice much less!! - The same AGV have been processed by the elevator (2^n) - The same AGVs are currently in the elevator (n^2) - The last load or unload action occurred at the same floor. 29

30 The queue assignment There are two decisions to be made: 1. AGV to queue assignment. 2. Elevator scheduling (DONE). The algorithm is fast enough to try all possible queue assignments. - For every elevator we run the algorithm max 3 times: without the new AGV, and with the new AGV in the left or right queue. - From this we compile results for all possible queue assignments and pick the best. - Best is using the least time (total time up to now, but we want something different). 30

31 31 Basically this it! Well: what about the real objective function, and the 0.5 sec constraint?

32 Using Pareto fronts to incorporate a different objective function We want to minimise the sum of the completion times, with additional penalties. Two relevant values for a partial schedule: - Total time used. - Total score for processed AGVs: sum of completion times + additional penalties We maintain a Pareto front of partial schedules. - Pareto front per equivalence class in the algorithm. With 2 values this can be done really fast: - k points: amortised log(k) time per addition of a point. - Keep the points sorted w.r.t. one component. 32

33 The algorithm as implemented for the customer. Hard constraint: we need an answer within 0.5 seconds. Dynamic programming is very fast, but scales poorly to many AGVs. - It is an exponential-time algorithm!! The algorithm (for elevator scheduling): 1. Run the dynamic programming algorithm until we obtain a maximum number of solutions. 2. If this does not solve the problem, use a greedy least-slack-time heuristic. 3. Execute a simple tabu search (almost hill climbing) algorithm to quickly improve the schedule. 4. Replace the first k load/unload operations from the tabu-search solution with the best equivalent partial schedule from the dynamic programming phase. 33

34 Results from x to u

35 % AGV traffic arriving in time distribution of tardiness 100% of AGVs arrive on time 35

36 Average time AGV in elevator control system Tower A Average total time in system ~ 65 s Queue time only small portion of total time Time from LSP to queue and elevator travel time are largest portion of total time During peak hours queue time increases so total time increases 36

37 Elevator usage - Tower A (1) Elevator 1 is used most as it has smallest travel time from LSP to front of elevator queue In peak hours ~ 78 % of time elevators are used 37

38 Results Increase traffic by 100% from x to u

39 Increase traffic by 100% - Tower A Challenge to scheduler: 98% of AGVs arrive on time 96 % of high priority food arrives on time In peak hour only 89 % on time Some requests take a very long time (average 97 sec, max 19 minutes) 39

40 Increase traffic by 100% - Tower A During peak hours: - Large increase in queue time - Elevators always busy - Two AGVs in elevator for 20 % of time - Queue at decision point 40

41 41

42 42